AI coding agents can write code, modify files, and report that a task is complete.
But a successful-looking response doesn't necessarily answer some important questions:
- Was the agent working on the correct source?
- Was the change within the approved scope?
- Is the reported result supported by actual evidence?
- Who decides whether the work is accepted?
These questions led me to build IntentChord.
What is IntentChord?
IntentChord is a local-first, human-governed development workflow that connects an owner's intent to workspace context, confirmed scope, agent-specific execution contracts, evidence-based review, and a final human decision.
Its central principle is simple:
An AI agent's report is not the same as verified execution evidence, and an agent's claim of success is not the owner's approval.
What's in the project?
The repository includes:
- Task and scope authority management
- Workspace discovery, indexing, and source-context foundations
- Governed execution contracts for Codex, Claude Code, and Gemini CLI
- Execution evidence and report-verification logic
- Human review and decision workflows
- A Next.js, React, TypeScript, and PostgreSQL-based application
The project is still evolving and is not presented as a production-certified system.
I'm opening the project to contributors
I've made the source public because I'd like to develop IntentChord with other developers.
I'm particularly interested in contributions involving code quality, testing, developer onboarding, architecture discussions, and improvements to the human-in-the-loop workflow.
There are already beginner-friendly and documentation tasks available in GitHub Issues.
Repository: https://github.com/hesham-m/IntentChord
Contribution opportunities: https://github.com/hesham-m/IntentChord/issues
The project is source-available under PolyForm Noncommercial 1.0.0, rather than an OSI-approved open-source license. Please review the repository's license and contribution guidelines before contributing.
I'd be interested to hear how other developers handle agent authority, scope changes, and evidence verification in their AI-assisted development workflows.
What would you improve or challenge in this approach?
Top comments (14)
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.
Dependency-aware revalidation sounds like the right direction, and the test I'd start with is intersection: a check carries over only if none of its inputs — files, tool permissions, environment — intersect the expanded scope, verified by hash rather than by name. The indirect part is the hard bit, because a check can depend on something it never named, so provenance has to be captured at run time, not reconstructed afterwards. I'd start narrow: deterministic, pure checks first, where re-running is cheap to verify, and keep stateful or side-effecting checks on full revalidation until that provenance is trustworthy. Does the lineage already record enough to compute that intersection, or would that be the new piece to build?
That's an excellent distinction, and I particularly like your suggestion to start with deterministic, pure checks rather than trying to solve every kind of validation at once.
To answer your question directly: the lineage doesn't yet capture enough to safely compute that intersection. That would be the new piece to build.
IntentChord already preserves parent/child run relationships, contract revisions, trusted validation evidence, source content hashes, and tool authorization traces.
But those records don't currently form a complete, runtime-captured dependency footprint for each individual check — covering its actual file inputs, relevant permissions, execution environment, and indirect dependencies.
So today, correction inheritance remains conservative: eligible checks can be inherited under the exact same execution authority, but an authority-changing rebase requires fresh trusted evidence.
I think your approach provides a sensible path forward.
One important distinction I'd preserve is that matching hashes prove the identity of observed inputs, not that every relevant dependency was actually observed. If dependency coverage is incomplete or uncertain, the system should fall back to revalidation.
Starting with deterministic checks, capturing their dependencies during execution, and keeping stateful or side-effecting checks on full revalidation sounds like a strong way to explore this without weakening the trust boundary.
This is exactly the kind of technical input I hoped opening IntentChord to contributors would encourage.
I'd genuinely be interested in how you'd approach capturing that runtime dependency footprint across different agent execution environments.
The hash-versus-coverage distinction is the key one — matching hashes prove the inputs you saw didn't change, not that you saw all of them. That pushes capture down to the runner rather than the agent's own report: if the footprint is recorded by whatever actually executes the check — file opens, tool calls, env reads — an unobserved dependency is a gap in the tracer, not a claim the agent forgot to make. Is there a portable layer for that across environments, or does each runner need its own tracer before the footprint is trustworthy?
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.