Guardrails for Agentic AI

Ontologies, schemas, and the machinery that stops an agent from confidently doing the wrong thing.

Self-paced  ·  Opens September 2026  ·  drC / The AI Edge

An embedding tells you which text is closest. It cannot tell you which text is correct. Retrieval inherits that blindness — it will hand your agent the topically nearest chunk with complete confidence, including the chunk that says the opposite of what's true.

Prompting doesn't fix this. You can write "only use the retrieved context" in capital letters eight times and it will work most of the time, which in an agentic system — where one bad output becomes the next step's input — is another way of saying it fails.

This course is about the other kind of instruction: the kind that guarantees rather than guides. Schemas the API enforces. Validators that reject bad data before it moves. And at the top of the stack, a formal model of your domain that a reasoner checks every proposed action against — so this refund exceeds the original charge gets caught by machinery, not by hoping the model noticed.

The guardrail stack

Four layers. Each catches what the one below it can't.

Prompt
Nothing, reliably. It guides.
System prompts, few-shot examples
Schema
Malformed output — wrong shape, missing fields
tool_use with JSON Schema
Validation
Semantically wrong values — out of range, wrong type, broken business rule
Pydantic, retry loops
Ontology
Statements that are well-formed, plausible, and impossible in your domain
RDFS, OWL, SHACL, a reasoner

Most courses stop at layer three. Layer four is where the interesting failures live.

Ontologies as guardrails

An ontology is a formal, machine-checkable model of what exists in your domain and how it can relate. Not documentation — an artifact software reasons over.

RDFS gives you the skeleton: classes, subclass hierarchies, properties with declared domain and range. Say that prescribedFor runs from a Medication to a Condition, and an agent proposing to prescribe a medication for a physician has produced something a machine can reject without anyone writing a rule for that specific case.

OWL gives you the constraints that bite:

Disjointness

A transaction cannot be both a Refund and a Charge. Assert both and the knowledge base is inconsistent.

Cardinality

An Order has exactly one customer; an Account at most one primaryHolder. Not a convention. A restriction a reasoner enforces.

Functional properties

Relationships that can hold only once per subject, checked structurally rather than by convention.

Value restrictions

Every ICUAdmission needs an attendingPhysician who is a LicensedClinician, not merely a Person.

Run a reasoner — HermiT, Pellet, ELK — over the graph after an agent proposes an action, and inconsistency is a deterministic signal. That is a categorically different thing from a model reporting low confidence about its own output.

SHACL is the practical validation counterpart, and the distinction is worth real time. OWL reasons under an open-world assumption: what isn't stated is merely unknown. SHACL validates under a closed-world assumption: if the graph doesn't say it, it isn't true — and it returns a structured violation report naming which node broke which constraint. That report feeds straight back into the same retry loop you'll have built for Pydantic in Module 1. Same pattern, richer contract.

You don't start from scratch

Established ontologies are decades of domain modelling you can adopt instead of reinventing:

  • Clinical — SNOMED CT, ICD-11, LOINC, RxNorm
  • Finance — FIBO
  • Life sciences — Gene Ontology, UMLS
  • Commerce and the web — schema.org, GoodRelations
  • Provenance — PROV-O, for agent audit trails
  • Units and measurement — QUDT

Knowing when to adopt one, when to extend it, and when your domain genuinely needs something new is a judgement call the course drills directly.

Tooling: Protégé for authoring, rdflib and Owlready2 in Python, pySHACL for validation, SPARQL for querying, a triple store when the graph outgrows memory.

What this does not do. An ontology constrains a domain. It does not make a language model truthful in general, and nobody should sell it that way. What it does is make a specific class of wrong answer structurally impossible to act on — which, in a system that takes actions, is the class that matters.

Start free on YouTube

Two things, serving different purposes.

The argument

A three-part series, and the reasoning the course is built on.

  1. Embeddings — meaning becomes coordinates. But coordinates measure similarity, not truth.
  2. RAG and GraphRAG — retrieval inherits that blindness. Structure makes it better, not truthful.
  3. Ontologies as guardrails — what it takes to constrain an agent with a formal model rather than an instruction.

