An agent changes your code, and something validates that change before it lands. Six months later the code is still there and the reasoning that made it acceptable is gone. That's the expensive gap in agentic software development.
Last month, Prof. Frank Coyle of UC Berkeley gave a talk at the AI Engineer World's Fair called Why Agentic Systems Need Ontologies. More than 300,000 people have watched twenty-one minutes about ontologies since July, which tells you something about where this conversation is heading. If you haven't seen it, watch it before you read the rest of this.
His argument is straightforward, and I think he's right about all of it.
LLMs are probabilistic. Trying to prompt a probabilistic system into deterministic behavior isn't a control mechanism, it's a hope. So put the logic outside the model. Let it reason probabilistically, then validate what it proposes against a formal representation of the domain before anything consequential happens. Probabilistic reasoning inside, logical guardrails outside.
His refund example makes the distinction concrete. A schema can tell you that status is a string. An ontology can tell you that "probably shipped" isn't a thing that exists in your domain, that an order can only be refunded once, that a support rep and a customer are different kinds of entity. Structural correctness versus semantic correctness. Coyle's version of this is Pydantic at the door, ontology at the ledger.
Then there's the arithmetic he raised afterward, which I keep coming back to. Sequential reliabilities multiply, they don't average. Five agents chained at 99% accuracy each gets you 95% end to end. A hundred gets you 36.6%. Drop to 95% per step across a hundred steps and you succeed 0.59% of the time. No prompt fixes that.
Why aren't ontologies enough for AI code changes?
An ontology can validate a proposed code change, but validation alone does not preserve why that change was acceptable.
Consider what happens when the domain is software itself.
A coding agent isn't changing the state of an order. It's producing an artifact that gets deployed through several environments, depended on by later changes, audited by people who weren't in the room, and read by other agents as context for their own work. Every one of those readers receives the code. None of them receives the reasoning.
A bad refund is a bad transaction, and you reverse it. A bad change is something later changes build on top of. Coyle's chain math doesn't only describe the agent loop, it describes the codebase, and the errors land somewhere permanent.
How do you keep track of why an agent changed code?
Keep the validation, assumptions, and evidence connected to the change as durable, queryable records.
Here's the case that convinced me a guardrail alone isn't enough.
An agent modifies an authorization check. The ontology validates the proposal: the roles it references exist, the permission model it assumes is the one in force, the constraint about who can escalate is satisfied. The change is correct. It lands. Everyone moves on.
Eighteen months later the permission model changes. Now ask the question that actually matters: which changes already in the codebase were valid only under the old model?
That's answerable if the validation persisted alongside the change. It's unanswerable if the ontology was a gate the change passed through on its way to becoming a diff. You still have the code. You have no record of the reasoning that made the code acceptable, so you're back to reading diffs and guessing, which is exactly where we were before agents started producing changes faster than anyone can read them.
Coyle's ontology decides whether an agent's proposed action is consistent with the domain. Software change adds a second requirement. The reason the action was valid has to survive the action itself.
What does a durable AI-generated software change contain?
A durable change connects the patch to its intent, constraints, validation, verification, provenance, dependencies, and verifiable result.
Atomic started from source code management and a narrower question: what does a software change need to contain when the primary author is increasingly an agent? A patch by itself doesn't answer that. So the durable unit kept accumulating structure until it looked like this.
Intent. Acceptance criteria. Tasks and constraints. The agent session. Semantic validation. Verification. Provenance. The causal change. The Merkle state that makes the result independently verifiable.
Coyle arrived at ontologies by asking how to stop agents from doing the wrong thing. We arrived at them by asking what has to be recorded so anyone can later prove the right thing happened. Same foundation, opposite direction.
What do ontology, knowledge graph, SHACL, and provenance each do?
They define meaning, record relationships, validate required facts, explain how work happened, represent change dependencies, and make the resulting state verifiable.
These get collapsed into a single undifferentiated "AI graph" constantly, and the collapse is where systems go wrong. So, pedantically:
The ontology defines what things mean. Without it, an agent can produce a change that references a concept your domain doesn't have.
The knowledge graph records the relationships between them. Without it, you have entities and no way to traverse from a change to the intent that motivated it.
SHACL validates whether a particular graph satisfies required constraints. This is the one people fold into the ontology, and it's the fold that hurts. OWL operates under an open-world assumption, so the absence of a statement isn't evidence that it's false, which means OWL can't tell you something required is missing. SHACL closes the world for a specific shape and reports precisely that. You need both because they answer different questions. What can be inferred, versus what's actually here.
The provenance graph records how the work happened. Which agent, which session, which model, which human approved it, under what authority.
The causal change graph represents the transformation and its dependencies, so a change knows what it rests on and what rests on it.
Merkle state makes the result verifiable by someone who has no reason to trust you.
Related, and worth keeping apart.
Probabilistic
Agent
│
▼
PROPOSAL
│
┌─────┴─────┐
▼ ▼
Semantic Policy
Validation Validation
│ │
└─────┬─────┘
▼
Verification
│
▼
Causal Change
│
▼
Durable Graph
In prose: a probabilistic agent produces a proposal; semantic and policy validation constrain it; verification checks the result; and the accepted causal change, together with that evidence, becomes part of the durable graph. Coyle's argument establishes the validation boundary. Software change also has to preserve what happened below it.
What should happen after the ontology says yes?
The successful validation should become durable evidence explaining why the resulting software change was valid.
Putting logic outside the model is the right instinct, and I'd extend it in one direction.
Logic outside the model stops the agent from doing something incoherent. For software change, that logic can't evaporate the moment the model's action succeeds. The ontology shouldn't only guard the agent. It should become part of the durable evidence explaining why the resulting change was valid.
Probabilistic agents need deterministic boundaries. Durable software change needs proof that those boundaries held, preserved alongside the change itself.
A change isn't durable because its bytes survived. It's durable because its meaning survived with it.
Common questions
Why do AI coding agents need ontologies?
LLMs are probabilistic, so prompts alone cannot guarantee that a proposed action obeys domain rules. An ontology gives concepts and relationships formal meaning, allowing deterministic validation outside the model before a consequential action or code change is accepted.
Why isn't an ontology enough for AI code changes?
An ontology can determine whether a proposed change is consistent with the domain at validation time, but that decision can disappear after the change lands. Software needs the validation result and the assumptions that made the change acceptable to remain connected to the durable change.
How do you keep track of why an AI agent changed code?
Record the human intent, acceptance criteria, constraints, agent activity, semantic validation, verification evidence, provenance, causal dependencies, and resulting repository state as connected records alongside the change. That creates a traversable chain from current code back to why it exists.
What is the difference between an ontology, a knowledge graph, and SHACL?
An ontology defines what domain concepts and relationships mean. A knowledge graph records concrete entities and relationships. SHACL checks whether a particular graph contains the required facts and satisfies closed-world constraints; it can report required information that is missing.
What does a provenance graph record for an AI code change?
A provenance graph records how work happened: which human requested it, which agent and model performed it, which session produced it, what evidence verified it, who approved it, and under what authority.
What makes an AI-generated software change durable?
A change is durable when its meaning survives with its bytes. That requires a permanent change identity connected to intent, validation, verification, provenance, causal dependencies, and a cryptographically verifiable repository state.
Build on a foundation that remembers.
Install the CLI and start recording from the next agent turn. No account required.