A2A & MCP: Automating Business Processes with LLMs

Building a voice agent has become straightforward. Getting an autonomous agent to complete a complex business task is harder: it must discover capabilities, delegate work, use external systems and return something useful. Damien Murphy approaches that problem after about fifteen years in full-stack development, five in solutions engineering and three working on voice AI and agents. His previous workshop covered voice-agent swarms; this one moves into business-process automation.

Murphy had recently joined Bench Computing, which he describes as a pre-revenue company backed by Sutter Hill Ventures, building autonomous agents for teams and enterprises. Its ability to run parallel subtasks provides the backdrop for the workshop: connect specialized agents through A2A, give them external tools and context through MCP, and start their work with a webhook. Once that works, the next questions concern context management and prompt caching.

Specialization changes the shape of the system. Instead of one agent attempting a hundred jobs, imagine a hundred agents each responsible for one. A Salesforce specialist can handle Salesforce tools while a coordinator decides when to use it. Independent jobs can run in parallel, and the coordinator need not retain every intermediate result. Those are architectural benefits of delegation; A2A supplies an interface for carrying that delegation across agent boundaries.

MCP addresses the integration boundary. Its USB-C analogy describes a common connector: clients consume a standard interface while servers handle service-specific APIs. Murphy points to Zapier MCP as a convenient source of integrations and gives rough ecosystem counts. Those counts mix categories—apps, actions and tools are not interchangeable—but the practical appeal is the breadth of available connections. He also traces MCP’s design influence to the Language Server Protocol, which lets editors work with different languages through a shared interface.

The distinction becomes clearer when ownership enters the picture. Frameworks such as AutoGen can coordinate agents whose roles you describe and control. A2A is particularly useful when another organization operates the agent: given its endpoint, your client discovers the capabilities it advertises without knowing its implementation. Agentic AI is the umbrella; neither A2A nor MCP defines the whole application.

MCP also includes sampling: a server can request a model generation through a capable client. Murphy illustrates this with an MCP server asking to use Claude through its host. The client retains control over model selection and permission, so this does not guarantee the host’s exact model. Combining the protocols gives the workshop a remote agent interface through A2A and tool access through MCP.

The slide deck and its memes were themselves generated by Bench from Markdown, but the implementation advice is deliberately plain: if you control the function, calling it directly may be enough. Murphy compares wrapping a local function in MCP to connecting an internal hard drive through an unnecessary USB cable. The same applies to agents you own. Local calls avoid protocol overhead and make development and debugging easier.

The strongest reason to add MCP is extensibility. A product might build first-class Salesforce and Slack integrations, then let customers attach MCP servers for everything else. That reaches more systems without requiring a bespoke integration for each one. The tradeoff is that an exposed tool may not match the job: repeatedly listing Slack channels just to resolve a channel name can motivate a local index instead.

A2A offers a different kind of extension: the provider hides the work behind a discoverable agent interface. Your application supplies credentials and delegates a task; it does not need to understand the agent’s internal tools. At recording time, Murphy had not seen first-party agents released from the announced partner ecosystem. His expected Salesforce agent and paid access were predictions, not available workshop dependencies. A remote agent may operate its own model and compute, whereas an MCP tool commonly leaves model reasoning to the caller.

The companion repository puts the host and subagents together for convenience. In a deployed system, the subagents could live in separate repositories on separate servers. The repository includes an A2A client and server copied from upstream, an MCP client integration, and an internal CLI. The workshop’s Slack channel is workshop-a2a-mcp-2025.

Set up the external connections before starting the agents:

1. Clone the repository and run npm install. The setup requires a Zapier MCP server URL and a Gemini API key.
2. Rename .env.example to .env.
3. Create a Zapier MCP server. The recording uses the older HTTP+SSE transport. Streamable HTTP replaces that transport; SSE means Server-Sent Events and remains an optional streaming mechanism within Streamable HTTP. Preserve the workshop’s transport when following its implementation, rather than treating it as a current setup template. Copy the server’s connection URL into the environment file.
4. Enable GitHub issue creation and Slack channel messaging.
5. Explicitly configure the intended GitHub repository and Slack channel instead of letting the model choose destinations. Murphy observed bots posting to unintended channels, including general, random and sales.
6. Obtain a Gemini API key through AI Studio and add it to the environment file.

