I did not start with a plan to build an autonomous company. I started with a much smaller irritation: useful work stopped when I left my laptop.
By then I was already using coding agents heavily. They could take on real work, sometimes for long stretches. The awkward part was me. I still had to be in the right chair, in front of the right machine, keeping an eye on the right terminal.
That felt backwards. If an agent was doing the typing, running the tests and working through a problem, why did my physical location matter so much?
So I built Agent Bridge.
The early idea was almost embarrassingly literal: give the agents a permanent place to work, let me check in from Telegram, and let the work survive a closed laptop, a dog walk, the sofa, dinner or a holiday.
This was not a productivity theory. It was how I wanted to work.
The first change was not speed
The obvious way to talk about coding agents is speed. More code. More tasks. More output.
That has not been the most interesting change for me. The bigger change is that software work has become less like a session.
I can start something at a desk, leave, see that a test failed while I am walking the dog, give a short steer and review the result later. The agent has the development environment. I contribute attention when my attention is useful.
That sounds like a small distinction. It changed the shape of the whole project.
A terminal session has a natural human rhythm: sit down, work, stop. An always-on agent does not. Once the work can continue without you sitting there, different questions appear. When should it keep going? When should it stop? What can it decide on its own? What counts as evidence that it actually succeeded? What happens when it needs something only a human can provide?
Those questions are much closer to management than autocomplete.
Then the product started following the behaviour
Agent Bridge was the self-hosted answer to my own working pattern. Farstax came later: what would it look like if the same idea were managed for people who did not want to run the infrastructure themselves?
At first that still sounded like a product about coding agents: persistent workspace, remote access, multiple providers, sessions that survive, somewhere for agents to work when your laptop is shut.
But the more I used it, the harder it became to pretend that the interesting boundary was the pull request.
Software does not become someone else's problem after deployment. It has health, customers, incidents, decisions, follow-up work and a backlog that changes because reality changes. If the workspace is still there, and the agent is still there, why should the useful relationship end when the code ships?
That question pushed Farstax towards operations. Operations then pushed us towards the much more dangerous phrase: 'autonomous company'.
The phrase is ahead of the evidence
I am wary of it.
'Autonomous company' can become a blank cheque for architectural theatre. Draw an org chart. Add a chief executive agent, a manager agent, a research agent and a marketing agent. Connect them with arrows. Call the arrows orchestration.
You can make something that looks impressively company-shaped before it has done anything useful.
We have done versions of that thinking. Some of it survived. Quite a lot did not.
The current experiment is smaller. Can we give a capable agent a meaningful company outcome, enough current evidence to understand reality, clear limits on its authority and a way to continue useful work without waiting for me to decompose every step? Can it observe what happened, adjust and know when it has reached the edge of its authority?
That is the question. Not whether we can make a diagram with enough agents in it.
The odd thing about this journey
The ambition has grown while parts of the architecture have shrunk. That was not what I expected.
I assumed greater autonomy would require more machinery: more workers, more schedulers, more specialised agents, more coordination layers.
Repeatedly, we have found the opposite. A capable agent often already knows how to research, plan, write code, use tools and ask another model for help. Building a second imitation of those abilities around it can make the system more complicated without making it more capable.
So we have been moving responsibilities back to the agents and keeping the surrounding system focused on the things that need to be durable: goals, evidence, authority, state and stopping conditions.
I do not yet know whether that is the right decomposition. I know it has survived more contact with reality than some of our earlier ones.
What I am trying to learn now
The original problem was easy to state: I wanted the work to continue when I left my desk.
The current problem is harder. I want useful work to continue when I am not the person deciding every next step.
That is a different kind of absence. It requires more than remote access. It requires enough autonomy to make progress, enough evidence to stay grounded and enough restraint not to turn initiative into permission.
We are building that now. Slowly, sometimes backwards.
These Field Notes will document the bits that survive, the bits we delete, the incidents and reviews that expose a bad assumption, and the questions we still cannot answer. I would rather publish the uncertainty while it is useful than tidy it into a success story later.