We are building towards an autonomous company. I do not know what one is yet.
That sentence is less marketable than the alternatives. It would be easier to say we have found the architecture, draw the loop, name the components and turn the current implementation into a set of principles.
We have some principles. We also have a growing collection of things we were previously confident about and later removed.
So I want to keep the claim smaller than the experiment.
What exists today
We have an open-source runtime, Agent Bridge, that gives coding agents a persistent place to work, and Farstax, the managed product around that idea.
We also have durable company goals and events. We can give a Farstax-owned agent a company outcome, current evidence, operating principles and a bounded period in which to work. We can observe the result, record it and decide whether another episode should run.
Independent signals can tell us when parts of the world changed. Authority boundaries stop some actions and allow others.
Those are real pieces. They do not add up automatically to 'company'.
The gap is not more agents
The question that interests me most is what happens between the pieces.
A company goal might live for weeks while an agent run lasts minutes. The world can change while no agent is running. The agent can complete an impressive piece of work without moving the business outcome. A new opportunity can make yesterday's plan irrelevant. An action can be technically available but outside the authority we want the company to have.
How should the system decide when to wake? What context should a fresh episode receive? How much history helps before it becomes noise? When should one episode be allowed to create another? When does the owner need to be involved?
Those are not model-intelligence questions. They are operating questions.
That is why I think the interesting work is shifting away from 'which agent is smartest?'.
Our current hypothesis is deliberately plain
At the moment, the smallest company loop we trust looks roughly like this.
There is one persistent outcome and current authoritative evidence about it. A capable agent receives a concise briefing and a short set of operating principles, then gets one bounded episode to make useful progress.
During the work, we want enough narrative to understand the decisions without recording a firehose of internal reasoning. At the end, the agent reviews what happened, challenges its own conclusion and proposes at most one useful next episode.
Then the company pauses.
The owner can approve the next episode or stop. Fresh evidence can update what the next agent sees; it cannot quietly bypass the gate.
That is not a grand autonomous company. It is an experiment we can inspect.
Why the pause is there
The owner gate is the part I expect people to challenge. If the company has to ask after every episode, is it autonomous?
Maybe not enough.
But we are trying to learn where the safe continuation boundary belongs. Pretending we already know would be a strange way to run the experiment.
The pause gives us a clean place to ask three things: did reality move, did the agent learn something worth carrying forward, and is the proposed next work still inside the authority we are comfortable granting?
If repeated evidence says the gate is unnecessary for a class of work, we can remove it. I prefer earning autonomy that way to granting it because the demo looks better.
The unresolved questions are the interesting part
I have a list.
Can one capable general agent handle most company work, or will durable specialist roles become necessary? How much company memory should be explicit state and how much should be reconstructed from evidence? Can the system choose its own next episode reliably, or does that need a separate review step?
Which business outcomes are measurable enough to support autonomous loops without reducing everything valuable to a metric? How do we grant broad initiative without making permissions so vague that they stop meaning anything? When a model can use native subagents and tools, what orchestration still belongs in our software?
And the question underneath all of them: how do you know that an autonomous company is becoming more useful rather than merely more active?
I do not want to answer these in a manifesto. I want the system to make us answer them.
What these notes are for
That is the reason for publishing this series now rather than when the story is tidy. The interesting part is the change of mind.
We thought a separate worker was useful. Later we removed it. We thought platform health could naturally trigger customer investigation. Later we separated observation from authority. We thought more autonomous capability might require more orchestration. So far, several useful changes have involved less.
Any of those views may change again. If they do, I want the old reasoning to remain visible.
The goal of these Field Notes is not to prove that Farstax has solved autonomous companies. It is to keep a public record of the hypotheses we are willing to put under pressure.
The software can run. The interesting part is what it proves us wrong about next.