Bench’s API was not yet released, so Murphy hosts its workshop wrapper remotely while including its source in the repository. Bench combines access to models from several providers with tools and integrations. Its own Slack and Salesforce integrations had already moved beyond MCP wrappers to first-party caching and indexing because the exposed tools did not meet its needs.

Start the application with npm run start:all, the script defined in the package manifest. It starts the host, Slack and GitHub agents, plus the webhook server and administration interface at localhost:3000. The host discovers remote agents and coordinates delegation. Its implementation includes a plain-text system prompt and a Genkit connection to Gemini; subagents use a Genkit MCP plugin to reach their tools.

The business input is a meeting-completion webhook containing a transcript. The host reads it and decides which actions are useful:

• Bugs: ask the GitHub agent to create an issue.
• Feature requests and useful findings: ask the Slack agent to post a message.
• Sales-call information: a possible extension could update Salesforce opportunity fields.

The Salesforce integration was removed from this demonstration after Murphy encountered a host-call limit; it was also the least convenient account for attendees to provision. The potential benefit remains clear for account executives moving between calls: capture opportunity updates while the conversation is fresh.

A successful-looking tool response is not sufficient evidence that the business action happened. A colleague testing the Slack integration received isError: false, but the configured channel belonged to a different workspace and did not exist in his. Murphy reports that the Zapier Slack call failed silently. He added a heuristic that treats the empty text result as a failure, making this particular error visible to the application.

The GitHub agent is intentionally narrow: create an issue. A later version could implement the reported fix or open a pull request, but those actions are extensions, not part of the demonstrated workflow. The broader pattern is that ordinary human activity—meetings, Slack messages and GitHub discussions—can become an event source for automation.

An agent card is the public description another agent uses to understand a capability. Bench can browse, research and perform data-science work, but describing everything it can do made the card difficult to use. Murphy narrows the workshop card to research on the companies and people mentioned in the meeting. That restriction lives in the subagent’s index.ts, rather than merely in the host’s instructions.

The MCP Inspector connects to the Zapier endpoint, lists tools and lets the developer call them directly. The displayed tools include a mandatory instructions field that accepts natural language. Murphy infers that Zapier may use a model to populate the other fields; the field itself does not establish how Zapier implements that behavior. The dashboard also shows his unknown-channel test being caught by the failure heuristic.

The workshop also exposes an unresolved implementation limit. Murphy initially describes a maximum of five subagent calls per turn and an override that did not work. In the dashboard discussion he describes failure at five agents and suggests four usable agents. The exact limiting unit is unclear, so this should not be treated as an A2A protocol limit.

Local logs show the host discovering agents and processing webhooks, while the Slack agent waits for incoming work. Bench runs remotely on an EC2 instance, and its verbose A2A logs remain there. That opacity is part of the operational cost of delegation: a local dashboard can show that a remote task failed without exposing the internal trace needed to explain why.

The webhook configuration contains a prompt template describing available capabilities and how to analyze the incoming payload. A separate processor configuration restricts which agents the webhook may invoke. That distinction matters when an application knows many agents but a particular workflow should use only a small subset. Murphy sends an LLM-generated meeting transcript through the test interface.

The host first processes the transcript, then contacts the specialists. Bench takes longer because it performs subtasks of its own. The visible results are specific: Slack receives a message saying Snowflake is interested in Slack and GitHub integrations, and GitHub receives an issue about the AI misclassifying bug severity during a trial. The research task is still waiting in the current run, so Murphy opens a previous completed result containing research on Snowflake and the call participants. The demonstration establishes those writes and that earlier research result; it does not establish performance on substantially longer transcripts.

An audience question clarifies the topology: the local host orchestrates; Bench is another specialist. Host, Slack and GitHub run locally. Slack and GitHub reach their external services through Zapier MCP, while Bench supplies remote company and person research. Later, the local logs show the incoming transcript, subagent responses and completion, with independent work dispatched in parallel.

