The Agentic Leap — Part 6: Agent-to-Agent Communication with A2A
Agent-to-agent communication becomes easier when we stop imagining two human-like personalities having a conversation. Think instead about two independently operated systems exchanging a bounded task, status updates and a validated artifact.
Delegate a task, not unlimited authority. Accept an artifact, not unquestioned truth.Our ASP.NET Core application remains accountable for what it sends and what it accepts back.
Agent2Agent (A2A) is an open protocol for communication between independent, potentially opaque agentic systems. It addresses discovery, messages, stateful tasks, streaming progress and artifacts. It does not require agents to reveal private reasoning or internal tools.
This module targets the current A2A 1.0 specification available at publication time. Version negotiation matters because earlier 0.x examples remain widespread.
1. When delegation crosses a real boundary
Imagine BuildEstate Pro needs a specialist ecology review operated by a separate consultancy. The planning-support agent should not receive the consultancy’s internal tools or prompts. It sends a bounded task and receives progress and an artifact.
BuildEstate Pro A2A client
-> discover verified ecology agent
-> send scoped task
-> receive task ID and status
-> stream/poll progress
-> obtain signed report artifact
-> validate and present for human reviewIf both components are ordinary modules in one application, use a service call. A2A earns its complexity when ownership, deployment, technology or trust boundaries are genuinely independent.
2. Core concepts
- An A2A client initiates communication for a user or system.
- An A2A server exposes a remote agent.
- An Agent Card declares identity, endpoints, interfaces, security and skills.
- A Message is a communication turn containing typed parts.
- A Task is stateful work with an identifier and lifecycle.
- An Artifact is a tangible task output made from parts.
- Streaming and push notifications support long-running work.
3. Discovery and trust
The well-known Agent Card location can describe supported protocols, authentication and skills. Production clients should apply local trust policy:
public sealed record RemoteAgentRegistration(
Uri CardUri,
string ExpectedOrganisation,
IReadOnlySet<string> AllowedSkills,
IReadOnlySet<string> AllowedInterfaces,
string Environment,
bool SignatureRequired);Do not let the model browse for an agent and immediately delegate work. A supplier onboarding process should establish identity, contracts, data handling, service expectations and revocation.
4. Define a bounded task contract
Send only the minimum context the remote agent needs. Prefer references or time-limited access to controlled data over copying an entire project record.
{
"contextId": "planning-review-plot-18",
"message": {
"role": "user",
"parts": [{
"data": {
"projectReference": "BE-1042",
"question": "Identify missing ecology evidence for pre-application review",
"evidenceBundle": "bundle-7f2...",
"deadlineUtc": "2026-09-15T12:00:00Z"
}
}]
}
}Do not send internal access tokens, unrestricted URLs, hidden prompts or irrelevant personal data.
5. Own the lifecycle
A remote task can be submitted, working, waiting for input, completed, failed, cancelled or rejected according to the negotiated contract. Map remote states into an internal state machine rather than displaying raw strings as business truth.
Cancellation is a request with race conditions: the task might complete while cancellation travels. Store both facts and reconcile the final state. Timeouts should stop local waiting but do not prove that remote work stopped.
6. Artifacts are claims requiring validation
An ecology report artifact may be structured data, text or a file reference. Validate type, size, malware status, schema, provenance, signature and access. Treat its narrative as untrusted content when later placed into model context.
The receiving agent must not silently convert a remote recommendation into a BuildEstate Pro command. It can cite the artifact and prepare a proposal for an authorised human.
7. Identity and delegated authority
The remote system needs to know who or what is requesting work, but identity propagation does not automatically delegate every user permission. Establish:
- client application identity;
- end-user context when appropriate;
- tenant and purpose;
- allowed skill and data scope;
- expiry and audience-bound credentials;
- audit correlation across both organisations.
8. Reliability and idempotency
Use a client-generated request identity so retries do not create duplicate consultancy jobs. Persist the remote task ID before losing the response. Apply bounded polling with backoff, or authenticate push-notification endpoints and make handlers idempotent.
public sealed record DelegatedTaskLink(
Guid LocalExecutionId,
string RemoteAgentId,
string RemoteTaskId,
string IdempotencyKey,
DateTimeOffset CreatedAt,
RemoteTaskStatus LastKnownStatus);Messages and events may arrive late, twice or out of order. Version updates or apply monotonic lifecycle rules.
9. A2A, MCP and messaging
| Need | Better starting point |
|---|---|
| Invoke a known internal business operation | typed API/service call |
| Deliver an event or command asynchronously | message broker |
| Discover model-facing tools/resources | MCP |
| Delegate stateful work to independent agent | A2A |
10. Observability and evaluation
Correlate local execution, remote task, messages and artifacts without exchanging private chain-of-thought. Record timestamps, state transitions, skill, protocol/interface version, data classification and validation outcomes.
Test incompatible interfaces, forged cards, expired credentials, duplicate sends, out-of-order events, remote input requests, oversized artifacts, cancellation races and a remote agent that completes the wrong task fluently.
Extended implementation review
11. Specify the delegation contract
A remote agent needs more than a natural-language request. Define purpose, subject, allowed data, expected artifact, acceptance criteria, deadline, budget and cancellation policy. Include correlation identifiers that are meaningful to systems but reveal no unnecessary internal detail.
For the ecology example, the contract might request a structured evidence-gap report for one project version. It should exclude permission to contact authorities or modify the planning record. The returned artifact must identify source documents and distinguish observations from recommendations.
Reject a remote result that does not meet the contract even if its prose sounds persuasive. The local agent can ask for correction within a limit, request human input or terminate as incomplete.
12. Discover and verify remote agents
An Agent Card advertises endpoints, skills, interfaces and security requirements. Retrieve cards from a curated registry or verified domain, validate their schema and cache them conservatively. Pin expected organisation identity and supported interfaces. A card discovered through user-controlled content must not become trusted configuration.
Capability is not competence. Maintain onboarding evidence for each remote agent: contract tests, security review, data-processing terms, performance expectations and a named operational owner. Re-evaluate when the card, model behaviour or service version changes.
13. Map task lifecycles deliberately
The remote lifecycle will not exactly match your internal one. Define mappings for submitted, working, input-required, completed, failed, cancelled and unknown states. Preserve the remote state and timestamp even when mapping it to a smaller local enum.
Out-of-order or duplicate events are normal distributed-system conditions. Apply monotonic sequence or version checks when the protocol supplies them, deduplicate messages and reconcile by fetching authoritative task status. A push notification is a signal to inspect state, not necessarily the state itself.
If the remote agent requests input, validate that the request is within the original purpose. Persist the prompt and response, apply local approval policy and send only the minimum answer required.
14. Artifacts, messages and provenance
Messages coordinate work; artifacts are durable outputs. Store artifacts with media type, size, digest, producer, task ID and creation time. Scan files, validate structured schemas and keep untrusted active content isolated. Never execute a script or follow an embedded instruction merely because it came from a registered agent.
Evidence chains should survive delegation. A local final answer should point to the remote artifact and, where possible, the sources cited within it. Do not present remote model reasoning as verified fact. Mark unavailable or unverifiable sources clearly.
15. Identity, privacy and least disclosure
Use mutually authenticated channels where appropriate and audience-restricted OAuth credentials. The remote system should know the calling organisation, delegated purpose and scopes, but not receive unrelated user claims. The local system remains responsible for verifying that data may leave its boundary.
Classify every part before transfer. Project identifiers, personal data, commercially sensitive documents and geographic information may have different rules. Log metadata and decisions without copying full payloads into telemetry. Define retention and deletion across both parties before production use.
16. Reliability, cancellation and compensation
Use idempotency keys when submitting a task so a network retry does not create two reviews. Bound polling and streaming reconnects with backoff. Persist the remote task ID before waiting for progress. If submission times out with an unknown result, query or reconcile before resubmitting.
Cancellation is a request, not proof that work stopped. Track cancellation_requested separately from cancelled, and decide what happens to artifacts already produced. If the remote task caused an external effect, compensation may require a separate authorised operation.
Set circuit breakers and concurrency limits per remote agent. One failing partner must not exhaust all local workers. Provide a degraded path such as human assignment or a read-only partial assessment.
17. Evaluation and service governance
Evaluate task acceptance, contract adherence, artifact accuracy, citation quality, latency, cancellation, refusal and privacy. Include adversarial cards, mismatched interfaces, a convincing but irrelevant report, duplicate completion events and an agent that asks for data beyond scope.
Operational agreements should name incident contacts, change notification, availability targets, data location and deletion responsibilities. Maintain a kill switch that blocks new tasks while allowing reconciliation of existing ones. A2A makes communication interoperable; it does not eliminate supplier and service management.
18. Worked failure scenario
BuildEstate Pro submits an ecology review with idempotency key eco-42-v3. The connection closes before a response. It must not create another task with a new key. The client queries or retries with the same identity until it learns the remote task ID. Later, completion arrives before a working event. The client fetches authoritative state and ignores the older transition.
The artifact passes schema validation but cites a document outside the agreed scope. Ingestion fails acceptance even though the remote task says completed. The local execution records ArtifactRejected, preserves the digest and requests correction or human review. Remote completion and local acceptance are different concepts.
19. Decision questions
- Is the remote component independently owned and operated?
- Does it perform stateful work rather than expose a simple capability?
- Can its result be validated without private reasoning?
- Are identity, data purpose and retention agreed?
- Are duplicate submission, cancellation and unknown outcomes handled?
- Can the agent be revoked while active tasks are reconciled?
- Is a conventional API actually simpler?
20. User experience across delegation
Do not make users interpret two systems’ state machines. Present a consistent local status such as submitted, working, needs input, completed or unable to complete, while retaining the exact remote state for support. Show which organisation performs the work, what information was shared and when the result was last updated.
If input is required, explain why and where the answer will go. If the remote agent fails, preserve useful local progress and offer a human route. Do not display speculative percentages unless the remote service provides meaningful progress semantics.
Remote artifacts should appear as attributed contributions, not as the local application’s unquestioned conclusion. A qualified user may accept, reject or request correction. Record that decision separately from protocol completion. This keeps human accountability visible when work crosses organisational and technical boundaries.
Accessibility and localisation also cross the boundary. Prefer structured artifacts so the local application can render accessible headings, tables and status in its own design system. Preserve the source language and disclose machine translation. Never trust a remote HTML fragment as ready-to-render interface.
Design and test these cross-boundary behaviours with representative users before release.
Production checklist
- A2A is used only across a justified independent-agent boundary.
- Remote agents are registered, verified and revocable.
- Agent Cards are validated and treated as metadata, not trust.
- Tasks contain minimum necessary data and explicit purpose.
- Remote states map to an internal lifecycle.
- Requests, events and artifact ingestion are idempotent.
- Credentials are audience-bound and minimally scoped.
- Artifacts are scanned, validated and never auto-executed.
- Cancellation, timeout and reconciliation are designed together.
21. Continue the series
We now have tools, durable state and external delegation. Part 7 turns these into a production control plane with budgets, approvals, tracing, recovery and stopping conditions.
A real Azure integration
BuildEstate Pro needs an ecology assessment from a consultancy that operates its own agent. The local application creates a task envelope containing the project reference, purpose, permitted evidence, deadline and expected report schema. It does not send the complete conversation or unrelated project files.
public sealed record EcologyReviewRequest(
Guid CorrelationId,
string ExternalProjectReference,
IReadOnlyList<EvidenceReference> PermittedEvidence,
DateTimeOffset DeadlineUtc,
string ExpectedSchemaVersion);An ASP.NET Core IA2AClient adapter submits the request with workload identity and an idempotency key:
var task = await ecologyAgent.SendTaskAsync(
request,
idempotencyKey: $"ecology:{executionId}:{evidenceVersion}",
cancellationToken: ct);
await executionStore.AttachRemoteTaskAsync(
executionId, task.Id, task.ProtocolVersion, ct);Azure API Management can provide an externally governed gateway, while Microsoft Entra workload identity and OAuth scopes protect the service boundary. Service Bus may carry internal progress events, but A2A remains the contract with the independently operated agent. Application Insights correlates the local execution and remote task without recording private reasoning.
When the artifact returns, a local ingestion service checks media type, size, digest, schema, malware status, citations and project scope. Remote completed means the other agent finished; it does not mean BuildEstate Pro accepted the result.
Explain the user experience clearly
Show users which organization is performing the work, what data was shared and whether input is required. Map remote states into a small local vocabulary, but retain the exact remote status for support. If the partner fails, preserve useful local work and offer a human route.
This is especially important when the remote output sounds confident. Present it as an attributed contribution. A planning professional remains able to accept it, reject it or request correction. Human accountability should become clearer—not disappear—when agents communicate.