ACP Architecture: Building Interoperable AI Agent Systems

The durable lesson from ACP is simple: agent intelligence should be decoupled from agent communication.

That separation allows a product team to add a research specialist, replace a framework, or move a service to a different runtime without forcing every collaborating agent to be rebuilt. ACP made this idea tangible; A2A carries it forward for new cross-agent implementations.

01 / The architectural pressure

Specialisation should not create a tangle of custom integrations

A useful agent system rarely remains a single generalist for long. A planner may understand the user and break down work; a domain specialist may hold the best prompts, models, evaluation data, and permissions for a narrow task; another service may own search, compliance, or a business workflow. The value is in the hand-offs.

Without a shared boundary, every new connection becomes a private contract: bespoke endpoints, framework-specific message objects, implicit state, and unclear ownership. The system becomes harder to change precisely when it is becoming more capable.

Interoperability is not making every agent identical. It is agreeing on the minimum contract required for agents to work together safely.

02 / ACP architecture

Put the protocol at the edge of the agent

The Agent Communication Protocol (ACP), developed through IBM’s BeeAI ecosystem, addressed that integration problem with an HTTP-native, open communication layer. Its core pattern can be read as:

Client → ACP service → protocol wrapper → agent → tools and data

The client discovers an agent and requests work. The ACP-facing service provides the standard protocol boundary. Behind it, a wrapper translates structured protocol messages into the implementation an existing agent understands, then translates the result back. The agent itself can remain a LangChain, LangGraph, CrewAI, BeeAI, or custom implementation.

The wrapper is the practical hinge. It is where teams can validate input, enforce authentication and authorization, normalise errors, shape responses, and emit traces—without making an internal agent redesign itself around every external caller. It is an adapter, not a second brain.

Protocol layerDiscovery and exchange

Define how clients find capabilities, submit work, receive status, and interpret structured messages.

Agent layerReason and decide

Keep prompts, planning, models, private logic, and domain workflows inside the service that owns them.

Tool layerAct with bounded access

Connect APIs, databases, documents, search, and repositories through explicit credentials and policy.

03 / Execution model

A run makes agent work observable

ACP represented an execution as a Run. That matters because agent work is often not a single request followed by a single response. A run can produce intermediate output, operate asynchronously, stream progress, or pause for information before completion. Messages and message parts provide a structured way to carry text, files, images, JSON, and other content.

This is a helpful contract for the operations team as much as for the application developer: a run has an identifier, a lifecycle, input, output, and a visible failure state. It makes retries, audit trails, timeouts, and human approvals first-class design concerns rather than afterthoughts.

Design implication: a task status is not the same thing as a chat message. Preserve both. A person needs an understandable update; an operator needs a durable record of the request, the delegated work, the evidence returned, and the final action.

04 / Two complementary boundaries

Use MCP for capabilities; use A2A for collaborators

ACP and the Model Context Protocol (MCP) solve different problems. MCP standardises how an AI application or agent connects to tools, data sources, and external capabilities. ACP was designed for communication between independently implemented agents. They were complementary, not competitors.

Orchestrator agent
  ├─ A2A → specialist agent
  └─ MCP → tools, data and resources

Specialist agent
  └─ MCP → its own tools, data and resources

ACP’s original repository is now archived, and its maintainers state that ACP has become part of A2A under the Linux Foundation. For a new cross-agent integration, start with A2A. The architecture remains familiar: discover a capable peer, delegate a task, follow the task lifecycle, and receive results without coupling yourself to the peer’s framework or private implementation. MCP remains the complementary boundary for tools and data.

05 / A practical application

Apply the pattern to a resume-aware job-search assistant

The public CareerFlow experience already makes the user-facing side clear: upload a resume, review detected skills, choose a location, and use a CopilotKit-powered assistant to search. It is a strong example of where specialised collaboration can add value without making the interface more complicated.

The public page does not disclose every backend service, so the design below is an architectural extension—not a claim about its current implementation. A coordinating agent can retain the user context and ask a dedicated opportunity-research agent for evidence-led results. That remote specialist owns its search workflow and uses MCP to reach a tool such as Tavily. An AWS environment can provide isolated runtime, identity, secret handling, audit logs, and policy enforcement.

ACP and MCP architecture explainer. A short visual walkthrough of the separate but complementary communication and tool-access boundaries discussed in this section.

Notice what this avoids. The CopilotKit interface does not need Tavily credentials. The coordinating agent does not need to know the researcher’s internal prompt chain. The research specialist can improve its sourcing or change its runtime behind its public contract. Each boundary has a clear owner.

06 / Production choices

Interoperability needs operating discipline

A shared protocol does not create trust by itself. Before connecting a specialised agent, make the operational contract explicit.

Capability firstDiscover what an agent is allowed to do

Describe supported tasks, inputs, outputs, limits, and expected evidence. Do not route work only by a mutable endpoint name.

Least privilegeDelegate authority with the task

Give each agent only the user consent, scopes, credentials, and data it needs. Do not pass broad, reusable secrets through messages.

Evidence and provenanceReturn sources with recommendations

For a job-search result, retain the source URL, retrieval time, matching rationale, and any uncertainty so users can verify it.

Traceable lifecycleMake failure recoverable

Use task IDs, idempotency keys, deadlines, cancellation, and trace correlation across agent and tool boundaries.

On AWS, this normally means separate workload identities for agents, short-lived credentials, a secret manager rather than prompt-visible keys, encrypted data paths, centralised logs and traces, and clear retention rules for personal documents such as resumes. The protocol chooses how systems communicate; platform controls determine whether that communication is safe to run.

07 / The lasting idea

Build agents as components, not islands

ACP is best understood as an important step in the move toward interoperable agent architecture. Its direct implementation path has moved into A2A, but the design principle is more durable than any one specification: separate communication from intelligence.

When agents can be discovered, delegated to, governed, and observed through a clear boundary, teams gain the freedom to specialise without locking the whole system into one framework. A2A provides today’s cross-agent path; MCP equips those agents with the tools and data they need. Together, they make a multi-agent system easier to evolve with intent.

Further reading: the archived ACP repository, the A2A documentation, and the MCP introduction.