Questo articolo in italiano: Building the Autonomous Company: come si costruisce un'azienda che lavora anche quando dormi
Building the Autonomous Company: how to build a business that works while you sleep
In brief. An autonomous company is an organization in which deterministic loops observe, select, execute, and verify operational work while people do other things. It is not a company without human control: control is designed into the right points instead of being exercised by hand over everything. This is the definition I use after building it in two places, Arvo and a factory that repairs software, described here with the limits of what I actually saw. Published October 3, 2026.
The failure I noticed after 33 days
On July 24, the routine that refreshes the data of one of my projects got stuck. No error, no broken page, no alert. I noticed on August 26: 33 days later.
Until then I thought the enemy of automation was the visible error, the kind that breaks and somebody notices. The most expensive failure is the silent one: everything looks fine, and meanwhile nothing is happening. An autonomous system that cannot notice on its own that it stopped is not autonomous. It is just unwatched.
The second problem: the agent that grades its own homework
The second problem is subtler. You tell an agent "fix things," it fixes something, and writes back that everything is fine. Whoever made the change is also the only one who certified that it works.
A competent human does not behave that way in a healthy organization: whoever writes the code is not whoever approves it. With agents we forget this, because it looks like waste. The rule that came out of it is simple: whoever executes the fix has no words to say it worked. The verdict comes from a separate command, outside its session.
What I changed: control by design
Removing controls did not produce autonomy. It produced systems I could not trust. Autonomy arrived when I stopped deleting controls and started designing them. The full principle is in the Italian article on designing control instead of removing it; here is the operational summary:
- One driver's seat at a time. A single causal boundary under change at any moment, so two agents never step on each other.
- One deterministic selector. What to work on now is decided by a written rule, not by the model's mood.
- One independent verifier. The verdict on the work comes from someone who did not do it.
- One machine-readable measure. Without it, a loop spins idle and reports "all green."
Two real cases
Arvo: an organization of agents
In Arvo, a personal training app, agents have roles and handoffs like a small organization. The architecture is described in the Italian article on Arvo and the multi-agent architecture. The underlying lesson is in the Italian piece on building organizations instead of agents: the problem is not how smart a single agent is, it is how they split responsibilities and handoffs.
The factory that repairs software
The second experience is a loop that observes a project, picks a problem, fixes it, and has it verified. The full cycle closed four issues on a real project (PRs #4–#7), with a receipt for every step. It is a small number and I state it as such: it proves the cycle works, not how far it scales. The story is in the Italian article on the factory that repairs software while we sleep.
The definition I use now
| Concept | What I mean |
|---|---|
| Autonomous company | Loops that observe, decide, execute, and verify operational work |
| Control by design | Gates and boundaries written in advance, instead of continuous supervision |
| Independent verdict | Whoever executes cannot certify their own work |
| Learning loop | An error becomes a rule with a test, not a memory |
I tell the move from orchestrating prompts to orchestrating loops in the Italian article I no longer write prompts, I orchestrate loops.
What it means for your company
You do not need a factory to apply the idea. Three questions you can ask today about any process:
- If this process stopped silently, how many days would pass before anyone noticed?
- Who declares the work well done: whoever did it, or someone else?
- Do I have a measure a machine can read, or do I trust a "looks fine"?
If the answer to the first is "I don't know," you have already found the first job to do. For the costs and risks of running agents in a company, see my guide to architecture, costs, and organization.
The limits of what I know
This is one person's experience on two systems, not a market statistic. I have no evidence the model holds above a certain organizational scale, and I do not claim it does. Even my framework's conformance to its own spec is my self-assessment, not an external audit.
Frequently asked questions
What does building an autonomous company mean?
Building an organization in which automatic loops observe, select, execute, and verify operational work, with human control designed into the points that matter instead of applied at every step.
Does an autonomous company run without people?
No. People decide the goals, the boundaries, and the gates. What changes is that they do not have to watch every execution.
Why can't an agent verify its own work?
Because whoever made the change shares the same blind spot that produced it. The verdict must come from an independent actor, with a measure that does not depend on their declaration.
Where do you start?
With a small, repetitive process, and the three questions above: how long before you would notice a failure, who certifies the work, which measure is machine-readable.
This article is also available in Italian.