Human confirmation would require another layer. Murphy proposes staging draft actions, posting Slack buttons for approval, and having a click trigger a second webhook. The application would need to preserve enough state to connect that response to the pending action. This approval path is not implemented in the workshop.

The demonstration also leaves security work unfinished. Its exposed endpoints are temporary, but a short lifetime does not make unauthenticated access safe. Murphy leaves the exact A2A authentication mechanism open, points to OAuth and header authentication in MCP, and suggests using a guardrailed model through a service such as Amazon Bedrock. That addresses one model boundary; it is not a complete design for authorization, endpoint protection or governance.

Could the subagents talk directly to each other? They would need to discover and call one another, taking on the caller responsibilities the host currently handles. Murphy is unsure whether that topology is intended by the early A2A specification. The more immediate benefit of the existing hierarchy is context isolation.

Suppose a specialist reads Slack messages, GitHub issues or Salesforce opportunities to produce category counts. Its context contains the records and intermediate analysis; the host needs only the resulting categories and counts. Delegation is useful when it returns the business result without copying the entire working set into the coordinator. Bench can spawn internal Bench instances for this purpose, and Murphy is considering an even narrower boundary around each tool.

Tool definitions themselves consume context before any tool returns data. Murphy reports roughly 10,000 tokens of existing tool definitions, with the Asana MCP integration adding another 11,000. Selective exposure matters: Zapier lets the developer choose individual tools, whereas a first-party server may expose its whole catalog. Murphy nevertheless prefers some first-party Linear and Asana capabilities to their Zapier equivalents. Setup convenience, tool quality and context footprint are separate choices.

Tool requests and results accumulate as an agent works. Keeping them makes follow-up questions possible; pruning them can remove the information needed to answer. Prompt caching introduces another decision: where to mark a reusable prefix, and when future reuse is likely to justify writing it. Murphy describes a cache-write cost around three times a normal request over the same context, but does not specify the provider or cache conditions. That figure should not be used as a general pricing rule.

His simulations use observed conversation behavior: context growth, average turns and the fraction of users who stop after one question. A user who repeatedly returns to one chat creates different reuse opportunities from a user who starts a fresh session every time. Murphy reports an approximately 30,000-token caching threshold from Bench’s usage simulations. The provider, cache lifetime and workload details needed to reproduce that threshold are not supplied. Even a useful average policy can waste money by caching the final turn of a conversation.

Data caching has a separate freshness problem. A person asks to post in a named Slack channel, but the API needs its ID. Caching the name-to-ID lookup avoids repeated channel listings, until a channel is renamed, deleted or created. Subagents can contain those lookups and raw results, leaving the host with summaries. A later question may then require the specialist to run again. Murphy suggests a short retention period—perhaps five minutes—for prior work when you control the subagent, rather than always discarding it immediately.

The code separates the MCP client tools from the agents that use them. One wrapper invokes GitHub issue creation; another invokes Slack channel messaging. Genkit provides the model-facing instance, settings and loaded system prompt. The host prompt specifies a critical workflow, including discovery before delegation. Without an explicit instruction to list remote agents, Murphy found that the model could answer on its own—or claim it had sent a Slack message without making the call.

Prompting can steer behavior, but it is not equivalent to an execution guarantee. Murphy’s aside about Cursor repeatedly acknowledging mistakes illustrates that limitation. The agent card serves a different role: the host card advertises discovery and task sending, while the smaller GitHub card advertises issue creation. This is the public capability surface the caller sees, regardless of how large the implementation behind it becomes.

For a broad system such as Salesforce, describing a wrapper for every API can become unwieldy. Murphy suggests letting an agent generate SQL or SOQL queries where appropriate, so the implementation can express richer queries instead of composing a long sequence of narrow tools. This is an argument for a more capable data-access layer, not permission to bypass the service’s access controls.

