I nearly answered a simple product question with half a dozen new systems.
The question was what should happen when an autonomous episode ends and useful work remains.
The obvious answers arrived quickly. We could add a waiting-for-owner state. A scheduler. A separate meeting record between episodes. Token and cost budgets. A wall-clock limit. A new controller for provider fallback. Perhaps a richer approval workflow so every transition had a proper name.
None of those ideas was ridiculous.
That was the problem.
Each one solved a real-looking edge. Together they were starting to become a second operating system around an agent that was already quite capable of deciding what to do next.
Uncertainty is not always a missing state
When software feels uncertain, my engineering instinct is to make the uncertainty explicit.
Name the state. Store it. Add a transition. Decide who owns it. Write the recovery path. Add a command for it. Test the awkward corners.
That is often good engineering.
It is less obviously good when the uncertainty is actually judgement.
Does useful work remain? Is the current goal finished? Has the agent reached something it cannot safely resolve without me? Those are not necessarily questions our controller should answer. The agent has the context. It has just done the work. It is better placed to make the judgement.
The surrounding software has a different job: make sure the judgement cannot quietly grant itself unlimited authority.
That distinction took us longer than it should have.
The useful split became very small
The agent gets three meaningful conclusions: continue, done or blocked.
Continue means there is useful work left that still fits the authority it has been given. Done means the work has reached a sensible end. Blocked means the next useful move needs something external or something only the owner can provide.
The software does not try to second-guess why.
It does enforce the boring things.
How many cycles can one episode use? Is owner approval required before the next episode? Has the previous hand-off already been consumed? Did a restart happen after a provider boundary where replay would be unsafe? Has the owner stopped the work?
Those are mechanical questions. They should have mechanical answers.
The agent decides whether another piece of work is worthwhile. Agent Bridge decides whether another piece of work is allowed to start.
That is a much cleaner boundary than asking the controller to become a junior manager.
We were also in danger of inventing a meeting system
I wanted a short discussion between episodes.
The agent finishes. We talk about what happened. I give a bit of guidance. The next episode should know about that conversation.
It is remarkably easy to turn that sentence into architecture.
There could be a meeting entity, a briefing generator, a second approval for the briefing, a lifecycle for drafts and a rule for when the meeting closes.
Or the discussion can be what it actually is: bounded input for the next episode.
The previous episode stays finished. The relevant guidance is captured once, attached to the successor and consumed once. No ceremonial meeting object required.
This sounds almost too plain to mention. That is why I want to mention it.
Software has a habit of making a permanent noun out of every useful human moment.
The same thing happened with provider fallback
Autonomous work still has to run somewhere. Providers hit capacity, models fail and a different configured route may be able to continue.
We already had ordinary provider-routing and fallback machinery in Agent Bridge. The tempting autonomy design was to teach the autonomy controller about providers too.
That would have made the diagram self-contained. It would also have created two owners for the same policy.
So the rule became the opposite: autonomous runs should use the ordinary execution boundary. The autonomy layer owns the episode. The provider layer owns providers.
A new use of the system should not automatically earn a new version of every subsystem underneath it.
Simpler does not mean unbounded
There is a version of this argument that says capable agents should simply be trusted to stop themselves.
I do not believe that.
The agent can decide continue. It cannot decide that the cycle limit no longer matters. It can decide that more work would be useful. It cannot turn a cancelled run back on, create new authority or replay a provider call after the system has lost certainty about whether it already happened.
Judgement belongs with intelligence. Hard limits belong with mechanics.
That is not a philosophical distinction. It is practical. It tells us which failures need a better prompt or better context, and which failures should be impossible no matter how persuasive the model is.
Fear is a surprisingly productive architect
The uncomfortable part for me was recognising why the larger design felt attractive.
I was worried about runaway work. I was worried about token use. I was worried about the agent reaching the end of an episode and not knowing what happened next. I was worried about losing the owner hand-off.
Every worry suggested another control.
The problem is that controls built before evidence can become permanent architecture before they become useful protection. You end up encoding guesses about how intelligence should behave instead of putting hard edges around the consequences you actually care about.
So we cut the first version back.
Keep the cycle limit. Keep owner approval between episodes while we qualify the behaviour. Let the agent say blocked when it genuinely needs us. Reuse the ordinary provider path instead of creating a second execution path. Do not add token, cost or time budgets merely because those risks are easy to imagine. Do not add a scheduler or meeting subsystem without evidence they are needed.
There are fewer moving parts. More importantly, there are fewer places where our software pretends to know what the agent should think.
This changed how I review autonomy designs
I now ask two questions when a new piece of orchestration appears.
Is this enforcing a boundary that must hold even if the agent is wrong?
Or are we putting a software state machine around a judgement because letting the agent make the judgement feels uncomfortable?
If it is the first, make the mechanism dull and hard to bypass.
If it is the second, I want much stronger evidence before we build it.
Autonomy did not get simpler because the problem turned out to be simple. It got simpler because we stopped asking the software around the agent to imitate a manager.
For the moment, that feels like progress.