AI coding agents can write code, modify files, and report that a task is complete.
But a successful-looking response doesn't necessarily answer so...
For further actions, you may consider blocking this person and/or reporting abuse
The central principle is the part most agent tooling skips — a successful-looking response answers none of the four questions you list, especially whether the change stayed in approved scope. Execution contracts plus evidence-based review is a stronger shape than another approval popup, because the human judges evidence, not prose. How do you handle scope drift mid-task — does the contract freeze, or can the agent renegotiate scope with evidence attached?
Great question — and this is an important distinction in IntentChord.
Scope Confirmation is a hard authority freeze, not a flexible instruction the agent can rewrite mid-task.
If an agent discovers that it needs a file or action outside the confirmed scope, it must stop and explain:
But that evidence does not grant permission.
The agent cannot inspect or modify the additional files until the owner explicitly authorizes a new scope.
IntentChord preserves the original confirmed scope and run history rather than silently modifying their authority. Any approved change requires an explicit rebase and scope re-confirmation through the backend. An active run cannot simply renegotiate its own permissions.
The backend also checks current source authority against the frozen context before allowing new execution. Source drift requires re-confirmation rather than implicit acceptance.
So the distinction is: the agent can propose a scope change with evidence, but only the human can authorize it — through a new confirmed authority boundary.
That's a central part of why we separate agent intent, execution authority, evidence, and the final owner decision.
The hard-freeze answer is cleaner than I expected — the agent can propose with evidence but can't spend it, and the backend re-check against the frozen context closes the drift loophole I was worried about. The part I'd still probe is the stop itself: when the agent halts mid-task to ask, does the run resume cleanly after re-confirmation, or does the rebase cost it the work it already did?
That's a very fair question — and there's a deliberate trade-off here.
IntentChord preserves the previous run, its evidence, findings, and decision history. A scope rebase doesn't erase that history or automatically roll back existing workspace changes.
However, it does not silently resume the old run under expanded permissions.
Once the owner resolves the stopped run and explicitly re-confirms the new scope, execution continues through a new, lineage-linked run using the newly approved contract.
There is an important distinction in what carries forward:
So the work isn't simply forgotten, but neither do we claim seamless restoration of an agent's live session or zero-cost continuation.
That distinction is intentional: preserving progress and preserving authorization are different problems. We're particularly interested in improving the continuation experience without weakening the evidence and authority boundaries.
The lineage-linked run is the right compromise — progress survives, but authorization doesn't get smuggled across the rebase, and re-establishing trusted evidence under the new contract is the price of that honesty. The cost question is where it bites in practice: does the new run re-verify everything, or only the checks that depend on the expanded authority? If it's the latter, the rebase stays cheap; if it's everything, a late scope change gets expensive fast.
You're absolutely right — and I think you've identified a genuinely valuable improvement opportunity.
To answer directly: today, IntentChord does not perform selective revalidation across an authority-changing rebase. Previously trusted checks remain preserved as historical evidence, but the new run must establish fresh trusted evidence under the new contract.
That doesn't necessarily mean redoing all the implementation work. The distinction is between preserving completed work and proving that its validation is still applicable.
You're right that this can become expensive, especially when a late scope expansion affects only a small part of the task.
The encouraging part is that IntentChord already has some foundations we could build on:
What's missing is a reliable way to establish which checks are genuinely unaffected by an authority change — including their source dependencies, execution context, and indirect dependencies.
That makes dependency-aware revalidation a particularly interesting direction: preserve the authority boundary, but avoid repeating validation when its continued validity can be independently demonstrated.
I made IntentChord available for contributions precisely because discussions like this can reveal ways to improve the system without compromising its principles.
I'd be interested in your take: how would you approach proving that a check remains valid across a scope expansion, particularly when indirect dependencies are involved?
Thanks for raising this. It's exactly the kind of practical engineering question worth exploring.
Where does "evidence" come from in practice: does IntentChord collect it itself (diff, test run, exit codes), or does it verify what the agent's report points to? If the agent writes the evidence, a confident wrong report can still pass.
One thing that helped us: treat a scope change as a hard stop, not a note in the report. The agent pauses and asks before touching anything outside the confirmed files.
(From the Auten team, we build tooling for AI agents.)
Thanks for raising this — you've identified exactly the trust boundary we're trying to enforce.
On evidence: IntentChord does not treat the agent's report as independent proof, and self-reported test results or exit codes cannot produce a PASS on their own.
There are multiple layers:
VIOLATION, with the offending paths identified.One distinction worth making: we don't claim universal real-time interception of every filesystem write across all agent runtimes. Source observations and trusted execution evidence are separate from the agent's narrative.
On scope changes: We agree completely. Our execution contracts require the agent to stop before inspecting or modifying anything outside the approved boundary and request explicit owner authorization. The backend also freezes scope authority and rejects stale source/context authority until the owner explicitly re-confirms it.
So an out-of-scope change isn't something we simply document and accept afterward.
I'd be interested to compare approaches with Auten, particularly around capturing independently trusted file mutations across different agent runtimes.
Thanks, that answers it. Hashing the referenced files yourself and refusing a PASS on self-reported results is the right line.
Honest answer on the comparison: Auten doesn't capture file mutations at all. It's a different layer: it drives the screen (clicks, typing, reading) for the agent, so our trust boundary sits on screen actions, not files. Our safety skill tells the agent to ask before buy, delete, send or permission changes, and saved passwords are typed locally so the model never sees them.
One question back: when an agent edits through a GUI app instead of the shell (say a settings screen that writes a config file), does the Workspace Index still catch that as a source observation, or only changes made by the agent's own tools?
That's an interesting distinction between the two approaches. Thanks for explaining Auten's trust boundary.
Yes — IntentChord's Workspace Index is independent of how a file was modified.
It observes the actual filesystem state within the registered Workspace, rather than relying on the agent's tool calls or reported changes.
For example, if an agent uses a GUI application to change a setting, and that application writes a configuration file inside the indexed Workspace, a subsequent source observation can detect the file change through its content identity and the delta between Workspace revisions.
The same principle applies whether the change came from a shell command, an IDE, a GUI application, or another process.
There are two important boundaries:
We also keep source observations separate from the agent's execution report and from the final evidence-based verdict.
So the filesystem observation isn't dependent on the agent telling us which files it changed.
Your GUI example is a good illustration of why we wanted source truth to remain independent of the execution channel.
The scope freeze is the part that stands out to me. An agent proposing an expansion with evidence, while only a human can authorize it, keeps the boundary clear.