Own the Code

System six · The governed agent

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. Installing an AI feature takes an afternoon. Owning one is the rest of this page.

The problem it solves

Their model, their rules, their logs.

Every AI feature is governed by somebody, and the platform selling one rarely volunteers who. Make it answer, four times over. Name the model that replies to your client’s visitors. Name the rules that decide what it may say and do. Name the logs that record what it said. Name whatever settles it when a visitor claims the agent promised them something.

On a platform those four answers are the same answer, and it is not 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. The model is Control. The rules are Ownership. The logs are 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.

How it works

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.

Exhibit B: the agent’s constraints
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.

Yours to govern

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 or its own accountability, because those two are what make it the platform.

Install an AI feature, or own one.

Next in the playbook

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 and ships through the gate, and its answers are held to the standard set by write, then verify. The playbook puts them in order.

The free chapter

Read the sharpest chapter first. It costs an email.

We’ll send the build-gate chapter in full: the checks and the code that runs them, with the reasoning behind every one. 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.