Version and trust in a2
We checked a plan yesterday. Today we will run it again.
The files may have changed; that is why we are running it again. But what if the code the plan calls has changed too?
The skill’s name can remain the same. Its description can look unchanged. Yet the operation about to execute may no longer be the one we inspected yesterday.
A separate check in a2’s presentation package addresses this situation.
Knowing the version as well as the name
The demo plans carry the identity and code hash of the skill to be used. This makes the implementation on which the plan was prepared visible.
The same skill versions are reused on day one and day two. A separate check then attempts to run the old plan against changed skill state.
The package records this stopping reason:
skill_snapshot_changed
The completed-step list is empty. No plan step executed and no model call was made during this check.
What interests me is that the change becomes visible before execution starts rather than being discovered midway through the work.
Changed code does not mean wrong code
The new version may genuinely be better. It may fix a bug or handle a previously unsupported case.
Even so, I do not want to transfer the old plan’s approval to new code automatically.
The earlier review concerned a particular implementation. When it changes, we need to reconsider which behaviours are preserved. Moving to the new version should itself be a recorded decision.
In the earlier Evidrel essay, we considered a similar question through changes in sources: how should earlier acceptance be handled when its grounds change?
In a2, one concrete response is the version link between the plan and the skill it will execute.
What a code hash does not tell us
Matching the expected code version does not prove the code is correct. The same faulty code can be run again in the same way.
The question this check answers is narrower:
Is the implementation we are about to execute the one on which the plan relies?
Determining whether the result is correct still requires task rules and an independent expected output. A code hash does not replace those checks.
That is why two separate records in the demo matter: comparison with the expected result and refusal to execute after a version change. One checks output; the other checks the implementation underlying execution.
A condition for rerunning
Making recurring work easier carries a risk of making intervening changes invisible.
The plan’s version link limits that risk at a particular point. It adds a condition about which code will execute to the request to “run the same task again”.
This is one behaviour I value in the first technical preview: alongside a plan that can run, a plan that can explain why it will not run when its grounds change.
Source note — 18 October 2026: This text draws on the 0.1.0a1 release documents and existing demo records. Demo data is synthetic and skills are human-written. No new demo, model call or evaluation was run for this essay.
Source code · Release and downloads · Demo guide · Download HTML report · Download demo evidence · GitHub CI
Connections: a2 · The same task, a different file tomorrow · When should an agent stop? · When should we stop using a result? · a2’s first technical preview
This connects to
Examines a2’s 0.1.0a1 technical preview and the limited evidence in its release package.
Moves from the two-day demo to the separate refusal check after skill state changes.
Makes the stopping question concrete through checking the skill version expected by a plan.
Connects source changes in Evidrel with changes to code underlying an a2 plan, keeping the mechanisms distinct.