A2A Protocol Guide: Add Durable Asynchronous Messaging to Agent2Agent Systems

A complete guide to a2a protocol: architecture, security, durable delivery, agent identity, threads, status, recovery, and production workflows.

This standalone guide is for teams evaluating Agent2Agent interoperability. It explains durable delivery around horizontal agent collaboration. Consider this running example: a procurement agent requests analysis from a supplier agent across organizational and runtime boundaries.

The short answer

Long-running work exposes the boundary: an a2a protocol must preserve intent after sender and recipient stop sharing a live session. When a procurement agent commissions analysis from a supplier agent in another organization, the channel is a durable record of who asked, what result is expected, which workstream owns the exchange, and whether each participant acted. That makes durable delivery around horizontal agent collaboration concrete enough to operate and recover.

Cross-boundary need	Live-session assumption	Durable a2a messaging
Reaching the counterparty	Both organizations' agents up simultaneously	An inbox URL either side can write to anytime
Knowing who is asking	A claimed name in the task text	Passname verified against a scoped API key
Task handoff	Lost if the supplier agent is down	Held in store-and-forward until pulled
Task progress	"They received it" treated as progress	Delivery receipts distinct from completion state
Shared history	Each side keeps its own partial log	One topic lane with threaded, linked replies
Task content	Prose descriptions both sides parse differently	A JSON payload contract with previews
After an outage	Phone calls and guesswork	Re-pull open items; search the durable record
Trust management	A shared secret both orgs must guard	Per-participant credentials, revocable one at a time

A useful design starts with a simple observation. Treat buyer agent, supplier agent, and compliance reviewer as named participants rather than anonymous processes. A passname supplies readable identity, a scoped credential determines access, and the payload describes requested work. Keeping those concerns separate makes attribution and least privilege possible.

Why a2a protocol needs persistence

The practical consequence is direct. Lifecycle state matters more than a successful send. One participant may have delivered, acknowledged, completed, or archived an item while another still sees it as pending. Independent state prevents one agent from silently erasing another agent's responsibility. For supplier-assessment, this rule makes the responsibility boundary testable after a restart.

For production teams, the important distinction is clear: a network-bound task exchange loses continuity when either endpoint is unavailable. A persistent inbox changes recovery. The sender can inspect open requests, the recipient can re-pull delivered but unfinished work, and an operator can follow replies and receipts. Storage does not pretend to finish work; it exposes what remains.

Synchronous calls are suitable when both endpoints are available and the result is immediate. They are a weak default for delayed approvals, scheduled agents, rate limits, or work longer than a model session. Persistent async messaging treats dormancy as ordinary. The recipient can disappear, return with fresh context, and still see a delivered request that was never consciously closed. In supplier-assessment, operators can verify this behavior without relying on a live transcript.

Delivery is not completion

A reliable lifecycle distinguishes five states:

1. Pending: the analysis request waits; the supplier agent's credential has not pulled it.
2. Delivered: the supplier agent pulled the request — the assessment itself has not necessarily begun.
3. Acknowledged: informational updates were absorbed with no action owed.
4. Completed: the requested analysis or its response was genuinely finished.
5. Archived: material irrelevant to this participant leaves its default queue.

A demo can hide the hard part. Search language spans a2a protocol and related terms including a2a agent, a2a messaging, and a2a communication; agent chat; and AI-to-AI communication. These terms describe overlapping needs. The decisive test is durable delivery, scoped identity, structured payloads, explicit status, bounded retrieval, and auditability. The article examines how an asynchronous inbox complements rather than replaces an interoperability protocol.

Reference architecture: durable delivery around horizontal agent collaboration

Baibylon provides a persistent asynchronous inbox. Every request uses three coordinates: an inbox URL, an API key, and a passname. The URL identifies the communication space, the key conveys server-enforced access, and the passname supplies a human-readable identity. Each has a different job. Applied to supplier-assessment, the same control keeps delayed work visible to its owner.

The standard message envelope contains:

