NAEOS Technical Build Log #003-What Happens When Policy Changes Mid-Task?
Here's a simple experiment I'm using to think about AI agent governance.
Start with:
Policy v1
Dependency X is allowed.
The coding agent receives a task.
It creates a plan:
Install X → modify configuration → implement feature → run tests.
So far, everything is valid.
Then something changes.
Policy v2
Dependency X is no longer allowed.
The agent still has its original plan.
Its context still contains the old decision.
Its generated code may still assume X exists.
Now we have an interesting question:
Should the system trust the plan because it was valid when created?
I don't think so.
A plan is not an authorization token.
This leads to an important NAEOS design principle:
Authorization must be evaluated at the controllable execution boundary, not only when the plan is created.
The agent can continue reasoning.
It can update its plan.
But before the externally meaningful action occurs, the current policy should be evaluated again.
That creates something like:
Plan → Policy Check → Execute
rather than:
Plan → Execute
This distinction becomes particularly important when agents operate asynchronously or for long periods.
Policies change.
Repositories change.
Dependencies change.
Permissions expire.
Security conditions change.
An agent's context can become stale without the model itself becoming “wrong.”
The system needs to recognize that difference.
That's one reason I'm treating policy and runtime as separate concerns from the model in NAEOS.
The model is responsible for proposing.
The governance layer is responsible for deciding.
The runtime is responsible for executing.
The observation layer is responsible for establishing evidence.
I'm now interested in testing this with multiple coding agents against the same repository.
If two agents receive the same task and the policy changes halfway through, can the governance layer consistently prevent the stale plan from becoming an unauthorized action?
That's the experiment.
Repository:
https://github.com/NAEOS-foundation/naeos
What would you re-check at the execution boundary in an agent system?
Alongside the policy version, I’d re check the concrete target and capability scope. An approval can become unsafe if the branch, working tree, lockfile, or command arguments change afterward. Binding authorization to a digest of the proposed action and relevant state and making it shortlived and single use would force re planning instead of silently reusing an old “yes.” For the 2 agent test, will approval be capability level or tied to an exact diff and command?
The Plan then Policy Check then Execute pattern maps directly to what I see in long coding sessions. We run multi-hour builds on our SEO platform across seven languages, and the context window itself is the stale-plan problem in miniature. An agent proposes a fix based on state it read forty minutes ago. If a dependency updated or a config changed in between, the fix is syntactically valid but semantically wrong.
The latest model upgrade improved this specific failure mode. It re-reads the actual error trace instead of pattern-matching to a cached fix from earlier in the session. Three or four debugging passes compressed to one. That is basically your governance principle applied at the model level: re-evaluate at the execution boundary, not just at planning time.
The two-agent experiment against the same repo is the right test. The interesting edge case is when one agent gets the updated policy but the other has enough context to produce a valid-looking but unauthorized commit.
This is where the technical experiment starts becoming a strategic question: if governance consistently controls authorization at the execution boundary, what does that justify NAEOS owning as its foundational layer?
Spot on with validating right at the side-effect boundary. On top of checking policy versions, I’d also re-check structural file/repo state at that same moment. If a concurrent merge modified the codebase, executing that stale plan risks code corruption alongside policy violations.
Are you feeding policy rejections back into the context window for live re-planning, or hard-killing the execution?
I’d re-check authorization freshness at the exact moment the side effect is about to happen, not just when the plan is created. The execution request should probably carry the policy/version and relevant state it was evaluated against, then the runtime should revalidate that before granting the capability.
I’d also test the race condition explicitly: agent A gets approval → policy changes → agent A tries to execute the old plan. If that old decision can still produce a side effect, that’s probably the boundary worth investigating.