Prompt engineering, then context engineering, then loop engineering. Each shift fixed something real. Better prompts, richer context, agents that plan and correct themselves. None of it answered the question that actually matters, how do you know an agent did what it was asked to do?
Most systems answer that informally. The model looks at its own output, decides it looks done, and exits the loop. A test runs, a tool call succeeds, a file changes, and the connection between the original goal and the proof that it got met stays implicit until someone reconstructs it later. Orchestration wrapped around probabilistic guesses isn't an execution model. What's missing isn't another prompting technique. It's a proof model.
An Intent Is More Than a Prompt
Engineers think in solutions. That's what ends up in a prompt, and it's all the LLM ever sees, one proposed fix with no view into why it's needed or what it's not allowed to break.
At Atomic, we start earlier. We search the Vault for previous related work before ever proposing a change, then convert that proposed solution into a structured problem statement we call an Intent. It captures why the change should exist, the outcome someone wants, the criteria that outcome has to meet, the boundaries of the work, and the ordered tasks required to get there. Tasks depend on each other, and each one ties to the specific criteria it's supposed to satisfy. Tasks, acceptance criteria, change records, Intents, Memories, Turns, and Sessions are all semantically linked using W3C ontologies, and the Vault is where that linked structure lives.
A prompt is text. An Intent is a searchable record of change, one an LLM can validate against using skills instead of guessing. Run an atomic query against the first-class elements in the Vault, and it returns the linked elements in the semantic change graph, so the system can tell you which tasks are ready, which are blocked, which criteria are still unsatisfied, and what evidence still has to exist before the Intent counts as done.
Loop Engineering Needs a Definition of Done
A loop is only as good as its stopping condition. Without an external definition of success, the agent ends up deciding whether its own answer is good enough: the code compiles, a tool returned success, a self-check says it's fine. None of that proves the objective got met.
An Intent graph changes what the loop is doing. The agent iterates against explicit proof obligations instead of its own judgment, tracing back through the Vault to the TODO, the acceptance criterion, and the problem statement each one has to satisfy. SHACL keeps that structure honest: an Intent needs acceptance criteria, a task needs to reference the criterion it addresses, and anything malformed gets rejected before it becomes trusted context for the next step. A task can't advance until its dependencies clear and its evidence checks out. A change that violates something ruled out of scope hasn't succeeded, even with every test green.
The loop stops being open-ended and converges on a state defined in advance. The model underneath stays probabilistic. The conditions governing completion don't have to be.
Provenance Is Not Logging
Most systems treat agent activity as logs: a stream you dig through later if something breaks. Logs explain what happened. They don't explain why an action was supposed to serve the objective.
Atomic represents every session, every turn, every tool call, and every resulting change as structured provenance, built on W3C PROV, connected directly to the Intent, the task, the criteria, and the evidence produced. That gives you a chain you can walk in either direction. From an Intent, you can see every task it spawned and every change that came out the other end. From a change, you can walk backward and ask why it exists, who authored it, and what evidence justified including it.
That's the difference between reconstructing intent after a session closes and having it already there. Our competitors log intent as a transcript on a checkpoint branch, so by the time you go looking, you're doing archaeology on a session that already ended. A graph built this way gives you the answer before the question comes up, which is the whole point of refusing to leave the why unrecorded.
From Execution to Proof
There's a rough analogy to mathematical proofs. The Intent is the proposition. Tasks are intermediate obligations. Dependencies set the order they resolve in. Acceptance criteria define what has to be demonstrated. Provenance records the steps, and evidence backs the claim that each obligation got satisfied. When all of that closes out, the Intent hasn't just been declared finished by whoever's watching. It's been demonstrated, and the graph is what lets you check that instead of taking someone's word for it.
That's the gap between a harness and an execution system. A harness helps a model use tools and repeat actions. It doesn't establish correctness. A proof-oriented system defines the work, constrains how it proceeds, records the provenance, and checks the outcome against an explicit model of success. Making probabilistic models deterministic was never the goal, that's a category error. The goal is building deterministic systems around probabilistic models, since agents will keep generating uncertain output and needing correction, and good infrastructure assumes that instead of hiding from it.
Software delivery shouldn't run on an agent saying "I think I'm done." It should run on whether the system can prove the work satisfies the Intent.
Common questions
How do you know an AI coding agent actually did what it was asked?
Most systems let the model decide its output looks done and exit the loop. Atomic uses a proof model instead: work is captured as an Intent with acceptance criteria and ordered tasks, execution is recorded as W3C PROV provenance linked to that Intent, and completion is demonstrated in a graph you can check rather than asserted by the agent.
What is an Intent in Atomic, and how is it different from a prompt?
A prompt is text describing a proposed solution. An Intent is a structured, searchable record of change: why it should exist, the outcome wanted, the acceptance criteria that outcome must meet, the scope boundaries, and the ordered tasks, all semantically linked with W3C ontologies so an agent can validate against it instead of guessing.
How does Atomic give an agent loop a real definition of done?
The agent iterates against explicit proof obligations traced through the Vault to each acceptance criterion and problem statement. SHACL enforces the structure, a task cannot advance until its dependencies clear and its evidence checks out, and a change that violates an out-of-scope rule has not succeeded even with every test green.
How is provenance different from logging?
Logs explain what happened; they do not explain why an action served the objective. Atomic represents every session, turn, tool call, and change as structured W3C PROV provenance connected to the Intent, task, criteria, and evidence, so you can walk from a change back to why it exists instead of reconstructing intent from a transcript after the fact.
Build on a foundation that remembers.
Install the CLI and start recording from the next agent turn. No account required.