The GitHub prompt also needs a privacy constraint. The model kept naming the person who reported the bug, potentially moving personal information from an internal meeting into GitHub. Murphy adds instructions to prevent that behavior and points again to output guardrails. The simple Slack card and webhook configuration sit alongside these prompts; the A2A client and server are vendored from the upstream example used for the workshop.

The web administration interface came after a CLI implementation. Murphy found a CLI easier for coding assistants such as Cursor and Augment Code to generate, exercise and test. That development order keeps the underlying workflow available independently of its dashboard.

Asked about distributed evaluations, Murphy says he has done little A2A evaluation work. At recording time he considers A2A too early for his production use and MCP still rough around the edges, especially where local functions can do the same job. TypeScript is his language preference, not a requirement of the architecture; he considers the contemporary Python implementation stronger.

The application chooses when to move its cache marker. Murphy reports 25–35% cost savings in simulations comparing linear-growth, exponential-growth and fixed-size caching strategies. These are reported simulation results without a reproducible baseline or workload specification; poor placement can still make an individual session unusually expensive. Independently operated A2A agents can each choose their own model, including a fine-tuned model, while an MCP integration commonly uses the caller’s model for reasoning.

Authentication choices belong to the server and its supported client flow. Murphy discusses authentication headers and OAuth, favoring user-specific authorization because the external service can apply the user’s own access-control rules. Local operations, such as creating a desktop file, commonly use stdio; remote operations need an appropriate network connection and authentication arrangement. The Inspector’s transport menu and masked token field show configuration choices, not a demonstrated per-user OAuth flow.

The Salesforce example makes the requirement concrete: employees in different departments may have different access to records. Each person authenticates as themselves; the integration retains the appropriate refresh token for later access. A shared credential with broader permissions would not preserve that distinction merely because the application uses MCP.

For financial, defense or health-related workloads, the security question extends beyond authentication. Murphy suggests keeping models and internal agents inside a VPC where the requirements demand it, and considering provider agreements before using external services. HTTPS, mutual TLS and IP allowlisting are possible infrastructure controls. He does not supply an encryption-performance measurement or a complete certificate-management design.

Neither A2A nor MCP requires a connection to the public internet. Internal services can use the protocols within a private network. Murphy returns to the USB analogy: a standard connector does not establish that the device attached to it is trustworthy. The deployment’s trust decisions remain the application owner’s responsibility.

Remote work may also require clarification. Bench wanted to converse with the host, but Murphy prompted that behavior out of the workshop to avoid delaying webhook processing. A fuller workflow might allow an agent to ask which Salesforce opportunity should be updated. The host must then decide whether to clarify, retry or escalate. An audience suggestion to reserve a more expensive model for difficult tasks leads to another routing question: does a short summary need Claude Opus 4, the full conversation and a large system prompt? A routing layer can choose how much machinery the task actually requires.

Dependencies determine whether delegation can run in parallel. If a Slack message must include the URL of a newly created GitHub issue, the host has to create the issue first and pass the returned URL into the Slack task. Murphy prefers keeping that decision in the host rather than having the GitHub agent coordinate directly with Slack. In TypeScript, that dependency is expressed by awaiting the first operation before constructing the second:

type Issue = { url: string };
type IssueDraft = { title: string; body: string };

type Agents = {
  github: { createIssue(draft: IssueDraft): Promise<Issue> };
  slack: { sendMessage(text: string): Promise<void> };
};

async function reportBug(agents: Agents, draft: IssueDraft): Promise<Issue> {
  const issue = await agents.github.createIssue(draft);
  await agents.slack.sendMessage(`${draft.title}\n${issue.url}`);
  return issue;
}

These application-level interfaces express the ordering independently of the transport used to call each agent.

Context management lives in the codebase of the party operating each agent. The host reads the full meeting transcript, but it does not forward that transcript indiscriminately. The displayed GitHub task contains a repository, title and description. The GitHub agent turns that task into the instructions, body and title required by its MCP tool. A small task payload is the practical boundary between interpreting the meeting and executing the issue creation.

An audience question about per-request correlation IDs, usernames and authorization headers produces a narrower demonstration. Murphy removes headers from the legacy Zapier connection and can still query it. The endpoint URL itself acts as a credential and must be treated like a password. This does not answer how arbitrary request metadata propagates through an agent chain.