Standalone explainers

Independent, watch in any order.

  • A history of AI — why the last few years are a scaling story, not a story of new ideas
  • Transformers — how attention relates meanings, and what it still doesn't tell you

No signup, no cost. They stand on their own whether or not you ever take the course.

[ video links go here as each one publishes ]

The curriculum

Five modules. Five MAKE artifacts — each one runs, each lands in its own GitHub repository, each is yours to keep. Every module pairs a video walkthrough with runnable Jupyter notebooks and start-up Python scripts, so your attention goes to judgement rather than scaffolding.

1 — Foundations & Structured Output

Messages API, stop_reason, tokens, temperature. Few-shot examples, tool_use schemas, Pydantic validation, retry loops. GitHub onramp.

MAKE — Schema EnforcerMeasure prompt-only enforcement against schema-plus-validation across repeated runs, and document the gap.

2 — Context & Grounding

Context windows, RAG as an architectural strategy, chunking and similarity, GraphRAG and multi-hop retrieval, lost-in-the-middle, prompt caching, progressive summarisation.

MAKE — Retrieval pipelineThree context strategies, measured for accuracy, token cost, and latency.

3 — Ontologies as Guardrails

RDFS and OWL, disjointness and cardinality, reasoners, SHACL validation, SPARQL, adopting and extending established ontologies, using an ontology to type graph extraction.

MAKE — Domain ontology + validation gateModel a domain, then reject agent output that violates it.

4 — Tools & MCP

Tool schemas, descriptions as the selection signal, tool_choice, structured errors, MCP architecture, server scoping, error contracts.

MAKE — MCP serverTool schemas generated from your Module 3 ontology, so the contract has one source of truth.

5 — Agentic Loops & Orchestration

The loop from scratch, programmatic prerequisites, hooks, hub-and-spoke, subagent context isolation, structured recovery, deterministic escalation, Claude Code and CI/CD.

MAKE — Guarded multi-agent systemOrchestration with an ontology-backed gate on every action, wired into CI.

The ontology thread runs through Modules 3, 4, and 5. That's the point: a guardrail you build once and never wire into anything is a diagram, not a guardrail.

No prior experience with RDF, OWL, or knowledge graphs is assumed. Module 3 starts from what a triple is.

Who this is for

  • You can write basic Python — functions, loops, dictionaries — but haven't built with AI APIs yet
  • You've watched an agent do something plausible and wrong, and want to stop it structurally rather than with a better prompt
  • You work somewhere with real constraints — clinical, financial, legal, regulatory — where usually correct isn't a standard anyone accepts
  • You learn by making things rather than by watching survey videos

Before you start

The course assumes you're comfortable at a terminal and can get a Python environment running. If that's not yet true, four short videos cover exactly that ground. They're free, they're not part of the course, and you should watch only the ones you need.

Built on the CCA blueprint

The course is structured around the five domains of Anthropic's Claude Certified Architect exam. Not because this is exam prep — it isn't — but because that blueprint is an unusually good map of what an engineer building production AI systems actually needs to know, and organising around it keeps the course honest about coverage.

DomainTopicWeight
1Agentic Architecture27%
2Tool Design / MCP18%
3Claude Code20%
4Prompt Engineering20%
5Context Management15%

If you go on to sit the CCA, you'll have covered the ground and built the hands-on work that demonstrates practical experience. Registration, scheduling, and eligibility are Anthropic's, not this course's — check their current requirements directly before planning around them.

How it works

Self-paced. No cohort, no start date to miss, no weekly deadline. Modules open in sequence and you move at whatever speed fits your life.

You keep what you build. Five repositories, five working systems, yours regardless of what you do next.

Get notified when it opens

The course opens September 2026. Leave your email and you'll get:

  • A note when each free video goes live
  • One message when the course opens, with details and pricing

That's it. No drip sequence, no reselling your address, unsubscribe from any message.


Ready to start?

The course will be launched in September 2026. At completion you’ll exit with a portfolio that proves you can build production AI systems — and a clear pathway to CCA certification. To get notifications about the course, click the link below.