I keep a slightly embarrassing mental list of things we built and then removed: a worker system, a dedicated health bot and its surrounding management, provider paths we no longer wanted to support, plus tables, services, configuration, status screens and fallback rules.
None of these were jokes. They were built for reasonable reasons. Tests existed. Architecture existed. Some of them worked.
Then the project moved on and they became wrong.
Deleting them has been some of the most useful work we have done.
Building creates a strong presumption of innocence
Once a feature exists, it develops gravity. There are tests for it. Configuration knows about it. Other code has learnt its name. Documentation explains how to use it.
Removing it looks risky, while leaving it alone looks free.
Leaving it alone is not free.
Every extra execution path is another answer to 'who owns this work?'. Every extra bot is another process that can disagree with another process. Every extra provider is another branch in setup, fallback, diagnostics and support. Every old table is an invitation for future code to assume the old concept still matters.
The system pays rent on ideas long after we stop believing them.
The worker was a useful mistake
Earlier versions of Agent Bridge had a stronger idea of a separate worker. That made sense when we were thinking in terms of an interactive bot for conversation and another thing for autonomous engineering work.
As the ordinary agent run became more capable, the distinction got less useful. Why should autonomous work need a separate species of executor?
If the normal run already knows how to use the repository, provider, tools, session and safety rules, a second worker path means duplicated machinery for the same fundamental act: let the agent do work.
So we started removing it. Not because background work stopped mattering, but because the ordinary execution path had become the better owner of it.
That distinction is important. Simplification is not the same as abandoning capability.
Health went through the same cycle
We also built a dedicated Agent Bridge health system with its own modes, service lifecycle and management surface. Then Farstax developed a more direct view of application health.
Keeping both meant two overlapping ideas of who was observing what. That is exactly the kind of duplication that feels harmless until an incident asks a simple question: which one is authoritative?
We removed the managed health-bot path from Farstax. Agent Bridge still has local health primitives. Farstax still observes application health. The useful capabilities remained; the duplicate owner did not.
Removing a provider was clarifying too
Supporting another agent provider sounds additive: one more choice, one more route, more flexibility.
The hidden cost is everywhere else. Configuration accepts another value. Selection logic knows another name. Session storage carries another case. Fallback has another branch. Documentation explains another setup. Tests defend another contract.
When we decided one provider path no longer justified that weight, removing it was not housekeeping. It was an architectural decision. The supported surface became smaller and more truthful.
I would like us to get better at making that call earlier.
The surprising connection to autonomy
'Autonomous company' thinking has a natural tendency to add nouns: goals, tasks, departments, workers, managers, incidents, actions, sensors, memories, schedulers, episodes.
Some of those nouns may deserve to exist. Every noun is expensive.
Once it becomes a first-class concept, the system needs to store it, route it, recover it, explain it and decide who owns it. We are trying to make ourselves earn each new concept with evidence.
Can the existing run own this? Can the existing event history represent it? Can the current agent reason about it without a permanent new role? Can a plain file carry this context instead of a new service?
Often the answer is yes. That has been one of the strongest lessons from the things we deleted.
Deletion is evidence too
There is a version of a project history that makes every removed feature look like wasted work. I do not find that useful.
The worker taught us where ordinary execution needed to improve. The health system taught us which health responsibilities belonged locally and which belonged to the platform. Provider removal taught us that breadth has a carrying cost.
The important question is whether we keep paying for the lesson after we have learnt it.
We are still adding plenty of code. I am not pretending the path to an autonomous company is git rm. But I now pay attention when a design requires a new durable concept.
The burden of proof has flipped.
'Could we build this?' used to be enough to start. Now I want to know why the current owners cannot do the job.
If the answer is weak, I would rather delete an arrow from the diagram than add another box.