# A2A & MCP Workshop: Automating Business Processes with LLMs

Damien Murphy, Bench | AI Engineer World's Fair 2025 | 1:23:14

Source: https://www.youtube.com/watch?v=wXVvfFMTyzY
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/a2a-mcp-workshop-automating-business-processes-with-llms
Published: 2025-07-26
Tags: agents, context-engineering, mcp, multi-agent, workflows

## TL;DR
- A2A connects agents over the web, while MCP gives agents a standard way to consume tools and context.
- Subagents can keep large tool results and intermediate work out of the host agent's context, reducing context growth and latency.
- A2A and MCP are still early, and local function calls are usually easier to build, debug, and control when you own the agents and tools.

## Summary
Damien Murphy builds a workshop system that receives a meeting transcript through a webhook and sends the work to several agents. A host agent discovers and coordinates A2A agents. Local Slack and GitHub agents use Zapier MCP tools to post a Slack message or create a GitHub issue, while a remote Bench agent researches the company and meeting participants. Murphy explains the boundary between the protocols: A2A is for communicating with remote agents whose internal capabilities are opaque, while MCP exposes tools, resources, and context through a standard interface. Much of the talk focuses on context management. Subagents process detailed tool output and return only the business result the host needs. He also discusses prompt caching, authentication, human approval, testing with synthetic accounts, observability, and the limits of current implementations. His conclusion is practical: use direct code when you control the system, and treat A2A as an early protocol with substantial rough edges.

