This week's video

For a while, my agent Emma could tell me exactly what was wrong with my site. She just couldn't fix it. Every week she pulls my analytics, compares performance week over week, and surfaces what's worth my attention. Recently she caught that a paid campaign was sending traffic to my services page with no conversions, then traced it to a missing booking event and a Cal.com modal that ad blockers were probably breaking. Then she'd hand the list back to me, and I'd go open the repo and do the work myself.

This week's video is about closing that gap. I gave Emma, my custom Mastra agent, repo-capable behavior by letting her hand coding tasks to Claude Code through ACP, the Agent Client Protocol.

Watch the video →

The idea underneath the build is that each tool plays its position. I didn't have to make Emma good at everything. She's good at context, analytics, and knowing what matters to me. Claude Code is good at working inside a repo. ACP is the clean interface between them. Emma finds the opportunity and proposes the work, I approve it, Claude Code executes in its own git worktree and opens a PR, and Emma watches what happens next. The human approval gate in the middle is deliberate. She can propose a change to a production repo, but she can't ship without me signing off.

Resources mentioned:

• Agent Client Protocol (the spec and docs)
• ACP on GitHub
• Mastra

What ACP actually is, and what it isn't

ACP is the layer that lets your agent stop describing work and start delegating it.

The cleanest analogy is LSP. Before LSP, every editor needed a bespoke integration for every language. After it, editors and language servers evolved independently against one shared contract. ACP does that for coding agents. A client speaks ACP once and can drive many agents. An agent implements it once and shows up in many clients. Claude Code speaks it, which is why Emma can hand it a task instead of me being the integration layer between them.

It helps to place ACP next to the protocols you already know. They're complementary layers, not competitors:

• ACP is how a client or editor talks to an agent.
• MCP is how an agent talks to its tools and resources.
• A2A is how an agent talks to another agent.

My build only uses two of them. Emma reaches some of her tools over MCP, and she hands a coding task to Claude Code over ACP. Mastra supports A2A, but I'm not using it here. The handoff to Claude Code is agent-to-agent delegation in spirit, just done over ACP at the editor surface instead of a general orchestration bus.

Two things stood out. First, it's past the experiment stage. It has a stable v1 and an official registry, and the adapter list already covers most of the coding agents you'd name: Gemini CLI, Codex CLI, Cursor, Copilot, Goose, JetBrains Junie. When that many vendors implement the same contract independently, it stops being one editor's side project. Second, it standardizes a lot more than "spawn a process and send text." It covers sessions you can resume, structured plans, tool-call reporting, terminal control, and file access that can include unsaved editor state. That last detail is the tell. ACP treats the editor as a live runtime surface, not just a launch button.

Where it's still thin: remote and hosted-agent support is a work in progress, transport is still mostly stdio, and a long compatibility list doesn't mean every pair supports the full surface equally well. It's strongest today exactly where I used it, as a local handoff between a client and an editor-style coding agent.

The loop I haven't closed yet

The build has a clean forward path. Emma proposes, I approve, Claude Code opens a PR. Then it stops.

But opening the PR is the easy part. What happens when it picks up review comments? When a check goes red? When it's approved and ready to merge? Right now all of that is back on me. Emma did the handoff and then went quiet the moment the work left her hands. I'm the integration layer again, just later in the process.

That's the loop I want to close next, and the piece that makes it possible is one of Mastra's recent additions: an inbox for agents. You connect an external source like GitHub, subscribe to the events it emits, and the agent wakes on the ones that matter instead of only when you prompt it (the thread from Mastra).

The shape I'm after: a PR event lands in Emma's inbox as a signal. She wakes, reads what changed, and picks the next move. Review comments go back to Claude Code through ACP to address, the same handoff as before, just triggered by the reviewer instead of by me. An approval becomes a nudge for my sign-off. A failing check becomes something to investigate before anything else moves.

The gate stays exactly where it is. Emma can gather context and route comments on her own, but merging into a production repo is still mine to approve. Signals close the loop without removing the checkpoint. I'll show the build once it actually runs.

Worth your attention

X shipped a hosted MCP server today. The announcement: point Grok, Cursor, or any MCP-compatible tool at the X API with no setup, and your agent gets real-time access to what's happening on the platform (docs here). This lands right on the MCP layer from earlier in this issue, and it connects to something Jesse Genet posted last month about using X to level up her agents. Real-time signal is one of the few inputs a model can't get from training, and a hosted MCP turns it into a tool any agent can call. It also sharpens the question the rest of this issue keeps circling. Once your agent can pull live, unvetted input, what do you let it act on without you?

In case you missed it: Agent Loops vs. Workflows: The Boundary That Makes AI Reliable, my post from last Friday on when to reach for a workflow instead of an agent loop, built in Mastra. A good companion if this week's build has you thinking about agent architecture.

Mastra has been shipping

Since this week's whole build runs on Mastra, two more recent additions worth a look if you build on it too:

• Durable agents. Agent runs now survive client disconnects, browser refreshes, and network blips. The stream is cached, so you reconnect and pick the run back up instead of losing progress when the connection drops.
• Heartbeats (alpha). Run an agent on a cron schedule, delivering each run as a signal into a conversation thread or as an isolated run. Good for daily summaries, periodic checks, or scheduled nudges. Still alpha, so expect breaking changes.

Those two, plus the agent inbox from earlier, point in a consistent direction: agents that wake on events, run on a schedule, and stay alive long enough to finish the job. The same proactive shape Emma has when she watches the analytics and proposes the work.

If you've built a custom agent, what's the first job you'd want it to stop describing and actually hand off? Reply and tell me what you'd delegate first.

And if your team is building custom agents on Mastra and wants help getting them from describing work to doing it, that's the kind of thing I help design in production. Here's how I help Mastra teams.

Damian