There is a very tempting way to design an autonomous company: start with the org chart.
Chief executive at the top. A few general managers underneath. Marketing, engineering, product, operations. Give each box an agent, give the managers permission to delegate to the workers, then add a graph so they can pass tasks around.
It looks plausible because it looks familiar.
We spent time thinking this way. I still think some form of role may matter, but I am much less convinced that a company-shaped hierarchy is the thing to build first.
The awkward question is: what problem is the hierarchy solving for the agents?
Human organisations carry human constraints
A human company needs structure for reasons that are so normal we stop seeing them. People have limited attention. They need clear reporting lines. They cannot all know everything. They need career paths, accountability, meetings, salaries, handovers and ways of dividing work across days and teams.
An agent has different constraints.
A capable coding agent can inspect a repository, read the issue history, research a library, write a test, change the code and review the result in one run. It can also use tools or call other models without us pretending those tools are permanent employees.
If I split that same work into a Product Manager Agent, Engineering Manager Agent, Developer Agent and Reviewer Agent, I may have created four identities and a coordination problem without creating four useful capabilities.
The diagram gets richer. The work gets slower.
That is the failure mode I am trying to avoid.
Roles can become prompts wearing suits
Role names feel more substantial than they are.
Call an agent 'Chief Strategy Officer' and it sounds as if we have created an executive function. Often we have created a prompt with a title.
That is not useless. A role can focus attention, carry a useful perspective and tell an agent which trade-offs to care about. But there is a difference between a perspective and an organisational primitive.
The distinction matters because primitives become architecture. Once 'Marketing Agent' is a first-class thing, you need state for it, routing to it, rules for who can wake it, memory for it and perhaps a manager for it. Soon the software is maintaining the organisation rather than helping the organisation do work.
We have already had enough experience with this project to be suspicious of anything that demands a lot of machinery before it produces evidence.
The smaller model we are testing
Our current experiment is flatter. There is a company mission, but it is not a task. There is one measurable outcome we care about right now, evidence about what is actually happening, and a capable agent with a short set of operating principles and clear limits on what it is allowed to do.
The agent decides what matters next.
That last line is the uncomfortable bit.
If I pre-build the departments, workflows and chain of command, I get to feel as though I have designed the company. If I give a capable agent the outcome and the evidence, I have to let it reason about the work.
That is harder to trust. It is also the thing we are supposedly trying to learn.
A concrete example
Suppose the company outcome is to get five more technical founders to a first genuinely useful result with Farstax.
I could turn that into a tree immediately. Marketing needs traffic. Sales needs conversion. Product needs onboarding. Engineering needs reliability. Customer success needs activation.
Every statement sounds reasonable. None tells me which problem exists today.
Maybe nobody is discovering the product. Maybe people apply and never finish setup. Maybe setup is fine but the first delegated job fails. Maybe the product works and the copy is simply attracting the wrong people.
The organisation should follow the evidence.
If I create five permanent agents and give each one a target, I may manufacture five streams of activity before I know which one matters. So the current rule is deliberately irritating: one outcome, current evidence, find the highest-value obstacle, act within existing authority, observe what happened.
It is less impressive on a whiteboard. That is partly why I like it.
What roles may still be good for
I do not think roles are dead. We are experimenting with something more modest: roles as temporary lenses rather than permanent departments.
A technical lead lens can challenge an implementation. A sceptical reviewer can look for the thing everybody missed. A customer lens can ask whether the workflow makes sense outside the codebase.
Those are useful forms of disagreement. They do not necessarily need durable identities, inboxes and reporting lines.
This is still unresolved. Persistent roles may become useful once there is enough repeated work to justify them. If the same kind of decision keeps appearing, a stable specialist with its own context may be exactly the right answer.
I just do not want to pay that architectural cost in advance.
The test I care about
The question is not whether an autonomous company looks like a company. It is whether it can notice reality, decide what matters, make useful progress, learn from the result and stop when it reaches an authority boundary.
If a flat system can do that, I would rather add structure when the evidence demands it. If it cannot, we will have learnt something useful about where specialisation and hierarchy genuinely help.
For now, the org chart is a hypothesis. It is not the product.