HOT TAKE ALERT
Building multi-agent AI systems that actually talk to each other, and the contract that decides what they are allowed to say.
William Hill · Forward Deployed Engineer
@emjay_hill · mjhilldigital@gmail.com
You will know how to tell whether your AI feature is limited by the model or by what it knows.
And you will have a rule for when to write that knowledge down as a contract, and when not to bother.
The problem
The forecast is in a weather app.
Your schedule is in a calendar.
What you actually own is in a closet.
15 shirts and 10 pairs of pants make 150 outfits.
You can put on a lot of stuff. That don't mean you're putting that sh*t on.
The system I built
Put That Sh*t On. Give it a city, get ranked outfits from clothes I own.
Orchestrator takes the city and delegates. weather_agent fetches the forecast. wardrobe_agent returns what suits the temperature. outfit_agent composes the ranked outfits.
MCP is how an agent reaches data. A2A is how agents reach each other. An Agent Card is how one agent tells another how to call it.
What PTSO knew about my closet
Six columns per garment: type, category, brand, color, fabric, style.
Enough to filter a list. Not enough to justify a choice.
The suede loafers matched on color, on style, and on temperature. Every check the system had, passed.
Not one of them knows what rain does to suede.
What PTSO knew about my closet
I tuned the orchestration. I improved the prompts. I moved up to newer models.
The outfits stayed generic.
The limit was not the agents, and it was not the model. It was the data underneath them.
What PTSO knew about my closet
A model that never made anything up would never suggest anything you had not thought of.
The guessing and the usefulness are the same machinery. You cannot keep one and delete the other.
A model that never hallucinates is the overfit one. It can only hand back what it memorised.
So stop trying to fix the model. Put something next to it that checks the answer.
Frank Coyle, UC Berkeley — Why Agentic Systems Need Ontologies
What PTSO knew about my closet
Not the model. Not the prompt. Not the framework.
Your data, and the rules about what it means.
Thin substrate, and the agent is far more likely to hand you a wack outfit, with total confidence.
An ontology is that second half: the rules. It turns rows in a table into something an agent can be held to.
Defining the term
"An explicit specification of a conceptualization."
Thomas Gruber, 1993. This is the definition the field actually uses.
Defining the term
Defining the term
What the things are called.
What each name means.
What is allowed to go with what.
Written down in one place, outside the model, where anything can check it.
Defining the term
This rulebook is your taste. You already follow every line of it, and none of it is written anywhere software can read.
The ontology inside PTSO
A human typed wool blend. A human typed charcoal.
Nobody typed layers over the merino crewneck.
PTSO worked that one out, and it names the rule that did it.
The ontology inside PTSO
The evaluator returns valid, a bounded score, violations — and repair_candidate_ids.
The ontology inside PTSO
Every outfit the model proposes is checked against the contract before I ever see it. Below 0.4, it is dropped.
The graph is a copy. Postgres holds the truth.
Before PTSO trusts that copy it checks how old it is, whether the contract version changed, whether the rows belong to this user, and whether the build matches. Any one fails and it answers nothing, rather than something stale.
Live — PTSO Closet Intelligence.
What I learned
V1 — four LLM calls, two network hops. The model decided everything.
V2 — the outfit agent moved in-process. One hop gone.
V3 — the rules decide what survives. The model only proposes.
The model now does strictly less than it did on day one.
What I learned
Build it when two systems must agree on a word, a wrong combination costs money, or the rule outlives the prompt.
Skip it when one codebase reads the data, a retry is cheap, or you cannot write the rule in a sentence.
What I learned
Clinical. The agent drafts a treatment plan. The contract blocks the interacting pair and names a substitute.
Access control. The agent assembles a report from three systems. The contract decides which rows this role may read, before the agent sees them.
Manufacturing. The agent configures a build. The contract rejects the parts that do not fit and lists the ones that do.
Same shape every time. The agent proposes. The contract disposes, and names the fix.
What I learned
If it sounds right but gets the world wrong, the limit is not the model. It is what the model knows.
Write that down when two systems must agree, or when being wrong is expensive. Otherwise do not bother.
Then let the model do the part it is actually good at.