Inter-Agent Communication Protocol Design Beyond REST

Giving every customer an isolated AI agent requires a separate sandbox per user and task, with scoped credentials injected at runtime and revoked on completion. A single provisioning API call is not proof of that isolation. Inter-agent communication protocol design beyond REST joins tools, delegation, identity, authorization, and execution safely.

Why REST cannot carry a task that talks back

REST’s stateless request-response model works well for passive resources. Autonomous delegation asks more of the connection. A task may move through several states, pause for a decision, and pick up again after the caller gives it input. REST has no native task lifecycle for that exchange, so builders must supply the missing behavior themselves.

Streaming mid-execution feedback lets a caller learn what is happening while another agent works, before the final response. Agent identity establishes who is acting beyond the credential on one request, while cross-organizational trust establishes authority without shared infrastructure. Agentic Services Computing describes the underlying shift as one from functional endpoints to autonomous entities, which explains why adding more endpoints does not settle the problem.

How the inter-agent stack is layered and why the layers are separate

The 2026 stack divides those requirements by responsibility. MCP connects agents to tools and data sources. A2A or ACP handles agent-to-agent delegation, while an agent-to-frontend protocol handles streaming updates between agents and frontends. OASF and InterSAGE primitives address identity, capability attestation, and trust. OAuth 2.1 with Dynamic Client Registration supplies authorization across the seams, and OpenTelemetry GenAI supplies the tracing substrate for execution-to-identity binding.

These layers are not competing replacements for REST. A2A connects agents to each other. MCP connects them to tools, so most systems need both. Likewise, communication and trust have separate jobs. InterSAGE argues that trust primitives should remain portable while communication protocols evolve, rather than tying security guarantees to protocol versions. The hard design work is therefore where the layers meet, as one layer’s guarantees end and the next layer’s job begins.

MCP: what the tool layer actually provides and where it stops

MCP gives an agent a standard contract for discovering and invoking tools without knowing their implementation. For a builder, that means configuring access to a tool endpoint instead of teaching the agent each connector’s internal details. A single endpoint can expose thousands of tools. Composio uses this pattern to put its integration layer behind MCP, reducing the number of separate connections a product must build.

MausBot makes that benefit concrete for a founder-built product. It gained access to Gmail, Slack, GitHub, and Notion through Composio’s shared integration layer without building each connector individually. InterSAGE’s audit identifies agent-native identity, mutual authentication between agents, and authorization semantics beyond transport-level security as outside MCP’s core specification. MCP also does not select another agent for a subtask, track the delegation’s outcome, or handle an agent returning INPUT_REQUIRED during execution. Those needs belong to the next layer.

A2A: the task lifecycle protocol and what its seven states force a builder to design for

A2A makes delegation a task with seven explicit states. SUBMITTED means a request has been submitted, WORKING means the work is under way, and COMPLETED means it is done. INPUT_REQUIRED means the remote agent has reached a decision requiring the caller’s input, forcing a return path for that input. Without one, a recoverable pause becomes a permanent stall.

FAILED, CANCELED, and REJECTED also need to be handled in different ways. A failure may call for a retry, while cancellation records that the work was stopped on purpose. Rejection means the receiving agent refused the task before starting, so the caller needs a routing fallback. Treating all three as a generic error discards the information needed to respond correctly.

Duan and Lu’s A2A case study describes a multi-transport design supporting JSON-RPC 2.0, gRPC, and HTTP plus JSON, with streaming and push notifications. Agent Cards describe capabilities, input and output modalities, and authentication requirements before delegation. A2A v1.0.1 adds an extension mechanism for new data requirements and RPC methods, with official examples including Secure Passport, Timestamp, Traceability, and Agent Gateway Protocol. Identity remains a separate design problem, however. That version does not standardize agent-native identity, structured delegation chains, or a dedicated cross-domain trust plane.

Topology: why the wiring diagram determines reliability more than protocol choice does

Transport carries the messages, protocol sets out what they mean, and topology decides who talks to whom. These are three independent choices. An orchestrated hub-and-spoke system puts a coordinator in charge of delegation, which gives it strong context isolation and makes loop control straightforward. That coordinator also becomes a bottleneck at scale and a single point of failure. Both weaknesses remain when a lifecycle protocol is in place.

Direct A2A peer-to-peer communication has the lowest latency, but the number of connections grows roughly at N² scale and loops get harder to control. Small meshes are its more workable setting. A message bus instead uses topics for context isolation and lets subscribers join without rewiring existing agents, at the cost of broker dependency and ordering complexity. Its loop control sits between the other two approaches. Production systems can mix orchestration for high-trust coordination, direct exchanges for latency-sensitive specialists, and a bus for broadcast and monitoring.

Every message still needs identity, permission, expiry, and routing. OpenClaw illustrates the hub-and-spoke pattern by dispatching external coding harnesses through Agent Client Protocol sessions, collecting results, and coordinating them. Claude Code and Cursor are examples of those harnesses. Codex has a separate native app-server path and uses ACP only as a fallback.

The trust gap the communication protocols left open

A valid connection does not prove an agent’s claims. MCP and A2A define communication, but not how an agent proves its identity, verifies advertised capabilities, limits delegated authority across organizations, or remains accountable afterward. HTTPS and OAuth tokens alone leave those questions open. Impersonation, capability escalation, and repudiated commitments require guarantees beyond protecting a connection or authorizing a request.

