Wiring Agents to Each Other

The two terminals had been open for three weeks. Claude Code on the left, Codex on the right. I would write a change in Claude Code, copy the diff, paste it into Codex, ask Codex to find what Claude missed, copy the feedback back, hand it to Claude, ask for the fix. The workflow worked. The catch rate was real. The friction was insulting.

A second agent reviewing the first agent’s work catches things the first agent cannot see. I wrote about why in The Adversarial Audit. The student grading their own homework misses the assumptions they never noticed they were making. Two instances of Claude reviewing each other share blind spots inherited from training. Two instances of any single model reviewing each other share the same problem. The critic’s value comes from lineage difference. A reviewer from a different model family catches what a same-family reviewer rubber-stamps. A cheap critic with the right ancestry can outperform an expensive critic with the wrong one.

Knowing this and acting on it are different things. The acting-on-it part has stayed clumsy. Two harnesses means two terminals, two prompts, two context windows, and a human ferrying state between them by hand. The workflow tax ate most of the value the second model was supposed to add. By the time I had moved the diff across the desk, I had already lost the thread of why I asked for the review.

The fix turned out to be hiding in plain sight.

Model Context Protocol is the standard for connecting agents to data sources. Anthropic shipped it for Claude. Everyone else picked it up. The official framing is agent-to-data. The protocol itself does not know the difference between a database and another agent. A tool call is a tool call. The remote end can be Postgres. It can also be a coding assistant.

Wrap the Codex CLI as a thin MCP server. Expose three tools: codex_review, codex_implement, codex_ask. The server is a hundred lines of code. Each tool shells out to the Codex CLI with the right flags, captures stdout, returns structured output to the caller. Add the server to Claude Code’s MCP config. Claude Code now sees Codex as a callable tool inside the same session.

The handoff that used to require two terminals and a human courier is now a function call. Claude Code finishes a change. It calls codex_review with the diff. Codex returns its findings as structured text. Claude reads the findings inside the same context window where it wrote the original code. The fix loop closes inside one session.

There is a quieter benefit underneath the obvious one. The Codex CLI uses the user’s ChatGPT subscription auth. The MCP server invokes it as a subprocess. No second API key. No per-token billing on top of the subscription. The same trick works in reverse: wrap Claude Code as an MCP server for Codex to call, and Codex sees Claude as a tool, billed against the Claude subscription. The OpenAI and Anthropic terms each have their own opinions about parallel subscription use, and the responsible move is to read them before scaling this pattern across a team. For a single developer running occasional reviews against work they are already doing, the integration is the cleanest version of the workflow I have found.

The pattern generalizes immediately. Any coding harness with a non-interactive CLI mode can be wrapped the same way. Cursor’s headless mode, Aider, Antigravity, anything that takes a prompt on stdin and writes structured output on stdout. The wrapping code is mechanical. The MCP server for each is roughly the same shape with the binary name swapped out. A developer who wants a four-agent panel, one implementer, one security reviewer, one refactorer, one test writer, each from a different model family, can build it in an afternoon.

This is the part that matters. The vendor’s blessing stops being required for interesting compositions. The model providers can ship whatever opinionated single-agent experience they want at the IDE layer. The practitioner gets to assemble their own panel underneath, each agent playing a role chosen for fit. The IDE-plugin politics stop driving the toolchain. The role I described in The Senior Agentic Engineer gains new reach. That role was already about orchestrating agents and reading the work they return. MCP wrapping extends the orchestration across vendor lines.

The Hitchhiker’s Guide had multiple field correspondents covering the same galaxy, each from a different angle, each catching what the others missed. The Guide was better for the redundancy. The pattern shows up wherever the cost of independent perspectives stays cheap.

Cost is the question to watch. A panel of four agents reviewing every change is overkill for routine work and probably too slow for trivial diffs. The instinct I have settled into is to scope reviewers by stakes. Critical paths get the panel. Routine refactors get one implementer and one critic. Exploratory work gets one agent and a fast feedback loop. The MCP wrapping removes the friction that was forcing the decision into “one agent because two is too annoying.” What you do with the flexibility is your call.

If any of this lands, here is what to do next. Pick the harness you use most. Identify the CLI for one other coding assistant whose lineage differs from your primary. Write the MCP server. There are reference servers on GitHub already; the wrapper for any new CLI takes a few hours of patient work. Wire it into your primary harness. Use it for a week on real work. Notice what the second agent catches that the first missed. Decide whether the pattern earns its place in your toolchain.

The interesting thing about agent-to-agent through MCP is how little ceremony it took to arrive. The protocol was there. The CLIs were there. The composition was waiting for someone to type the configuration. The agents have been ready to talk to each other for longer than most teams have noticed.

First published May 20, 2026 on 42 Insights.