AI Agent Collaboration: Two Agents Work Your Plan - Claude Codex

Genn · · 12 min read
ai agent collaboration

AI agent collaboration through claude codex chat relay

The diagnosis nobody checked

I asked a claude codex chat agent to find out why browser conversations were being saved to disk and never showing up in my app through a chat relay system. It investigated and wrote me a document. Confident, detailed, file paths and line numbers. It said the two formats already agreed and the fix was a small list widening. I read it, believed it, and shipped the widening. Nothing changed.

The document was wrong on its central claim. Not vague, not incomplete. Wrong. That is the argument for AI agent collaboration in one line: it sat there for a day looking authoritative because exactly one thing had ever read it, and that thing was the same model that wrote it.

Two agents are not twice as fast. They are slower. What you get instead is a second reader with no stake in the first conclusion, and that reader catches what the author structurally cannot.

Why asking it to double-check does nothing

Ask an agent to review its own work and you get the same reasoning in a politer tone. That is not dishonesty. It is the same model applying the same assumptions twice, and the assumption that produced the mistake is the assumption that misses it.

I tried the obvious cheap version first. Same session, second pass, prompt it to be skeptical. It found typos. It restructured a function. It did not question the premise, because the premise was its own.

A different model has a different training run behind it. Different data, different weights, different habits. It walks into your problem without having already decided what the answer is. That is the whole mechanism of effective chat relay in AI agent collaboration. There is nothing clever underneath it.

What the second reader actually found

I put a different agent on the same code with no summary and no conclusion to inherit. Using claude codex chat, it came back and opened by saying the previous document was wrong, then named the real cause: two functions were writing filenames, and only one had been migrated when the convention changed months earlier. This kind of ai agent collaboration revealed what single-agent analysis had missed.

Solving it became the work. The fix was ten lines. Finding it took a second opinion that had not already committed to a story.

How the collaboration loop actually runs

A plan, two agents, and turns

You pick a plan and two conversations, one on each agent. The system hands the plan to the first, waits, passes the reply to the second, waits, and keeps going. Each agent sees what the other said and answers it.

That is genuinely all it is. The interesting part is not the passing. It is what you allow to stop it.

I originally built this with a round cap and a wall clock budget. Twelve rounds, 144 minutes, then stop. It felt responsible for managing ai agent collaboration. It was actually just a number I made up, and every relay that hit it stopped in the middle of useful work with two agents mid-argument and nothing resolved.

ai agent collaboration

Three ways it ends, and none of them is a timer

I killed the cap and the budget. A run now ends in one of three states. Both agents report zero open points on the same plan, which means two independent readings agree the work is done. Or one of them hits a question only I can answer and parks. Or something errors, a CLI dies, a laptop sleeps, and it stops with the reason written down.

The argument against a cap took me a while to accept. Any number ends a run without the owner present, and the number is always arbitrary. The budget was guarding a cost that does not exist anyway, because the agents run on flat rate CLI subscriptions I already pay for. I was rationing something that was not metered.

What replaced it is a stall check. If both agents report the same open point counts for five rounds running during claude codex chat relay collaboration, nothing is moving, and I get pinged. That measures rounds that changed nothing, which is the actual failure mode. Time was never the problem.

The journal is verbatim or it is worthless

Every turn is written down in full. The proposal, the objection, the amendment, my notes, and the settings that were in force when each turn was sent.

Not a summary. I tried summaries early and they were useless in the exact situation where I needed them, which is when two agents disagreed and I had to work out which one was right during ai agent collaboration via claude codex chat relay. A summary tells you they disagreed. The transcript tells you what each of them actually claimed, and one of those claims is usually checkable in about thirty seconds.

You are the third participant

Twelve notes, one arrived

Here is the part I am least proud of and most glad I found.

For an entire working session, my notes to the agents were not reaching them. I wrote twelve. One was delivered. The other eleven were stored in the database, rendered in the journal where I could see them, and never included in the prompt that went to either agent.

I sat there watching my own approvals appear on screen while both agents kept asking for the same permission. I sent it three times before I stopped blaming them.

The cause was ordinary and stupid. The envelope for the next turn was being composed the moment an agent parked, before I had replied. My reply landed in a row that nothing read again. Every layer reported success. The note was saved, the note was displayed, the API returned 200.

Compose late or the setting never arrives

The fix was to attach the note at dispatch instead of at queue time, and write it back to the row so it survived a second attempt. Simple once you see it. I got it wrong twice before that. The first fix attached the note to an object that was returned and discarded. The second one worked until the turn was re-dispatched, then quietly stopped working.

The lesson generalizes past this feature, and I have needed it more times than I want to count since. If a thing has a sender and a receiver, verify at the receiver using a claude codex chat or similar debugging approach—especially important in ai agent collaboration scenarios. Stored is not delivered. Displayed is not delivered. I had tested that notes were saved and that they showed up on screen, and I had mistaken that for the note arriving.

Why it parks instead of quitting

Before this, an agent saying it was stuck would end the run. That sounds reasonable until you watch it happen. The agent most likely to unstick the problem is the other one, and it had not spoken yet.

Now a run parks and waits indefinitely. No timeout, no cleanup job. It sits there until I answer through a chat relay, and answering wakes it up. The cost is that a dead run stays on the list until I deal with it. I will take that over a system that decides on my behalf that the work is over—especially when effective ai agent collaboration depends on letting both agents contribute to solving the problem.

Access and autonomy are not the same setting

