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.
Build on a foundation that remembers.
Install the CLI and start recording from the next agent turn. No account required.