I have spent years turning vague work into task lists. It is a useful skill. It is also surprisingly hard to stop doing.
When coding agents became capable enough to take on larger pieces of work, my instinct was still to prepare the path for them: investigate this file, add this test, change this behaviour, open the pull request.
Then I started wondering what, exactly, I was testing.
The agent was doing the implementation. I was still doing most of the management.
A good task can hide a weak system
Detailed tasks are comforting. They make progress visible, reduce ambiguity and give the agent fewer ways to go wrong. They also make the final review easier because you already know what the answer should look like.
For ordinary engineering work, I still use them. But they are a poor test of whether a system can operate with less human initiation.
If I notice the problem, choose the solution, split the work into steps and decide the order, the agent may be highly capable without being meaningfully autonomous.
I have removed the typing, not the deciding.
That distinction became harder to ignore as Agent Bridge moved from remote coding towards the autonomous-company experiment.
So we made the prompt less helpful
Our current company experiment starts with a measurable outcome rather than a prepared programme of work.
One of the first outcomes is deliberately plain: get the next five suitable technical founders to a first genuinely useful result with Farstax.
The tempting thing is to decompose that immediately. Write more content. Improve the landing page. Change onboarding. Contact potential users. Fix product friction.
Those could all be sensible. They could also all be wrong.
If the actual problem is that accepted users cannot complete setup, more traffic may simply create a larger pile of people who cannot complete setup. If the product works but nobody suitable is finding it, another onboarding refactor may be immaculate and irrelevant.
So the agent gets the outcome and the current evidence. Its job is to work out what is most likely blocking progress now.
This is much harder to evaluate
A task has a neat completion condition: did you change the code, did the tests pass, did the pull request open?
An outcome is awkward.
The agent can do excellent work and the number may not move. It can make a choice that was reasonable from the available evidence and still be wrong. It can discover that the most useful next action needs an account or permission it does not have.
This is less satisfying than watching a queue of tickets disappear. It is also closer to the question we care about: can the system decide what work matters, not merely perform work we already chose?
The evidence has to be real
There is a trap here. If you give an agent a broad outcome and then let the agent decide whether it made progress, you have built a very agreeable manager.
The system can always explain why the work was valuable. That is not enough.
For the experiment, the business outcome is tied to evidence outside the agent's own report. The agent may write code, change copy or prepare outreach; those are actions. The outcome moves only when the real-world evidence moves.
That can make a productive day look like zero.
Good.
Activity is easy for agents to manufacture. We are trying to learn whether the activity changes anything.
I still intervene, just at a different level
Giving up the plan does not mean giving up responsibility. I still choose the outcome, decide which evidence we trust, set limits on authority, review consequential changes according to the rules we already use, and retain the ability to stop the experiment.
What I am trying not to do is answer the question the agent is supposed to answer: what matters next?
That is surprisingly difficult when you can see an obvious next step. Sometimes I have to let the agent make a different reasonable choice and see what happens. Otherwise the experiment becomes a puppet show with very advanced puppets.
This changes the way I write instructions
I used to optimise prompts for completeness: more context, more steps, more edge cases, more explicit output.
Now I separate different kinds of instruction. Stable principles should stay stable. Current facts should be fresh. Hard authority should be unambiguous. The outcome should say what needs to become true. The agent should have room inside that frame to decide how.
That separation has made the prompts shorter in some places and the surrounding evidence much more important. The cleverness moves out of the wording and into the quality of the situation we give the agent.
The risk is obvious
An agent can choose badly. It can chase a symptom, overvalue the evidence that is easiest to see, or spend an episode improving something that was not the bottleneck.
Humans do this too, which is not much comfort.
The point of the experiment is not to assume the agent will choose well. It is to make the choice observable, measure what followed and give the next episode enough evidence to adapt.
If that loop does not improve decisions, we will need more structure: perhaps explicit planning, specialist perspectives or a stronger review step. I do not want to add those because they make the architecture feel complete. I want the failures to earn them.
For now, we are giving the agent less of the plan. It makes each run less predictable, which is inconvenient. It is also the only way we will find out whether the agent can choose useful work rather than merely execute mine.