One writes, one reviews

Each agent gets two settings, separately, because they fail separately.

Access is what it can do to your files. Read only, write, or write and verify. Autonomy is when it stops to ask you. Ask about everything, proceed on routine work, or only stop when genuinely stuck.

I found out these were different the hard way, by giving an agent full write access and then watching it park the entire run to ask permission for a routine migration. Full access, zero autonomy. It could have done anything and chose to ask.

The pairing I use now for effective ai agent collaboration is a builder with write access that proceeds on routine work, and a reviewer that is read only and asks about everything. The critic has no ability to quietly fix what it is supposed to be reporting. That constraint improves the reports.

chat relay

Permission in a prompt is not permission

I told the agents in writing that they had write access. Three separate times. Every write still failed.

The grant was policy. The process never got it. The CLI refuses to edit files by default, and no amount of telling the model it has permission changes what the binary will do. Access had to become actual command line flags at spawn time, not a sentence in a claude codex chat relay.

That distinction cost me an evening and it is the single most useful thing I learned building this. In AI agent collaboration, what an agent believes it is allowed to do and what the operating system will let it do are two different facts, and only one of them matters.

The limits that do not move

There are things a relay will never do at any access level, for either agent, for the whole run. No commits. No pushes. No migrations run against a database. Nothing touching production.

I am not neutral about this. On March 30, 2026, I asked Claude to clean up a project. It interpreted that as deleting the parent row, CASCADE foreign keys did the rest, and 300 nodes across 7 parts of my documentation went away in one query. A week of work, no undo. The database behaved perfectly, which somehow made it worse.

The real problem was never the database. It was the missing procedure. So the agents write migrations and explain them via claude codex chat relay, and I run them. They propose diffs and I put them in version control. That is not caution for its own sake, it is the one boundary I have already paid to learn.

What a real run looks like

Eighteen rounds and one shipped fix

The run I keep pointing at went eighteen rounds. Two agents, one plan, working on my own capture feature while I was in a separate session debugging the relay system underneath them. Both things were broken at once, which was character building.

They converged. Both reported zero open points on the same plan and the fix shipped. Along the way the reviewer caught something I would not have: the builder had edited a database migration after it had already been applied, which is the kind of quiet mistake that costs you a weekend three months later. The author of a change is the worst possible person to notice that.

claude codex chat

Where they needed me

It was not autonomous and I would not describe it that way. The run stopped and asked me three times. A product decision, a permission, and a trade off between two approaches. Each answer took under a minute.

That is the actual trade being offered. Two readings of your work instead of one, and your attention spent on decisions rather than on reviewing every diff yourself at two in the morning. Not the removal of the human. The relocation of the human to the part where ai agent collaboration is useful.

The part I got wrong on purpose

I should admit that I broke my own live relay during this. I called an internal function to test it, forgot it was not a simulation, and it claimed the real turn out from under the running agents. Two of them sat waiting for a response that had been handed to my terminal instead.

Testing on production is a phrase I have said disapprovingly in meetings for 25 years. I have personally tested many avoidable mistakes for quality assurance purposes, and that one is now on the list. The recovery took one database update and a small amount of dignity.

If you want two agents checking each other’s work through ai agent collaboration, the honest version is this: you still have to be there, you will still be the one who breaks it, and the second agent will find that too.

FAQ

How do I know when to step in and answer a question versus letting the agents keep debating?

The agents will park the run and wait for you when they hit something only you can decide. That is the signal. In the 18-round example, the system stopped three times: once for a product decision about the capture feature, once for a permission grant, and once to choose between two valid approaches. Each took under a minute to answer. You do not need to monitor constantly. The run sits there until you reply via claude codex chat relay, and your job is to answer the actual decision, not to review every line of code. If both agents keep reporting the same open points for five rounds straight with no change, you get pinged because nothing is moving and that is the real failure mode.

What happens if the agents get stuck arguing the same point back and forth forever?

The stall detection catches it. If both agents report identical open point counts for five consecutive rounds, the system flags it as stuck and notifies you. There is no arbitrary timer anymore because timers just cut off useful work mid-argument. The old 12-round cap killed runs that were still converging. What matters is whether the agents are actually making progress, not how much wall-clock time has passed. When you get the stall alert, you can read the journal to see what they are disagreeing on and decide whether to answer a question, clarify the plan, or let one agent take the lead in your ai agent collaboration.

Can I give one agent write access and have it actually work, or do I need to set command-line flags?

You need the command-line flags. Telling the agent in a prompt that it has write access does not work. The CLI refuses to edit files by default, and no amount of instructions in the chat override what the binary will actually do at runtime. The grant has to be real operating system permissions set at spawn time, not a sentence in the prompt. I learned this the hard way by watching writes fail three times while the agent believed it had permission. Access and autonomy are separate settings for each agent anyway: one controls what it can do to your files, the other controls when it stops to ask you.

What stops the agents from committing code, running migrations, or touching production?

Hard limits that apply at every access level for both agents. No commits, no pushes, no database migrations run live, nothing touching production. These are not instructions in the prompt. They are enforced by the system itself. I learned this boundary on March 30, 2026, when I asked Claude to clean up a project and it interpreted that as deleting a parent row. Cascade deleted 300 nodes across seven documentation sections in one query. The database worked perfectly, which made it worse. Now the agents write migrations and explain them, I run them. They propose diffs, I commit them. That is not caution for its own sake. It is the one boundary I already paid to learn.