Who Does An Agent Protocol Connect?

1. One Renewal Question Needs Four Connections

A user asks in a web app: “Find the automatic-renewal clause, check our current plan, and ask the vendor specialist to confirm anything disputed.” A single agent.run() hides at least four independent questions:

1. How does the web app know whether the agent has started, is searching, is waiting for approval, or has failed?
2. How does the agent discover contract search and CRM lookup, including the parameters each capability accepts?
3. How does it discover a separate vendor agent and track work that may take minutes or require more input?
4. How does the runtime send history, tools, and streamed output to its model provider?

Either side of each connection may be built by a different team, in a different language, and released on a different schedule. If every integration invents another JSON envelope and callback set, replacing a frontend, tool service, or remote agent means rebuilding the adapter. Protocols exist to make those independent implementations cooperate.

2. A Plain Definition Of Protocol

A protocol is a public agreement between independently implemented parties about capability discovery, requests, state, results, and lifecycle.

An agent framework and a protocol sit at different layers. A framework decides who owns the loop, session, tool gate, memory, and graph inside a runtime. A protocol decides how an object crosses a boundary when it leaves that runtime. One framework can implement several protocols, and one protocol can be implemented by many frameworks.

3. Draw The Boundary Before Naming The Protocol

Ignore method names for a moment and place the participants. The Agent Runtime in the center owns this run, its session, and the tool loop. Four edges leave it or its product surface:

• User frontend ↔ Agent Runtime: AG-UI carries run, message, tool, and state events.
• Agent Runtime ↔ Tool/Data services: MCP discovers and invokes tools, resources, and prompts.
• Agent Runtime ↔ Remote Agent: A2A discovers the other agent and tracks Messages, Tasks, and Artifacts.
• Code editor ↔ Coding Agent: Agent Client Protocol carries coding sessions, streamed updates, and permission requests.

A fifth edge connects the Agent Runtime to a model provider. OpenAI Responses, Chat Completions, and Anthropic Messages are provider contracts. They are APIs, but in an agent-system map they answer “how does the runtime invoke a model?” rather than tool discovery, remote-agent collaboration, or frontend synchronization.

3.1 One Renewal Case Receives Several Linked Identities

Fix one unit for the rest of the chapter: renewal case RC-42. The product ledger first records the user and contract reference. Each protocol peer then creates the identity it owns. These are not interchangeable names; they form a parent-child correlation chain:

RenewalCase RC-42
└─ AG-UI thread th-9
   └─ frontend run r-3
      ├─ MCP tool call tc-7
      └─ A2A task at-88
         └─ Artifact ar-5
   └─ final UI message m-12

The runtime must persist this correlation because each protocol knows only its own work unit. The MCP Server does not need the full contract history; it receives a customer_id and query. The A2A specialist receives the disputed-clause summary and question. The UI receives displayable state. The provider receives the runtime's projected model view. A protocol standardizes the cross-boundary shape; it does not expose the entire internal ledger.

4. MCP: Let The Runtime See Tools And Data

4.1 An HTTP address is not enough

The renewal assistant needs contract search and CRM lookup. It must know more than an endpoint: which capabilities are currently available, which input schema each accepts, and whether a result contains text, images, or resource links. If capabilities change, the runtime also needs a way to refresh its registry.

MCP expresses this through Host, Client, and Server. The renewal assistant is the Host. It maintains one Client connection per MCP Server. Contract storage and CRM can be separate Servers. A Server may run locally over stdio or remotely over Streamable HTTP.

4.2 An MCP call does not begin at tools/call

1. Client and Server first initialize, exchanging protocol versions and capabilities.
2. The Client uses tools/list, resources/list, and related methods to discover actual capabilities.
3. The runtime selects the schemas appropriate for this user and conversation and exposes them to the model.
4. When the model chooses contract_search, the runtime routes a tools/call through the matching Client.
5. The Server returns structured content; the runtime decides how it enters the ledger, model context, and UI.

{"jsonrpc":"2.0","id":7,"method":"tools/call","params":{
  "name":"contract_search",
  "arguments":{"customer_id":"c-42","query":"automatic renewal"}
}}

This is a reduced wire shape. The important point is not the JSON-RPC boilerplate. The capability is discoverable and negotiable before invocation, and its result has a standard content shape afterward.

MCP is also broader than “remote function calling.” Servers expose tools, resources, and prompts; Clients can expose sampling, elicitation, and logging. Experimental Tasks add deferred retrieval and status tracking. Its primary edge is still runtime to tools and data, but the exchange across that edge can be bidirectional.

5. A2A: Delegate Work To An Opaque Remote Agent

5.1 A remote agent is not just a large tool

