How MCP and ACP Work Together
Perception meets Action. The full agentic loop.
We've learned about MCP (the eyes/hands that read data and check stock) and ACP (the handshake that negotiates and pays). In a real-world agentic commerce transaction, these two protocols operate in a tight, interleaved loop.
You can't buy what you can't see (MCP), and you can't own what you can't pay for (ACP). This chapter visualizes how they come together to execute a complex user request.
The "Perception-Action" Loop
Let's trace a single complex request: "Find me a vintage 1990s Chicago Bulls jacket, verify it's authentic based on the tag, and buy it if it's under $200."
This is not a single API call. It is a state machine that switches between protocols.
Step 1: Perception (MCP)
The Agent needs to find candidates. It uses MCP to "query" the world.
call_tool("search_products", { query: "vintage bulls jacket 1990s" }) // Result: Found item #8821 at "VintageVault.com"
Step 2: Verification (MCP)
The Agent found a candidate but needs to check authenticity. It "visits" the product page virtually.
read_resource("products/8821/images") // The Agent's Vision Model analyzes the tag image. Confidence: 98%.
Step 3: The Pricing Handshake (ACP)
The listed price is $220. The Agent initiates an ACP session to negotiate.
ACP_MESSAGE: DISCOVERY { intent: "buy_now", target_price: 200 } Step 4: The Counter-Offer (ACP)
The Seller knows this item has been sitting for 3 months.
ACP_MESSAGE: OFFER { amount: 200, valid_until: "10m", terms: "final_sale" } Step 5: Execution (ACP + MCP)
The Agent accepts, signs the transaction, and monitors fulfillment.
ACP_MESSAGE: COMMIT { offer_id: "off_123", signature: "sig_abc..." } // Later...
call_tool("track_package", { carrier: "UPS", code: "1Z..." }) The "Brain" in the Middle (ReAct)
Crucially, neither MCP nor ACP "thinks." They are just pipes. The LLM (the brain) sits in the middle, constantly deciding which protocol to use.
This decision-making loop is often called the ReAct (Reasoning + Acting) Loop. Here is what the raw internal log of the agent looks like:
[ACTION] mcp.call_tool("search", "Bulls jacket")
[OBSERVATION] Found Item A ($220) and Item B ($150).
[ACTION] mcp.read_resource("Item A Images")
[OBSERVATION] Tag reads "Made in USA 1992". Looks authentic.
[ACTION] acp.send_message("PROPOSE 200")
Handling Failure & Partial Success
The real world is messy. What happens when things go wrong? This is where the interplay becomes critical.
Scenario: "Ghost Inventory"
MCP says "In Stock".
ACP negotiation starts.
Result: Payment fails because the Seller Agent checked the real warehouse db and realized the item is damaged. The ACP error message feeds back into the ReAct loop, prompting the agent to look for the next item.
Scenario: "Price Drift"
MCP lists price as $100.
Agent commits to buy.
ACP responds with "Price updated to $110".
Result: The agent pauses. It checks its "Budget Guardrails" (Chapter 7). If $110 > Limit, it asks the human for help.
The Multi-Agent Future
The most exciting capability is when an agent coordinates multiple downstream agents.
Imagine a "Travel Agent" (your personal bot) trying to book a trip.
- It speaks MCP to your Calendar ("When am I free?")
- It speaks ACP to United Airlines ("Book flight UA123").
- It speaks ACP to Marriott ("Book Room").
If the Marriott negotiation fails (no rooms), the Agent knows to rollback (cancel) the United flight immediately. This transactional integrity across different vendors is impossible with today's API silos.
Key Takeaways
- MCP handles the information gathering (Perception); ACP handles the transaction (Action).
- The 'ReAct Loop' is the brain that sequences these protocols based on observations.
- Handling partial failures (e.g., inventory mismatch) requires tight feedback between protocols.
- Multi-Agent orchestration allows for complex, atomic transactions across different vendors.