## Key ideas
### A2A lets a host agent discover and delegate to remote agents
[01:46](https://www.youtube.com/watch?v=wXVvfFMTyzY&t=106s)
Murphy describes A2A as Google's protocol for agents that communicate over the web. Its focus is remote agents, often owned by another team or company, rather than several agents that one developer controls locally. A host connects to an endpoint, discovers the agent card, and learns what the remote agent can do. The remote agent's internal implementation stays hidden. Murphy contrasts this with frameworks such as AutoGen, where the developer describes and controls the agents directly. He presents agentic AI as the larger category, with A2A and MCP as different communication and tool-use approaches within it.

### MCP standardizes access to tools and context, but its scope is wider than tool calls
[06:00](https://www.youtube.com/watch?v=wXVvfFMTyzY&t=360s)
Murphy compares MCP with a USB-C interface for AI systems. It gives agents a standard way to consume external tools, context, and resources, and it also includes prompt templates and sampling. Sampling lets an MCP server ask the host LLM to produce a response, potentially using the same model as the client. He says that many users focus only on tools, even though MCP includes these other features. He also explains that MCP drew ideas from the Language Server Protocol, which helped development tools understand different programming languages through a common interface.

### Direct functions are preferable when the application owns the tools and agents
[07:40](https://www.youtube.com/watch?v=wXVvfFMTyzY&t=460s)
Murphy is clear about when protocols add unnecessary work. If a function is local to the codebase, calling it directly is easier to maintain and faster to develop. There is no protocol overhead, and debugging is simpler. The same applies to agents that the application fully controls. Local function calls can coordinate those agents without putting a network protocol between them. MCP becomes more useful for third-party tools because a product cannot build first-class integrations for every available service. A2A becomes useful when another party provides an agent whose internal complexity the application does not need to understand.

### The workshop uses a host agent to route meeting-transcript work to specialized agents
[11:20](https://www.youtube.com/watch?v=wXVvfFMTyzY&t=680s)
The example application starts a host agent, Slack and GitHub agents, a remote Bench agent, a webhook server, and an admin panel. A sample meeting transcript arrives through the webhook. The host analyzes it and delegates separate tasks. The Slack agent posts relevant feature requests or other information to Slack. The GitHub agent creates an issue when it detects a bug. The Bench agent researches the company and people mentioned in the meeting. Murphy says the agents process their work in parallel, which keeps the demo responsive and avoids making the host perform every operation itself. He also mentions a possible Salesforce workflow that updates an opportunity after a sales call.

### Agent cards need a narrow description because broad capabilities make delegation harder
[19:31](https://www.youtube.com/watch?v=wXVvfFMTyzY&t=1171s)
Murphy says the Bench agent can browse the web, conduct research, and perform data science, among other tasks. Describing all of those abilities in an agent card becomes difficult as the number of functions grows. For the workshop, he deliberately reduces the public description to a handful of capabilities, even though the agent can do more. The agent card is the public information another agent receives about an agent's skills. He shows that the host exposes abilities such as listing remote agents and sending tasks, while the GitHub agent has a much smaller card focused on creating GitHub issues.

### Subagents protect the host from context growth and expensive tool output
[32:00](https://www.youtube.com/watch?v=wXVvfFMTyzY&t=1920s)
A subagent can process a large collection of Slack messages, GitHub issues, or Salesforce opportunities and return only a summary such as categories and counts. The host then grows by the business value of the result instead of by every raw record and tool response. Murphy says this also keeps intermediate reasoning, images, and large encoded payloads away from the primary context. In Bench, composable subagents can absorb a context flood and run subtasks in parallel. Raw data can be discarded after processing, while references such as a subtask ID can remain available if the host later needs to retrieve more detail.

### Prompt caching needs application-level decisions about session behavior and context size
[35:06](https://www.youtube.com/watch?v=wXVvfFMTyzY&t=2106s)
Murphy explains that prompt caching requires the developer to place and move a cache marker in the conversation context. The initial cost of writing content into the cache is about three times the cost of one request with that context, so caching every short exchange can waste money. He describes simulations using different growth strategies and says they produced between 25% and 35% cost savings, with outliers when caching happened at the wrong point. He says roughly 30,000 tokens worked as an overall threshold in his simulations, although the best approach depends on whether a user keeps adding prompts to one session or starts a new session for each question.

### A2A and MCP leave important production concerns to the surrounding application
[44:46](https://www.youtube.com/watch?v=wXVvfFMTyzY&t=2686s)
Murphy says the demo does not include human approval, but a production workflow could create a draft, show actions in Slack, and use a second webhook after someone clicks to confirm. State may need to be persisted. Authentication can use headers, OAuth, HTTPS, mutual TLS, and IP allowlists, depending on the deployment. He recommends keeping highly regulated workloads inside the organization's VPC and being careful with third-party services. The protocols do not define all governance, audit, guardrail, and encryption decisions. He also notes that the current Genkit implementation limits the host to five subagent calls per turn, and he considers A2A too early for his production use case.

## Notable quotes
- "A2A is more about remote agents, right? So agents you have no knowledge of." (05:51)
- "If you have full control of the tools then you probably don't need it." (08:03)
- "The host agent only incrementally grows by the business value it got from that agent." (33:16)
- "Context growth becomes cost and cost becomes profitability." (53:07)
- "A2A is very early. It's kind of where MCP was four or five months ago, which is forever in AI." (1:08:51)

## Tools & references mentioned
- A2A
- Model Context Protocol
- Google
- MCP Inspector
- Zapier MCP
- Genkit
- Gemini
- Slack
- GitHub
- Salesforce
- Bench
- AutoGen
- AgentOps
- Claude Sonnet 4
- Claude Opus
- Claude Haiku
- DeepSeek
- Llama
- Linear
- Asana
- Amazon Bedrock
- OAuth
- SSE
- streamable HTTP

## Who should watch
- You are deciding whether a remote agent protocol adds value beyond local function calls, especially when different teams or vendors own the agents.
- You are building webhook-driven workflows that need to inspect meeting transcripts and take actions in tools such as Slack, GitHub, or Salesforce.
- You are dealing with growing tool definitions, large tool results, prompt-cache costs, or questions about approvals and access control.

## Related talks

- [Just do it. (let your tools think for themselves)](https://aietalks.com/talks/just-do-it-let-your-tools-think-for-themselves) (Robert Chandler, Wordware, 06:50)
- [Building Agents (the hard parts!)](https://aietalks.com/talks/building-agents-the-hard-parts) (Rita Kozlov, Cloudflare, 21:12)
- [Exposing Agents as MCP Servers with mcp-agent](https://aietalks.com/talks/exposing-agents-as-mcp-servers-with-mcp-agent) (Sarmad Qadri, Last Mile AI, 18:05)
- [The Future of MCP](https://aietalks.com/talks/the-future-of-mcp) (David Soria Parra, Anthropic, 18:46)
- [MCP Is Not Good Yet](https://aietalks.com/talks/mcp-is-not-good-yet) (David Cramer, Sentry, 16:41)