The Golden Tablet: turning operating knowledge into agent doctrine.
Agents cannot inherit tacit knowledge. The constraint on internal agent deployment is not model capability. It is whether anyone has written down how the work is actually decided.
Every company has a person everyone asks.
They know which deals are real. They know which invoice disputes settle and which ones escalate. They know that a ticket from this account at this point in the renewal cycle is not a support issue. Nobody wrote any of that down, because for twenty years the way to transfer it was to hire carefully and let people sit next to each other.
That transfer mechanism does not work on agents.
An agent cannot sit next to anyone. It inherits nothing by osmosis. It gets the model, the tools, the data it is permitted to see, and whatever rules somebody bothered to make explicit. Everything else that made your best operator good is invisible to it.
I think of this as the Golden Tablet problem: the operating truth of the company exists, it is real, it is valuable, and it is unwritten.
What a Golden Tablet actually is.
A Golden Tablet is the explicit, versioned statement of how a specific business loop is run well. Not a process map, and not a policy document written for auditors. A working artifact that answers the questions an agent has to answer before it acts.
What does good look like at the end of this loop? What inputs are trustworthy and which ones are routinely wrong? What are the common exceptions, and what does each one mean? Which actions require approval, and from whom? What evidence has to be left behind? Which decisions are reversible and which are not? What are the failure modes that are unacceptable regardless of efficiency gained?
Those questions are familiar. They are the same questions a control plane has to answer before agents touch real work. The difference is that the control plane enforces the answers and the tablet supplies them. A control plane without doctrine is a permissions system with nothing to permit.
Doctrine is the word that matters here. Documentation describes what the system does. Doctrine states what the organization has decided to do, including what it has decided not to do. An agent can execute doctrine. It cannot execute a wiki page.
Why this is the binding constraint, not model capability.
Most internal agent programs stall in the same place, and the stall gets misdiagnosed.
A team picks a loop, wires an agent into it, and the agent performs well on the happy path and badly everywhere else. The output is plausible and occasionally wrong in ways that take a human longer to check than to have done the work. Leadership concludes the models are not ready yet, or that the team needs better prompts, or that the users are resisting.
None of those is usually the problem. The problem is that the happy path was the only part of the work that had ever been written down, so the happy path was the only part the agent could learn. The exceptions lived in someone’s head. The judgment calls lived in someone’s head. The escalation instinct lived in someone’s head.
Model capability is improving on a curve nobody in your company controls. Doctrine extraction is improving on a curve you control entirely. That is why it is the constraint worth working on: it is the part of the gap that is yours.
It also compounds in a way that model choice does not. Doctrine survives a model swap. It survives a vendor change. It is the asset that stays yours when the underlying capability commoditizes, and it is the part a competitor cannot observe from the outside.
How to build one.
The extraction method matters more than the format. Five steps, in this order.
Pick a loop with a named owner. Not a department and not a tool. A loop is a business motion that runs until a state improves: collections aging, onboarding completion, incident triage, renewal risk. If nobody owns the loop today, the tablet will have no arbiter and the project will end in a workshop.
Shadow the best operator, not the average one. Sit with the person everyone asks. Watch a full week of real work rather than interviewing them about it, because the thing you are trying to capture is exactly the thing they will not think to mention. When they do something surprising, stop and ask why. The answer is a doctrine line.
Capture the exceptions before the happy path. The happy path is already in the runbook, the CRM stage definitions, and the training deck. The value is in the branch conditions. Write the ten most recent cases where the standard process was wrong, and what the operator did instead. That list is the first real draft of the tablet.
Write the escalation rules before the automation rules. Decide what the agent must hand back to a human before you decide what it may do alone. Teams that do this in the other order end up retrofitting escalation after the first incident, which is expensive and erodes trust in the whole program. Escalation rules are also easier to get agreement on, because nobody has to argue about losing control.
Version it like code. The tablet lives in review, has an owner, has a change history, and has a date on every line. When the business changes a rule, the change lands in the tablet first and reaches the agent second. When an agent behaves badly, the postmortem asks which line of doctrine was missing, wrong, or stale. That loop is the entire point.
Failure modes.
Five ways this goes wrong, all of them common.
The tablet becomes a document project. A large cross-functional effort produces ninety pages, nobody disagrees with any of it, and no agent ever reads it. Doctrine written at the altitude where nobody objects is doctrine with no decisions in it. Keep it to the rules that would change an agent’s behavior, and accept that it will be shorter and more contentious than a policy document.
The tablet encodes the org chart instead of the work. Escalation rules that route to titles rather than to decisions age badly and quietly become wrong the first time someone leaves. Write the decision that has to be made and who holds the right to make it, then map that to a person.
The tablet is captured from the wrong person. The most articulate operator is not always the best one, and the most senior person often describes the process as they designed it rather than as it is run. Verify against outcomes: whose work rarely comes back?
The tablet goes stale silently. This is the same failure as an unowned model version. A rule that was right in March and wrong in September looks identical on the page, and the agent applies it with complete confidence either way. Date every rule, and review the tablet on the same cadence as the business cycle it governs.
The tablet is treated as the deliverable. It is not. Governed execution is. A tablet with no enforcement surface produces a company that has written down its judgment and still applies it by hand.
What changes when you have one.
The first benefit is not the agent. It is the argument.
Extracting doctrine forces a leadership team to say out loud what good looks like, which exceptions it accepts, and where it will not trade reversibility for speed. Most organizations discover during that exercise that two functions have been running incompatible rules for years and neither knew. That finding is worth the effort on its own, and it arrives before a single agent is deployed.
The second benefit is that onboarding gets faster for humans too. A new hire reading the tablet reaches competence in weeks rather than absorbing it over quarters.
The third is the one that matters commercially. Without doctrine, agents create output. With doctrine, agents create operating force. Output is drafts, summaries, and suggestions that a person still has to inspect. Operating force is a loop that keeps running until the business state improves, inside rules the company has chosen and can defend.
Start with the loop. Write the tablet. Then decide where the agent fits.
Extracting doctrine is operating-model work before it is AI work, and it is hard to run from inside the team whose tacit rules you are trying to write down. That sequence is how I run the approach with product organizations.