On this page
I use Claude Code, Codex, and Antigravity to work on projects such as Blosharper and rig-c. Giving each agent a task is straightforward. Keeping their work coordinated takes more effort.
When several sessions are working at once, someone needs to know who owns a change, which work depends on it, and whether the next task can start. Without that shared understanding, even useful work can become a problem. An agent may begin a reasonable fix while another session is already changing the same area.
I have had to stop parallel work and bring it back under the project’s coordination process. That experience made the problem concrete: connecting agents is only the beginning. They also need rules for making decisions together.
AgentBridge provides a communication path between these otherwise separate tools. Around it, I have been developing an operating model with a coordinating session that I call HQ.
Team structure and roles
My assistant is the main point of contact, while project HQs coordinate the work. A Tower coordinates an individual issue, and workers (sub-agents) handle investigation and implementation. These roles do not need to form the same hierarchy in every project. Depending on the scale and complexity of the work, HQ can assign it directly to workers or organize it through a Tower.
Tools and roles
This article focuses on the tools, roles, and operating structure. I introduce the individual agents and their family illustration separately in Meet My AI Agent Squad.
The execution tools are OpenAI Codex, Google Antigravity, and Anthropic Claude Code. Assistant, HQ, Tower, and worker describe responsibilities when assigning work, rather than products or fixed specialties.
The diagram summarizes roles and delegation and reporting paths. A Tower is an optional layer. Each project’s harness defines worker counts, further delegation, direct execution, and authority to review and merge. A harness is the set of rules governing how agents run and delegate work. AgentBridge provides communication between supported sessions; it is not another management layer.
Responsibilities of the assistant, HQ, Towers, and workers
The assistant agent brings together project updates and external information, identifying decisions that need human attention. It helps with research and administration, personal and work schedules, and messages I might miss in email or Slack. It routes detailed project work to HQ and brings product direction and consequential decisions back to me.
HQ manages project-wide priorities, the roadmap, assignments, and dependencies. It resolves overlapping ownership or conflicting directions between issues, reviews plans and results, and connects completed work to what comes next. HQ can delegate to a Tower or assign work directly to a worker. When it assigns work directly, HQ also owns the review of the result.
A Tower oversees the resolution of one assigned issue. It checks the objective against the current state, plans the work, delegates tasks to workers, and independently reviews their results. It returns incomplete work for revision and escalates decisions it cannot resolve or changes affecting other issues to HQ. Its focus is coordination and review, so implementation details do not consume the attention needed to oversee the whole issue.
A worker investigates, implements, and validates within its assigned scope. It reports evidence, tests, and unresolved problems alongside the result. If an instruction conflicts with the actual state, it should challenge it with evidence. Decisions beyond its scope go back to the Tower or HQ that assigned the work. Further delegation and actions such as committing or deploying follow the authority granted with the assignment.
Which tool fills each role, whether to include a Tower, and how many workers to launch are choices for each setup. What matters is clear ownership, decision boundaries, and responsibility for reviewing results. Combining roles does not remove those responsibilities.
Assigning and reviewing work
With several sessions working at once, I need clear responsibility for assigning work, making decisions, and reviewing results. I separate project-wide coordination from execution within an issue, with a way for findings from the work to feed back into the plan.
Communication and authority are separate
AgentBridge connects agent sessions. HQ manages the work.
A tool that delivers a message does not, by itself, decide whether the recipient should act on it. Those decisions belong to the operating rules.
An assignment needs to define decision authority and reporting relationships alongside its objective and scope. A Tower coordinates its assigned issue and reports the result to HQ; when HQ assigns work directly, HQ reviews the plan and result. Authority to implement, review, and merge needs to be explicit. A completed commit is not, by itself, approval to merge.
Sessions can also exchange informational notifications where useful. But a status update does not give another session permission to start a new task or change the plan. The Tower assigns workers and directs revisions within its issue; decisions affecting other issues go through HQ.
Project-level decisions center on HQ, while each Tower performs a similar coordinating role within its issue. This does not mean that every informational message must become a conversation with a higher-level coordinator. The important boundary is who can authorize work and change its direction, and within what scope.
A worker needs permission to disagree
HQ having the broader view does not mean it is always correct.
A worker inspecting the actual code may discover that an instruction assumes an API that no longer exists, conflicts with an existing implementation, or touches work assigned elsewhere. Blindly following the instruction would make the coordination structure less useful.
The worker should explain what it found, provide evidence, and challenge the instruction when necessary. In a setup with Towers, the Tower reviews that feedback and revises the plan within its issue, escalating conflicts with other issues to HQ. Workers assigned directly by HQ raise their objections with HQ.
A central coordinator needs feedback from the sessions closest to the work. Otherwise, it simply becomes a convenient place to distribute the same mistake.
From issue assignment to the final report
The following cycle is one way to organize work with a Tower. When HQ assigns work directly to a worker, HQ also takes responsibility for coordinating that issue and reviewing the result. Worker counts and delegation details follow each harness:
- HQ assigns an issue to a Tower. The assignment identifies the objective, relevant repository, scope, and expected result.
- The Tower plans the work and assigns workers. It checks the assignment against the actual state and divides the necessary investigation, implementation, and verification work.
- HQ resolves project-level coordination issues. It handles dependencies, conflicting ownership between issues, and changes in direction.
- The workers implement and validate. Work happens in the assigned workspace or worktree, with tests and checks appropriate to the change.
- Unresolved decisions are escalated. The Tower handles questions within its issue, HQ handles project-level questions, and decisions requiring my judgment come back to me.
- The Tower reviews and reports the outcome. It sends incorrect or incomplete results back to the workers for revision. After review, it reports what changed, what was checked, and anything still unresolved to HQ.
- HQ connects the result to the next issue. It decides what can proceed and what still needs review.
These are responsibilities, not seven mandatory pauses for every change. A routine task may move through them quickly; a conflicting requirement may send the work back to planning.
The boundary between planning and execution needs to be explicit. A worker should not have to guess whether silence means approval. Tasks that require approval should say so; tasks that already authorize execution should not acquire an unnecessary extra waiting step.
Separate worktrees help keep changes apart while they are being developed. They do not resolve incompatible design decisions or make merging automatically safe. Coordination is still necessary.
The working setup
Among the projects I work on, rig-c and Blosharper alone span 26 GitHub repositories. I also work on other projects, including my next game, while holding a salaried day job. I cannot personally attend to every session across these projects. Dividing responsibilities and connecting the work of my agents has expanded the range of work I can manage as one person.
A day job and multiple projects
It has been almost a year since I last wrote code by hand. In the implementation work I give these agents, their coding ability already feels beyond human level to me. These days, I spend more time deciding what several agents should work on and how their work connects.
I feel like a CTO leading several development teams at once. My day involves reading reports from several projects, setting direction, and assigning the next work.
My current subscriptions
Readers may want to know what I actually use, so here is my current setup.
- Two Claude Ultra accounts and two Max accounts (four in total)
- One ChatGPT Pro 500 account
- One Google AI Ultra 30TB subscription
I use ChatGPT’s dot as my assistant. The official documentation describes it as powered by GPT-6 Astra. In my setup, I connect external tools through MCP without paying a separate API token bill. Conversations with dot do not count toward ChatGPT usage limits. Delegated Work and Codex tasks do consume their respective allowances, so when using this setup, I take care not to have work delegated to those surfaces.
I try to use all of the weekly allowance available to me. With several subscriptions, keeping track of where work is concentrated and where capacity remains becomes part of running the projects.
Allocating the available capacity
I mainly use Claude for project HQs. HQ needs capacity for code review, research, and project management, so I do not give it much direct implementation work. Depending on the scale of the work, HQ assigns implementation directly to workers or delegates through a Tower. Direct-execution exceptions follow each project’s rules.
Lately, I start with Codex because its allowance resets frequently in my setup. Since October 31, when about 2% remains, I assign new work to Antigravity and reserve the final 2% for code review. Work already in progress and revisions requested during review are still finished. Antigravity currently gives me the most room to work within the subscriptions I use.
Argon has felt well suited to coding recently. I have used it for about a month without a major incident. I do not use Flash for my coding work: in my experience, the review-and-revision back-and-forth consumed more tokens. Getting the first implementation quickly is only part of choosing a model.
This allocation reflects my current subscriptions and workload. I expect to adjust it as the allowances and models change.
Changes in the workflow
The aim is to connect work through meaningful events: a task finishes, a dependency becomes available, or a worker encounters a blocker.
Letting results drive the next step
Instead of making me carry every result from one session to another, the coordinator receiving the result decides what comes next. Where a Tower is involved, it reviews worker results and reports to HQ. For direct assignments, HQ reviews the results itself and connects them to the next issue.
This does not make message delivery equivalent to task completion. A message can arrive without the requested work succeeding. A session can also stop before reporting its result. Reliable operation requires checking outcomes, not just confirming that a request was sent.
The same applies to context. A restarted session may need to recover the assignment and inspect the current state before continuing. Previous instructions are not a substitute for knowing what has actually happened since then.
Agents waking each other up
The biggest advantage I notice is that the agents wake each other up. HQ and its directly assigned workers wake each other through assignments, questions, answers, and completion reports. In setups with a Tower layer, HQ and Towers do the same. Towers and workers exchange questions, results, and revision requests in turn. Once a Tower returns a reviewed outcome to HQ, work can move on to the next issue. I spend less time moving between sessions to tell each one to keep going.
With a roadmap and a prepared issue list, that flow can continue for quite a while. It feels as though they run until the GitHub issue list is dry. Decisions they cannot resolve and usage limits still require intervention. Even so, reducing the time spent waiting for the next instruction makes a substantial difference.
Comparing GitHub activity
In September, I had three desktops open and coordinated the agents myself, without AgentBridge or HQ. I was already working with multiple agents. In October, I moved that coordination toward AgentBridge and project HQs.
My GitHub profile shows roughly 27,000 contributions over the past year. Since September already involved manual multi-agent coordination, I compared October with August instead. Using the public contribution calendar checked at 01:06 KST on October 31, 2026, I compared the same 29 days, excluding October 30 because that day was still in progress on GitHub’s calendar.
Period | Contributions |
August 1–29, 2026 | 3,195 |
October 1–29, 2026 | 9,627 |
October activity was about 3.01 times August’s level over the comparable period, an increase of 201.3%. That matches my impression of much more work moving through the system after I began using AgentBridge in earnest. Contributions include activity such as commits, pull requests, and issues. The work and project conditions were not held constant, so these counts do not establish a threefold increase in productivity or quality, or prove that AgentBridge caused the entire increase.
Human responsibility and remaining challenges
I want routine coordination to require less attention. I still want to make the decisions that determine what the projects should become.
What I still keep human
HQ and the Towers help concentrate those decisions within their respective scopes. Workers handle implementation details within their assignments, while product direction, ambiguous trade-offs, and consequential changes can come back to me.
Current limitations
There are still limits. HQ can become a bottleneck. Models can misunderstand the same requirement. Context can be lost, sessions can fail, and usage limits can interrupt otherwise sound plans. Centralizing decisions does not eliminate these problems; it gives me a clearer place to inspect and resolve them.
For me, multi-agent orchestration is an ongoing effort to make those boundaries explicit. Adding another capable agent is useful when the system knows what it should do, who can change that decision, and how everyone else learns the result.
AgentBridge gives the sessions a way to communicate. The operating rules are what help them work as a team.
A change in how we work
Working this way has made me think that the culture of work is changing. I expect project direction and the ability to orchestrate several AI agents to become increasingly important human skills.
Using one agent well is a starting point. I think we also need practice making several agents do their own work and carry the results forward. I am learning that by running three projects at once. Having those three projects running at the same time is one concrete result of my experiment.