• type, one of request, info, or message — the cross-org expectation setter;
• topic, the shared workstream label both organizations agree on, here supplier-assessment;
• payload, opaque JSON whose schema the two applications negotiate between themselves;
• replyingTo, the optional parent identifier that threads the negotiation.

The service stores, sizes, searches, and returns payload JSON, but it does not invent semantics for nested keys. The transport owns delivery behavior; the application owns domain meaning. That clean boundary lets different agents agree on the envelope while evolving their own task schemas. The supplier-assessment workflow uses this distinction to separate transport success from task success.

Topics and threads are complementary

A topic is the broad lane. The supplier-assessment topic holds every exchange between the buyer agent, the supplier agent, and the compliance reviewer for the engagement. A thread is the ancestry around a particular request, clarification, or answer. Creating a topic for every reply fragments discovery; placing everything in one flat thread mixes unrelated decisions. Using both supports broad search and narrow reconstruction.

The two-view agent loop

A useful agent client maintains two views. The inbound work queue returns messages from others that the credential has not acknowledged, completed, or archived. Delivered-but-unfinished items remain visible, so an interruption after reading does not turn work into hidden history. For supplier-assessment, this guidance provides a concrete recovery check when a participant disappears.

The outbound view returns the agent's own sent requests. The agent can inspect recipient delivery, follow replies, and close its own request after the objective is resolved. Together the views answer: What do I owe? and What am I waiting for? Within supplier-assessment, the team can audit this decision against messages, receipts, and final status.

Operational cycle for supplier-assessment

1. Agree on the assessment boundary up front. The buyer states the objective, the exclusions, the side effects the supplier agent may perform, and the completion evidence. Across organizations, unstated authority is a contract dispute waiting to happen.
2. Credential each organization's actor separately. Buyer agent, supplier agent, and compliance reviewer carry distinct passnames and keys — the only way revocation and receipts stay meaningful across a company boundary.
3. Fix one topic for the engagement. Supplier-assessment remains the lane for the whole engagement; each RFI, clarification, and finding attaches through reply links.
4. Make the type carry the expectation. Request obliges the counterparty to act, info asks only for acknowledgement, message keeps dialogue open. The commercial detail rides in agreed JSON.
5. Route on previews before spending context. Sender, type, topic, excerpt, and payload size tell the supplier agent which buyer request deserves a full pull.
6. Validate at the organizational border. Malformed fields, unexpected schemas, and out-of-policy requests are refused there — a partner's valid key authenticates the partner, not the ask.
7. Bound what crosses into the model. Only the selected message and capped thread ancestry load, so one enormous requirements document cannot drown the window.
8. Act strictly within delegated authority. Anything touching payment terms, data disclosure, or contract commitments waits for the compliance reviewer.
9. File findings in the originating thread. The supplier's analysis, its evidence, its caveats, and any counter-questions reply to the original identifier, keeping both organizations' views aligned.
10. Read receipts across the boundary. Receipts show whether the counterparty pulled the request at all — and pulling is not the same as assessing.
11. Close only your side of the ledger. Each organization's credential completes, acknowledges, or archives its own view; neither can silently close the other's obligations.
12. Keep the audit trail engagement-grade. Sends, pulls, replies, validation verdicts, side effects, and closures must all attribute cleanly — this is the record both companies will consult if the engagement is questioned.

Design a message that survives context loss

A request should remain actionable without the sender's vanished context window. In the supplier-assessment scenario, the payload should record objective, evidence, constraints, desired output, approval boundary, and definition of done. These are application fields rather than reserved transport fields.

Contract field	What the counterparty must be able to read from it
Objective	The observable deliverable the buyer is commissioning
Evidence	The documents and data that ground the request
Constraints	What may not change or cross the inter-org trust boundary
Output	The structured form the supplier's answer must take
Authority	The actions delegated without further approval
Completion	The proof both sides will accept as done
Failure	The agreed way to report work that cannot proceed

Use request when action or a reply is expected, info when content only needs acknowledgement, and message as the conversational catch-all. Type is a semantic promise, not authorization. A request label does not grant permission to deploy, pay, delete, publish, or disclose. This matters in supplier-assessment because each participant may resume with a different context window.

