The acronym is the first architecture test. If a meeting begins with “ACP” and nobody expands it, pause. In today's agent ecosystem, ACP can refer to more than one protocol, and those protocols solve different problems.
For teams building with Kiro, ACP means Agent Client Protocol. It standardizes the connection between a user-facing client, such as an IDE, and a coding agent. MCP means Model Context Protocol. It standardizes how an AI application discovers and uses external tools, resources, and prompts. The older IBM Agent Communication Protocol addressed agent-to-agent communication, but IBM now states that project is part of A2A under the Linux Foundation [3]. There is also an Agentic Commerce Protocol in the market, which belongs to commerce workflows and is outside the scope of this article.
The distinction is more than vocabulary. It tells you where a protocol belongs in the system:
- MCP connects an agentic application to capabilities.
- Agent Client Protocol connects an interactive client to a coding agent.
- A2A connects independent agents when work must cross an agent boundary.
- APIs and events remain the right choice when the interaction is deterministic and does not need agent discovery.
Once those boundaries are clear, MCP and ACP stop looking like competing standards. They become complementary parts of an enterprise agent architecture.
The Clean Mental Model: Experience, Capability, and Delegation
MCP follows a host-client-server architecture. The host manages the AI experience and security decisions, each MCP client maintains an isolated connection to one server, and servers expose focused capabilities such as tools, resources, and prompts [1]. That structure answers a practical question: what can this AI application access and do?
Agent Client Protocol answers a different question: how can a client application interact with a coding agent without a custom integration for every pairing? The protocol covers sessions, prompts, streaming updates, tool calls, permission requests, file access, and terminal interactions. Its role resembles the Language Server Protocol pattern: a common connection lets clients and agents evolve independently [2].
Delegation is a third boundary. When one independently deployed agent must discover another, assign a task, exchange artifacts, or track a long-running job, use an agent-to-agent protocol such as A2A. Do not force MCP to impersonate a multi-agent task protocol. Do not use editor-oriented ACP as a generic enterprise message bus.
| Architecture question | MCP | ACP: Agent Client Protocol | A2A |
|---|---|---|---|
| What does it connect? | AI host to tools, data, resources, and prompts | Editor or client experience to a coding agent | Independent agent to independent agent |
| Best fit | Capability discovery and invocation | Interactive coding-agent experiences | Cross-agent delegation and task exchange |
| Typical boundary | Agent runtime to enterprise systems | IDE, CLI, web, or mobile client to agent harness | Team, runtime, vendor, or trust boundary |
| Avoid using it for | General distributed workflow state | Tool catalogs or arbitrary business integrations | Simple tool calls that belong behind MCP |
This table is a design guide, not a claim that every system needs all three. A single assistant that reads a CRM and opens a ticket may need only MCP. A coding agent embedded in several editors may need ACP and MCP. A network of specialist agents owned by different teams may add A2A.
Kiro Shows How ACP and MCP Fit Together
Kiro offers a useful reference architecture because both protocols appear in one product without doing the same job.
Kiro documents one unified agent harness behind its IDE, CLI, web, and mobile experiences. Those clients talk to the harness through Agent Client Protocol. The harness manages conversation state, model access, permissions, context, tool execution, and agent behavior. Local clients can connect over stdio, while remote surfaces can connect to a sandboxed harness over WebSocket [4].
MCP sits on the other side of that harness. When a developer connects an AWS documentation server, a project tracker, or an internal engineering service, MCP adds those capabilities to the agent's available tool and context set. Kiro's own ACP documentation makes the layering visible: ACP session updates can report tool calls, while Kiro-specific ACP extensions can report MCP server initialization and OAuth requests [4].
Think of the flow this way:
Developer in an editor -> ACP -> Kiro agent harness -> policy and permission checks -> MCP -> approved engineering capability
ACP keeps the agent experience portable across compatible clients. MCP keeps external capabilities portable across compatible AI hosts. The harness is the control point that joins the two.
This separation helps platform teams avoid a common mistake: embedding every integration directly into every user interface. If a Jira action is coded into an editor plug-in, another client must rebuild it. If the action is exposed as a governed MCP tool, Kiro can discover it through the harness and any other authorized MCP client can reuse it.
Amazon Quick Extends the Same Capability Fabric to Business Teams
Amazon Quick demonstrates the other side of the architecture. It is a business-facing AI experience, not a coding editor, so Agent Client Protocol is not the relevant integration boundary. MCP is.
AWS documents that Amazon Quick can connect to remote MCP servers and register each exposed tool as an action that its AI assistant can invoke in a conversation [5]. A project management MCP server, for example, can let a user create a ticket, retrieve an issue, or update status without a one-off connector for each conversational experience.
Quick supports MCP servers reachable on the public internet and private servers reachable through an Amazon Quick VPC connection. Private servers can run in a connected VPC or on premises through Direct Connect or VPN. AWS also documents user OAuth, service-to-service authentication, PKCE, and resource indicators. Quick supports remote MCP connections rather than local stdio servers, and prefers HTTP streaming over the earlier SSE approach [5].
Now place Kiro and Quick over the same governed capability layer:
- A developer uses Kiro to inspect an incident, propose a code change, and open a remediation task.
- A product manager uses Quick to review the same incident's customer impact and update priority.
- A designer uses an approved research or design-system capability to retrieve the affected journey and attach acceptance evidence.
- An operator uses the same incident capability to verify deployment status and record the recovery timeline.
These users should not receive identical permissions. They should reuse the same capability contract with identity-aware authorization, action-level policy, and role-specific views. Reuse belongs at the tool and evidence layer, not at the permission layer.
That is the beginning of a shared capability fabric: one catalog of trusted actions available through several agent experiences, with policy deciding who can see and invoke each action.
Make MCP Tools Product Interfaces, Not Thin API Wrappers
The fastest way to create an unusable MCP estate is to expose every REST endpoint as a separate tool. The model sees a crowded catalog, tool descriptions consume context, and users inherit internal API complexity.
AWS Prescriptive Guidance recommends designing tools around complete user workflows, particularly when several API operations commonly belong together. It also recommends splitting tools that grow beyond one user intent or require too many parameters [6]. That guidance points to a broader principle: an MCP tool is a product interface for an agent.
Every production tool should define:
- 1User intent. State the outcome in language a person would use, such as “prepare release readiness evidence,” not the underlying endpoint name.
- 2Authority. Identify which human or workload identities can discover and invoke the tool, and which parameters are further restricted.
- 3Contract. Use a narrow schema, bounded values, useful descriptions, and versioned behavior.
- 4Risk class. Separate read, draft, reversible write, irreversible write, and regulated-data actions.
- 5Evidence. Return source identifiers, timestamps, status, and enough structured output to verify what happened.
- 6Failure behavior. Define timeouts, retries, idempotency, partial success, and escalation rather than returning an ambiguous paragraph.
- 7Operational target. Assign an owner, service level, cost budget, and deprecation process.
The distinction between discovery and permission is especially important. Hiding irrelevant tools improves selection quality, but discovery filtering alone is not authorization. The server or gateway must enforce the caller's rights again at invocation time.
A Collaboration Model for Product, Design, Engineering, and Operations
Protocols create interoperability. They do not create collaboration on their own. Cross-functional teams need a shared artifact model that turns a business intent into a traceable capability release.
Start with a capability brief owned by product. It defines the user, desired outcome, source systems, allowed actions, success measure, and explicit non-goals. The brief is small enough to review and precise enough to become acceptance criteria.
Design then defines the interaction and evidence contract. Which information should be visible before a tool runs? Where must the user approve? How does the experience display a draft, a completed action, a partial failure, or a denial? The designer is not decorating an agent transcript. They are specifying how human judgment enters the workflow.
Engineering implements the protocol contracts. ACP carries the interactive coding session where appropriate. MCP exposes the approved enterprise action. A2A is added only if responsibility genuinely crosses to another independently operated agent. The developer also supplies contract tests, policy tests, idempotency behavior, and observable events.
Security owns the decision points, not a late-stage checklist. It defines identity propagation, least-privilege scopes, data boundaries, approval thresholds, server allowlists, credential handling, and incident controls. A remote MCP server that can write to a system of record should never depend on a model prompt as its authorization layer.
Operations owns the runtime truth. Every interaction should carry a common correlation ID from client session to agent turn, MCP invocation, downstream system, and result. Teams need latency, success, denial, cost, and human-intervention signals segmented by capability version. Without that chain, an agent may complete a task while the organization remains unable to prove what changed.
The resulting delivery path is simple enough to repeat:
Brief -> experience contract -> tool contract -> threat model -> evaluation set -> staged release -> runtime evidence -> product review
This is how different disciplines develop one capability without handing documents across organizational walls. Each role contributes to the same versioned object and evaluates the same business outcome.
Security and Reliability Practices That Survive Production
Local MCP servers deserve the same scrutiny as any executable installed on a developer machine. Kiro warns that a local stdio server can run with the environment's privileges and may access source code, environment variables, secrets, and credentials. Review the package, pin versions, restrict available credentials, and prefer a managed remote server when central policy and shared operations matter [4].
For remote MCP and ACP connections, apply a production baseline:
- Authenticate people and workloads separately. A service token should not silently inherit a user's business authority.
- Default to deny. Allow read tools first, require explicit policy for writes, and put human confirmation in front of high-impact or irreversible actions.
- Validate both directions. Inspect tool arguments before execution and outputs before they enter model context. Treat retrieved text as untrusted data because it may contain prompt injection.
- Keep credentials out of protocol payloads. Use a secret manager, short-lived credentials, OAuth where supported, and server-bound tokens.
- Version schemas and pin clients. Capability negotiation does not replace compatibility testing. Run contract tests against every supported client and server version.
- Make writes idempotent. Retries should not open duplicate tickets, charge a customer twice, or apply the same infrastructure change again.
- Separate environments. Development agents should not discover production write tools by default. Use different server registrations, identities, and policy sets.
- Trace decisions and effects. Log the requesting identity, agent, model, tool version, policy decision, arguments hash, downstream result, latency, and cost without copying sensitive payloads into every telemetry store.
MCP's official architecture deliberately gives the host responsibility for connection permissions, consent, authorization decisions, and context aggregation [1]. Enterprises should treat those as explicit control-plane functions. A protocol connection is not evidence that the connected capability is safe.
A 90-Day Path From Integrations to a Capability Fabric
Days 1 to 30: map the boundaries. Inventory agent clients, MCP servers, direct APIs, plug-ins, and agent-to-agent calls. Expand every ambiguous ACP label. Identify duplicate tools and capabilities that bypass identity or audit controls. Select one high-value, reversible workflow shared by at least two roles.
Days 31 to 60: build one governed capability. Design the tool around user intent, place it behind a managed MCP endpoint, enforce user or workload identity, and add structured evidence. Connect it to a coding experience such as Kiro and a business experience such as Amazon Quick where the use case supports both. Give each role a distinct policy.
Days 61 to 90: operate and expand. Run evaluation prompts, failure injection, permission tests, and schema compatibility checks. Measure task completion, incorrect tool selection, denials, latency, human approvals, and cost. Publish the capability in an internal registry only after its owner and runtime target are clear. Add a second workflow by reusing the same identity, policy, telemetry, and release path.
The goal is not the largest MCP catalog. It is the smallest trusted set of capabilities that meaningfully improves work across roles.
Turn Protocol Choices Into an Operating System
Tactical Edge helps enterprises move from protocol experiments to governed capability delivery. Connectory provides the inventory and relationship layer for agents, MCP servers, owners, policies, data sources, and business outcomes. Our Agentic Process Transformation and AgentOps services turn priority workflows into tested AWS architectures with identity, observability, evaluation, cost controls, and human decision points designed in from the start.
The core design principle is straightforward: use ACP for the client-to-agent experience, MCP for reusable capabilities, and A2A only where independent agents truly need to collaborate. Then place all three inside one operating model that can answer who owns a capability, who may invoke it, what evidence it returns, and whether it improves the work.
That is how a product manager, designer, developer, security engineer, and operator stop using separate AI assistants and start building a shared system of capability.
Talk with Tactical Edge about your enterprise agent protocol architecture.
References
[1]Model Context Protocol. “Architecture.” https://modelcontextprotocol.io/specification/2025-06-18/architecture
[2]Agent Client Protocol. “Protocol Overview.” https://agentclientprotocol.com/protocol/v1/overview
[3]IBM Research. “Agent Communication Protocol.” https://research.ibm.com/projects/agent-communication-protocol
[4]Kiro. “How Kiro Works” and “Agent Client Protocol.” https://kiro.dev/docs/how-kiro-works/ and https://kiro.dev/docs/cli/acp/
[5]Amazon Web Services. “Model Context Protocol Integration: Amazon Quick.” https://docs.aws.amazon.com/quick/latest/userguide/mcp-integration.html
[6]Amazon Web Services. “Model Context Protocol Strategies on AWS.” https://docs.aws.amazon.com/pdfs/prescriptive-guidance/latest/mcp-strategies/mcp-strategies.pdf
[7]Model Context Protocol. “Transports.” https://modelcontextprotocol.io/specification/2025-06-18/basic/transports