InterSAGE maps that gap into four layers. Persistent Identity, L0, binds developer, code package, operator, and deployment context to a stable, verifiable identity. Discovery, L1, requires capability advertisements to be genuine, issuer-bound, and fresh. Trust Negotiation, L2, requires signed structural guarantees that delegated permissions shrink or stay within their original scope. Accountability, L3, binds usage, delegation, and execution traces to identity through cryptographic audit trails without requiring a consensus ledger.

That map does not settle the implementation choice. Coral Protocol takes a different approach through open, decentralized infrastructure for communication, coordination, trust management, and payment, built on distributed and blockchain principles. The trust layer remains contested ground. Its separation from communication protocols lets builders address that uncertainty without treating every new messaging version as a new security model.

OAuth 2.1, Dynamic Client Registration, and auth at every seam

OAuth 2.1 is the practical authorization layer. At the MCP seam, Composio’s managed-auth pattern lets an agent connect an account through a runtime session. The platform handles OAuth flows, API keys, token refresh, and credential lifecycle, with permissions scoped per connection. Authentication can follow what the user wants to do during a conversation. It need not all be configured in advance.

Composio stores each user’s credentials as a separate connected account so the agent acts for the right person without the developer handling tokens. MausBot and Ramp Inspect illustrate this credential-isolation requirement. Dynamic Client Registration addresses another practical problem. Agents provisioned per user or task cannot depend on every instance being manually registered beforehand, so DCR lets new instances register at runtime and receive scoped credentials.

The A2A seam has a broader published security menu. Its guidance includes HTTPS, API keys, HTTP auth, OAuth 2.0, OpenID Connect, and mutual TLS, rather than mandating OAuth 2.1 alone. It does not standardize delegation-chain representation. Request authorization therefore has a separate job from proving which agent acted, whether its authority grew during delegation, and whether later evidence can hold it to account.

How do you give each user an isolated AI agent environment?

Per-user and per-task sandboxing makes protocol-level protections meaningful at execution time. Separate tokens are not enough on their own. Agents that share a writable filesystem or a common credential environment can cross boundaries that the authorization layer was supposed to protect.

NVIDIA’s practical sandboxing guidance establishes the January 30, 2026 position that shared-kernel containers are insufficient for untrusted AI agent code. Its mandatory controls include network egress allowlists, workspace write restrictions, and configuration-file protection. That last control blocks changes to hooks, MCP server configs, and IDE extensions. Rather than inheriting every host API key, cloud role, and database connection string, an agent receives only task-specific credentials at runtime, revoked when the task completes.

CVE-2025-59528 in Flowise AI Agent Builder shows the failure mechanism, with a CVSS score of 10.0. Its root cause was unsafe use of JavaScript’s Function() constructor to process unvalidated user input in the application’s own process context, a failure only partly captured by “missing sandboxing. Execution isolation addresses the boundary that this failure crossed. Ramp’s engineering team chose separate ephemeral environments using sandboxed VMs for each Inspect agent session.

Discovery and observability: the two unsealed seams in the 2026 stack

Agent Cards help callers who know where to look. InterSAGE identifies the need to verify issuer provenance, subject binding, permission alignment, and freshness before interaction, which currently deployed protocols do not solve. Delegation across organizations consequently depends on shared documentation and manual vetting. That out-of-band work does not scale to an Internet of Agents.

OpenTelemetry GenAI supplies tracing, but standardized cryptographic binding between execution traces and agent identity is still missing. A trace can show what happened without proving which agent instance acted or whether it stayed within the scope of its authority.

Petrova et al.’s Web of Agents survey concludes that further progress depends less on protocol design than on the socio-technical infrastructure around it. The NIST AI Agent Standards Initiative, the Linux Foundation’s Agentic AI Foundation, and EU AI Act phased enforcement form part of that institutional layer. Technical specifications are not the whole deployment environment. Standards, regulation, and commercial payment networks are developing around the unresolved seams.

Design decisions that matter at each seam when building an agent-powered product

At the MCP seam, builders should choose between managed authentication and owning token storage and credential lifecycle themselves. Composio’s pattern trades platform dependency for less integration work. A single MCP endpoint reduces the integration surface, while per-tool registration offers finer revocation control. These are separate decisions, even when one platform bundles them.

At the delegation seam, implement distinct responses to INPUT_REQUIRED, FAILED, and REJECTED. Choose topology against latency, scale, and loop risk. Then decide whether extensions such as Traceability and Agent Gateway Protocol provide the observability and interoperability surface the product needs. Extensions can come into use without waiting for the core specification to change.

At the trust seam, use OAuth 2.1 and Dynamic Client Registration as the deployable authorization baseline while keeping persistent identity pluggable. Set credential scope at issuance so delegation cannot amplify permission. At execution time, choose between building isolation and using infrastructure that provides it, with one environment per user and task and task-scoped secret injection. Managed infrastructure avoids spending engineering time on that machinery. For a buyer seeking a per-user AI agent sandbox provisioned via single API call, the decisive criteria remain execution isolation, credential scope, network controls, and configuration protection.