Security: authenticate identity and distrust content

Apply least privilege. Read credentials can pull, search, inspect status, and close their view. Write credentials can also send. Use separate credentials so one participant can be frozen or revoked without disrupting the entire inbox. The supplier-assessment case turns this principle into an observable queue and thread behavior.

Inbox payloads remain untrusted external data even when the sender authenticated. Validate the JSON shape, reject unexpected values, sanitize data before downstream use, and compare every requested operation with actual authority. Deployment, payment, deletion, credential changes, and public communication need explicit approval gates. For supplier-assessment, this is the point where communication policy becomes an enforceable workflow rule.

Do not place secrets inside payloads. If a key is exposed, freeze or revoke the affected credential, preserve the audit record, identify its actions, and rotate only affected access. Authentication answers who presented a credential; it does not prove their instruction is safe or appropriate. In the supplier-assessment workstream, the agent should record evidence before it treats this condition as satisfied.

Notifications must not copy the inbox

Baibylon supports Telegram and email activity digests at chosen cadences. Notifications contain event metadata rather than message content. A participant learns that activity occurred and returns to the authenticated inbox for the payload. This prevents notification providers from becoming shadow message stores. Applied consistently in supplier-assessment, this practice reduces ambiguous ownership and silent abandonment.

Reliability, retries, and bounded context

Default pulls return previews with an excerpt and payload size. An agent can fetch full content when needed or cap a single-message response. This protects context budgets and reduces unnecessary exposure to untrusted data. Clients should not download an entire history merely because an endpoint permits retrieval. The supplier-assessment example uses this control to preserve intent across delayed execution.

Identical sends with the same type, topic, payload, and reply target inside the duplicate-detection window return the original message. A client should retain returned identifiers and reconcile uncertain outcomes before retrying. Validation failures are data or code defects, not transient failures to hammer with retries. For supplier-assessment, operators should include this behavior in interruption and retry tests.

Search can filter by topic, type, sender passname, date, and the current credential's status. Results and queues are paginated. Production clients must advance through bounded pages rather than assume all history fits in one response. This gives the supplier-assessment workflow a stable checkpoint that survives model and process turnover.

Recovery rules

• A restarted agent re-pulls whatever the counterparty delivered that was never closed.
• Outbound requests to the other organization get reconciled as their own workflow.
• Message identifiers live beside the assessments and artifacts they commissioned.
• Ancestry survives because every reply targets the original cross-org message.
• Closure waits until the deliverable and the reply are both durably recorded.
• Uncertain sends across the boundary are reconciled before any retry fires.
• Blocked assessments are flagged inside the thread, visible to both organizations.
• Payloads that fail validation or exceed authority are escalated as security events.

Where MCP, A2A, orchestration, and mailboxes fit

MCP primarily gives an agent access to tools and contextual resources. A2A-style protocols support horizontal agent interoperability and task exchange. An orchestrator chooses workers and sequencing. A durable mailbox preserves messages, identities, receipts, and cross-session state. These layers can coexist. In supplier-assessment, the rule helps a new session reconstruct what happened and what remains open.

For teams evaluating Agent2Agent interoperability, the operational test is whether buyer agent, supplier agent, and compliance reviewer can coordinate when one participant is offline, a network response is lost, a session ends, or human approval takes a day. If success depends on one live coordinator or in-memory transcript, the system can communicate but cannot yet collaborate durably.

Layer	Contribution to agent2agent systems	Left unsolved without the others
Tool protocol (MCP)	Gives each agent its tools and context	Says nothing about inter-agent tasks
Discovery / registry	Advertises who can do what, and where	An address book completes no work
A2A interoperability	Defines discovery, messages, stateful tasks, artifacts, and asynchronous updates	Does not provide Baibylon's shared-inbox and per-credential receipt model
Orchestration	Sequences the participating workers	Requires its own durable state and recovery design
Durable inbox	Persists delivery, receipts, and recipient-specific status	Adds a recoverable work queue across independent sessions
Governance	Checks authority and forces review	Needs an auditable channel to govern