CRM lookup has a stable input and output and fits a tool. A vendor specialist is different. It has its own model, tools, memory, and approval process, and it may ask a human for more information. The caller should not need its prompt or tool chain. It needs the agent's declared capability, current task state, and final deliverable.

A2A targets independent, potentially opaque agent systems. The caller discovers capabilities, supported interfaces, and security requirements through an Agent Card, then sends a Message. A short exchange may return another Message. Trackable work becomes a Task, and its deliverables become Artifacts.

5.2 Task gives long-running collaboration an identity

1. The renewal assistant reads the Agent Card and finds a skill for interpreting vendor renewal rules.
2. It sends a Message containing the clause and the disputed question.
3. The remote agent returns a Task id whose status moves from submitted to working and may enter input-required.
4. The caller can poll, subscribe to streaming updates, configure push delivery, or cancel work that is no longer needed.
5. The remote agent completes the Task with an Artifact, while Task history retains the multi-turn collaboration.

Agent Card → Message → Task: working
                         ├─ status update
                         ├─ input-required → Message
                         └─ completed → Artifact

A2A 1.0 separates its canonical data model, abstract operations, and protocol bindings. The same Task, Message, Agent Card, and Artifact semantics can map to JSON-RPC, gRPC, or HTTP/REST. The important question is therefore not whether A2A “is JSON-RPC,” but whether each binding preserves the shared task semantics.

6. AG-UI: A Frontend Needs More Than A Token Stream

6.1 Text deltas cannot reconstruct an agent run

The renewal assistant has called two tools and started a remote task. If the backend emits only assistant text deltas, the browser cannot reliably answer: which run owns this delta? Which tool call is waiting? Which interruption should an approval resume? How should a reconnect rebuild state?

AG-UI defines the frontend to agent-backend edge as a bidirectional event protocol. A run enters as RunAgentInput, and the backend returns a stream of BaseEvent. threadId identifies the conversation line, while runId identifies one execution. Messages, tool calls, state, and lifecycle each have typed events.

RUN_STARTED(threadId, runId)
→ TOOL_CALL_START(toolCallId, "contract_search")
→ TOOL_CALL_ARGS(toolCallId, ...)
→ TOOL_CALL_RESULT(toolCallId, ...)
→ STATE_DELTA(...)
→ TEXT_MESSAGE_START(messageId)
→ TEXT_MESSAGE_CONTENT(messageId, delta)
→ RUN_FINISHED(runId)

The sequence tells the UI what one run is and which deltas belong to the same message or tool call. STATE_SNAPSHOT establishes a complete baseline, while STATE_DELTA carries incremental JSON Patch changes. The frontend no longer has to infer runtime state from prose.

6.2 An interrupt is a run outcome, not an unfinished reply

If CRM access requires user approval, the current run can finish with an interrupt outcome. The frontend renders the approval UI, then starts a new run with resume data after the user decides. The previous run has a clear terminal state, and the backend does not keep one HTTP request suspended indefinitely.

7. ACP: First Expand The Acronym

7.1 Agent Client Protocol connects an editor and a coding agent

Replace the example with a coding task: “Change the renewal reminder logic and run the tests.” The editor needs to launch or connect to an agent, create several sessions, provide files and prompts, stream messages and tool calls, and ask the user for permission before the agent executes a command.

This is a side comparison, not a mid-run protocol swap inside RC-42. A browser business product will usually express runs and UI state through AG-UI. ACP fits when the editor itself owns the workspace, coding sessions, and command-authorization surface.

Agent Client Protocol standardizes that edge. For a local agent, the editor commonly launches a subprocess and exchanges JSON-RPC over stdin/stdout. The agent uses notifications to stream session updates to the UI and bidirectional requests to ask the editor for tool permission. ACP reuses MCP types where useful, but its participants remain editor and coding agent, not MCP Client and Server.

editor launches agent subprocess
→ initialize
→ session/new
→ session/prompt
→ session/update ...
← session/request_permission
→ user decision
→ session/update ...

7.2 Agent Communication Protocol is a different historical ACP

ACP searches also find BeeAI's Agent Communication Protocol. It addressed remote communication among agents, applications, and people, so its boundary was closer to A2A than to an editor protocol. The repository was archived in 2025, and its README states that the work became part of A2A under the Linux Foundation. This article therefore uses ACP for Agent Client Protocol. Older material must be disambiguated by the full name.

8. Why Responses And Chat Completions Sit In Another Row

The AgentScope chapter compared OpenAI Responses and Chat Completions concretely. Responses uses typed items and can continue through response identity. Chat Completions primarily accepts a messages array, with different tool-call and result wire shapes. AgentScope needs two formatters and model adapters before normalizing both into one internal ChatResponse.

