Frontier agent harnesses (Claude Code, Codex) include cross-agent messaging features. We've discovered a lightweight technique for connecting together agents working on similar tasks. We believe this technique is generally useful, and we're excited to share it.
Agentic coding
Agentic coding requires different skills from traditional software engineering. We no longer cultivate tip-of-the-finger recall of language syntax and libraries; instead, we frantically context-switch between reviewing code and drafting design documents. My humain brain isn't great at managing ten workstreams at once; I quickly find that I need tools to help, UI or otherwise.
There are a few well-known approaches to this issue. I've tried and abandoned having a single "captain" agent manage my multiple workstreams, in the spirit of Steve Yegge's Gastown. I quickly found myself out-of-the-loop and disoriented. Subagents are a moderately-successful solution to the same issue, but they suffer from certain technical limitations - nesting is generally disallowed, and you can't directly interact with them.
What I really wanted was horizontal agent-to-agent communication. It turns out there is a simple way to implement that. The next section describes the recipe; feed it to your favorite coding agent to try it out.
Tracking agent activity across tickets and PRs
If you organize your work in tickets (Linear, GitHub Issues, JIRA), then you're probably already in the habit of having your agents consult them directly from the source. Your agent does this by calling a tool, either CLI or MCP. By hooking the tool call in your agent harness, you can have local scripts activate when an agent touches some work item. If you simply record the interaction in a database, e.g. SQLite, you get a log of agent accesses to work items. If, in addition, you hook the end of agent sessions, you can compile a live view of which agent conversation is working on which work item.
This is already useful, but you can take it one crucial step further: if, as part of the tool call hook, your script returns to the agent the list of agent IDs currently working on the task, your agents will be able to send each other messages!
For example, the hook could return this to an agent inspecting a PR:
notice: PR <number> is also adopted by Codex session <uuid> since <datetime>. Coordinate with that session before editing or pushing overlapping changes; use the Codex task messaging tool as needed.
This is helpful in a number of circumstances. For example, two agents working on overlapping tasks may spontaneously negotiate ownership boundaries. You can configure similar hooks on PR activities; an agent tasked with updating a PR will coordinate with a different agent tasked with reviewing the same PR.
We initially discovered this by accident. Our goal was to tag and un-tag issues and PRs as work began and stopped in order to give the team visibility. In order to do this it was necessary to implement a semaphore, and we chose the design described above; it was a happy surprise to find that this enabled our agents to work together as a team.
Sample use case: coordinating access to compute resources
We ran heavy backtests this week. Going off loose guidance from our agent skills, multiple agents self-organized in order to avoid clobbering our internal backtest cluster. In the exchange below, a backtest agent asks for another compute window after an interrupted attempt. The backfill agent needs the next slot for production work. Times are UTC.
In another exchange, the backtest agent noticed an error in the backfill runner and notified the agent that owned the task.
This is not a traditional approach to managing the load on compute clusters. It was, however, a highly effective, zero-investment solution to our immediate problem.
We believe that this broad technique - networking agents together by leveraging tool call metadata - is likely to have many uses, and we're excited to find out what other software development teams achieve with it.