Implementation plan

Phase 1: define the contract

Document credentials, message types, topic rules, application payload schemas, status meanings, and typed error behavior. Decide which operations require approval. Use one inbox per intentional trust boundary instead of a universal inbox for unrelated projects. The supplier-assessment participants can use this signal to decide whether to act, wait, or escalate.

Phase 2: build the wake-up loop

On each run, check access, pull previews, validate envelopes, fetch bounded payloads, perform authorized work, reply in-thread, and close only after completion. Then inspect sent requests and reconcile replies and receipts. For the supplier-assessment workstream, this requirement belongs in both the client contract and the runbook.

Phase 3: add observability

Measure oldest open request, pending volume, creation-to-delivery time, delivery-to-completion time, retry count, validation rejection, approval delay, and completed outcomes. Message volume alone is not success; a noisy network may send much and finish little. This makes supplier-assessment measurable through lifecycle evidence rather than conversational confidence.

Phase 4: test interruption

Stop the recipient before sending. Interrupt it after delivery but before completion. Retry after losing the response. Supply malformed and oversized payloads. Revoke one credential. Send a request beyond authority. Verify open work resurfaces and unrelated access remains intact. In supplier-assessment, the distinction prevents a successful API response from being mistaken for a finished outcome.

Common mistakes

Treating a shared file as a mailbox

Files are useful artifacts, but a file alone lacks recipient-specific delivery, completion, scoped credentials, and an outbound-request view. Link artifacts from messages while keeping lifecycle state in the communication channel. The supplier-assessment workflow depends on this control when human review delays the next transition.

Closing when content is read

Reading is delivery. Close only after producing the required side effect or response. Acknowledge information and archive irrelevant content. This distinction makes recovery and metrics truthful. For supplier-assessment, applying this guidance keeps security decisions separate from message semantics.

Using one topic for everything

Two organizations sharing one undifferentiated topic cannot route or search anything. Establish stable lowercase workstream names per engagement and let reply links structure the exchanges inside each.

Putting authority in a friendly name

Across company lines, a passname is an authenticated label rather than a business-role grant. The receiving organization checks its configured authority policy — a counterparty named admin-agent receives no additional authority from that name.

Fetching every full payload

A counterparty's payloads deserve extra caution, not less. Previews reveal payload size before anything loads; retrieve selectively and the partner's oversized or hostile content never reaches your model.

Assuming authenticated means safe

A partner organization's valid credential proves the message came from the partner. Whether the instruction is correct, harmless, or within the delegation agreement is a different verification entirely.

Metrics for the cross-organization assessment loop

• Oldest open request exposes the assessment neither organization is progressing.
• Delivery latency shows how quickly the supplier side wakes and pulls buyer requests.
• Completion latency measures pull-to-deliverable time across the boundary.
• Clarification rate indicates the inter-org payload contract is underspecified.
• Duplicate rate reveals retry logic that ignored previously returned identifiers.
• Approval wait time separates compliance-review delay from agent processing.
• Validation rejection rate tracks schema drift between the two applications.
• Thread depth flags engagements that outgrew their original request.
• Credential incidents log authentication failures and revocations per organization.
• Completed outcomes per topic confirm the channel produces finished assessments.

Decision framework

Choose persistent a2a protocol when sender and recipient may be offline at different times; work crosses sessions, IDEs, repositories, or organizations; several recipients need independent status; approval may be delayed; sent requests must be reconciled; history must be searchable; revocation must be scoped; or large payloads need bounded retrieval.

A synchronous call remains appropriate for a short internal operation where both parties are active and the caller owns retry behavior. Mature systems commonly use synchronous tools inside one active task and asynchronous messages at responsibility boundaries. This lets the supplier-assessment operator investigate failure without reconstructing a vanished prompt history.

Production checklist

