A Reference Architecture

Agents as both hosts and peers

A practical enterprise layout: a front-door agent talks to the user and acts as an MCP host for its own tools (search, ticketing, internal APIs via MCP servers) and as an A2A client that delegates specialised, long-running work (billing, legal review, logistics) to remote agents owned by other teams. Each remote agent has its own MCP servers behind it. Between boundaries sit gateways that enforce authentication, rate limits, logging and policy, and a registry lists approved MCP servers and Agent Cards. Keep identity consistent (who is the end user?) by passing delegated, scoped credentials rather than shared super-keys, and keep context minimal across each hop.

Tools down, peers across

A real system uses MCP for tool access and A2A for collaboration, plus common engineering discipline.

The picture

Vertical links are MCP; horizontal links are A2A.

user -> [ Front-door agent ] ---- A2A (via gateway) ----> [ Billing agent ] -- MCP --> invoices DB
                |                                           [ Legal agent   ] -- MCP --> contracts
                | MCP (host)
                +--> search server   +--> ticketing server   +--> internal API server

gateway: authN/authZ, rate limits, logging, redaction     registry: approved servers + Agent Cards
identity: end-user identity -> delegated, scoped tokens per hop (never a shared super-key)

Quick check: In this architecture, what do the A2A links connect?

• Agents to other agents
• Agents to databases directly
• Browsers to GPUs
• Models to tokenizers