Agentic Frameworks & Coordination

7 — Agent Inter-communication (A2A)

Interoperate across independently operated agents through explicit capability discovery, task lifecycle contracts, authenticated messages, and verifiable artifacts.

Concept overview

Agent inter-communication exchanges work requests and results across runtime or organizational boundaries. A useful contract specifies the requested task, identity, deadlines, accepted modalities, artifact schemas, and cancellation semantics. It does not require agents to expose their prompts, private reasoning, or internal orchestration implementation.

The Agent2Agent protocol provides a concrete interoperability model including Agent Cards, messages, tasks, and artifacts. Protocol versions evolve, so deployments should pin and negotiate supported versions rather than assume examples from different releases are interchangeable. Transport interoperability does not establish trust: advertised capabilities and returned artifacts still require independent validation.

Why it matters in production

Proof of concept

A prototype can call a known peer directly with a fixed contract. Verify that a remote agent adds a capability unavailable through an ordinary tool API.

Production

Production introduces authenticated discovery, request signing or suitable transport security, scoped delegation, timeout rules, and stable correlation identifiers. Treat remote text and artifacts as untrusted input.

Enterprise scale

At scale, capability registries, compatibility tests, and per-peer quotas become essential. Separate remote task status from local workflow status so a peer outage cannot silently turn an incomplete local operation into success.

Architecture components

Agent directory

Publishes trusted peer identities, supported contracts, and approved capability metadata.

Protocol adapter

Translates local task requests into the pinned peer protocol and normalizes responses.

Delegation policy

Limits which user authority and data can cross the peer boundary.

Remote task tracker

Maps local operations to remote task identifiers and lifecycle states.

Artifact verifier

Checks provenance, media type, schema, size, and safety before consuming remote results.

The architecture, mapped

A controlled inter-agent boundary — The local agent treats discovery, delegation, and artifact acceptance as separate trust decisions.

sequenceDiagram
 participant L as Logistics agent
 participant D as Trusted directory
 participant P as Delegation policy
 participant C as Carrier agent
 participant V as Artifact verifier
 L->>D: Resolve carrier capability and version
 D-->>L: Approved peer metadata
 L->>P: Check shipment data delegation
 P-->>L: Scoped authorization
 L->>C: Submit bounded routing task
 C-->>L: Remote task identifier
 L->>C: Read task progress
 C-->>L: Route artifact and evidence
 L->>V: Validate returned artifact
 V-->>L: Accepted result or rejection

Remote task reconciliation — Local completion depends on accepted remote evidence rather than a missing response or elapsed wait.

flowchart TD
 L["Local task registry"] --> Q["Query approved peer task"]
 Q --> C["Confirmed completed artifact"]
 Q --> P["Still pending"]
 Q --> U["Peer unavailable"]
 C --> V["Artifact acceptance checks"]
 P --> D["Remaining local deadline"]
 U --> D
 D --> W["Wait within budget"]
 D --> E["Explicit expired local task"]
 V --> R["Record remote provenance"]

Runtime flow

1
Discover peer
Resolve an approved identity and inspect its declared capabilities and protocol compatibility.
2
Authorize delegation
Confirm that the requester may share the required data and invoke the remote capability.
3
Submit task
Send bounded instructions, artifact references, deadline, and correlation metadata through an authenticated channel.
4
Track lifecycle
Observe streaming, polling, or callback updates according to the peer's supported capabilities.
5
Validate artifact
Verify returned evidence and distinguish completed work from requests for additional input.
6
Close local task
Record remote provenance, release resources, and reconcile cancellation or unknown outcomes.

Coordinating a specialist carrier service

Logistics · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A freight platform works with carriers whose routing expertise and operational systems remain under separate ownership.

The problem

Custom integrations expose inconsistent task status and make it difficult to know whether a route proposal is final.

Agent requirement

The assistant must request specialist routing evidence without disclosing unrelated customer records or losing task accountability.

Architecture

A protocol adapter uses an approved carrier agent contract, scoped shipment data, and a local-to-remote task registry.

Runtime

A dispatcher requests an alternative route; the platform discovers a compatible carrier capability and submits only the relevant shipment constraints.
The carrier returns a task identifier and later a route artifact, which is checked against dimensions, delivery windows, and approved endpoints.

Failure scenario

If the carrier becomes unreachable, the local task remains pending or expires explicitly; no booking is inferred from a missing response.

Operational impact

Measure interoperability failures, remote task age, invalid artifacts, and peer-specific completion quality before expanding automated delegation.

Architecture tradeoffs

Decision	Benefit	Cost
Standard protocol	Reduces bespoke lifecycle integration between independent systems.	Version compatibility and profile differences still require testing.
Opaque peer implementation	Partners preserve internal autonomy.	Local operators have less visibility into remote failures.
Asynchronous tasks	Long investigations can survive disconnected clients.	Status reconciliation and cancellation become distributed concerns.

Failure scenarios & recovery

A malicious card advertises an internal endpoint

Detect: Discovery validation detects an unapproved host or identity.

Recover: Reject the peer and investigate registry provenance.

Remote success contains an invalid route

Detect: Artifact checks find violated shipment constraints.

Recover: Reject the result and request correction without booking.

Common architecture mistakes

Equating protocol support with authorization

Apply explicit delegation policy for every task.

Forwarding full conversation histories

Share only the task data necessary for the peer capability.

Mixing protocol versions silently

Pin adapters and test supported lifecycle behavior.

When to choose this pattern

Choose it when

Independent agent systems need a shared task lifecycle.
Partners must preserve their internal implementation boundaries.
Remote work requires artifacts and asynchronous progress.

Avoid it when

A stable synchronous business API fully meets the requirement.
Peer identity and data-sharing authority cannot be established.
The integration does not need agent-specific task semantics.

Architecture checklist

Pin supported protocol versions.
Authenticate discovery and peer endpoints.
Restrict outbound network destinations.
Scope delegated identity and data.
Validate every returned artifact schema.
Reconcile remote cancellation and unknown outcomes.