A2A & MCP Workshop: Automating Business Processes with LLMs — Damien Murphy, Bench

A deep dive into using Google's A2A (Agent-to-Agent) framework and MCP (Model Context Protocol) to build intelligent, automated workflows. This summary covers the core concepts, strategic implementation, a practical multi-agent architecture, and critical insights on lean context management to control costs and latency.

July 26, 2025 4 min read

A2A & MCP Workshop: Automating Business Processes with LLMs — Damien Murphy, Bench — source: https://www.youtube.com/watch?v=wXVvfFMTyzY

The current challenge in AI is not building simple agents, but creating autonomous agents that can perform complex tasks. The A2A (Agent-to-Agent) and MCP (Model Context Protocol) frameworks are emerging as key components for building these sophisticated, automated business processes.

Demystifying A2A and MCP

A2A (Agent-to-Agent) is a protocol from Google designed for communication between remote AI agents, particularly those you don’t control. Its key benefits include:

Agent Specialization: Instead of one monolithic agent doing 100 things, you can have 100 specialized agents that each do one thing very well.
Task Delegation: A primary agent can delegate tasks to specialized third-party agents (e.g., a Salesforce agent).
Parallel Processing: Tasks can be run in parallel, improving speed.
Hidden Complexity: The inner workings of a remote A2A agent are completely opaque; you connect to it and discover its capabilities without needing to know its implementation details.

MCP (Model Context Protocol) is often called the “USBC for AI.” It provides a standard interface for agents to consume external context, tools, and resources without needing to build custom API integrations. Its power comes from its plug-in architecture and access to a massive ecosystem of tools, including over 7,000 integrations from Zapier alone.

The Strategic Decision: When to Use A2A and MCP

A common point of confusion is when to use these protocols. The decision should be a strategic one based on control and necessity.

When NOT to use them: If you have full control over your agents and the tools they use, it’s often better to avoid A2A and MCP. Calling functions directly within your own codebase is faster, easier to maintain, easier to debug, and avoids protocol overhead. “Why do you need to create, you know, a USBC? It’s kind of like me plugging in my hard drive with a USB cable… shouldn’t I just use the hard drive that’s in my machine?”
The Primary Use Case: The number one reason to use A2A and MCP is to interact with third-party tools and agents. They provide a standardized way to achieve extensibility and leverage a vast ecosystem of services without building and maintaining countless bespoke integrations.

Workshop Architecture: A Practical Multi-Agent System

The workshop demonstrates a system where a webhook from a finished meeting triggers an intelligent workflow that analyzes the meeting transcript.

The architecture consists of several agents:

Host Agent: The central coordinator that runs locally. It receives the webhook, discovers available sub-agents, and delegates tasks to them in parallel.
Slack Agent: A local sub-agent that uses a Zapier MCP to connect to Slack. It posts summaries of feature requests or items of interest mentioned in the transcript to a designated channel.
GitHub Agent: Another local sub-agent using a Zapier MCP. It identifies mentions of bugs in the transcript and automatically creates a new issue in a GitHub repository.
Bench Agent: A remote, third-party A2A agent. Its task is to perform research on the companies and people mentioned in the transcript, demonstrating how to leverage external, specialized agents.

A key learning from the workshop was that these frameworks have rough edges. For example, the Zapier Slack MCP was found to fail silently if a channel didn’t exist, highlighting the potential unreliability of third-party implementations.

The Critical Benefit: Lean Context Management

Perhaps the most significant advantage of a multi-agent architecture is protecting the host agent’s context window.

The Problem: AI agents accumulate context with every tool call and response. As the context grows, so do costs and latency. Caching the prompt can help, but it comes with its own 3x cost premium and requires a complex strategy to be effective.
The Solution: Sub-agents act as a protective barrier. A sub-agent can process a large amount of raw data (e.g., querying thousands of Salesforce opportunities or Slack messages) and return only a concise, high-value summary to the host. The host agent’s context remains lean, containing only the final business result, not the voluminous raw data used to generate it. This dramatically reduces token consumption and cost.

For example, to get a count of GitHub issues, a sub-agent would perform the necessary API calls and processing, and the host agent would only receive the final count. The raw data from the API calls is discarded after processing by the sub-agent, never bloating the primary context. This composability is crucial for building scalable and cost-effective agentic systems.