That difference matters, but it occurs between the runtime and model provider. MCP does not choose which OpenAI API invokes the model. An A2A peer may use an entirely different provider. An AG-UI frontend should consume stable UI events rather than provider deltas. Keeping provider APIs on a separate edge makes each adapter responsible only for semantics it actually owns.

9. Replay The Whole Renewal Task

The straight success path is easy. A better integration test is a remote agent asking the user for more information. Let at-88 enter input-required and follow the durable record:

1. The browser sends RunAgentInput; the runtime links RC-42 to th-9 / r-3.
2. The model selects contract search. After permission checks, the runtime sends MCP call tc-7 and records its result.
3. For disputed language, the runtime sends a summary to the A2A specialist and stores returned Task at-88.
4. at-88 returns input-required. The runtime stores parent thread, Task id, question, and waiting_user, then ends r-3 with an interrupt.
5. AG-UI projects the question to the frontend. The answer creates a new run r-4; it does not revive an old HTTP request.
6. The runtime finds the original Task and sends the answer as a new Message to at-88. The remote agent returns ar-5.
7. The runtime stores the Artifact reference, merges local and remote evidence, and asks the model for message m-12.
8. AG-UI emits final text and RUN_FINISHED; the product ledger marks RC-42 completed.

before input-required
RC-42: {run: r-3, a2a_task: at-88, status: waiting_remote}

after input-required
RC-42: {run: r-3, a2a_task: at-88, question: "Which region?",
        status: waiting_user, resume_from: at-88}

after user reply
RC-42: {run: r-4, a2a_task: at-88, artifact: ar-5,
        final_message: m-12, status: completed}

Failure paths retain different owners. An MCP failure returns as a tool error to r-3, not an empty result. An A2A timeout keeps at-88 for query, cancellation, or later reattachment. A browser disconnect interrupts event delivery only; reconnect should rebuild the UI from snapshot and deltas without rerunning tools.

If the entry surface is a code editor, Agent Client Protocol may replace AG-UI at the outer edge. The coding agent can still use MCP for tools and A2A for remote delegation. “Primary boundary” means each protocol has a main position, while several protocols can compose in one run.

10. Compress The Map Only After Teaching It

11. Do Not Begin Protocol Selection With “Supported?”

A README that says “supports MCP/A2A/AG-UI” proves only that some integration surface exists. It does not prove that every lifecycle semantic is complete. A more useful review order is:

1. Draw the parties: is the runtime calling a tool, delegating to an agent, serving a frontend, or being launched by an editor?
2. Find the identity owner: who creates, persists, and restores tool-call, task, run, and session ids?
3. Inspect termination: are success, failure, cancel, user input, and resume first-class states or custom text?
4. Audit security: who enforces connection identity, user authorization, argument validation, and Artifact or resource visibility?

A protocol does not create trust automatically. An MCP tool is not authorization for the current user. An A2A Agent Card skill is not proof of peer identity. AG-UI can carry an approval decision, but the frontend must not bypass backend policy. Protocols give security information an interoperable carrier; each owner must still enforce the decision.

11.1 Accept Protocol Support Through Recovery Tests

Before adopting an adapter, run at least five scenarios: the Host refreshes after an MCP Server schema change instead of sending stale arguments; a restarted caller reattaches to A2A Task at-88; an AG-UI reconnect rebuilds from a snapshot without duplicate execution; backend policy revalidates frontend authorization; and changing model provider does not force the frontend to understand a new delta format.

Passing these cases validates protocol semantics. Enabling the adapter in production and choosing which users receive it remain application adoption decisions. “Adapter exists,” “recovery tests pass,” and “product enables it” are three distinct states.

12. Carry This Map Into The Framework Chapters

These names recur later, but each occurrence should return to its boundary. ADK's Agent and Workflow first explain internal execution. Agno places that route inside AgentOS and several external interfaces. AutoGen and Microsoft Agent Framework compare a multi-agent runtime with production orchestration. CrewAI separates role collaboration from deterministic Flow. Eino uses Go components and graphs. tRPC-Agent-Go exposes distinct MCP, A2A, AG-UI, and OpenAI-compatible server surfaces.

The next chapter enters ADK Python. With protocol boundaries separated, the series can return inside the framework and ask how autonomous Agent decisions and deterministic Workflow steps coexist on one Runner and Event path.

Official Specifications And Documentation

• Model Context Protocol architecture
• A2A latest released specification
• AG-UI overview
• AG-UI core architecture
• AG-UI events
• Agent Client Protocol introduction
• Agent Client Protocol architecture
• Agent Client Protocol session setup
• Agent Client Protocol prompt turn
• Archived Agent Communication Protocol and A2A migration notice
• OpenAI Responses API migration guide