2026 global infrastructure edition
The Hitchhiker's Guide to the Agentic Economy
Agent-to-agent coordination for AI systems
The protocols and platforms forming around agent-to-agent coordination, the states they standardise and the boundaries they leave unresolved.
Agentic Economy market map · Checked September 2026
View MarkdownChapter 8 of The Hitchhiker's Guide to the Agentic Economy
Report hub · Previous: tools, browsers and service access · In this chapter: protocol map · task lifecycle · Delegation Envelope · Next: identity, authority and policy
Our view
Two agents can exchange a valid message and still disagree about who owns the objective, whether the receiver may act, what counts as a good result, who gets paid and who repairs a loss. Coordination protocols reduce that ambiguity at the conversation and task boundary. They do not establish the principal, permission, quality, commercial relationship or recourse.
Agent-to-agent coordination is the exchange of capabilities, messages, task state and artefacts between independently operated agent systems. Independence here means a separate application, runtime, organisation or trust boundary. It does not imply that an agent is a legal person or that it acts without a principal.
The practical design question is therefore not “Which agent protocol wins?” It is “Which facts must survive this hand-off, and which system enforces them?” A production route needs a protocol message plus a delegation record, an authority decision, an artifact lineage and a recovery owner. The protocol can carry some of those as metadata or extensions. It does not make the surrounding obligations disappear.
Key Takeaways
- A2A 1.0 defines Agent Cards, messages, tasks, artefacts, streaming, push notifications and task operations for independent agent systems. It does not grant authority or prove a supplier's quality.
- MCP 2026-07-28 primarily connects a host and its client to servers that provide context and tools. Its optional Tasks extension supports long-running handles, input requests and polling, with cooperative cancellation.
- In-process patterns such as agents-as-tools and handoffs in the OpenAI Agents SDK or Microsoft Agent Framework are useful orchestration choices. They are not automatically a cross-organisation coordination contract.
- A durable workflow engine can hold the parent and child task graph while A2A or another interface carries one edge. Direct messaging and orchestration solve different failure problems.
- An agent card or directory listing is a discovery claim. Reachability, protocol conformance, completed delivery, accepted work and commercial recourse are separate market events.
Sources and scope
Agentic Economy compared the official specifications, repositories and provider documentation named in the Part II brief. Sources were checked on 13 September 2026, with protocol versions and document dates retained where they are available. The record covers A2A 1.0, MCP 2026-07-28, AGNTCY Directory, Agentic Resource Discovery, Microsoft Agent Framework, Amazon Bedrock AgentCore A2A, the OpenAI Agents SDK, Temporal, Prefect, Agent Network Protocol and the historical Agent Communication Protocol.
This is a documented-supply map. The named sources establish what a specification or product says it supports. They do not establish a common production implementation, adoption rate, quality level or commercial outcome. Agentic Economy did not run a cross-provider interoperability test or a paid delegated job for this chapter. About Agentic Economy explains the publication and its Australian focus. Readers can submit source corrections through the contact page.
Coordination is splitting across two markets
One market coordinates agents inside a single application. Frameworks expose managers, specialists, hand-offs and agents-as-tools while one runtime retains control. The second market connects independently operated agents across applications or organisations. A2A, agent cards, directories and adjacent specifications are developing around that external boundary.
The two markets use similar language but solve different problems. Local orchestration decides which component runs next. Cross-system coordination needs shared discovery, message, task and artefact semantics. Durable workflow products can sit beneath either model. We expect local agent composition to remain framework-specific while a smaller set of open interfaces develops for remote tasks and service relationships.
Google launched A2A on the belief that “universal interoperability is essential” for collaborative agents (Google Developers Blog, "Announcing the Agent2Agent Protocol"). The protocol's broad partner list signalled substantial industry interest. The market still has to prove that shared messages produce portable authority, accepted results and durable commercial relationships.
Coordination is an interface, not a trust system
An agent boundary creates a small set of shared questions:
- How can the caller find a possible participant?
- How does each side describe the capabilities and interaction modes it supports?
- How are messages, context and structured inputs exchanged?
- How does a long-running task become visible after the first request?
- How are progress, additional input, cancellation, failure and completion represented?
- How are output artefacts delivered and referenced?
These questions matter because an agent may be opaque to its caller. A bounded remote task does not require access to the other system's prompt, memory or tool implementation. A2A's stated design is to let independent agent systems discover one another, negotiate modalities and manage collaborative work without sharing internal state, memory or tools (A2A Protocol Specification).
The missing questions sit beside the wire:
- Principal: Which person or organisation owns the objective?
- Permission: What may this actor do with this data, resource and budget?
- Quality: What makes the returned work correct, complete and fit for purpose?
- Commercial relationship: Is this a one-off request, a quote, a purchase, a subscription or a supplier contract?
- Recourse: Who must correct, refund, restore, explain or absorb the loss when the task fails?
An A2A implementation can require authentication and perform authorisation checks. The specification leaves the authorisation model to the agent and its operator. MCP's current security guidance likewise says that the protocol cannot enforce consent and authorisation principles at the protocol level (MCP Specification 2026-07-28). A signed message can show integrity. It cannot, by itself, prove that the sender had the right to commission the work or that the result satisfies a customer's acceptance test.
The US National Institute of Standards and Technology treats software-agent identity and authority as an active design problem spanning identification, authorisation, audit and controls against delegated misuse (NIST, "Identity and Authority of Software Agents"). That work reinforces the boundary: coordination needs an authority chain beside the message, not another message field presented as trust.
The same distinction applies to local frameworks. A framework can route a request from a triage agent to a specialist and preserve the conversation. It cannot decide whether the specialist is an approved supplier, whether the data may cross the boundary or whether a customer should accept the result.
The protocol boundary map
The following map separates the interface that reaches a tool from the interface that delegates to another agent and the interfaces that create a commercial transaction. It is Agentic Economy analysis, not a claim that every combination is interoperable.
objective, principal, authority and acceptance
|
agent application and runtime
/ | \
/ | \
MCP A2A / ANP commerce interfaces
host -> client -> agent client -> platform -> merchant
tool or context remote agent checkout -> order
server system -> payment -> fulfilment
\ | /
\ | /
delivery, evidence and recourse
Figure 8.1. Protocol boundary map. The text diagram is the complete accessible equivalent.
| Boundary | Representative interfaces | Primary question answered | Still outside the interface |
|---|---|---|---|
| Application to tool or context | Direct API, MCP, connector or browser access | How can this application invoke a capability or obtain data? | Cross-agent delegation, supplier trust, payment, acceptance and recourse |
| Agent to independent agent | A2A 1.0, ANP, product-specific task APIs; historical ACP from BeeAI | How can one agent discover, message and track work performed by another agent system? | Principal, business authority, quality, contract, settlement and remedy |
| Resource discovery | A2A Agent Cards, ARD, AGNTCY Directory, MCP server or tool listings | Where is a capability described and how can a caller search for it? | Independent verification, current availability, permission, quality and demand |
| Local multi-agent orchestration | OpenAI Agents SDK, Microsoft Agent Framework and similar runtimes | Should a manager call a specialist, or should control transfer to it? | Cross-organisation trust, portable task semantics and commercial terms |
| Commerce and order state | Commerce protocols such as ACP and UCP, merchant APIs and order systems | How can an agent discover an offer, create checkout and update an order? | General agent coordination, non-commerce work, delivery quality and all recourse |
| Payment authority and settlement | AP2, x402, MPP, cards, wallets and bank rails | Which participant may initiate or settle a payment, and through which rail? | The underlying work, delivery acceptance, tax, accounting and supplier relationship |
| Identity and policy | OAuth, workload identity, policy engines and mandates | Who is acting, for whom and under which constraints? | Conversation semantics, task execution and proof that the result was accepted |
ACP is an overloaded label. This chapter calls IBM and BeeAI's coordination project ACP (BeeAI). The historical ACP repository says that project is now part of A2A under the Linux Foundation (ACP repository). The commerce use of ACP is a separate Part III subject. A shared acronym does not imply a shared protocol or boundary.
The map has a practical consequence. A service can be A2A-reachable while its only commercial offer is a negotiated contract. A merchant can expose an agent checkout while its fulfilment team still works through ordinary enterprise systems. An MCP server can invoke a paid data API while no agent-to-agent delegation occurred. The edge that moved the job is therefore the controlling analytical unit.
Who supplies coordination
| Participant or record | Layer | Documented capability at the checked date | Commercial or operating model | Evidence boundary |
|---|---|---|---|---|
| A2A 1.0 | Open agent-to-agent protocol | Agent Cards, messages, parts, tasks, artefacts, multi-turn context, streaming, push notifications, task listing and cancellation across JSON-RPC, gRPC and HTTP+JSON bindings | Open specification implemented by agents, frameworks and hosting providers | Versioned semantics and security requirements; no proof of conformance, adoption, quality or recourse |
| MCP 2026-07-28 | Host, client and server protocol for context and tools | Resources, prompts, tools, JSON-RPC requests, capability negotiation, progress, cancellation and opt-in extensions negotiated during initialization | Open specification and ecosystem implementations | The overview describes requests as stateless and self-contained, while extensions such as Tasks add durable server handles; neither makes the boundary an agent delegation contract by itself |
| MCP Tasks | MCP asynchronous extension | Durable task handles, polling, input-required states, terminal results or errors and cooperative cancellation | Optional extension supported by clients and servers that opt in | Host support varies; cancellation acknowledges intent and is not a guarantee that side effects stop |
| AGNTCY Directory | Distributed discovery and record exchange | OASF-based capability records, content addressing, cryptographic provenance, semantic links, APIs, SDKs and distributed synchronisation | Open-source directory that can be deployed locally or as distributed services; operating and support costs remain with the operator | Repository and tooling show a capability; they do not establish the size, freshness, trust or usage of a directory network |
| Agentic Resource Discovery (ARD) v0.91 | Federated search envelope | JSON-LD entries for MCP, A2A, skills, APIs and other resources; domain-anchored publishing, /.well-known/ard.json, REST search and artifact-agnostic envelopes |
Open proposal for publishers and registry operators | Proposal dated 26 August 2026; authentication and artifact schemas are delegated, and pending media-type registration remains an open seam |
| Microsoft Agent Framework | Local agent framework and workflow orchestration | Agent-as-tool and handoff patterns, sessions, workflows, checkpoints, human approval and autonomous or interactive operation | Framework with Microsoft model, Azure and self-hosting integrations; exact service terms vary by deployment | Provider documentation establishes supported patterns, not portable cross-organisation semantics or production outcomes |
| Amazon Bedrock AgentCore A2A | Managed A2A hosting and proxy | JSON-RPC over HTTP, Agent Card discovery, session isolation, containerised A2A servers, SigV4 or OAuth 2.0 and transparent payload forwarding | Managed AWS runtime and related cloud usage | Hosting support is documented; it does not establish a customer's authority model, quality or adoption |
| OpenAI Agents SDK handoffs | Local agent coordination | Agents-as-tools, handoffs, input filters, callbacks, guardrails, sessions, tracing and a runner that manages turns | Open-source SDK used with model and platform services; model, hosting and observability costs are separate | Handoffs stay within a run and transfer control to a configured agent; this is not a universal remote task protocol |
| Temporal Durable AI | Durable workflow execution | Workflow history, crash and timeout recovery, human waits, task queues, worker routing and integrations with agent frameworks | Open-source and hosted workflow operating models; infrastructure and operations are part of the buyer's decision | Durable execution can preserve a graph; it does not make each agent message authorised or each result accepted |
| Prefect agent workflows | Dynamic workflow orchestration | Runtime branching, agent state machines, retries, result caching, task-level observability and type-safe human input pauses | Open-source workflow engine plus Prefect Cloud and Horizon offerings | Documented orchestration capability; no independent measure of agent quality or cross-provider adoption |
| Agent Network Protocol (ANP) | Layered open agent network protocol suite | DID-WBA identity foundation, encrypted messaging, agent description and discovery, meta-protocol negotiation and application protocols | Open-source specifications under the MIT licence | Official materials say the specifications are under active development, with individual documents at different release or draft states |
| ACP (BeeAI), historical | Earlier agent communication protocol | Multimodal messages, real-time, background and streaming responses, discovery, long-running tasks and shared state | Open-source BeeAI project; repository now directs users to A2A | The repository's migration notice makes it historical evidence, not proof of a current independent ACP ecosystem |
The table is a map of documented supply, not a ranking. It also shows why “multi-agent platform” is an insufficient procurement category. One product may route local handoffs, another may host a remote A2A endpoint, another may index capabilities and another may make the execution durable. The buyer still has to join those records to a particular job and consequence.
Discovery is easier to standardise than selection
Discovery answers “what might be available?” Selection answers “what has this job been authorised to trust and use?” The first can be represented as metadata. The second needs authority, evidence and a business decision.
Agent Cards describe a possible remote capability
A2A 1.0 makes the Agent Card a central discovery object. A card can describe a provider, supported interfaces, protocol binding and version, capabilities, skills, input and output modes, authentication schemes and documentation. The specification also defines optional signing and an authenticated extended card for details that should not be public (A2A Agent Card and data model).
This gives a caller a useful first filter. It can reject a candidate that does not declare the required modality or task capability before sending sensitive input. It can negotiate a supported interface version rather than guessing. It can cache a card and refresh it when its version changes.
The card remains a publisher statement. A signature can protect integrity and bind the record to a key. It does not show that the skill performs well on a specific job, that its endpoint is currently available, that its owner will accept liability or that the actor is authorised for the principal. An Agent Card is a discovery record, not an approval.
Other discovery designs are still forming
Agentic Resource Discovery v0.91, AGNTCY Directory and the Agent Network Protocol represent three broader approaches: federated resource search, distributed capability records and a layered agent network. Their specifications and repositories establish active designs and testable interfaces. They do not establish a settled discovery market, a representative live directory or a reliable supplier-selection process.
The durable buyer question is the same across them. Can the caller verify publisher, record freshness, endpoint, version and declared capability before it sends data? A signed or content-addressed record can protect integrity. It cannot establish current capacity, authority, quality, price, service level or recourse. Those facts need separate evidence and a local selection decision.
The evidence ladder starts before discovery
The discovery market separates into explicit states:
| Market state | What was shown | What remains unknown |
|---|---|---|
| Listed | A card, manifest or directory record exists | Whether the endpoint is current, reachable or suitable |
| Reachable | DNS, transport and an initial request work | Whether the caller is authorised or the task can complete |
| Protocol-compatible | A named fixture passes the declared version and message shape | Quality, reliability, data handling and commercial fit |
| Task-complete | The participant returned a terminal state and an artefact or result | Acceptance, side effects and remedy |
| Accepted | The responsible buyer or operator accepted the defined result | Repeatability, safety, margin and long-term support |
| Commercially settled | Order, payment, invoice or contract state was reconciled | Whether delivery was valuable or whether future recourse is adequate |
Directory metrics, repository activity and partner announcements are useful supply signals. Without a denominator and job-level record, they do not establish adoption or outcomes.
Messages, tasks and artefacts
Coordination has three different payloads. A message is a communication event. A task is a state record for work that may continue after the first message. An artefact is an output or intermediate result. Keeping them separate makes retry and acceptance decisions clearer.
A2A puts the task at the centre
A2A 1.0 defines a Task with a server-generated identifier, optional contextId, current status, artefacts, history and metadata. Messages contain parts that can represent text, files or structured data. The specification includes operations to send a message, stream updates, get or list tasks, cancel a task, subscribe to a task and configure push notifications. It also defines status and artefact update events for streaming and asynchronous delivery (A2A Protocol Specification).
The task model solves a real transport problem. The caller can submit work, disconnect, reconnect and ask for the current state. A remote agent can request more input or authentication. An artefact can be delivered without exposing the remote agent's internal memory or tool calls. The caller can retain a context and task identifier to join the exchanges.
The task model does not solve the business problem by itself. completed means the remote implementation reached its terminal success state. It does not mean that the parent agent accepted the file, that the customer received what was promised or that a downstream record was changed correctly. The caller has to validate the result and keep the authority and commercial records that sit outside the A2A task.
MCP has a different centre of gravity
The MCP 2026-07-28 specification describes hosts, clients and servers. A host is the LLM application, a client is the connector inside that host and a server provides resources, prompts and tools. Its overview describes a JSON-RPC base with stateless, self-contained requests and capability negotiation. Optional extensions require explicit client and server support negotiated during initialization; Tasks then add durable handles and server-held task state.
MCP's Tasks extension adds asynchronous handles for operations that may take seconds, minutes or longer. A client and server opt in. The server can create a durable task before returning, the client polls with tasks/get, an input_required state can expose a request for more information, and terminal states carry a result or error. The extension defines working, input_required, completed, failed and cancelled states. Cancellation is cooperative: the server acknowledges the request but is not required to stop the work. Support varies by host and client.
An MCP task can therefore represent a long-running tool invocation. That does not turn the server into an independent supplier agent. The host still owns the model loop, and the server remains a capability endpoint selected by that host. If a tool server internally delegates to an agent, the resulting parent and child records are an application responsibility unless the server exposes them explicitly.
Local frameworks make different ownership choices
The OpenAI Agents SDK documents two common patterns. Agents as tools keeps a manager in control of the user-facing conversation and invokes a specialist for a bounded subtask. Handoffs transfer control to a configured specialist, which becomes the active agent for the remainder of the run (Agent orchestration). The handoff documentation says handoffs are represented as tools, can filter the input history and stay within one run (Handoffs).
That distinction changes who owns the next decision. A manager can reject, combine or re-check a specialist's answer. A handoff can give the specialist the response surface and the conversation history. Neither pattern establishes a portable remote contract. The SDK's own documentation warns that an is_enabled check cannot authorise values inside an argument-bearing handoff; application checks must run before side effects. A routing decision is not an authority decision.
Microsoft Agent Framework documents a similar choice. Its handoff orchestration uses a mesh in which configured agents can transfer control, while an agent-as-tool pattern returns a subtask result to the primary agent. The documentation also covers approval-required tools, sessions, context synchronisation and checkpoint storage (Microsoft Agent Framework handoff orchestration). The framework can broadcast user and agent messages across the local workflow while keeping tool-related handoff mechanics out of the shared conversation. Those are useful implementation semantics. They do not make a workflow's authority or customer acceptance portable to another organisation.
Hosting and durability are separate from wire semantics
Amazon Bedrock AgentCore Runtime documents an A2A contract for containerised servers. It expects JSON-RPC 2.0 over HTTP, an Agent Card at /.well-known/agent-card.json, a root endpoint on port 9000, and supports SigV4 or OAuth 2.0. The runtime passes A2A payloads through while adding session isolation (A2A protocol contract; deploy A2A servers).
This is an example of a managed boundary around a protocol. The hosting layer can supply deployment, authentication integration and session handling. It does not redefine what the remote agent promises, whether the caller's principal is authorised or who pays for a failed job.
Temporal and Prefect approach the problem from the execution side. Temporal's Durable AI documentation says a workflow can resume after a crash, network timeout or a multi-day human approval wait, and lists integrations with several agent frameworks (Temporal Durable AI). Prefect's agent workflow documentation describes dynamic control flow, runtime branching, retries, result caching, task observability and typed human input pauses (Prefect AI teams).
An orchestrator can represent the parent-child graph durably and call a remote A2A endpoint as one activity. It can also coordinate agents without direct messages, using workflow state, signals and task queues. That often makes recovery easier to reason about. The orchestrator still needs an envelope that says which principal owns the job, what the child may do and what evidence closes the parent.
A task is a state machine
The following lifecycle combines protocol states with the business states that surround them. The protocol states are documented by A2A 1.0 and MCP Tasks. The other states are Agentic Economy's proposed operating view for the application or workflow layer.
proposed -> discovered -> authorised -> submitted
|
v
working
/ | \
/ | \
input/auth child delegated retry or wait
| | |
+--------> working <---------+
|
v
artefact ready
|
v
acceptance pending
/ \
v v
accepted failed / rejected /
cancelled / expired /
unknown -> recover or reconcile
Figure 8.2. Delegated task lifecycle. proposed, discovered, authorised, acceptance pending, accepted, expired and recover or reconcile sit outside the core coordination state in at least one of the named protocols.
| Lifecycle state | A2A 1.0 representation | MCP Tasks representation | Required operating evidence |
|---|---|---|---|
| Proposed | Not a task yet | Not a task yet | Objective, principal, scope, expected result and owner |
| Discovered | Agent Card, interface and skill record | Server and tool or resource description | Source, version, freshness, authentication path and selection reason |
| Authorised | Agent-defined authentication and authorisation; not a universal state | Host and server security controls; not a universal task state | Authority record, policy decision, data boundary and expiry |
| Submitted | TASK_STATE_SUBMITTED acknowledges task receipt |
Task handle creation acknowledges an asynchronous request | Parent and child IDs, idempotency key, submission receipt and deadline |
| Working | TASK_STATE_WORKING |
working |
Current owner, progress, latest heartbeat or poll and external effects |
| Input required | TASK_STATE_INPUT_REQUIRED |
input_required |
Exact question, permitted responder, expiry and changed-scope check |
| Authentication required | TASK_STATE_AUTH_REQUIRED |
No equivalent core Tasks state; application or host state | Credential request, audience, user or workload identity and reauthorisation result |
| Child delegated | A new task and message context, if the implementation exposes them | A nested task or external workflow, if the server exposes one | Parent-child link, narrowed envelope, data transfer and child owner |
| Retry or wait | Application state around task updates and errors | Application state around polling, errors and task handles | Retry budget, backoff, duplicate prevention and reason for waiting |
| Artefact ready | artifacts or task artefact update events |
Terminal result, or a result returned by the wrapped tool |
Schema, content hash, provenance, completeness and side-effect receipt |
| Completed | TASK_STATE_COMPLETED |
completed |
Protocol terminal receipt; does not prove acceptance or commercial completion |
| Failed | TASK_STATE_FAILED |
failed |
Error class, partial effects, residual work and recovery decision |
| Rejected | TASK_STATE_REJECTED |
Application-level rejection | Reason, whether input can be corrected and whether any work or data was retained |
| Cancelled | TASK_STATE_CANCELED |
cancelled |
Request time, acknowledgement, observed stop point and any effects that remain |
| Expired, unavailable or timed out | Wrapper state around an inaccessible or stale task | Wrapper state around an inaccessible or stale task | Last known native state, possible effects, reconciliation before retry and an escalation owner |
| Unknown or indeterminate | TASK_STATE_UNSPECIFIED |
Client-side unknown state | Native value, separate external-effect status and a reconciliation owner where uncertainty remains |
| Accepted | Outside the protocol's terminal task semantics | Outside the protocol's terminal task semantics | Named acceptance actor, test result, rework and customer or operator record |
The key control is the distinction between completed and accepted. A child can complete while the parent discovers that the file has the wrong schema, the evidence is stale or the customer needed a different result. A cancellation can be acknowledged while an external action that already committed remains in place. A timeout can hide a successful side effect. Resource reconciliation therefore precedes any retry.
Failure is a join problem
Coordination failures happen at joins, not only inside a model call.
| Failure join | Example | What the protocol may show | What the business still needs |
|---|---|---|---|
| Discovery to endpoint | Card points to a retired URL or stale interface version | A failed request or unsupported operation | Card refresh, owner contact, replacement decision and no sensitive retry |
| Message to task | The caller loses the response after the server creates work | Connection error or unknown task status | Stable task ID, idempotent lookup and resource reconciliation |
| Parent to child | A child receives too much context or a broader objective | Child task completes normally | Envelope comparison, data-boundary proof and parent acceptance mapping |
| Task to artefact | Output is truncated, malformed or missing provenance | completed with an artefact or result |
Schema and hash checks, source lineage and rejection path |
| Push to receiver | A callback is duplicated or delivered after expiry | Repeated status event or webhook response | Authenticated receiver, deduplication, event ordering and replay policy |
| Cancel to effect | A downstream tool commits before it sees cancellation | canceled or cancelled task state |
Exact side-effect check, compensation and customer notification |
| Protocol to policy | Authentication succeeds but the job is outside purpose or budget | Valid message and authorised endpoint | Resource-level policy decision, denial evidence and accountable owner |
| Completion to commerce | A paid request returns a result that is not usable | Protocol task complete and payment settled | Delivery, acceptance, invoice, refund or contractual remedy |
The safest default after an ambiguous failure is not an automatic retry. First determine whether the remote participant created a task, changed an external resource or emitted an artefact. Then use the envelope's retry and reconciliation policy. A protocol's request identifier is not a universal idempotency guarantee for the resource being changed.
Delegation chains multiply evidence obligations
One agent can delegate to a second, which can delegate to a third. A message protocol can represent the immediate edge. The organisation needs the whole chain.
root job
-> parent task
-> child task A
-> grandchild task A1
-> child task B
-> parent artefacts and acceptance
For each edge, preserve:
- the parent job and task identifiers;
- the delegating and receiving agent identifiers;
- the principal and accountable owner;
- the objective, allowed scope and explicit exclusions;
- the data classes and records transferred;
- whether further delegation is allowed and the maximum depth;
- the acceptance condition contributed by the child;
- the deadline, cancellation authority and failure policy;
- the artefact identifier, content hash, schema and provenance;
- the identity or authority record used at the point of action; and
- the protocol, framework, version and runtime evidence.
Possession of an endpoint does not establish the child's authority, and a request for “a finished report” does not establish acceptance. Each hop needs a narrower purpose or an explicit reason why the same boundary is safe. A further supplier adds another data movement, returned result and accepting person or system to the chain.
This is where a durable workflow can help. Temporal's event history or Prefect's run state can preserve graph structure through a worker failure. They do not supply the principal or acceptance rule. The envelope remains the join key between the workflow, the protocol messages and the business record.
Artefacts need lineage, not just a download link
An artefact is useful when the receiver can determine what it is, where it came from and whether it satisfies the task. A file reference or JSON result is only the transport representation.
| Artefact fact | Minimum question | Evidence to retain |
|---|---|---|
| Identity | Which task and producer created it? | Parent and child task IDs, producer identifier and creation time |
| Content | What bytes or structured fields were delivered? | Content type, schema version, size and cryptographic hash |
| Provenance | Which sources, tools or child tasks influenced it? | Source references, versions, transformations and upstream artefact IDs |
| Authority | Was the producer allowed to access or create it? | Authority and policy references, not only transport authentication |
| Completeness | Is this final, partial, provisional or superseded? | Status, missing parts, pagination, continuation and supersession markers |
| Acceptance | Who decided it met the job's requirement? | Acceptance test, reviewer or deterministic check and timestamp |
| Use and remedy | What happened after delivery? | Resource receipt, downstream effect, rework, correction, refund or dispute |
A2A's Artifact object and MCP's terminal result can carry content and references. The surrounding system needs the rest. In particular, an artefact being present is not proof that a human or customer accepted it, and a result being cited is not proof that its sources were permitted or current.
Business models around coordination
Coordination protocols usually reduce integration friction. They do not automatically capture the value created by a completed job. Value can accrue to the directory, runtime, model provider, specialist agent, service provider, merchant or payment rail, depending on who controls a scarce boundary.
| Market layer | Typical buyer | Common operating or commercial model | What the buyer is actually paying for |
|---|---|---|---|
| Open protocol and specification | Framework, platform and service teams | Open implementation, foundation or consortium governance; support and hosted products may sit around the standard | A shared message and task vocabulary, not a completed service |
| Directory or registry | Agent platforms, developers and enterprise operators | Public or private index, self-hosting, managed search, support and integration | Fresh discovery, filtering, record exchange and sometimes provenance; listing alone is not demand |
| Agent framework | Application builders | Open-source library plus model, cloud, support and observability usage | Local routing, handoff, tools, guardrails, sessions and developer speed |
| Durable orchestrator | Operations, platform and engineering teams | Hosted or self-managed workflow service, metered runs, workers, storage and support | State, retries, timers, human waits, concurrency and recovery |
| Remote agent or specialist service | A business or another agent | Per-task fee, subscription, retainer, quote, usage, outcome-based contract or managed service | Capability and delivery of a defined result; the protocol is one access channel |
| Commerce and payment layer | Merchants, buyers, platforms and payment providers | Checkout or network fees, wallet or token services, payment processing and enterprise contracts | Order and settlement state, not the quality or acceptance of the underlying work |
The procurement implication is simple. An open protocol can make a supplier easier to reach while leaving the supplier's margin, support burden and liability unchanged. A hosted runtime can make recovery easier while adding platform dependency and operating cost. A directory can make a capability visible while shifting selection and verification work to the buyer.
What the sources establish
The named sources support a useful supply map. They do not provide one shared measure of interoperability or adoption.
| Evidence type | What it establishes | What it does not establish |
|---|---|---|
| A2A 1.0 specification | Defined data objects, operations, bindings, lifecycle states, artefacts and security responsibilities | That two specific providers implement the same version correctly or preserve authority and acceptance across a chain |
| MCP 2026-07-28 specification and Tasks extension | Host, client and server roles; context and tool primitives; opt-in asynchronous task semantics | That an MCP tool is an independent agent, that cancellation stops effects or that a host supports the extension |
| ARD proposal | A federated, JSON-LD and HTTP search model for heterogeneous agentic resources | Stable governance, broad publisher coverage, media-type finality, trust, quality or adoption |
| AGNTCY repository and tooling | A distributed directory design with OASF records, content addressing, provenance and deployment tools | A representative network denominator, current record quality or production usage |
| Framework documentation | Supported local patterns such as handoffs, agent-as-tools, sessions, approvals and checkpoints | Portable semantics, reliable outcomes, safe authority or customer acceptance |
| Managed runtime documentation | Hosting, session isolation, authentication integration, task queues or durable execution features | Correct configuration, service reliability for a particular workload, adoption or recourse |
| Repository, SDK or partner activity | A source implementation, example, compatibility intention or visible development | Active production traffic, accepted jobs, market share or business value |
| A dated conformance test | One implementation's behaviour in a named environment and version | General interoperability, future versions, quality or a commercial relationship |
| An accepted-job record | A defined result met a stated business test for a named principal and period | Protocol conformance, safety for other jobs or broad adoption |
The official documentation is strongest on the shape of the supply. It is weakest on the join between a remote task's terminal state and a buyer's accepted outcome. That is the seam the Delegation Envelope is designed to make visible. It is an analysis artefact, not a tested industry standard.
The Delegation Envelope
Each material delegation is represented by an envelope around the protocol interaction. The envelope owns the parent-to-child edge, inherited limits, task lineage and artefact acceptance. It references the current job, run and Authority Record instead of becoming another source of policy truth. Chapter 10 defines the shared record ownership and join keys. Implementations can hold the envelope in message metadata, an extension, orchestration state or a separate evidence store; secrets and unnecessary personal data sit outside it.
| Field | Recorded definition | Why the field survives the hand-off |
|---|---|---|
| Envelope version and ID | Which schema and unique record identify this delegation? | Lets receivers and auditors interpret the record and join retries |
| Root job, parent task and delegation depth | Which customer job and immediate task are in scope? How many hops have occurred? | Prevents a child task from becoming an orphan and makes chain limits enforceable |
| Principal and accountable owner | Who owns the objective, and who can accept, reject or stop the work? | Keeps responsibility distinct from the software actor |
| Delegator and delegatee | Which application, workload, provider and task instance are passing and receiving control? | Preserves actor identity even when several agents share a runtime |
| Objective and completion condition | What result is requested, and what is the stopping condition? | Prevents a vague request from expanding at the next boundary |
| Allowed scope and explicit exclusions | Which actions, resources, data classes and outputs are allowed? What is prohibited? | Gives the receiver a useful negative boundary, not only a positive prompt |
| Subdelegation rule | May the receiver delegate? What must be inherited, narrowed or refused? | Stops a child from silently creating a broader authority chain |
| Data boundary | Which inputs may cross, under which tenant, retention and handling rules? | Separates task context from permission to reuse or retain it |
| Task state and transport | Which protocol, version, task ID, status endpoint, callback or poll path is active? | Makes reconnect, monitoring and state translation explicit |
| Expected artefacts | Which schemas, formats, provenance, hashes and completeness markers are required? | Makes delivery inspectable before a buyer accepts it |
| Acceptance test | Which deterministic or human test decides whether the result is usable? | Stops protocol completion being mistaken for business completion |
| Deadline and expiry | By when may the work start, finish, receive input or use the authority? | Limits stale tasks, late artefacts and indefinite delegation |
| Failure, retry and compensation | How many retries are allowed, which errors are retryable and who repairs a committed effect? | Prevents a transport error from becoming a duplicate business action |
| Cancellation and stop path | Who may cancel, how is the request propagated and how is the observed stop recorded? | Makes cooperative cancellation and in-flight effects visible |
| Authority reference | Which identity, authority and policy record should the receiver or resource consult? | Links Chapter 8 coordination to Chapter 9 enforcement without duplicating it |
| Commercial reference | Which counterparty, quote, order, contract, service level, billing state, liability terms and dispute or remedy owner govern this delegation? | Joins task activity to Part III commerce without embedding payment credentials or implying that protocol completion settles the relationship |
| Evidence requirements | Which messages, tool receipts, decisions, artefacts, hashes and acceptance records must be retained? | Defines what recovery and dispute investigation can actually reconstruct |
| Issuer, signature and timestamps | Who issued the envelope, which version is current and when did each state change? | Supports freshness, tamper evidence and a reliable chronology |
Illustrative envelope shape
The following is a proposed shape, not a real job or evidence from an Agentic Economy test.
envelope_version: "0.1"
envelope_id: "env_<unique-id>"
root_job_id: "job_<root-id>"
parent_task_id: "task_<parent-id>"
delegation_depth: 1
principal_ref: "principal:<owner-record>"
accountable_owner_ref: "owner:<business-record>"
delegator:
agent_ref: "agent:<application>"
workload_ref: "workload:<instance>"
delegatee:
agent_ref: "agent:<receiving-system>"
provider_ref: "provider:<organisation>"
objective: "<bounded result and stopping condition>"
scope:
allowed: ["<named action>", "<named resource>"]
excluded: ["<prohibited action>", "<excluded data or resource>"]
subdelegation:
allowed: false
maximum_depth: 1
data_boundary:
inputs: ["<approved record or reference>"]
classes: ["<data class>"]
retention: "<rule or expiry>"
task:
protocol: "<A2A, MCP Tasks or application interface>"
protocol_version: "<version>"
state: "submitted"
status_ref: "<poll or callback reference>"
deadline: "<timestamp>"
artifacts:
expected: ["<schema and format>"]
provenance_required: true
content_hash_required: true
acceptance:
test: "<deterministic check or named reviewer>"
acceptance_owner_ref: "owner:<acceptance-record>"
failure:
retry_policy: "<bounded policy and idempotency key>"
cancel_policy: "<request, acknowledgement and reconciliation>"
compensation_owner_ref: "owner:<recovery-record>"
authority_ref: "authority:<record>"
commercial_ref: "<quote, order, contract or service-class reference>"
evidence:
retain: ["messages", "state transitions", "artefact receipt", "acceptance result"]
issued_at: "<timestamp>"
issuer_ref: "issuer:<record>"
The protocol-specific task ID and the root job ID are different records. A2A generates a server task ID. MCP Tasks creates a task handle at the server's discretion. The envelope supplies the cross-system join and records how a local ID maps to the parent job. Retries retain the root and envelope IDs while recording a new attempt.
Five delegation gates
- Issue: the delegation exists only when principal, accountable owner, objective, scope, exclusions, acceptance test and expiry are present.
- Transmit: approved data and references cross the boundary; credentials remain in identity and secret systems rather than the message or envelope body.
- Narrow: each child envelope preserves the root job and narrows scope, data, deadline and subdelegation unless a named owner approves a change.
- Reconcile: a timeout, duplicate event or cancellation leads back to the remote task and external resource before a retry.
- Close: protocol terminal state maps to artefact validation, acceptance, commercial records and any correction or compensation; a child's
completedstate cannot close the parent by itself.
What the market has not resolved
The market has several ways to describe capabilities and exchange tasks, but no broadly adopted commercial identity or accountability layer between independent agents. Agent Cards can advertise a service. A2A can carry messages and task state. Durable workflow products can retain a parent-child execution graph. The commercial relationship still sits elsewhere.
We expect open coordination protocols to become infrastructure rather than the whole product. Value will collect around discovery, hosting, identity, durable execution, proprietary data and accepted delivery. Protocol support will matter, but it is unlikely to be a durable differentiator on its own.
Where we see the market going
Coordination protocols will standardise discovery, task state and artefact exchange before they standardise trust or commerce. A2A and adjacent approaches can reduce bilateral integration work, but independently operated agents will still need application-level authority, lineage, acceptance and remedy.
The strategic contest will shift to directories and task control planes: who keeps capability claims current, who owns the durable task record and who can reconstruct a multi-agent failure. Protocol adoption will matter less than whether those records survive across implementations.
Five questions remain open:
- Can a portable envelope preserve principal, authority, scope, data boundary, task lineage and acceptance across A2A, MCP, local frameworks and durable workflow engines?
- How should a caller reconcile cooperative cancellation with an external action that has already committed?
- Can federated directories keep capability claims fresh and independently verifiable without becoming a new closed gatekeeper?
- Which commercial models will support repeated work, service levels, correction and recourse when an agent supplier is not a human-facing application?
- Will A2A, ANP and other coordination approaches converge on compatible task and artefact semantics, or remain specialised for different network assumptions?
Signals that would change our view
The chapter's conclusion would need revision if later evidence shows any of the following:
- A widely implemented coordination standard carries and enforces principal, permission, quality, commercial relationship and recourse semantics across organisations, rather than leaving them to extensions and contracts.
- Independent cross-provider tests demonstrate multi-hop jobs with durable state, bounded authority, correct artefact lineage, cancellation and accepted outcomes without substantial application-specific glue.
- Directory operators publish independently audited freshness, quality, adoption and remedy evidence that makes a listing materially equivalent to a trusted supplier decision.
- Longitudinal production records show that protocol completion reliably predicts customer acceptance and recovery across materially different jobs.
- A local framework or hosted runtime can prove end-to-end authority and acceptance for every delegated edge without a sidecar record such as the proposed Delegation Envelope.
About the author and editorial record
Agentic Economy is the accountable publisher of this report. Joel Chan founded the publication in Perth to research the infrastructure, companies and operating choices shaping the agentic economy. This chapter is source-led market analysis, not a sponsored ranking or proof that every listed protocol or product has been independently tested.
Summary
Coordination protocols make it easier for agent systems to find one another, exchange structured messages, track work and return artefacts. Among the specifications reviewed for this chapter, A2A 1.0 covers a broad task surface across discovery, messages, asynchronous state, artefacts and cancellation. That is a specification comparison, not an interoperability or reliability result. MCP is a complementary host-to-server interface, with an optional asynchronous Tasks extension. Local frameworks and durable orchestrators provide other ways to route and recover work.
The durable business requirement is wider than the wire. Every material delegation needs the principal, authority reference, scope, data boundary, parent-child task chain, artefact lineage, acceptance test, deadline, cancellation result and recovery owner. Protocol completion remains one event in a job, not proof that the customer received an accepted result.
Limitations
This chapter is a dated documentation review, not a conformance suite, production integration study or adoption estimate. Protocols and provider products change quickly. ARD is a proposal, ANP materials describe active development, and ACP (BeeAI) is recorded as historical because its repository directs the project into A2A. Framework and managed-runtime documentation describes supported capability, not reliability, quality, customer demand or recourse in a particular deployment.
No claim here establishes Australian availability, legal compliance, pricing, production use by a named customer or successful interoperability between the listed systems. The chapter does not define identity, authority, payment, tax, fulfilment, acceptance or dispute law. Those boundaries belong to Chapter 9, Part III and the accountable organisations operating each job.
Back to the report hub · Previous: tools, browsers and service access · Next: identity, authority and policy.