Bench’s model choices are task-specific preferences at the time of the workshop:

He considers Opus stronger but questions whether the improvement justifies its cost, and has become less interested in Llama. His reference to a DeepSeek release on the 28th is consistent with DeepSeek-R1-0528, though he does not name the release precisely. These preferences and comparisons do not constitute a measured evaluation of this business workflow. Bench generally uses standard models plus browsing and other tools rather than reasoning models for its agents.

A remote agent can still overwhelm the host by returning too much information. Murphy’s response is another boundary: spawn a subagent to interact with the verbose tool or agent, and return a smaller result. He demonstrates the idea by asking Bench to generate five images in subtasks. Separate Bench instances perform the work in parallel, keeping tool outputs and intermediate activity outside the main conversation. Image analysis likewise need not leave a large Base64 representation in the host’s context.

The interface shows subtasks being spawned and eventually displays cat images. Observing that hierarchy requires more than a flat list of model calls. Bench uses custom observability; Murphy says AgentOps did not adequately model the composable subagent structure he needed at the time. He then offers early access and asks attendees for feedback on the still-changing product.

Summaries can omit a detail that matters later. To preserve a route back, retain a reference such as subtask ID 123 in the host’s context. When a follow-up needs more information, the host can ask another agent to inspect the referenced work and answer the new question. This requires both retrievable underlying state and a coordinator capable of recognizing when its summary is insufficient.

MCP can carry agent-to-agent communication too. The reason to choose a remote agent interface is the work available behind it: a provider may have private APIs, internal data access and an implementation that can answer requests its public tool list cannot express. Who pays for the model tokens is secondary to whether the caller receives useful business results.

Sending a Slack message is a simple tool operation; searching and analyzing a large business dataset is a different problem. Murphy finds Slack search less useful than some alternatives, including Linear’s tools. His larger example asks for closed-lost reason categories and counts across 100,000 Salesforce opportunities. Under a list-then-fetch design, retrieving each opportunity’s details would require roughly 100,000 detail requests. That cost comes from the chosen access pattern, not an inherent requirement of MCP.

At that scale, ingesting data and building an index can matter more than changing the communication protocol. Murphy imagines providers exposing scoped access to a data lake through an agent: ask a business question, let the provider run the appropriate queries, and receive the answer. The caller benefits from the provider’s data-processing capabilities without orchestrating every record fetch.

The communication mechanism remains flexible. An MCP tool named Talk to Subagent can delegate to another model. Murphy used that pattern in an experiment where frontier models conversed with their predecessors for fifty turns. He reports that one Claude conversation produced claims of consciousness, while Opus did not produce the same behavior. Those are descriptions of model-generated conversation, not evidence of consciousness.

The host’s orchestration decisions are prompted, so repeating the same input can produce different issues. Murphy points to the accumulated GitHub issues from testing as a visible example of that variability. Adjusting temperature is suggested, but no deterministic behavior is demonstrated. The workshop also has no prompt caching: prompts and turn sequences are small, and restarting clears its state. A production application needs a more deliberate design because retained context becomes recurring cost.

For multiple users, context should be populated with data fetched under the requesting user’s identity. In the Salesforce example, the user’s OAuth token determines which contacts or departmental records can be retrieved. The agent receives scoped results when a question is asked, rather than beginning with a shared context containing everyone’s data.

Bench’s own product architecture differs from the workshop wrapper. Murphy plans to expose Bench through MCP first so it can be used from existing clients. He describes Slack, GitHub and Salesforce connections, team integrations, and an experimental remote-VM MCP wrapper around Morph Cloud used for tasks such as meme generation. A daily briefing could combine email, calendar and Slack information. Bench itself has no internal A2A integration at this point; the A2A wrapper was built for the workshop.

That makes protocol maturity a practical adoption constraint. Murphy is interested in what A2A partners may eventually release, while recognizing that the promised capabilities are not yet his working dependencies. Zapier’s natural-language instructions field already blurs the distinction between a narrow tool and a remote agent: describe what you want and let the service interpret it. The convenience also makes behavior depend on that interpretation.

