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
Multi-agent delegation and trust boundaries
When an autonomous system divides a complex objective across specialized sub-agents, delegation crosses distinct architectural perimeters.
Two independent agents can exchange syntactically valid JSON messages across a network while remaining in complete operational disagreement about critical commercial terms: which corporate principal authorized the job, what budget ceilings apply, what quality metrics define delivery acceptance, who invoices the customer, and who absorbs financial loss if an automated action fails.
Coordination protocols standardize message formatting, task polling, and artifact delivery between software actors. They do not by themselves establish corporate authority, commercial terms, output quality, or legal recourse.
Agent-to-agent coordination represents the structured exchange of capability metadata, task state, and delivered artifacts between independently operated agent systems. Independent operation implies separate runtime processes, distinct security perimeters, or independent corporate organizations. It does not imply that an agent possesses legal personhood or acts without an underlying human or corporate principal.
The engineering challenge in multi-agent architectures is determining what operational state must survive a task hand-off and which system enforces it. Production deployment requires a standardized message protocol paired with an immutable delegation record, a cryptographic authority reference, artifact lineage tracking, and a designated human or workflow recovery owner. Protocols can transport these parameters as payload metadata, but the commercial and legal obligations remain external to the wire.
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.
Two distinct coordination markets
The multi-agent landscape has divided into two distinct technical domains:
- In-process multi-agent orchestration: Coordination within a single application boundary. Frameworks expose manager-worker hierarchies, specialized sub-agent routines, and in-memory hand-offs where a single runtime maintains state and credentials.
- Cross-boundary agent coordination: Protocols connecting independently operated agent systems across different applications, VPCs, or corporate organizations. Standards like A2A, Agent Cards, and decentralized capability directories operate at this external boundary.
In-process frameworks manage thread scheduling and tool selection. Cross-boundary coordination requires standardized discovery schemas, asynchronous task state machines, and cryptographic artifact verification. Durable workflow engines can supervise execution across either model.
When Google announced the Agent2Agent (A2A) protocol, it framed universal interoperability as essential for autonomous collaboration (Google Developers Blog, "Announcing the Agent2Agent Protocol"). Industry participation confirms strong demand for interoperability standards. However, technical message interoperability does not automatically resolve legal delegation, commercial pricing, or cross-organizational dispute resolution.
The technical boundary of coordination protocols
Coordinating across independent agent systems requires resolving six operational questions:
- How does a client discover candidate agent services?
- How do participants declare supported modalities, schemas, and protocol versions?
- How are task instructions, contextual data, and parameter inputs structured?
- How is the lifecycle of long-running, asynchronous tasks monitored after submission?
- How are intermediate progress, clarification prompts, cancellations, and failures communicated?
- How are output files, datasets, and structured artifacts delivered and referenced?
These requirements focus on communication mechanics. An agent system can remain a complete black box to its caller; executing a delegated task does not require exposing internal system prompts, proprietary vector databases, or private tool code. The stated design of A2A 1.0 is to allow independent agents to negotiate tasks and collaborate without exposing private internal state or execution tools (A2A Protocol Specification).
However, critical commercial parameters remain outside the network message:
- Principal identity: Which corporate entity or individual owns the objective and balance sheet?
- Authority scoping: What specific corporate resources, databases, and financial budgets is the downstream agent permitted to touch?
- Quality validation: What objective acceptance test verifies that the delivered deliverable satisfies the contract?
- Commercial structure: Does the transaction operate as a one-off API query, a binding commercial quote, or a contracted enterprise service?
- Liability and recourse: Which party absorbs operational and financial loss when an autonomous sub-agent hallucinates, leaks data, or fails to deliver?
While an A2A endpoint can enforce authentication via standard mTLS or OAuth tokens, the specification leaves authorization policies entirely to the receiving host. Similarly, Model Context Protocol security guidance notes that consent and authority enforcement cannot be resolved at the wire protocol layer (MCP Specification 2026-07-28). A cryptographically signed message confirms payload integrity; it does not establish that the sender possessed corporate authority to commission the work, or that the deliverable satisfies enterprise acceptance criteria.
The National Institute of Standards and Technology (NIST) highlights that software-agent identity, authority, and auditability represent critical enterprise security boundaries that must be managed independently of message transport (NIST, "Identity and Authority of Software Agents").
Protocol boundary mapping
The protocol landscape separates into distinct layers: tools access, inter-agent task delegation, and commercial settlement:
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
| Operational boundary | Dominant protocols | Core problem solved | Requirements outside the protocol |
|---|---|---|---|
| Application to tool/context | Model Context Protocol (MCP), direct REST APIs | Standardizes how a single agent discovers and invokes tools or context | Cross-agent task delegation, supplier trust, payment settlement, legal recourse |
| Agent to independent agent | A2A 1.0, Agent Network Protocol (ANP) | Standardizes how independent agents discover each other, pass tasks, and stream progress | Corporate principal mapping, spending mandates, work acceptance, commercial terms |
| Resource and capability discovery | A2A Agent Cards, ARD v0.91, AGNTCY Directory | Standardizes metadata schemas describing agent capabilities and endpoints | Independent uptime validation, security audits, pricing verification, commercial fit |
| In-process multi-agent routing | OpenAI Agents SDK, Microsoft Agent Framework | Coordinates routing, hand-offs, and shared context across local sub-agents | Cross-organizational identity federation, portable task schemas, vendor contracts |
| Commerce and order states | Universal Commerce Protocol (UCP), Agentic Commerce Protocol (ACP) | Standardizes product catalogs, shopping carts, and order status transitions | General task coordination, deliverable quality inspection, SLA dispute recourse |
| Payment authority and settlement | AP2, x402, Machine Payments Protocol (MPP) | Standardizes payment mandates, challenge-response flows, and digital clearing | Verifying business task delivery, three-way invoice matching, accounting ledgers |
| Identity and authorization | OAuth 2.0, SPIFFE/SPIRE, AuthZEN, policy engines | Establishes authenticated identities and evaluates least-privilege policies | Conversation state machines, task progress streaming, final deliverable acceptance |
Note on protocol terminology: The acronym ACP is used in two unrelated domains. IBM and BeeAI originally developed an Agent Communication Protocol, which has since migrated into the A2A project under the Linux Foundation (ACP repository). In Part III of this report, ACP refers to the Agentic Commerce Protocol, an e-commerce checkout standard.
An endpoint can be reachable via A2A while remaining governed by an off-band master services agreement. A merchant can expose an automated checkout protocol while fulfillment is executed manually. An MCP server can wrap a paid third-party API without involving multi-agent delegation. Architecture is governed by the functional boundary crossed.
Who supplies coordination infrastructure
The multi-agent ecosystem spans open protocol specifications, distributed directories, cloud hosting runtimes, and durable workflow engines:
| Organization or standard | Technical layer | Documented capabilities | Commercial model | Operational boundary |
|---|---|---|---|---|
| A2A 1.0 | Open agent-to-agent protocol | Standardizes Agent Cards, messages, multipart payloads, tasks, artifacts, streaming, push notifications, and cancellation across JSON-RPC, gRPC, and HTTP | Open standard supported by agent frameworks and cloud hosting platforms | Defines wire formats and state transitions; does not provide verified uptime SLAs, quality guarantees, or commercial dispute recourse |
| MCP 2026-07-28 | Host-client-server protocol for tools and context | Standardizes resource discovery, prompts, JSON-RPC tool invocation, progress tracking, and capability negotiation | Open specification and open-source ecosystem | Optimized for tool and context integration; stateless request model does not constitute cross-organizational delegation contract |
| MCP Tasks | Asynchronous execution extension | Introduces durable task handles, polling APIs, input_required states, terminal status, and cooperative cancellation |
Optional extension negotiated during protocol initialization | Host support is optional; cancellation is cooperative and does not guarantee that underlying backend processes halt |
| AGNTCY Directory | Distributed discovery and capability exchange | OASF-based capability records, content-addressed storage, cryptographic provenance, and distributed synchronization | Open-source directory deployable on private infrastructure | Tooling provides registry primitives; does not verify publisher reliability, uptime, or commercial quality |
| Agentic Resource Discovery (ARD) v0.91 | Federated resource discovery | Standardizes JSON-LD metadata for MCP, A2A, skills, and APIs via /.well-known/ard.json |
Open proposal for registries and publishers | Specification in draft; authentication and artifact schemas are delegated to underlying services |
| Microsoft Agent Framework | Local agent orchestration and durable execution | Supports agent-as-tool and mesh hand-off patterns, checkpointing, human approvals, and Durable Functions integration (handoffs) | Framework included with Azure AI compute and Azure Functions consumption | Optimizes in-process and Azure-hosted execution; does not establish cross-organizational commercial contracts |
| Amazon Bedrock AgentCore A2A | Managed A2A runtime hosting | Containerized A2A server hosting, automated Agent Card publication, SigV4/OAuth 2.0 integration, and session isolation (runtime contract) | Managed AWS cloud compute and API gateway consumption | Hyperscaler manages container infrastructure and proxy routing; application retains full responsibility for task authority and delivery quality |
| OpenAI Agents SDK | Client agent orchestration library | In-process multi-agent orchestration via agents-as-tools, stateful hand-offs, guardrails, and session tracing | Open-source SDK driving OpenAI model API consumption | Manages local in-memory execution; hand-offs stay within a single run and do not provide remote cross-network task guarantees |
| Temporal Durable AI | Crash-resilient workflow engine | Event-sourced state persistence, automated worker recovery, multi-day human waits, and task queue routing across agent steps | Open-source server with managed Temporal Cloud consumption | Preserves execution graphs and coordinates retries; interactions with external third-party agents still require idempotency keys |
| Prefect | Dynamic workflow orchestrator | State-machine task tracking, runtime branching, automatic retries, task caching, and typed human input pauses | Open-source engine paired with Prefect Cloud control-plane plans | Workflow primitives track task lifecycles; does not evaluate model reasoning validity or factual accuracy |
| Agent Network Protocol (ANP) | Layered agent networking suite | Decentralized identity (DID-WBA), end-to-end encrypted messaging, agent discovery, and meta-protocol negotiation | Open-source MIT specification | Comprehensive networking architecture currently in active community development |
Broad vendor support establishes protocol supply. Enterprise procurement must distinguish between the wire protocol, the hosting runtime, and the commercial contract.
Discovery versus selection in multi-agent routing
Discovery identifies candidate endpoints: What services are advertised on the network? Selection enforces enterprise governance: Which service is authorized, qualified, and insured to execute this specific task?
Agent Cards as discovery metadata
A2A 1.0 establishes the Agent Card as the foundational discovery schema. An Agent Card declares provider identity, supported protocol versions, task capabilities, input/output schemas, accepted authentication mechanisms, and human documentation (A2A Agent Card specification).
This provides a vital preliminary filter. A client system can verify whether an endpoint supports required data formats before transmitting sensitive context. It allows automated version negotiation and caching.
However, an Agent Card is a publisher-asserted advertisement. Cryptographic signatures verify payload integrity and author identity; they do not prove that the endpoint is currently available, that its model outputs are accurate, that the provider carries commercial liability insurance, or that the client's internal spending policy permits calling it. An Agent Card is a discovery record, not an enterprise procurement approval.
The six-stage verification ladder
Evaluating external agent services requires progressing through six operational gates:
| Verification gate | Technical evidence required | Remaining commercial uncertainty |
|---|---|---|
| 1. Listed | Valid Agent Card, directory entry, or ARD JSON-LD manifest | Whether the endpoint is currently active, reachable, or trustworthy |
| 2. Reachable | Successful TLS connection, DNS resolution, and authenticated ping | Whether the caller holds authorization or the system can execute tasks |
| 3. Protocol-compatible | Passes declared A2A or MCP schema validation and version negotiation | Real-world output quality, data handling compliance, and commercial terms |
| 4. Task-complete | Endpoint executes multi-step task and returns a terminal status code | Whether the returned deliverable satisfies business acceptance criteria |
| 5. Formally accepted | Authorized human or automated verification rule confirms output meets scope | Performance repeatability, unit contribution margin, and ongoing support |
| 6. Commercially reconciled | Purchase order, invoice, payment settlement, and tax records reconcile | Whether the business derived positive ROI and retains legal recourse |
Messages, tasks and artifacts
Multi-agent coordination operates across three distinct data objects:
- Messages: Ephemeral communication payloads exchanged between agents.
- Tasks: Stateful operational records representing work progressing over time.
- Artifacts: Output files, datasets, or structured results generated by a task.
Task-centric state in A2A
A2A 1.0 places the Task at the center of its protocol model. A task maintains a unique server-generated ID, an optional contextId for multi-turn collaboration, real-time status, artifact references, and execution history. The protocol defines explicit operations to submit messages, stream intermediate thoughts, poll task state, cancel execution, and subscribe to push notifications (A2A Protocol Specification).
This decouples the client from synchronous HTTP connections. A client agent can dispatch a complex analytical research brief, disconnect, and reconnect hours later to inspect progress or download deliverables.
However, protocol task completion must not be confused with business acceptance. In A2A, TASK_STATE_COMPLETED confirms only that the remote software reached its internal stopping condition. It does not verify that the returned analysis was factual, that the client's business rules were satisfied, or that external database updates were committed accurately.
Asynchronous tool execution in MCP Tasks
The Model Context Protocol’s core design assumes stateless, synchronous JSON-RPC request-response cycles. To accommodate long-running operations, the optional MCP Tasks extension introduces durable server-held task handles.
Clients opt into the extension, allowing servers to return a task ID that can be polled via tasks/get. The extension defines five core states: working, input_required, completed, failed, and cancelled. Cancellation is cooperative: a server acknowledges a cancellation request, but is not architecturally forced to terminate underlying background processes immediately.
An MCP task represents an extended tool invocation within a host application's control loop. It does not establish an independent counterparty relationship; the host maintains ownership of the workflow.
In-process orchestration in developer SDKs
The OpenAI Agents SDK provides two in-memory orchestration patterns:
- Agents-as-tools: A primary manager agent invokes specialized sub-agents as synchronous functions to resolve sub-tasks, retaining full control over the central user conversation.
- Handoffs: The active agent transfers execution authority entirely to a specialized sub-agent, which directly interfaces with the user for the remainder of the interaction (OpenAI multi-agent orchestration; handoffs).
Microsoft Agent Framework supports a similar architecture: workflows can route tasks through a decentralized agent mesh or maintain centralized supervisor hierarchies, with state checkpoints persisting across session databases (Microsoft Agent Framework handoffs).
These patterns provide clean developer abstractions within a single codebase. They do not represent cross-organizational coordination protocols. The OpenAI Agents SDK explicitly notes that client-side routing checks cannot validate parameter security inside argument-bearing hand-offs; enterprise authorization must be enforced independently before committing external side-effects.
Managed hosting versus durable orchestration
Amazon Bedrock AgentCore Runtime provides managed hosting for A2A-compliant containerized servers, supporting automated Agent Card discovery, SigV4/OAuth authentication, and session isolation (AgentCore A2A runtime). Hyperscaler hosting manages container scaling and network proxying; it does not define the business contract or provide legal dispute arbitration.
Durable workflow engines like Temporal and Prefect approach multi-agent coordination from the execution persistence layer (Temporal Durable AI; Prefect AI teams). A Temporal workflow can manage a complex parent-child agent graph, surviving node crashes, network timeouts, and extended human approval pauses, while invoking external A2A endpoints as discrete activities. Combining durable workflow orchestration with standardized A2A messaging provides crash resilience across distributed agent networks.
The delegated task lifecycle
A production task traverses sixteen discrete operational states, bridging wire-level protocol events with enterprise governance ledgers:
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
| Lifecycle state | A2A 1.0 status | MCP Tasks status | Mandatory operational evidence |
|---|---|---|---|
| Proposed | External to protocol | External to protocol | Sponsoring business owner, task objective, acceptance criteria, and budget ceiling |
| Discovered | Agent Card / Skill manifest | Server / Tool schema | Publisher ID, schema hash, supported versions, and selection rationale |
| Authorized | Local authorization check | Host client security check | Enterprise Authority Record ID, policy engine approval, and data residency boundary |
| Submitted | TASK_STATE_SUBMITTED |
Task handle created | Root job ID, parent task ID, unique idempotency key, and execution deadline |
| Working | TASK_STATE_WORKING |
working |
Active worker ID, progress percentage, heartbeat timestamp, and interim logs |
| Input required | TASK_STATE_INPUT_REQUIRED |
input_required |
Explicit clarification query, authorized responder identity, and response timeout |
| Auth required | TASK_STATE_AUTH_REQUIRED |
Application-level state | Credential request payload, target audience, requested OAuth scopes, and re-auth rule |
| Child delegated | Nested task context | Sub-task execution | Child task ID, narrowed delegation envelope, and sub-delegation depth counter |
| Retry / Waiting | Application-level state | Polling backoff state | Retry budget count, backoff parameters, idempotency key, and error reason |
| Artifact ready | artifacts update event |
Terminal result returned | Artifact URI, MIME type, cryptographic content hash, and source lineage |
| Completed | TASK_STATE_COMPLETED |
completed |
Protocol terminal receipt; explicitly distinct from business acceptance |
| Failed | TASK_STATE_FAILED |
failed |
Error classification, partial execution state, and recovery routing decision |
| Rejected | TASK_STATE_REJECTED |
Application-level rejection | Rejection rationale, input validation errors, and data purge confirmation |
| Cancelled | TASK_STATE_CANCELED |
cancelled |
Cancellation timestamp, acknowledgement receipt, and committed side-effect audit |
| Timed out | Application-level timeout | Application-level timeout | Last verified state, in-flight action reconciliation, and incident escalation |
| Unknown state | TASK_STATE_UNSPECIFIED |
Client unknown state | Ambiguous write record, reconciliation queue ID, and prohibition on automated retries |
| Formally accepted | External to protocol | External to protocol | Inspecting reviewer ID, acceptance test result, and three-way invoice matching |
The critical architectural separation is between completed and accepted. An agent service can achieve protocol completion while delivering an artifact with hallucinatory data, invalid legal analysis, or an expired schema. Completed indicates execution termination; accepted confirms commercial fulfillment.
Operational failure modes across coordination joins
Multi-agent failures concentrate at the interfaces where systems hand off execution:
| Coordination interface | Concrete failure mode | Wire-level manifestation | Enterprise remediation requirement |
|---|---|---|---|
| Discovery to endpoint | Agent Card references an expired URL or retired schema version | HTTP 404 Not Found or unsupported method error | Refresh directory cache, notify provider, halt execution; prohibit blind fallback |
| Message to task | Network drops after server creates task but before client receives ID | Network timeout or connection reset | Query status via distributed idempotency key; reconcile before re-submitting |
| Parent to child | Parent accidentally transmits unauthorized context or customer PII | Child processes task normally | Audit data boundary leakage, execute security incident response, notify privacy officer |
| Task to artifact | Returned deliverable is truncated, corrupted, or missing citations | Task reports completed status |
Validate artifact SHA-256 hash and schema; reject invalid deliverable; trigger rework |
| Push notifications | Webhook callback is duplicated, delayed, or received out of order | Repeated HTTP POST to client webhook | Authenticate webhook signatures, enforce replay protection, verify event sequence |
| Cancel to execution | Downstream agent commits a financial charge before receiving cancellation | Remote task reports cancelled |
Execute explicit compensation or refund request; alert business account owner |
| Protocol to policy | Message is authenticated but requested task breaches corporate budget | HTTP 200 message exchange | Intercept request at policy gateway; enforce hard budget ceilings; log policy breach |
| Completion to billing | Sub-agent reports success and bills customer, but deliverable is unusable | Protocol task complete; charge settled | Route deliverable to dispute queue; hold merchant payout; initiate formal SLA review |
Following an ambiguous failure, the default action must never be an unconstrained retry. The system must query whether the remote agent created a task, altered an external database, or settled a payment.
Managing multi-hop delegation chains
When an autonomous agent delegates a sub-task to an external agent, which in turn sub-delegates to a third-party service, operational risk compounds exponentially:
root job
-> parent task
-> child task A
-> grandchild task A1
-> child task B
-> parent artefacts and acceptance
Governing multi-hop delegation requires tracking ten parameters at every hop:
- Root job ID and immediate parent task ID.
- Identifiers for both delegating and receiving agents.
- Accountable corporate principal and sponsoring business owner.
- Bounded task scope and explicit negative exclusions.
- Permitted data classes and associated privacy handling rules.
- Explicit sub-delegation permissions and maximum allowable delegation depth.
- Specific acceptance criteria required from the child deliverable.
- Execution deadlines, timeout limits, and cancellation protocols.
- Artifact schema requirements and cryptographic hashing standards.
- Sponsoring authority records and payment mandate references.
Possessing a valid network endpoint does not grant an agent authority to sub-delegate corporate tasks. Each hop must inherit a strictly narrowed mandate, explicit data residency limits, and defined legal recourse.
Artifact verification and data lineage
A delivered artifact requires rigorous verification before entering downstream enterprise workflows:
| Verification dimension | Operational question | Mandatory audit evidence |
|---|---|---|
| Provenance | Which specific agent, model, and workflow version produced the artifact? | Parent and child task IDs, producer public key, creation timestamp |
| Integrity | Have the delivered bytes been corrupted or tampered with in transit? | Cryptographic SHA-256 hash, byte size, and format schema |
| Lineage | Which input documents, external APIs, and sub-agents influenced the result? | Source document URIs, ingestion timestamps, and sub-agent task references |
| Authorization | Was the producer authorized to access the underlying source data? | Authority Record IDs and policy decision logs |
| Status | Is the deliverable final, provisional, partial, or superseded? | Lifecycle status tags and pagination metadata |
| Acceptance | Who formally verified that the artifact satisfies business requirements? | Inspecting analyst ID, automated test suite run ID, sign-off timestamp |
| Recourse | What commercial remediation applies if the artifact is defective? | Transaction receipt, SLA terms, credit request, or formal dispute record |
Commercial models in agent coordination
Coordination protocols reduce integration friction, but value captures around scarce operational boundaries:
| Market layer | Typical customer | Commercial monetization model | True source of commercial value |
|---|---|---|---|
| Open protocols (A2A, MCP) | Framework builders, enterprises | Open-source foundation governance; consortium sponsorship | Interoperable message schemas; does not deliver completed business work |
| Capability directories | Enterprise developers, agents | Subscription tiers, verified listing fees, managed search APIs | Curated discovery, verified publisher trust, and active endpoint health monitoring |
| Development frameworks | Application engineering teams | Open-source core with commercial cloud tracing, hosting, and tooling | Rapid prototyping, developer productivity, and pre-built integration scaffolding |
| Durable workflow engines | Platform and DevOps teams | Metered cloud execution, state storage fees, and enterprise support | Fault-tolerant state persistence, automated worker recovery, and multi-day pauses |
| Specialized agent services | Corporate business units | Fixed task fees, monthly retainers, metered usage, or outcome pricing | Domain expertise and guaranteed delivery of verified business deliverables |
| Commerce and clearing | Merchants, enterprise buyers | Transaction percentages, clearing fees, and merchant acquiring spreads | Secure payment execution, dispute arbitration, and three-way ERP matching |
Open protocols commoditize communication transport. Defensible enterprise value accumulates in discovery curation, durable state management, proprietary domain data, and guaranteed outcome delivery.
Evaluating coordination evidence
Analyzing multi-agent coordination claims requires matching evidence types to the operational conclusions they support:
| Evidence source | What it establishes | Unresolved operational question |
|---|---|---|
| A2A 1.0 specification | Standardized message schemas, task operations, and bindings | Real-world multi-vendor interoperability, output quality, or commercial recourse |
| MCP Tasks extension | Asynchronous task handles, polling semantics, and cooperative cancellation | Multi-agent delegation governance, cross-organization trust, or financial clearing |
| ARD v0.91 proposal | JSON-LD schema design for federated agent discovery | Media-type standard approval, publisher coverage, or active market adoption |
| AGNTCY repository | Distributed directory architecture and content-addressed storage code | Active network node volume, record freshness, or enterprise production usage |
| Framework documentation | Supported developer patterns for in-memory hand-offs and tools | Multi-tenant security isolation, cross-company trust, or balance-sheet liability |
| Hyperscaler runtime docs | Managed container hosting, session proxies, and IAM integrations | Real-world reliability across messy legacy systems or third-party outages |
| Public partnership news | Corporate marketing intent and initial integration exploration | Production transaction volume, accepted business deliverables, or realized ROI |
| Conformance test suite | Protocol compliance of an isolated endpoint within a controlled test | Operational reliability, prompt injection defense, or commercial contract enforceability |
| Job-level production log | Empirical evidence of verified task completion for a specific principal | Generalizability across unrelated enterprise workflows or industry domains |
The Delegation Envelope
Production systems require an explicit operational envelope wrapping every multi-agent interaction:
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 five delegation gates
Production systems enforce five operational gates across every hand-off:
- Issuance gate: The delegation is invalid unless principal, accountable owner, objective, scope, exclusions, acceptance criteria, and deadlines are explicitly populated.
- Transmission gate: Only authorized data records cross the network boundary; enterprise credentials remain isolated in secure vaults rather than passing through message payloads.
- Narrowing gate: Each child delegation automatically inherits the root job ID while strictly narrowing scope, data access, spending limits, and delegation depth.
- Reconciliation gate: Ambiguous timeouts, duplicate callbacks, or cancellation acknowledgments must query remote resource state before triggering retries.
- Closure gate: A child's
completedstatus cannot close the parent task; final closure requires artifact schema validation, human or rule-based acceptance, and three-way financial reconciliation.
The trajectory of agent coordination
Multi-agent coordination protocols are standardizing message formats, asynchronous task state machines, and artifact transport. They do not by themselves establish corporate authority, commercial terms, or legal recourse.
Market advantage will concentrate in directory curation, durable state orchestration, proprietary domain context, and guaranteed outcome delivery. Supporting protocols like A2A and MCP will become a standard baseline for software connectivity, while commercial differentiation will center on whether systems can enforce authority boundaries and guarantee accepted business work.
Every delegated task requires an unambiguous answer to the foundational governance question: Who authorized this action, under what policy, and how is that authority instantly revoked? Chapter 9 examines the identity and policy layer: managing corporate standing, enforcing runtime guardrails, and proving effective revocation.
Sources and method
- Primary sources: Technical specifications, developer documentation, and official repositories from A2A (Linux Foundation), Model Context Protocol, AGNTCY, ARD Project, Microsoft Agent Framework, AWS Bedrock AgentCore, OpenAI, Temporal, Prefect, and Agent Network Protocol checked as of 13 September 2026.
- Analytical frameworks: The Protocol Boundary Map, the sixteen-state delegated task lifecycle, and the Delegation Envelope are original analytical structures developed to evaluate multi-agent governance.
- Evidence boundaries: Specifications establish declared message schemas and protocol state machines. Production interoperability, sub-agent uptime, and commercial recourse require empirical validation on customer workloads.
- Institutional references: Public concept papers from the National Institute of Standards and Technology (NIST) on software agent identity and authority establish the governance context for delegated computing.
- Editorial record: Published by Agentic Economy, Perth, Western Australia. Updates and corrections are logged via the editorial record.
Back to the report hub · Next: identity, authority and policy.