One thing that became clearer while building AdamI is that “thinking about what to do” and “actually doing it” should not be treated as the same thing.

At first, it is very tempting to keep the loop simple:

Goal → Model → Action

The model gets a task, reasons about it, decides what should happen next, and then calls a tool.

For demos, this is often enough.

For a long-running agent, it becomes uncomfortable very quickly.

The problem is not that the model cannot plan.

The problem is that a plan is still only an idea.

Execution changes the outside world.

That difference sounds obvious, but it has a lot of consequences once an agent starts working with files, tools, APIs, queues, credentials, or anything that can create side effects.

While building AdamI, I started to think about this as a very simple rule:

A plan is a proposal. Execution is a commitment.

They should not have the same authority.

The reason this matters is that models are naturally good at producing coherent next steps.

Give a model a goal and enough context, and it will usually generate something that looks reasonable:

first inspect the repository,

then modify a file,

run the tests,

fix any failures,

commit the result.

As a plan, this is useful.

But every step in that sequence lives in a different operational context.

Reading a file is not the same as modifying one.

Modifying a file is not the same as running a shell command.

Running tests is not the same as pushing code.

The model may see them as one continuous chain.

The system should not.

That is the distinction I care about.

The model can think in terms of “what should happen next.”

The runtime has to think in terms of “what is actually allowed to happen next.”

This is one of the reasons AdamI does not collapse reasoning, routing, planning, and execution into a single step.

There are separate pieces involved in deciding where a request should go, how a task should be broken down, and how work should actually run.

That separation is not about making the architecture look more sophisticated.

It is about creating places where the system can interrupt itself.

That turns out to be important.

If planning and execution are tightly coupled, the agent tends to move directly from “I think this is the next step” to “I am doing this now.”

There is very little room to ask:

Is the current state still valid?

Does this action need permission?

Has something changed since the plan was created?

Should the system wait?

Is the tool available?

Has this action already been attempted?

Would repeating it create a problem?

Those questions belong between planning and execution.

This also connects to something I have been thinking about a lot recently: persistent agents.

A short-lived chatbot can get away with assuming that the world stays mostly stable during one response.

A persistent agent cannot.

A plan created ten minutes ago may already be stale.

A plan created yesterday almost certainly needs to be checked again.

Maybe a file changed.

Maybe another task completed first.

Maybe the user changed the goal.

Maybe a credential expired.

Maybe the system restarted.

Maybe the task is still valid, but one step no longer is.

This is why I do not want AdamI to treat a generated plan as a script that simply runs until the end.

The plan should remain revisable.

Execution should remain conditional.

The longer the agent runs, the more important that becomes.

There is another reason I like this separation: it makes failures easier to understand.

If an agent makes a bad decision and planning and execution are fused together, it can be difficult to tell where the real problem was.

Was the reasoning wrong?

Was the routing wrong?

Was the plan fine, but the environment had changed?

Was the action allowed when it should have been blocked?

Was the right action executed with the wrong parameters?

Those are very different classes of failure.

If the architecture keeps them separate, we get more useful evidence.

We can inspect the proposed plan.

We can inspect the state before execution.

We can inspect the action that was actually allowed.

We can inspect what happened afterward.

That is much more valuable than a single log line that says the agent “failed.”

This is especially important for replay.

I do not want replay to mean simply re-reading what the model said.

I want it to be possible to reconstruct the chain:

What did the system know?

What did the model propose?

What did the runtime allow?

What actually executed?

What came back?

What changed afterward?

If those boundaries are clear, replay becomes useful for debugging.

If those boundaries are blurred, replay becomes mostly storytelling.

That is a big difference.

The Guardian layer also fits naturally into this design.

A model can suggest an action.

That does not mean the model grants itself permission to perform it.

This sounds like a small architectural choice, but I think it is one of the most important ones for autonomous systems.

The more capable the model becomes, the less comfortable I am with giving it a direct path from reasoning to side effects.

Better reasoning does not remove the need for control.

In some ways, it increases it.

A weak system makes limited mistakes.

A strong system can execute a bad assumption much more effectively.

So the goal is not to stop the model from planning aggressively.

I actually want it to explore possibilities.

The goal is to make sure that exploration and authority are not the same thing.

This also changes how I think about autonomy.

Autonomy is often described as removing humans from the loop.

I do not think that is the most useful definition.

A system can be highly autonomous while still having strong internal boundaries.

It can plan freely, but validate before acting.

It can continue tasks, but stop when state becomes uncertain.

It can use tools, but only inside defined permissions.

It can recover from failures, but not silently reinterpret them as success.

That kind of autonomy is much more interesting to me than simply letting an agent run without interruption.

AdamI is not finished here.

There are already separate components for routing, planning, workflow execution, task state, and security-related controls.

But having those components is not the same as proving that the boundaries between them are correct.

The next useful work is to test the transitions.

What happens when a valid plan becomes invalid before execution?

What happens when a task resumes after interruption?

What happens when a tool is available at planning time but unavailable at execution time?

What happens when a proposed action exceeds current permissions?

What happens when the system is not sure whether a previous step completed?

Those are the cases that matter.

Not because they look impressive in a demo.

Because they are exactly where long-running agents become unreliable if the architecture is too trusting.

The more I build around this problem, the more I think the separation between planning and execution is not just an implementation detail.

It is part of the control model.

A model should be able to think broadly.

A system should act narrowly.

That gives us room to add validation, permission checks, state checks, waiting, recovery, and replay without asking the model itself to be the final authority over all of them.

And that leads to the principle I keep coming back to:

The more autonomous an agent becomes, the more important it is to separate what it wants to do from what the system actually allows it to do.

That is the direction I want AdamI’s runtime to keep moving toward.

AdamI Architecture Note #7 — Building a persistent AI system, one engineering problem at a time.