A governed AI agent that answers to you.
Every platform now sells AI features. The playbook’s agent runs on infrastructure you control, under rules you wrote, with transcripts the browser cannot forge. That is the difference between installing an AI feature and owning one.
Whose model, whose rules, whose logs?
Ask any platform that sells an AI feature one question: who governs it? The questions underneath are concrete. Whose model is answering? Whose rules decide what it may say and do? Whose logs record what it said? And when a visitor claims the agent promised them something, whose word settles it?
On a platform, the answers are all the same, and none of them is you. The model is theirs and changes when they change it. The rules are theirs and are not published. The logs are theirs, kept for as long as they choose, and the dispute is settled by whoever holds them.
This is the CODES test applied to AI features. Whose model is Control. Whose rules is Ownership. Whose logs is Data. A platform’s AI feature fails all three on the day you switch it on.
An AI feature you rent answers to the landlord.
Four constraints, enforced by schema.
The agent is schema-governed: what it can do is a list, and the list is written by you. Each of the four constraints below closes one way an agent on a public site is usually abused or misquoted.
- Enum-only tool arguments
- It chooses from a list. It never types a value.
- Layered request rejection
- Each layer can refuse before the model sees it.
- HMAC-signed auth
- Every request carries a signature your server issued.
- Signed transcripts
- The browser cannot forge what the agent said.
Each constraint is checked by the server, not requested of the model.
Enum-only arguments mean the model cannot invent a parameter: a tool takes one of a fixed set of values, and anything else is rejected before it runs. Layered rejection means a request is checked at several points on the way in, each able to refuse it, so a single bypass is not enough. Signed authentication means the server can tell a genuine request from a forged one.
And a signed transcript means the record of what the agent said carries a signature the browser cannot produce. When the dispute arrives, the record settles it.
What owning one looks like.
The agent runs on infrastructure you control, on the same owned stack as the site. The model is the one you chose, and swapping it is your decision. The rules are a schema in your repository, reviewed like any other code. The logs are yours, kept as long as you choose, and every transcript in them is signed.
When the visitor says the agent promised a refund, you do not ask a vendor for the record. You read it, check the signature, and answer. Clients feel this difference even when they cannot name it: an agent on their site that they, through you, actually govern.
It is also the part no platform can sell you. A platform can sell a model and a settings panel. It cannot sell you its own logs, its own rules or its own accountability, because those are what make it the platform.
Install an AI feature, or own one.
Six systems. Read from the top.
The agent is the last of the six and depends on the five before it. It runs on the stack, ships through the gate, and its answers are held to the standard of write, then verify. The playbook puts them in order.
Read the sharpest chapter first. It costs an email.
We’ll send the build-gate chapter in full: the checks, the code, and the reasoning. Read it. If it doesn’t change how you think about shipping client sites, you’ve lost ten minutes and kept a working release gate.
That did not send. Check the address and try again.