There are two equally annoying ways an agent can fail to be autonomous.
The first is recklessness. It decides the next step needs a new service, creates an account, asks for broad credentials, moves data somewhere new and treats each choice as an implementation detail.
The second is helplessness. It reaches a normal engineering decision and asks the human what to do: which library should I use, should I write a small script, should I open an issue, can I add this test, do you want me to investigate the obvious failure?
One has too much initiative. The other has too little.
We have been looking for a boundary that avoids both. The current version is simple enough to fit in one sentence:
The company owns implementation and capability discovery. The owner supplies new external trust.
Routine work should actually be routine
If I give the company an authorised outcome, I do not want to become its task decomposer.
The agent should be able to inspect the evidence, research the problem, choose a sensible implementation, write the code, add tests and use the tools already available to it. If it discovers a missing capability, it should investigate that too.
Maybe the active coding agent already has a native tool for the job. Maybe there is a mature open-source library. Maybe a small local utility is cleaner. Maybe an external service really is the best answer.
The agent should make that comparison.
Asking me 'which one do you want?' before it has done the work is not autonomy. It is outsourcing the interesting reasoning back to the owner.
But implementation choices can become trust choices
The boundary appears when the preferred solution changes who or what the company trusts.
A new API key. A new account. A new OAuth connection. A paid subscription. Permission to send private company or customer data to a new remote service. Broader access to an existing system.
Those are different.
The technical step might be tiny: paste a token, click connect, add a billing method. The organisational consequence can be much larger. The company has created a new dependency, a new data recipient or a new source of authority.
I do not want an agent to infer permission for that simply because the integration would be useful.
‘Ask me’ is still not enough
There is another trap here.
If the agent reaches a trust boundary and sends me a vague message — 'I need access to analytics' — I still have to do half the reasoning.
So we changed what a useful block looks like. Tell me the capability that is missing, which outcome it blocks, the preferred solution and material alternatives, the minimum access required, and what you will do once it exists. Do not ask me to paste a secret into chat.
That turns an interruption into a decision I can actually make. It also gives the next run a durable account of why the capability exists.
This is a management problem disguised as permissions
The more I work on this, the less it feels like traditional access control. It is closer to delegation.
A good manager does not approve every line of work. They establish scope, resources and boundaries. The person doing the work makes ordinary decisions inside them and escalates the decisions that genuinely change the commitment.
We are trying to give agents the same shape of responsibility without pretending they are employees.
The code can enforce some hard limits. Operating instructions can set expectations. The surrounding system can record what authority was granted. The model still has to exercise judgement.
That combination is uncomfortable because it is less deterministic than a workflow engine. It is also more compatible with capable agents doing open-ended work.
The line will move
I do not expect 'new external trust' to be the final answer.
Some external relationships may eventually be pre-approved. A company might have a standing budget for a class of services. A customer might deliberately grant an agent authority to manage an account. On the other side, some actions inside existing systems may be consequential enough that they deserve their own gate.
We will learn that by running the company, not by making the permission vocabulary more elaborate in advance.
For now, this boundary is doing useful work. It tells the agent to stop bothering me with routine implementation, while also making clear that competence is not consent.
I expect the line to move. I would rather move it because repeated work has earned more authority than because a capable model found a persuasive reason to cross it.