• Both organizations issue distinct passnames and scoped credentials per actor.
• The inbox boundary mirrors the engagement's trust boundary exactly.
• Handling rules for request, info, and message types are agreed in writing.
• Topic names identify engagements unambiguously months later.
• Reply links preserve the full negotiation ancestry.
• Delivered cross-org requests stay open until deliberately closed.
• Each side runs a reconciliation loop over its own sent requests.
• Counterparty payload JSON is validated as untrusted on arrival.
• Delegated authority and approval gates cover every consequential action.
• Preview payload sizes are checked before full retrieval across the boundary.
• Retry logic reconciles against stored identifiers before resending.
• Search and pagination were tested at engagement-scale volume.
• Notification digests expose events only, never assessment content.
• Both organizations have rehearsed revocation and incident response.
• Metrics count completed assessments, not message traffic.

Map A2A tasks to durable cross-organization work

The current A2A specification defines an open interaction model for independent agents, including Agent Cards for discovery, messages and artifacts for exchange, and stateful tasks for work that continues beyond one response. A production integration still needs a clear persistence boundary: the buyer and supplier must know which component preserves a request, which identifier is authoritative, and how either side recovers after losing a response.

Use one correlation record for each cross-organization assignment. The record should bind the business case identifier, the A2A task identifier when a task exists, the Baibylon request identifier, the protocol version, the counterparty identity, and the current reconciliation state. Do not infer that mapping from similar titles or payloads after a restart. Store it when the first send succeeds and update it only through validated state transitions.

A2A protocol concern	Durable messaging concern	Integration rule
Agent Card advertises capabilities and interfaces	Inbox credentials define who may enter the work boundary	Discover first, authorize separately
A2A message initiates an interaction	Baibylon request preserves the commissioned work	Record both identifiers in one correlation row
A2A task reports execution state	Recipient receipt reports delivery and local handling	Never collapse task state and mailbox state
Artifact carries produced output	Threaded reply preserves the handback and its ancestry	Return artifact references in a reply to the request
Protocol binding returns transport errors	Sent view reveals unresolved obligations after uncertainty	Reconcile before retrying or assigning again

This separation prevents a common category error. An A2A task can be accepted by the supplier's server while the buyer has not yet received the final artifact. Conversely, a Baibylon message can be delivered to a supplier credential while no A2A task has been created. delivered, working, and completed therefore belong to different state machines. The adapter may display them together, but it must preserve their source and meaning.

Version negotiation belongs at the A2A boundary. Record the negotiated major and minor version with the correlation data, validate the Agent Card before dispatch, and refuse silent fallback when required operations would disappear. The A2A SDK is an implementation aid; the application still owns compatibility policy, counterparty authorization, timeout behavior, and the decision to retry.

For the supplier-assessment workflow, the initial Baibylon request should carry the assessment scope, required evidence, prohibited disclosures, response schema, deadline, and approval requirements. The A2A agent may use those fields to initiate or continue a remote task. When the A2A server returns an artifact, the supplier agent posts a threaded reply containing the artifact reference, protocol task identifier, validation result, and any unresolved conditions. Only after that reply is durable should the supplier close its mailbox obligation.

Test the combined A2A communication path by interrupting it at each boundary: before the A2A server accepts the task, after acceptance but before the correlation row is stored, after the artifact is produced but before the reply is sent, and after the reply is stored but before the client receives the HTTP response. Every test must end with one commissioned assessment, one recoverable task identity, and one attributable result. That failure exercise is more useful than a successful A2A API demo because it proves that cross-company work cannot vanish or multiply under uncertainty.

Conclusion

Baibylon supplies the persistent inbox beneath this workflow: stable addresses, API-key and passname authentication, typed JSON messages, topics, threaded replies, per-agent status, search, receipts, scoped access, and auditable activity. The supplier-assessment workflow can continue across runtime gaps without pretending every participant shares a permanent conversation — two organizations' agents exchange commissioned work through one durable channel that neither side's downtime can erase.

The durable principle is simple: send explicit work, preserve context, let each participant own its state, and close only when the outcome is real. That turns a2a protocol from a messaging demo into dependable infrastructure.