I spent a while assuming Agent Bridge would eventually need an agent layer of its own.
A worker to own the task. A planner to break it down. Maybe a few roles to pass work between. If you are building something with "agent" in the name, this can feel almost compulsory.
The awkward part was that the coding agents already had the bit I was trying to rebuild.
Claude Code, Codex, Cursor and the other tools we support already bring their own agent loop: they inspect repositories, follow instructions, use tools and manage provider-native sessions. Putting another agent framework around them did not add much capability. It mostly gave me two systems deciding what the work meant.
That has changed how I think about Agent Bridge.
It should not be another coding agent. It should make the work around the coding agent durable.
The agent was already there
A fairly normal Agent Bridge conversation now looks like this:
``text Telegram or Discord ↓ durable workstream ↓ ordinary Run ↓ provider-native session ↓ Codex / Claude Code / Cursor / Agy / Grok ↓ repository + AGENTS.md + Skills + native tools ``
The provider is still the agent doing the software work.
Agent Bridge owns the parts that become awkward once that work has to survive outside one terminal: recoverable conversation history, message delivery, Run lifecycle, cancellation, provider selection and fallback, scheduled work, and bounded autonomous continuation.
That is a narrower job than "be the agent", but it has turned out to be a useful one.
The workstream identity is designed to survive provider changes. A Telegram topic, for example, has its own canonical conversation key. Claude Code might start the work. Later I can continue from my phone, or switch to Codex if that is the better tool for the next step. The wider workstream is separate from each provider's native session identity.
That distinction matters. We are not pretending a Claude session somehow becomes a Codex session. The durable thing is the workstream around those sessions.
Ordinary Runs became a design constraint
The phrase "ordinary Run" appears rather a lot in the Agent Bridge code and documentation. It is not especially glamorous terminology, which is probably healthy.
The idea is simple: work should enter through the same execution path whether I type a message now, a scheduled routine fires later, or an explicitly authorised autonomous episode wakes up.
There should not be one path for conversations, another hidden job system for unattended work, and a third orchestration engine for anything described as autonomous.
Scheduled routines are a good example. A routine stores an agreed instruction and, when its time arrives, submits that instruction back into the existing companion Run or bounded autonomy controller. It does not acquire extra authority because a clock was involved. The existing provider, repository, credential and execution rules still apply.
This constraint has occasionally made a feature slightly harder to add. It has also made the resulting system easier for me to reason about. When something goes wrong, there are fewer competing owners of the work.
We did build more machinery
This is not a principle I arrived at before writing the software.
Agent Bridge previously had a persisted Engineering Worker product model: work items, jobs, role assignments, approvals, feature plans and related tables. We removed those tables in schema version 9 because there was no longer a runtime owner for that model.
The removal was useful evidence rather than just tidying. We had built structures for a version of the product in which Agent Bridge itself organised engineering work. In practice, the provider agents and repository instructions were already much better placed to organise that work.
I wrote recently that the autonomous company probably is not an org chart. This is the same lesson one layer down.
If Claude Code already knows how to investigate a failure, ask its native subagents for help, edit the code and run the tests, Agent Bridge does not need to invent a "developer" role and a "reviewer" role so that it can feel agentic enough.
It needs to make sure the right conversation reaches Claude Code, the Run can be stopped, durable state survives a restart, the result gets back to the user and a fallback provider can take over when needed.
Those are less theatrical problems. They are also the problems I keep encountering in real use.
The boundary is not ideological
I do not think "never build orchestration" is a useful rule.
A future requirement may eventually need a runtime primitive that cannot be expressed cleanly as an ordinary Run around a native coding agent. If that happens, the right answer may be to add one.
But I want the requirement to earn the abstraction.
The provider CLIs we use already have their own session models, tools and delegation mechanisms. Rebuilding those features outside them creates another layer that has to understand their behaviour, stay compatible with it and decide which system is authoritative when the two disagree.
The simpler division is holding up better:
Let the coding agent own the software work. Let Agent Bridge own the durability around it.
Farstax then adds a different layer again. It runs Agent Bridge in a managed workspace so the repository, tools and sessions have somewhere persistent to live. The managed product owns infrastructure and lifecycle; it still does not need to become the coding agent.
That boundary is useful partly because it leaves room for the underlying agents to improve without us having to imitate each improvement first.
What I am watching next
The interesting question now is where that boundary breaks.
Some of the work we are considering — voice input, richer workstreams, better continuation and more reliable unattended execution — fits the current model quite naturally. It changes how work enters, survives or returns. It does not require Agent Bridge to decide how a coding task should be decomposed.
Something eventually may.
Until then, I am increasingly suspicious of architecture that appears mainly because the product category seems to demand it. We already have capable agents. The more useful job for Agent Bridge is making their work durable enough that I do not have to sit beside the terminal while they do it.