Your Agent Needs a Schema, Not a Better Prompt

The failure nobody demos

The agent demo always works. The customer asks for a refund, the agent calls the right tool, and the money moves.

Then it ships, and a week later it refunds an order that was never delivered. Or it issues a refund larger than the purchase. Or it approves an expense for a "manager" who has no reports.

None of these are reasoning failures. The model reasoned fine. It just acted on something that isn't true in your business, because nothing in the system told it what is true.

Prompts ask. Ontologies define.

The usual fix is a longer system prompt: never refund more than the order total; only refund delivered orders. That helps, until the prompt grows to 4,000 tokens and the rule you care about competes with forty others for the model's attention.

A prompt is advice. The model follows it most of the time.

An ontology is a different kind of object. It is a formal, machine-readable statement of what can exist in your domain and how things relate: an Order has exactly one Customer, a Refund points to exactly one Order, a Manager has at least one direct report.

It doesn't ask the model to behave. It defines the world the model is allowed to act in, and it can be checked mechanically, every time, in milliseconds.

The pattern is simple: the LLM proposes, the ontology disposes. The agent stays flexible in how it understands a request. It loses the freedom to commit an action that contradicts the domain.

A guardrail you can read

The W3C standard for this is SHACL (Shapes Constraint Language). Here is the refund rule as a shape:

ex:RefundShape a sh:NodeShape ;
  sh:targetClass ex:Refund ;
  sh:property [
    sh:path ex:forOrder ;
    sh:class ex:DeliveredOrder ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:message "A refund must reference exactly one delivered order."
  ] ;
  sh:property [
    sh:path ex:amount ;
    sh:datatype xsd:decimal ;
    sh:minExclusive 0
  ] .

The "amount can't exceed the order total" rule is a few more lines, written as a SPARQL constraint inside the same shape.

Notice who can review this. A compliance officer who will never read your Python can read "a refund must reference exactly one delivered order" and tell you whether it's right.

Closing the loop

The guardrail sits between the agent's decision and the side effect:

• The agent proposes an action as structured data (JSON-LD maps cleanly to the graph).
• A validator such as pySHACL checks it against the shapes. No model call, no tokens.
• If it conforms, the action executes.
• If not, the validation report goes back to the agent as a tool result: which shape failed, on which field, with the human-written message.

That last step matters. "Action rejected" teaches the agent nothing. "A refund must reference exactly one delivered order; order 8812 has status Shipped" gives it something to reason about.

In practice it either corrects itself or escalates to a human, which is exactly the behavior you wanted the prompt to produce.

What it buys you past the demo

One artifact does three jobs that teams usually build separately:

• Context. The same ontology that validates actions can generate the agent's tool descriptions and entity definitions. The model sees the domain as it actually is, in a few hundred tokens instead of a few thousand.
• Guardrails. Rules are declarative, deterministic, and versioned in git. A rule change is a reviewed diff, not a prompt tweak someone made on a Friday.
• Evals. Every rejection is a labeled failure: shape, field, timestamp. Count violations by shape across a test suite and you know exactly where the agent misunderstands your domain, instead of reading an LLM-judge score of 6 out of 10.

The trade-off is real. Someone has to model the domain, and that is slow, careful work. But the knowledge already exists in your database schema, your policy documents, and your senior people's heads. The ontology is where it stops being tribal.

Where to start

Don't model your whole enterprise. Pick the one agent action that would hurt most if it went wrong - the refund, the record deletion, the outbound email. Write three shapes for it.

Put the validator in front of that one tool call and log every rejection for a week. You'll learn two things quickly: how often your agent was about to do something your domain forbids, and how many of those cases your prompt had already "handled."

Frank Coyle, PhD, teaches generative AI and LLMs at UC Berkeley's School of Information and taught computer science at SMU for 32 years. He trained in neuroanatomy and neurophysiology at Emory before moving to computer science. He spoke on "Ontologies as Guardrails" at AIE Code Summit.