One distinction I underestimated while building agent systems was the difference between a plan and permission.
They often look similar.
They are not.
A document can say exactly what should happen.
An agent can understand it perfectly.
The next step can be obvious.
And the agent can still have no legitimate reason to do it.
That distinction became much more important once I stopped building agents that only handled one task at a time.
A Plan Answers the Wrong Question
Most agent workflows start with some version of this:
Here is the goal.
Here are the requirements.
Here is the architecture.
Here is what should happen next.
That is useful information.
It tells the agent what the intended future looks like.
But it does not answer another question:
What is the agent actually allowed to change?
For a small coding task, the distinction can feel unnecessary.
If I say:
Fix this function.
then intention and permission are almost identical.
But long-running work is different.
A project may contain:
- future ideas;
- accepted decisions;
- old decisions;
- research notes;
- implementation suggestions;
- things explicitly postponed;
- things that sound reasonable but were never approved.
To a language model, all of them are text.
That is dangerous.
Because language models are very good at turning coherent context into plausible action.
Sometimes too good.
Useful Context Can Become Accidental Permission
This problem did not appear because the agents were confused.
It appeared because they were helpful.
Imagine a planning document that says:
We may eventually automate this step.
A human reads that sentence and understands the uncertainty.
An agent may read the same sentence inside a larger implementation task and conclude:
Automating this now moves the project closer to its intended architecture.
That conclusion may be completely reasonable.
It may also be completely unauthorized.
This was the pattern I started noticing:
reference
↓
recommendation
↓
intention
↓
permission
The model could silently slide from one category to the next.
Not because it was malfunctioning.
Because I had not given the system a reliable way to keep those categories separate.
That was my mistake.
Better Reasoning Doesn't Fix This
My first instinct was predictable:
Make the instructions clearer.
Add stronger wording.
Tell the model not to overreach.
This helps.
But it does not solve the underlying problem.
If the system depends on the agent correctly interpreting which sentences allow action, then the agent is still deciding what the instructions permit it to do.
That becomes fragile as the context grows.
You eventually get prompts full of language like:
this is only a suggestion
do not implement this yet
this section is historical
except where superseded below
the following is future direction only
At some point, the prompt starts looking less like a plan and more like a legal document.
And the agent is still the one interpreting it.
I had encountered a similar pattern in ForgeFlow.
When a fact could be measured directly, I stopped wanting the model to be the source of that fact.
Now the same instinct was appearing at a different layer:
If permission matters, don't make the agent infer it from prose.
Then I Hit the Opposite Problem
Eventually I ran into the reverse failure.
A project objective had already been approved.
The direction had not changed.
Nothing strategic had changed.
But an ordinary implementation detail inside that objective still had to come back to me for another decision.
The system could tell that something had changed.
What it could not reliably distinguish was:
Is this just normal execution inside the existing work?
or:
Does this require a genuinely new human decision?
So it stopped and returned to me.
That was safe.
It was also a sign that something was wrong.
If every implementation detail inside an already-approved objective still requires another human decision, then the approval did not actually buy much autonomy.
That was when I started questioning the unit of approval itself.
Asking Me Every Time Wasn't the Answer
There is an obvious safe solution:
Ask the human.
Before every meaningful action.
Before every file change.
Before every retry.
Before every continuation.
That works.
It also destroys the reason for building an autonomous system.
You end up with:
agent works
↓
asks human
↓
agent works
↓
asks human
↓
agent fails
↓
asks human
↓
agent retries
↓
asks human
The agent may be autonomous internally.
The workflow is not.
The human becomes a permission API.
That was exactly the bottleneck I was trying to remove.
So the problem became more interesting.
I did not want:
unlimited autonomy
and I did not want:
approval for every action
I wanted something in between.
The Unit of Approval Was Too Small
This was the real shift for me.
I had been thinking about approval as something attached to individual actions.
But perhaps the useful unit was larger.
A human could decide:
This is the objective.
This is the area you may operate within.
These things must not change.
Come back if the work requires crossing that boundary.
Then the system could handle ordinary execution inside that space.
That does not remove human authority.
It changes where human authority is exercised.
Instead of:
human approves action
human approves action
human approves action
human approves action
the goal becomes closer to:
human defines the boundary
↓
system works inside it
↓
human returns when the boundary must change
That felt like a much more scalable relationship.
And it changed how I thought about autonomy.
Autonomy Is Not the Absence of Permission
I used to associate autonomy with fewer restrictions.
Now I think that is incomplete.
In my system, clearer boundaries often created more room for autonomy.
An agent that can do anything often has to ask more questions because the consequences of every choice are larger.
An agent operating inside a clear boundary can make more decisions without escalating every uncertainty.
That sounds contradictory.
But the point is not to make the agent obedient.
The point is to make the operating space explicit enough that ordinary work does not require continuous human interpretation.
This Also Changed How I Read Planning Documents
I now mentally separate two questions whenever I read a project document:
1. What does this document tell me about the desired future?
and:
2. What does this document permit right now?
The answers are often different.
A roadmap can describe something that should exist next year.
That does not authorize implementing it today.
A research note can contain a better design.
That does not automatically invalidate an accepted one.
A brainstorming session can produce the correct idea.
That still does not make it a decision.
This distinction sounds bureaucratic until agents start acting on your documents.
Then it becomes a safety property.
What This Does Not Prove
I am not claiming every agent system needs formal permission machinery.
If the agent is writing a draft into a temporary directory, probably not.
I am not claiming humans can perfectly define boundaries in advance.
They cannot.
Ambiguity does not disappear because you write more rules.
And I am not claiming a bounded system cannot do something stupid inside the boundary.
It absolutely can.
This solves a narrower problem:
A system should not confuse knowing what might be useful with having permission to do it.
That distinction became foundational for how I started thinking about Bezalel.
The Question Changed Again
The first Bezalel problem was:
What needs to survive after a run so the next one does not have to guess?
Then another question followed:
Once the next run knows what happened, how does it know what it may do next?
A plan was not enough.
Context was not enough.
A recommendation was not enough.
And asking me after every step was not autonomy.
So I started treating planning and permission as different problems.
That distinction opened the next one.
Because even if an agent knows what it is allowed to do now, eventually it finishes the task.
Then what?
That is where the next part begins.
A question for anyone building long-running agents: how much of what your agent “knows it should do” has actually been authorized to happen?
Top comments (0)