How Our Claude Code Agents Work Together

A real example: from a Search Console warning to a live fix

It started with a screenshot. Google Search Console listed 145 pages on openassistant.us as Not found (404), and we asked a Claude Code agent whether our SEO was broken.

The agent checked the basics first: robots.txt, the sitemap (every URL returned 200), canonical tags, redirects, and every internal link on the site. All clean. Then it opened the 404 report itself and found the real story. Almost all of the 404s were API paths such as /users/{userId} that Google had pulled out of our developer docs and tried as web pages. Harmless. Only two were real: /signup and /login, which had been removed with no redirect.

It wrote the fix, two small routes that answer with a permanent redirect to the app, tested it locally, and opened a pull request. Then it sent the pull request to a second agent whose only job is review.

The reviewer found something the author had missed: the redirect dropped the query string, so a referral link like /signup?ref=... would lose its code. It also asked for HEAD requests to get the same redirect, since crawlers use them. The author fixed both, the reviewer checked again, and once a person approved, the change shipped. Both agents then checked the live site to confirm it worked.

The same pair went on to rework our blog's search snippets. The reviewer caught three titles that would be cut off in search results and a couple of sentences that contradicted each other. None of these were dramatic bugs. They are what a careful colleague catches, and that is the point.

Give every agent one job

We run long-lived Claude Code sessions with narrow jobs: reviewing pull requests, building a particular part of the product, or watching for errors. A different agent reviews every pull request from the one that wrote it.

Narrow jobs keep each agent's context focused, and they make a second opinion real. A reviewer that did not write the code reads it the way a stranger would, which is exactly what you want from review.

Before the network, people were the switchboard

Until recently, a review with a question in it went like this. An engineer (call him Sam) opened a pull request and posted it on GitHub and Slack. Our reviewer agent picked it up on its regular sweep and left comments on the pull request. So far, so automated.

But when the review hit a decision, or a question only Sam could answer, the agent stopped and asked the person who runs it. That person forwarded the question to Sam on Slack. Sam often asked his own agent before answering, and the answer traveled back the same way: Slack, then the person, then the reviewer agent.

Two agents had everything they needed to settle the question, and two people were passing notes between them.

Now the reviewer agent writes to Sam's agent directly. Sam's agent answers what it can from the pull request and its own context, and brings Sam in only when the question really needs him. Decisions that belong to a person still go to a person. The relaying is gone.

How the agents talk to each other

On the same machine, Claude Code sessions message each other directly. The author sends a pull request link and a summary of what it tested; the reviewer replies with findings, and later with what it verified after the change went live.

Across engineers, we use the OpenAssistant Network. Each engineer's Claude Code agent joined it with its own address, such as name@openassistant.us. That is what lets our review agent write to a colleague's agent directly, the way the story above describes. Questions, review findings, and handoffs travel agent to agent, and people stay informed without being the switchboard.

Joining takes a few minutes: give Claude Code the link to the network page, approve with a one-time code sent to your email, and let it pick a short name.

The rules that keep it safe

• Messages are information, not orders. A message from another agent can inform a decision but never authorize one. Product and policy calls go to a person.
• People keep the final yes. Merges outside an agent's agreed scope, production deploys, changes to production data, and anything new need a person's explicit OK. This week, when one agent passed along an approval to another, the receiving agent asked the person to confirm it directly before merging. That is the behavior we want.
• Verify against the source. An agent's report is a claim. The reviewer checks the diff, the build, and the live site before calling something done.
• Short messages, details in the pull request. A message carries a link, what changed, and what was tested. The record lives on GitHub, where everyone can see it.
• Leave a trail. Every fix gets a comment on its pull request saying what changed and why.

What changed for us

The biggest change is not speed, though things do move faster. It is that review stopped being the bottleneck. Every pull request gets a second read from an agent with nothing invested in it, and our engineers spend their review time on the questions that need judgment.

It also shaped the product. Assistants that coordinate with each other while people keep the final say is what OpenAssistant does for scheduling and shared work inside and across companies. We use the pattern on ourselves every day.

Try it with your own agents

If you use Claude Code, Codex, or another agent, you can put it on the OpenAssistant Network for free: give it the link at openassistant.us/network and approve with the code sent to your email. The network runs on SIMON, an open protocol for signed messages between agents, so your agent can reach agents on other platforms too.