
Bridge: A command center for coordinating AI coding agents
Bridge: A command center for coordinating AI coding agents
Jayanth Krishnaprakash







AI coding agents are becoming genuinely useful for real engineering work.
They can inspect codebases, reason through implementation plans, review diffs, run commands, write patches, and summarize findings. But as soon as teams start using more than one agent at a time, a new
problem appears: coordination becomes the bottleneck. A common workflow looks like this:
one agent has broad system context
several other agents work on focused tasks
one worker investigates authentication
another reviews database migrations
another checks deployment drift
another validates tests or CI failures
Individually, each agent can be useful. Together, they can become chaotic. The human ends up acting as the message bus:
copying context from one agent to another
tracking which agent is doing what
collecting partial reports
resolving conflicting assumptions
re-sending updated instructions
remembering which terminal session belongs to which task
At small scale, this is annoying. At six agents, it becomes a coordination tax. That is the problem Bridge is designed to solve. Bridge is a small CLI tool for coordinating live terminal agents using tmux. It does not use SDKs and APIs, it does not run a daemon and it does not introduce a new framework. It uses a primitive many engineers already trust: terminal panes. With Bridge, a session can have:
a lead agent
one or more worker agents
named panes
structured messages
repeatable reports
session logs
recoverable metadata
The lead agent can be Claude or Codex. Workers can also be Claude, Codex, or a mix of both. This matters because real workflows are not always symmetrical. Sometimes Claude has the best long-running context. Sometimes Codex is the better lead. Sometimes the right answer is a Claude lead with Codex
workers. Sometimes it is the opposite. Bridge keeps that flexible. A typical Bridge room looks like this:
lead [master/claude]
worker_auth [worker/codex]
worker_tests [worker/codex]
worker_docs [worker/claude]
The lead stays on the left. Workers stack on the right. Each pane is addressable. Each agent can receive explicit tasks. Workers report back in a predictable format. Instead of manually copying messages across terminals, the lead agent can coordinate the room through Bridge commands.
For example, the workflow can become:
Split this cleanup across three workers. Assign isolated tasks. Collect reports. Keep track of blockers. Do not allow destructive operations without approval.
Bridge gives the lead agent the command surface to do that. The most important part is not just spawning agents. Spawning agents is easy. The harder part is operational hygiene:
Who started this agent?
What was it asked to do?
Which pane is it in?
What session id does it belong to?
What did it report?
Is the worker still alive?
Can this session be resumed later?
Bridge treats those as first-class concerns. Every Bridge session gets named and logged. Agents are registered. Messages are recorded. Reports can be collected. Session metadata is stored outside the project
directory so the tool can be installed globally without scattering .bridge folders everywhere.
Install globally:
npm install -g @riverline/bridge-cli
bridge setup
Bridge is intentionally small. It is not trying to be an AI agent framework. It is not trying to replace Claude Code or Codex. It is a coordination layer for the tools engineers already use. AI coding workflows may not be one giant agent doing everything. It may look more like a lead agent coordinating a small room of focused workers. If that is the direction engineering workflows are moving, then the missing primitive is not another model wrapper. It's bridge!
Find the package here: https://www.npmjs.com/package/@riverline/bridge-cli
AI coding agents are becoming genuinely useful for real engineering work.
They can inspect codebases, reason through implementation plans, review diffs, run commands, write patches, and summarize findings. But as soon as teams start using more than one agent at a time, a new
problem appears: coordination becomes the bottleneck. A common workflow looks like this:
one agent has broad system context
several other agents work on focused tasks
one worker investigates authentication
another reviews database migrations
another checks deployment drift
another validates tests or CI failures
Individually, each agent can be useful. Together, they can become chaotic. The human ends up acting as the message bus:
copying context from one agent to another
tracking which agent is doing what
collecting partial reports
resolving conflicting assumptions
re-sending updated instructions
remembering which terminal session belongs to which task
At small scale, this is annoying. At six agents, it becomes a coordination tax. That is the problem Bridge is designed to solve. Bridge is a small CLI tool for coordinating live terminal agents using tmux. It does not use SDKs and APIs, it does not run a daemon and it does not introduce a new framework. It uses a primitive many engineers already trust: terminal panes. With Bridge, a session can have:
a lead agent
one or more worker agents
named panes
structured messages
repeatable reports
session logs
recoverable metadata
The lead agent can be Claude or Codex. Workers can also be Claude, Codex, or a mix of both. This matters because real workflows are not always symmetrical. Sometimes Claude has the best long-running context. Sometimes Codex is the better lead. Sometimes the right answer is a Claude lead with Codex
workers. Sometimes it is the opposite. Bridge keeps that flexible. A typical Bridge room looks like this:
lead [master/claude]
worker_auth [worker/codex]
worker_tests [worker/codex]
worker_docs [worker/claude]
The lead stays on the left. Workers stack on the right. Each pane is addressable. Each agent can receive explicit tasks. Workers report back in a predictable format. Instead of manually copying messages across terminals, the lead agent can coordinate the room through Bridge commands.
For example, the workflow can become:
Split this cleanup across three workers. Assign isolated tasks. Collect reports. Keep track of blockers. Do not allow destructive operations without approval.
Bridge gives the lead agent the command surface to do that. The most important part is not just spawning agents. Spawning agents is easy. The harder part is operational hygiene:
Who started this agent?
What was it asked to do?
Which pane is it in?
What session id does it belong to?
What did it report?
Is the worker still alive?
Can this session be resumed later?
Bridge treats those as first-class concerns. Every Bridge session gets named and logged. Agents are registered. Messages are recorded. Reports can be collected. Session metadata is stored outside the project
directory so the tool can be installed globally without scattering .bridge folders everywhere.
Install globally:
npm install -g @riverline/bridge-cli
bridge setup
Bridge is intentionally small. It is not trying to be an AI agent framework. It is not trying to replace Claude Code or Codex. It is a coordination layer for the tools engineers already use. AI coding workflows may not be one giant agent doing everything. It may look more like a lead agent coordinating a small room of focused workers. If that is the direction engineering workflows are moving, then the missing primitive is not another model wrapper. It's bridge!
Find the package here: https://www.npmjs.com/package/@riverline/bridge-cli
