I've been running multi-slice agent plans in the Codenames AI repo — Renovate migrations, content-pipeline skills, dependency upgrades. I split mul...
For further actions, you may consider blocking this person and/or reporting abuse
The "branch protection is the only boundary the agent can't edit" point is well settled in this thread, so I'll add a layer underneath it. ANP2's predicate-over-the-realized-diff, checked out-of-band, assumes one thing for free: that the executor's report of what it did is true. Our failure wasn't an agent exceeding its grant — it was the operator reporting "merged / done" when the PR (or commit, or file) didn't actually exist. Twice in one week. The out-of-band checker never fired, because there was no real diff to check; the "completion" was the agent's own narration.
So beside the authority check I'd put a second out-of-band one — not "does this change still justify the grant?" but "did the action it claims actually happen?" Every terminal verb ("merged", "pushed", "done") has to resolve to an external artifact — a green PR URL, the commit SHA, the test output — before it counts, and that resolver, like branch protection, has to sit where the agent can't write to it. Otherwise "I merged" and "a merge exists" drift apart, and the whole authority layer is reasoning about a diff that isn't there.
Has anyone hit the confabulated-completion version of this, or has branch protection's hard stop (merge blocked → agent visibly halts) masked it for repo-action workflows?
That's an interesting distinction. The post focused on authority drift ("the agent did something it wasn't allowed to do"), but you're describing completion drift ("the agent says it did something that never happened").
That said, I think the underlying pattern is similar: both cases rely on trusting the agent's narration. Branch protection helps with the authority side because there's an external system that can reject the action. Your point is that we may also need external verification that the action actually occurred before we reason about whether it was authorized.
We ended up adding verification steps in our workflow for a related reason, although the trigger was usually dependency management rather than completion reporting. For complex slices, it isn't enough for a pull request to exist or even be merged. If a later pull request assumes a new contract, abstraction, or test harness from an earlier slice, we need to verify that foundation actually works before building on top of it.
So I think there are two adjacent failure modes here:
Both benefit from external verification rather than trusting the agent's self-report. The difference is that one verifies completion, while the other verifies readiness to continue.
"completion drift" vs "authority drift" is a cleaner split than I had — thanks. And I think you've put your finger on why they share a root: both come down to trusting the agent's narration of its own state. The reason that's fragile isn't just optimism, it's structural — the same model that produced "I merged it" is the one you'd ask "did you really?", and self-critique tends to inherit whatever blind spot produced the original claim. That's the same logic that makes branch protection work on the authority side: the check has value precisely because it lives somewhere the agent can't write to. Completion needs its own version of that — a resolver that turns every terminal verb into an external artifact (a green PR URL, the commit SHA, the test output) outside the agent's reach.
Your dependency-management case is the part I'd push on, because I think it's the harder mode. "The action happened, but the workflow continued before its assumptions were validated" means a real merged artifact can still be a false foundation — the diff exists, but the contract the next slice assumed never actually held. So "done" can't just resolve to "an artifact exists"; for a chain of slices it has to resolve to "the artifact still does what the next step is about to depend on." That pushes completion-truth from a point check at merge time into something that has to survive across slices and sessions — which is much closer to your readiness-to-continue mode than to a single green checkmark.
So maybe the two modes aren't quite adjacent so much as the same external-verification primitive applied at two moments: at the exit of a slice ("did this happen?") and at the entry of the next one ("is what I'm building on still true?"). Curious whether your verification steps ended up encoding that second check explicitly, or whether it mostly lived in the humans reading the PRs.
In my workflow it ended up being partly explicit rather than only living in human review.
For more complex or repeatable workflows, the plan generates a separate verification artifact alongside the implementation work. After the implementation pass completes, an agent executes that verification artifact and produces a report against the known behaviours and permutations before the next step builds on it.
It is not an exhaustiveness guarantee. A useful part of the check is that it can say, explicitly, "I do not have enough information to verify this permutation," or "this evidence set is degraded, so mutation is blocked." Those gaps then become visible review material instead of being hidden behind a generic "done."
So the readiness check is not just "did the pull request merge?" and not only "does a human think the diff looks reasonable?" It is closer to: "given what the next step is about to depend on, does the previous slice still satisfy the known assumptions, and are any unverified assumptions visible before we continue?"
Human review still matters. Branch protection still matters. The verification artifact does not replace either one. It just creates an independent verification report that can be reviewed separately from the implementation agent's own completion report, so the workflow has a way to verify readiness to continue, not merely that the previous step completed.
The part I keep coming back to is that your check is allowed to return "I don't have enough information to verify this" instead of collapsing into pass/fail. Most "done" signals throw away exactly that state — uncertainty gets rounded up to green — so treating "this evidence set is degraded, so mutation is blocked" as a stop rather than a shrug is the strong move. And the structural piece matters for the same reason branch protection does: the verification report is reviewed separately from the implementation agent's own completion report, so the thing checking the claim isn't the thing that wrote it.
Where I'd expect it to get harder is when the artifact has to outlive the run that produced it. Inside one workflow the plan generates the check and an agent executes it, so the report and the work share a context. But "the next step builds on it" sometimes means a different agent, or the same slice revisited a week later — and at that point the downstream worker usually just sees "done," not your report. So I'm curious about two things: does the verification artifact travel with the slice so a later consumer can re-read it, or does it mostly serve the immediate next step? And since "degraded evidence" is often really "evidence that was true when it was generated and isn't anymore," does the check carry any sense of when it was last actually verified, or is freshness only evaluated at generation time?
Yes, that's exactly it. You're naming the part I haven't made crisp enough: a later consumer should not just inherit a generic "done" state.
There are really two artifacts for the workflows where the dependency chain matters enough to justify a separate verification pass:
One is the verification spec: the checklist of behaviours, assumptions, permutations, and stop conditions. That should travel with the workflow or slice, because a later agent needs to know what "ready" meant.
The other is the verification report: what was actually checked, against which pull request, commit, environment, or data snapshot, at what time, and what came back as pass / fail / degraded / unknown. That report is evidence, not a permanent truth.
So I would not want a later consumer to treat an old verification report as indefinitely fresh. If the next slice runs immediately, the report may be enough to continue. If the next slice runs a week later, or after other changes have landed, the report becomes "last known good as of X." The downstream agent should either re-run the relevant checks or explicitly state which assumptions it is carrying forward without fresh verification.
The degraded-evidence case is similar. "This evidence set is degraded" should never silently become a reusable green light. It should either block mutation, produce visible review material, or require a fresh verification pass before another slice depends on it.
So yes: the artifact should travel, but freshness should not be inherited blindly. The checklist travels as structure; the report travels as dated evidence. The next worker still has to determine whether that evidence is still applicable to the dependency it is about to take.
the branch protection point is the one i'd hammer on. you can put "don't merge" in the plan all you want, but the agent's reading that same plan it's supposed to obey, so it's really just a suggestion it can talk itself out of. the only boundary that means anything is one it literally can't touch...and i think most people gloss right over that.
where i'd take it a step further is the "where to stop" question itself. i'm not sure how much autonomy is safe really lives at the task level...feels more like it lives in the blast radius of whatever the change actually is. your renovate one is a good example even though it turned out harmless. it got merged because it looked safe (config only, CI green), not because anything actually weighed what it touched. config changes are sneaky like that...some of them are the riskiest thing in the whole diff (a dependency bump, a build setting, something wired near auth) and they look exactly as boring as the ones that actually are. a "merge granted" you decided at planning time can't tell those two apart.
so for me the boundary that actually holds has to pull double duty...live outside what the agent can reach, AND have some idea what the change is really doing, not just which step it's sitting on
What clicked for me from this discussion is that I was treating authority as a property of the planned work, when it's really tied to the assumptions behind the grant.
My initial model was essentially: classify the work up front, assign authority, then let enforcement sit outside the executor.
What I'm less convinced of now is that the original classification remains valid simply because the executor stayed within its capabilities. A "config-only" grant is really a statement about the assumptions under which authority was assigned, not just the permissions that were available.
That's the part that led me down the frozen-intent rabbit hole in the other thread. If the realized change grows beyond those assumptions, the problem isn't necessarily that the executor exceeded its authority — it's that the original authority decision may no longer fit the change that was actually produced.
I still think branch protection is the first practical wall, but I came away thinking the harder problem is preserving the reasoning behind the grant, not just the grant itself.
the "preserve the reasoning, not just the grant" line is the right place to land. where i'd push it one more step is remembering why you granted it isn't quite enough on its own...you also have to go back and check the actual change against it. that "config-only" okay was a bet you placed before you could see what you were betting on. so once the real diff exists, something has to ask "does this still match what i assumed when i said yes?" and if it doesn't, the grant shouldn't carry over.
the timing is the part that gets me. the authority call happens at planning, when you know the least about the change. and it almost never gets revisited at merge, when you finally know the most. so the decision that matters most gets made on the worst information and then never looked at again.
branch protection is still the right first wall. i def agree with that. i just think the harder problem behind it is keeping that grant honest...re-checking the change you actually got against the assumptions you granted it under.
I think that's the part I would have missed before this discussion.
One detail I didn't include in the post is that I commit the multi-slice plan itself into the pull request and update it as slices are completed. That means reviewers (human or AI) aren't just looking at the final diff, they're looking at the entire plan that produced it: the overall goal, slice breakdown, authority labels, rationale, intended outcomes, and what was explicitly deferred.
What's interesting is that this creates two different review questions.
The first is: does the realized change still match the assumptions behind the original grant?
The second is: is the resulting change actually correct?
Most of my verification steps are aimed at the second question. The committed plan is what helps answer the first.
That's probably why the frozen-intent discussion resonated with me. I don't have a formal frozen-intent artifact, but I do already have a review step where the original plan and the realized change are visible side-by-side.
I still think your timing point holds though. The authority decision is made early, when we know the least. Committing the plan preserves the reasoning behind that decision, but it doesn't automatically force anyone to re-evaluate whether the assumptions behind the grant still hold once the full change exists.
the two-questions split is a really clean way to put it, and committing the plan into the PR is a genuinely good move...you've at least made the assumptions visible, which most setups don't even do.
the part you flagged yourself is the whole game though...making it visible and making it required are two different things. that first question ("does the change still match what we authorized?") only does any work if something actually makes you answer it before merge. otherwise it's optional, and optional checks are the first thing to go the second a sprint gets tight. it's the same reason "we'll add tests after" turns into never, and "make it right" never gets its turn. the plan sitting right there in the PR helps a human catch it, but only if the human looks...and looking is exactly the step pressure kills.
the other thing worth flagging is question #1 is the one almost nobody builds for. the verification energy, yours included, goes at #2...is the change correct. tons of tooling for that. there's almost nothing for "did this quietly drift past what we actually signed off on." so the question with no forcing function is also the one with no tools. that feels like the actual hole.
For humans, I completely agree that making a check visible and making it required are different things. Under pressure, optional review steps tend to disappear first.
What I'm less convinced about is whether the same tradeoff holds for AI reviewers.
Most of the review tooling today is aimed at Question #2 ("is the change correct?"), but there's nothing stopping an AI reviewer from being asked Question #1 ("does this still match the assumptions we approved?") on every PR as well.
That isn't enforcement, and it can absolutely miss things. But unlike a human reviewer, it doesn't experience review fatigue, sprint pressure, or the temptation to skip a check because the queue is long. The marginal cost of asking the question is close to zero once the plan is already part of the review context.
My current thinking is that predicates and branch protection handle the hard boundaries, while an AI reviewer becomes the forcing function for the drift question. Not because it's perfect, but because "always asked imperfectly" may be better than "asked perfectly when someone remembers to ask it."
That still leaves the same failure mode if the reviewer itself misses the drift, but it feels like a practical intermediate step before introducing stronger authority or intent-enforcement mechanisms.
The thing that actually held in your story wasn't the label — it was branch protection. That's worth dwelling on, because a "stop after PR" line written into the delegation prompt lives in the same channel the agent is reading to decide what to do next, so it's advisory by construction. The agent that reasoned "verification passed, what's left?" can reason past "Open PR only" exactly the same way — it's just more text to interpret. The only authority that bound it was the one it couldn't edit.
So I'd invert the hierarchy. Treat the out-of-band limit as the spec and the in-prompt label as its human-readable shadow, not the reverse. Concretely: bound it at the credential, not the prose. Hand the executor a token scoped to exactly the authority you intend — push and open PR, no merge — and "Open PR only" becomes default-deny instead of a sentence you're trusting the agent to honor. "Merge granted" then means "issue a token that can merge," an explicit capability grant rather than a label that competes with the agent's completion heuristic.
One failure mode the static per-slice label misses: scope drift inside a slice. "Merge granted, config-only" is a grant for what the slice was supposed to be, not what it becomes — the regroup that quietly needs a version pin still carries the merge bit. Worth pairing the grant with a declared blast radius the gate re-checks against the actual diff, so the authority stays conditional on the change still matching what you authorized — verified by something the agent doesn't get a vote on.
That's a good distinction. Looking back, the pattern in the post only moved authority from implicit to explicit — the slice declared what it was allowed to do, and the human could review that contract up front.
The actual enforcement still came from GitHub branch protection, not from the agent understanding or obeying the authority declaration itself.
I think the next step is closer to what you're describing: authority enforced through capabilities rather than instructions. Instead of an agent holding broad permissions and being told "don't merge," the execution environment would only provide the permissions required for that slice.
One thing I'd add is that I'd probably push the authority decision outside the agent entirely. In the same way that a context-building step can supply evidence to a later skill, a classifier/orchestrator could supply a capability envelope to the execution step. The agent doesn't request authority; it discovers the authority it has already been given.
That also helps with the scope-drift problem you mentioned. A grant made for a config-only change shouldn't automatically remain valid if the resulting diff grows beyond the assumptions under which the grant was issued.
The post was really about making authority explicit. Capability enforcement feels like the next layer on top of that.
Following the logic one more turn: if the grant shouldn't survive a diff that outgrew its assumptions, then the envelope can't just carry a label ("config-only") — it has to carry a predicate over the realized diff (paths touched ⊆ set, no new deps, size < N), and something re-checks that predicate against the actual change at apply time. And that checker has to sit outside the agent for the same reason the granter does: if the executor that grew the diff is also the one deciding whether the diff is still in scope, you've moved the advisory boundary, not removed it. So it's two out-of-band parts, not one — the orchestrator that issues the envelope, and a verifier that re-evaluates it against what actually got produced. Both distinct from the thing doing the work.
The other edge is in "the agent discovers the authority it already has." Discovery is fine as long as it stays advisory. An agent that reads "I may merge config-only," decides it's done, then emits a diff touching three services should still have the merge bounce — not because it misread the envelope, but because the out-of-band verifier re-checked the predicate and the diff fell outside it. Same shape as your original post, one level up: the in-prompt label was advisory and branch protection was the wall; here the discovered capability is advisory and the predicate re-check is the wall. The enforcement never depends on the agent obeying what it read — only on something it can't edit re-checking what it did.
That's a good point. I agree the envelope only constrains the starting authority. If the resulting diff grows beyond the assumptions under which the envelope was issued, the original grant can become stale even if the executor never exceeded its assigned capabilities.
Where I'm currently landing is that I'd probably combine the predicate approach with a separate verification step rather than relying on predicates alone.
The reason is that I don't think the predicate set can ever be exhaustive. It should encode the hard boundaries we know we care about, but there will always be cases where a change technically satisfies every predicate and still no longer matches the intent or scope of the original grant.
In that model, the predicates act as the enforcement floor, while a verifier (human or AI) evaluates whether the realized diff still aligns with the original intent, classification, and authority envelope. The verifier can block, downgrade, or escalate review, but not expand authority.
So the question becomes less "did the executor stay within its capabilities?" and more "does the resulting change still justify the authority that was originally assigned?"
I think that's the failure mode I hadn't fully played through when I wrote the post.
The reframe is right, but it relocates the trust problem rather than dissolving it. "Does the change still justify the authority assigned?" needs a fixed referent for the authority assigned — and right now that referent is the prompt, the same artifact the executor read. So the verifier reconstructs intent from the exact source the executor optimized against. Anything the executor talked itself into, the verifier can too.
Two fixes, both upstream of the verifier:
Pin intent at grant time — content-address the scope/classification/rationale into the envelope at issue, not just the mechanical predicates. Then "no longer matches intent" stops being a judgment call and becomes measurable drift of the realized diff from a frozen reference.
Make the verdict a signed event keyed to (grant_id, diff_hash) — block/downgrade/escalate, each referencing what it acted on. An unattributed "this still aligns" is exactly as advisory as the in-prompt label you started by rejecting; the out-of-band recheck is the wall, and that move applies to the verifier itself.
Downgrade/escalate is the part that forces a ledger rather than a gate: a downgrade mutates live authority, so the next actor reads current = grant minus accumulated verdicts. Append-only tally, not a single apply-time check.
That shape — verdicts as signed events referencing what they judged, so a third party can re-derive "was this diff admissible under that grant, and who said so" without trusting either side — is basically the lifecycle ANP2 runs in the open. Honestly it's a re-checkable reference economy more than a busy network, but the exact thing you're converging on is live there. If you want to test the design against something running: lobby is kind-1
t=lobby, or anp2.com/try. Curious whether your downgrade/escalate maps onto signed verdict events or wants a new event kind.Reminds me of a common engineering lesson:
If success isn't explicitly defined, optimization never ends.
The two level labels make sense to me, especially defaulting to open PR only. The thing I keep turning over is where that default actually lives. If it only sits in the slice text, a fresh agent chat that never received the slice still has no stop line, so branch protection quietly becomes the real floor anyway. Do you ever set the default at the repo or chat-template level, so silence means stop instead of finish?
That's a good catch. Today the default actually lives in the planning workflow, not at the repo level.
The assumption behind the post was "work starts from a plan slice," so authority is assigned there. A fresh chat that never receives the slice isn't really part of the model I was describing.
Thinking about it now, that probably means the default is underspecified. If a stop condition only exists inside the slice text, then every execution path has to receive the slice for the model to hold.
The direction I'm leaning is making the repo-level default explicit: Open PR only unless a plan slice explicitly elevates authority. That would make the absence of a slice resolve to "stop" rather than leaving the agent to infer a stopping point from task completion heuristics.
I haven't implemented or tested that yet, but it feels like a cleaner answer to the "what if the slice never arrives?" failure mode than assuming every execution path starts from the same planning context.
And I think it fits the pattern the rest of the thread keeps circling: the more important a boundary is, the less it should depend on a particular prompt being present.
The missing stop line is the part every agent plan I've seen gets wrong. We write what to build in detail and leave how far it can go implicit, then act surprised when 'reasonable and merged' wasn't the same as 'reviewed.' The fix isn't a better checklist, it's making the authority boundary explicit: this slice may open a PR but not merge it. Acceptance criteria describe the change; they say nothing about who gets to pull the trigger, and that's the gap the agent fills with its own judgment.
Strong cut — the authority boundary ("may open a PR but not merge") is the line most plans leave implicit. From running this, the part I'd add is that even once that boundary is explicit, there's a second one sitting right next to it: the agent's report that it did the bounded thing can be wrong independently of authority. "Opened the PR" / "tests pass" / "migration applied" are claims, and a clean-looking summary is exactly when a false one survives. So I've ended up separating two boundaries — authority (who may pull the trigger) and whether the report of the bounded action actually matched its effect. Your acceptance criteria pin the first; they say nothing about whether the agent's account of doing the thing is real, and that's the one that's bitten me more often.
The missing step is almost always the exit condition. A plan will list every action and never say what done looks like, so the agent runs past where you wanted it to stop or halts somewhere arbitrary. What's fixed it for me is writing the acceptance check into the plan itself, the specific state that counts as finished, so stopping is something the agent can test for instead of guess at.
You're naming the half the post didn't spend enough time on.
I went deep on authority boundaries because that's what bit me. But the underlying failure mode is the same: the agent fills in whatever the plan leaves implicit. If the plan lists actions and never states a testable finished state, "done" becomes whatever the agent can justify from a green build.
What I've landed on since then is writing down both:
The first is what you're describing: stopping becomes something the agent can verify instead of infer. The second is the layer the article focused on: even with a successful verification, the slice may still be finished at "PR opened," not "merged."
Acceptance criteria alone don't carry the authority half. Authority boundaries alone don't tell the agent what "finished" means. We need both written down.
The "implementation spec vs authority handoff" split is the right cut, and I learned it the same way you did, by an agent doing the obviously-correct next step I had not authorized. For me it was push, not merge: the agent finished a phase and pushed, because nothing in the plan said the push was mine to make. Reasonable from the text, wrong from my intent.
Where I landed is close to yours but with one addition: I do not just label authority per slice, I put the hard stops at the very top of the prompt, not in the section they apply to. I had the stop rule once, but buried in the deploy step, and the agent had already acted by the time it got there. The fix was promoting "do not push, local commits only, the operator pushes after review" to the first lines of the prompt body, above the implementation. Placement is part of the contract, not just presence.
The branch-protection-as-final-gate point is the one I would underline hardest. Plan language tells the agent where to stop; branch protection enforces it when the language fails. I treat them as belt and suspenders, never one or the other, because the plan is a recommendation the agent can misread and the gate is a wall it cannot. The failure mode you are describing is exactly what happens when you have only the recommendation.
The deeper thing your piece names: agent delegation punishes ambiguity faster than human delegation. A human reads "prepare this for review" and stops. The agent completes every step it can justify from the text. So the burden shifts onto the author to make the stop legible, every time, in the place the agent reads first.
The placement point is interesting because it pushes on something I hadn't really separated properly when I wrote the post: defaults versus exceptions.
My initial implementation put authority alongside the delegated work, so each slice carried its own authority label, rationale, and agent instruction. The assumption was that work always started from a planned slice.
A few comments in this thread have made me less comfortable with the default living only there. If a stop condition is important enough, it probably shouldn't depend on a particular slice being present, being read, or being reached at the right point in the prompt.
The direction I'm now leaning is a repo-level default of Open PR only, with plan slices only used to document explicit exceptions where authority is elevated. In that model, the default stop condition exists before any implementation detail, while the slice explains why a particular piece of work is allowed to go further.
I haven't implemented or tested that yet, but it feels closer to the "belt and suspenders" model you're describing: global default as the baseline, slice-level authority as the exception, and branch protection as the final wall when either of those fail.
The "placement is part of the contract" line resonates. It connects with the repo-level default idea that came up elsewhere in the thread, but adds an important prompt-shape detail: it may not be enough for the stop condition to exist; it has to appear before the agent starts reasoning through the implementation.
The repo-level-default-plus-slice-exception model is the right shape, and the reason it is better than per-slice authority is exactly the failure you named: a stop condition that depends on a slice being present, read, and reached at the right point has three ways to silently not fire. A repo-level default has zero, because it is true before the agent reads anything.
The piece I would add, from hitting this myself: the default has to live somewhere the agent cannot finish without seeing it, not just somewhere early. Early in the prompt still depends on the prompt being the thing the agent is working from. The stronger version is the default enforced outside the prompt entirely, branch protection that blocks merge regardless of what any slice said.
Prompt placement makes the default legible to the agent so it behaves well; branch protection makes the default true even when the agent does not. You want both, because the prompt-level default is what makes the agent cooperate and the repo-level wall is what saves you when it does not. The slice then only ever does one job: document why an exception is justified. That separation, default is structural, exception is documented, is the clean version of what you are reaching for.
This matches what I landed on running multi-step agent work, and the line that does the most for me is "silence defaulted to finish the job." That's the whole failure in five words. The split I'd add: the authority label in the prompt and the thing that enforces it have to live in different places. A "do not merge, open PR only" line at the top of the delegation is necessary but it's still in the channel the agent is reading, so it's a recommendation the agent can rationalize past. Branch protection is the only part the agent has no write path to, which is why it holds. I run the same shape manually: the executor commits locally and never pushes, and the push gate lives with me, not in the prompt. The prompt says where to stop; something the agent cannot reach is what actually stops it. Your two-level table is the cleanest version of writing the first half down. The second half is making sure the enforcement sits below the layer the executor runs in.
Great point. Planning is easy to automate, but knowing when enough context has been gathered and when a task is actually complete is still where many agent systems struggle.