How MCP Events Can Unlock Agent-to-Agent Communication

Your subagents no longer have to live on your platform.

Almost every agent product now has subagents. A common pattern is to have a main agent delegate and orchestrate tasks into smaller pieces for subagents to handle. The subagent usually runs on the same platform, with the same tools, inside the same session.

But sometimes, the best subagent for a task lives somewhere else, on another platform with its own computer, tools, integrations, and context. You want to give that specialist the relevant task, and when they're finished they'll come back with the results.

We're building this into runneth, the agent that understands marketing. A specialist for other agents to call.

What is MCP events?

Essentially, agents can subscribe to events and be notified when an mcp server fires an event. So your agent can fire off a quick tool call, go to sleep, and minutes or hours later receive an update that a chunk of work it delegated has completed and can continue from there.

MCP 2.0, the July 2026 revision, came with a draft MCP Events specification. A server can publish named events. A host subscribes with a webhook, answers a one-time challenge, and then receives signed deliveries. A host that supports events can wake an idle agent when one arrives. OpenAI documents this for ChatGPT Work chats and for dots.

If you're thinking that's a webhook, you're right, but now it's offered natively on mcp servers to be able to wake an agent.

The agent-to-agent demonstration

I asked chatgpt what ad angles to test this week. It asked runneth and subscribed to the completion event. runneth finished the work and sent the event. Chatgpt then retrieved the work and can continue with whatever task it needs to do. No copy pasting between the two agents or polling needed at all.

This is one example. It applies for any task where one agent needs to get data or work done with integrations or context another agent has.

Here are some other potential ideas

1. A coding agent like devin/grok bot is about to change a landing page. It asks runneth which ads send traffic there and what they promise, and resumes with the hooks and claims so the copy stays consistent.

2. An email agent is drafting the weekly newsletter. It asks the ads agent, the support agent, and the sales agent what happened this week, then goes idle. The answers land one by one, it wakes up with each, and writes the newsletter from real updates instead polling until they're done.

3. A marketing agent is launching a campaign and hands the landing page layout to a design agent like Figma's. It goes idle while the designs come together in the brand's style, then picks the launch back up once they're ready.

The agent uses the ask_runneth tool and keeps the response ID it gets back. It subscribes to runneth.response.finished for that response and names a webhook. Runneth does the work and fires off a signed event, the host receives it and resumes the agent. The agent calls get_conversation and reads the response the event identified.

Why delegate across platforms?

Subagents were the first step. The next step is agents that specialize in one part of the business, and we're already seeing this trend with grok bots, devin and runneth.

As different platforms keep releasing specialized agents, people are going to pick the best agent for each task. Those agents will need a way to hand work to each other and get the result back. MCP events could make this agent to agent communication a lot easier.

Security

When you open up pandora's box of assigning tasks to an agent that may call other specialized agents, which may call other agents to get their tasks done, the risk of data exposure increases and strong guardrails will need to be managed by every agent.

In the demo, the agent never exposed any credentials or personal information, it checked the identity and authority of the caller and based on that provided it the information it was allowed to access. (An article about how we're using a fast decision model to guardrail coming soon)

What still needs care

A finished response is not a successful assignment. It can hold an answer, a question, a partial result, or a failure. The caller must read it before it acts. Deliveries can repeat, so the receiver must recognize the same event ID twice. Subscriptions expire, so long work needs renewal.

If you want to try it, start small. Pick one assignment, subscribe to one event, and read what comes back.