Farstax has a management layer: the part that provisions workspaces, sees status and controls the surrounding infrastructure. In software, that is often called a control plane.
The name is almost asking for trouble. It can see the system. It has status. It has buttons. Surely it should control the work too.
So when Farstax started observing whether a customer's application was healthy, the next step seemed obvious: if something goes wrong, start an agent and fix it.
That would be convenient. It would also cross a line we had not defined clearly enough.
The platform could observe a problem. That did not mean the platform had permission to enter a customer's workspace and act. Once we saw that distinction, we changed the design.
Seeing is not owning
Imagine Farstax notices that an application has failed two health checks. There are at least three separate facts hiding in that simple sentence.
Farstax has evidence that something may be wrong. The customer has an agent in their own workspace that could investigate. A repair might involve changing code, restarting something or touching customer data.
It is easy to slide from the first fact to the third. We nearly did.
The more we looked at it, the less comfortable that felt. The customer connected their coding agents and credentials to their workspace so they could use them. They did not silently grant Farstax a roaming right to operate those tools whenever our monitoring saw an anomaly.
That is not a technical nuance. It is a product boundary.
The design got weaker on purpose
The new flow is less magical.
Farstax observes the unhealthy state and the customer gets a warning where they already work. Nothing investigates automatically.
They can choose to hand the finding to their own agent. That investigation runs in their workspace, using their agent, context and existing permissions. If the agent finds a reasonable fix, the customer can authorise the fix. If they want to tell Farstax what happened, that is another explicit choice.
Observation. Investigation. Repair. Reporting.
Four moments, each with a different kind of authority.
At first this can look like added friction. I now think it is useful friction because each step changes who is allowed to do what.
Why this mattered beyond health checks
The health feature exposed a more general mistake in our thinking. We had been treating the platform as the natural owner of anything that happened around the agents. It provisions the workspace, knows whether it is alive and manages the surrounding service. Surely it should coordinate the work too.
But the coding agent already has an execution environment. It already knows how to inspect files, run tools, reason about a problem and make changes. Putting a second executor in the platform would not just duplicate capability. It would blur responsibility.
So we have been making the control plane narrower.
Farstax owns the things that are genuinely platform concerns: the managed environment, durable product state, customer-facing status and the evidence it can legitimately observe. Agent Bridge owns the execution of agent work. The customer's agent owns the customer's investigation. The autonomous-company experiment owns Farstax's own company work, not the customer's.
Those sentences took us a surprisingly long time to earn.
A weaker control plane can make a stronger product
There is a common instinct in software to centralise authority because centralised systems are easier to reason about on paper. One service can trigger everything. One database knows everything. One orchestrator decides what runs next.
The trouble is that a clean diagram can hide a messy trust model.
If the platform can start an agent in any customer workspace because it saw a health signal, a monitoring feature has quietly become an execution channel. If it can use the customer's credentials to investigate, a convenience feature has quietly become remote access.
I would rather the diagram have one extra arrow labelled 'customer chooses' than pretend those differences do not exist.
This also changes how we think about autonomy
The autonomous-company work makes this boundary more important, not less. We are actively trying to make Farstax more capable of continuing work without me initiating every step, but that does not mean all boundaries should dissolve.
Farstax the company can have broad initiative over Farstax-owned work. A customer workspace is different. The system needs to know which world it is acting in.
This sounds obvious when written down. It was not obvious enough while we were building.
That is one reason I have become sceptical of the phrase 'agent orchestration'. It often describes how work moves without saying who is allowed to move it.
The routing is the easy part. Authority is the architecture.
What we still do not know
We have not found the perfect line. Too many gates and the agent becomes a fancy notification system. Too few and 'autonomy' becomes a polite word for unintended access.
We are still testing where standing authority is useful, where a one-time approval is better and where the system should simply stop.
One principle has survived several redesigns: knowing that something happened is not the same as owning the right to act on it.
For now, Farstax is clearer because the platform does less. If later evidence justifies more standing authority, we can add it deliberately rather than smuggling it in through a monitoring feature.