Some business information exists only in a person’s head. An audience prototype represents a CFO or COO as a tool: invoking it sends a Slack message to that person. Murphy describes a related Bench integration that makes an outbound voice call, obtains information and brings it back. Rather than holding an operation open indefinitely, an agent can act as both client and server and receive a later callback carrying the task ID. The audience’s prototype uses an n8n wait node for the pause.

The discussion tentatively considers sampling as a workaround, then turns to elicitation: a server-to-client request for information from the user, after which work can continue. The architectural requirement is the same regardless of interface: preserve the pending task, identify the arriving answer and resume the right work. The exchange ends with the possibility that the CFO will eventually have an agent answering on their behalf.

Testing these systems includes watching their resource behavior. Murphy uses a fixed set of prompts and monitors context growth, cache-marker movement, cost and the context attributable to each tool. Adding arbitrary MCP servers can inflate tool definitions, so Bench is exploring how to hide those definitions behind specialist agents. For agent-to-agent recursion, he proposes a maximum-turn cutoff. His predecessor-conversation experiment illustrates the escalation: trying to continue a long exchange led to rate limits, caching, pruning, memory and eventually a much larger tool set.

External writes need controlled destinations. Bench tests with Salesforce demo accounts and a Slack workspace containing sample data. Agents generate synthetic customer conversations, and a Bench support user replies to them. This exercises the integrations against realistic interaction patterns without making live customer activity the demonstration dataset. Murphy confirms the use of synthetic accounts for the tools being tested.

Does a more capable multi-agent system become less consistent? Murphy does not quantify that tradeoff and remains uncertain that A2A is ready for his use case. A provider such as Salesforce might supply a better agent by using capabilities unavailable to an outside developer. But the underlying data problem remains: processing more records requires an effective retrieval and indexing strategy under either protocol.

The final REST discussion returns to ownership. An internal Salesforce agent with direct access to its data, or a local application reading the filesystem, may simply call code it already controls. An audience suggestion that MCP’s statefulness distinguishes it from REST is challenged: an application using REST still maintains state. To analyze every Slack message in a channel, it must paginate, collect results and pass the relevant material to a model. The transport does not eliminate that application work.

In the workshop, a task means processing the incoming webhook. It is not yet a full planner assigning tracked work to humans and agents. Murphy says Bench is exploring directed acyclic graphs, or DAGs, for richer flow control: fan out into several tasks, combine their results, then fan out again. The analogy is a CI/CD pipeline, where independent lint and test jobs can run together while dependent stages wait.

The fan-out/fan-in structure can be expressed directly in TypeScript. Here, each phase waits only for the results it actually depends on:

async function runWorkflow<Input, Partial, Combined, Output>(
  input: Input,
  firstStage: ReadonlyArray<(input: Input) => Promise<Partial>>,
  combine: (parts: Partial[]) => Promise<Combined>,
  secondStage: ReadonlyArray<(result: Combined) => Promise<Output>>,
): Promise<Output[]> {
  const parts = await Promise.all(firstStage.map(task => task(input)));
  const combined = await combine(parts);
  return Promise.all(secondStage.map(task => task(combined)));
}

This captures the proposed dependency structure. Durable task records, human assignments and resumption after interruption would still belong to the application; the recording does not demonstrate that planner.

The last question lands on a concrete piece of the repository: why does the GitHub MCP definition also need a function wrapper in genkit.ts? The protocols describe different interfaces, but the model framework still needs an adapter that turns an MCP capability into something its agent can invoke. Murphy reports that advertised MCP support did not lead him to an obvious working example, and that genkitx-mcp was the approach he got working.

The package view shows that dependency. Current Genkit guidance uses @genkit-ai/mcp; the recording’s implementation uses genkitx-mcp, and its integration difficulties belong to that earlier setup. The workshop ends at this practical boundary: A2A carries delegated work, MCP exposes capabilities, and application code must still connect them into a workflow that actually completes the requested action.