In Part I: An Integrator's Take on MCP, A2A, and ACP, we broke down the "alphabet soup" of AI Agent protocols. We established that A2A is for agents talking to agents, and MCP (Model Context Protocol) is the standard way agents access data and tools.

Today, we move from theory to practice.

We are going to build a Self-Healing Supply Chain. We’ll take a classic integration nightmare—a stuck order at 3 AM—and fix it using IBM webMethods, Zowe, and the power of MCP and A2A working together.

The Nightmare: The "Stuck" Order 😱

You know the drill. It’s Black Friday. An order comes into your webMethods Integration Server. The flow tries to book shipping via "Carrier X," but their API returns a 503 Service Unavailable.

The Old Way:

  1. webMethods throws an exception.

  2. PagerDuty wakes you up.

  3. You manually reroute the order and log into the Mainframe (green screen) to update the status.

The Agentic Way: You stay asleep. The robots handle it.

The Architecture: MCP Meets A2A

To make this work, we aren't replacing our integration stack; we are augmenting it. Here is the critical distinction we missed in the "Old Way": Standardized Tool Access.

  1. The Ops Agent (The Orchestrator): This agent lives inside your firewall. It uses A2A to ask for help, but critically, it uses an MCP Client to actually do things.

  2. The Zowe MCP Server: This is the magic sauce. Instead of hard-coding Zowe CLI commands into a script, we wrap Zowe in a Model Context Protocol (MCP) server. This exposes Mainframe capabilities (Jobs, CICS transactions, DB2 queries) as standardized "Tools" that the Ops Agent can discover and use safely.

  3. The Logistics Agent (The Specialist): An external or specialized internal agent that knows about shipping APIs.

The Workflow: A Sequence of Events

Here is exactly how the A2A negotiation and MCP execution happen in real-time.

Step 1: The Trigger

webMethods Integration Server hits the 503 error. Instead of purely logging text, it pushes a structured event to the Ops Agent.

Step 2: The Handshake (A2A)

The Ops Agent realizes it needs external help. It uses the Agent-to-Agent (A2A) protocol to ping the Logistics Agent.

  • Why A2A? Because the Ops Agent doesn't need to know how to call Carrier Y's API. It just needs to negotiate the outcome (price < $50).

Step 3: The Tool Use (MCP)

Here is where the rubber meets the road. The order is fixed in the cloud, but the Mainframe (System of Record) is out of sync.

In the past, giving an AI write-access to the Mainframe was terrifying. But with MCP, we introduce a safety layer. The Zowe MCP Server only exposes specific, approved "Tools" (functions) to the agent.

The Agent doesn't hallucinate a CICS command; it selects the cics_update_order tool from the MCP catalog provided by the Zowe server.

Agent Internal Thought: "I have a new tracking number. I see a tool named cics_update_order in my MCP context. I will call it with arguments id=12345 and carrier=Y."

Why This Changes Everything

This isn't just error handling; it's governed autonomy.

  • A2A let us separate concerns (Ops vs. Logistics).

  • MCP gave us a safe, standardized bridge to the Mainframe (via Zowe) without writing custom adapters for every single potential action.

  • webMethods kept the core business process running.

We just moved from MTTR (Mean Time To Resolution) to MTTI (Mean Time To Ignore—because it fixed itself). What this exercise demonstrates is that this new agentic future isn't about ripping out your existing infrastructure; it's about giving your proven, reliable infrastructure, like IBM webMethods and Zowe implementations, a serious brain transplant. By gluing them together with standardized protocols like A2A and MCP, we are finally moving past just "trapping errors" into genuine "self-healing." And honestly, any architecture that fixes a broken process at 3 AM before my phone goes off is a win in my book.

References and Further Reading

For those who want to dive deeper into the protocols and tools mentioned in this architecture:

Reply

or to participate

Keep Reading

No posts found