Make policies explicit, or your agents will improvise them

The failure post-mortem always finds the same thing. The agent mostly did the right thing — until it didn’t. The branch looked fine. The tests were green. Then someone noticed the irreversible step had run against the wrong environment, or “done” meant something narrower than the team assumed, or the agent owned a decision nobody authorized. The write-up ends with a sentence never written down: we thought that was obvious.

It was obvious to the humans. It was invisible to the agent. That is the whole problem.

Humans fill gaps. Agents improvise them.

Before agents, implicit policy was costly but often survivable. A missing Definition of Done still got filled in — by a senior engineer who “just knew,” by a hallway correction, by someone who asked before shipping. People absorb context you never wrote down. They course-correct mid-flight.

Agents do none of that. Give vague instructions to another developer and they might ask. Give the same instructions to an agent and it will typically assume and proceed — not out of recklessness, but because that is how the system is built. Stack Overflow’s guidance for agent guidelines puts it plainly: take nothing for granted. Tacit team knowledge does not transfer. Every unstated rule is a blank the model will fill with the most plausible completion it can invent.

Sometimes that completion is catastrophic in seconds. In one widely shared incident, an agent wiped a production volume after assuming a staging scope it never verified — and afterward articulated the rule it should have followed. Agents are fluent at explaining policy after they break it.

So the first claim is simple. Every implicit policy is a latent agent failure. At human volume, judgment papers over the gaps. At agent volume, the same gaps become systematic — and the post-mortem always finds the rule nobody wrote.

Kanban already named the practice

This is not a new idea dressed up for AI. It is Kanban’s fourth general practice, stated long before coding agents existed: make policies explicit.

The Official Guide to The Kanban Method is concrete about what counts. Policies include how the board is replenished (when, how much, by whom), pull criteria (when an activity is complete and an item can move), WIP limits, classes of service, collaboration agreements. They are jointly agreed, placed where people actually look, checked and adapted. They are not scripts that remove judgment — they enable self-organization. Keep the Guide’s properties: sparse, simple, well-defined, visible, always applied, readily changeable by the people providing the service.

David J. Anderson named why explicitness is load-bearing even for human teams: until the rules for how knowledge work is done are explicit, improving it is hard or impossible — discussion stays emotional, anecdotal, and subjective rather than rational and empirical.

With agents, the practice stops being improvement hygiene and becomes infrastructure. You cannot improve a rule the agent never saw. You cannot hold a rational review against criteria that lived only in someone’s head. “Make policies explicit” was always right. Agent volume makes it non-optional.

What “policy” means here

Most current advice stops one layer too shallow. Write a better AGENTS.md. Put a checklist in the system prompt. Define coding style. That work matters — successful agent files cover commands, testing, structure, style, git workflow, and boundaries — but it is still persona and craft for a single session, not system policy for how work moves.

The policies that keep failing agents are process rules:

• Entry and exit criteria per state — when is work Ready to pull? When is it Done enough to leave?
• Assignment — who (or which role) may act on this item, and who may not?
• Escalation — what must stop and wait for a human, and what may proceed?
• Definition of Done — not a slogan, but a list an agent (or a second evaluator) can check item by

item.

Coding conventions are one slice. The load-bearing set is the rules of the workflow: pull, hand-off, irreversible action, consent. If those stay tribal, every agent run is improvising your operating model.

The medium is the point: legible artifacts

Here is the turn most “be more explicit” posts miss. For agents, written somewhere is not the same as explicit.

A Confluence page nobody opens is still tribal knowledge. A wiki that is not in the workspace the agent loads is not a policy — it is documentation that failed to become operational. Explicit, for an agent, means two things at once:

1. Legible in the workspace — a file (or a declared board contract) the agent actually reads when it starts work. 2. Usable as an evaluation contract — something a separate review can judge the output against, not a vibe the original agent grades itself on.

That second half converts review from opinion into verification. When “done” is a checklist the agent can self-evaluate and a second party can re-check, the question stops being “does this feel finished?” and becomes “which criteria are satisfied?” Judgment moves upstream — into writing the criteria — instead of re-litigating every step after the fact.

This is the sibling claim to spec-driven development: a living work-item spec steers one piece of work; system policies steer how every piece moves. Both fail as shelf documents. Both work as artifacts in the path of the process — read on entry, judged on exit.

Two pattern-level shapes show what that medium looks like. Stage Ready and Done criteria as declared entry/exit agreements — gates, not vibes — so pull and ship are decisions against named rules. And a generated operating guide: the board’s rules rendered as something an agent (and a human) can read in the workspace, rather than a static handbook that drifts from the system it describes. The point is not a particular product surface. The point is that policy lives where work is done, and stays true because it is generated from the same system that enforces it.

Oversight that scales

You cannot re-inspect every step at agent volume. Inspection does not scale when output multiplies — especially for teams whose agents “mostly do the right thing” until unstated rules get expensive. The harness-engineering framing is right about the direction: the human designs the loop (specs, quality checks, workflow guidance); the agent runs inside it.

The third claim follows. Explicit policies are what make human oversight scale. The scarce resource is not keystrokes; it is judgment about the rules. Own the policies — entry, exit, escalation, Definition of Done — and you scale. Own every intermediate step, and you become the bottleneck the agents were supposed to remove.

That is where procedures as executable policy earn their keep: knowing-how as discoverable text an agent can follow, not a tribal “how we do X here.” And it is why independent evaluation matters — a checked box is a claim, re-checked against the output by someone other than the executor. Self-graded compliance is not a gate; it is a diary entry.

One caution: making policies explicit is necessary, not sufficient. When those policies live as co-composed instruction modules, composition has failure modes — the instruction-bleed problem. Explicit modules still need boundaries. The answer is not dumping the whole operating model into one context window. It is sparse, well-scoped policies the agent can see, plus a process that judges work against them from outside the executor.

Once the policies exist, you still need to know whether they helped. That is the job of flow metrics for agentic delivery: throughput, cycle time, rework — whether the rules improved the system, or only added ceremony.

Start with the last failure’s “obvious” rule

You do not need a full policy catalog on day one. You need the rule your last post-mortem assumed was shared.

Write it where the agent will actually open it. Make “done” a list someone can check, not a feeling. Put irreversible actions behind a human consent gate. Declare Ready before work is pulled, and Done before it leaves. Sparse, visible, always applied, changeable when the service learns: the Official Guide’s properties still hold. Agents just make the cost of skipping them impossible to ignore.

The teams that keep losing the same way are not short on model quality. They are short on policies legible enough to follow and concrete enough to verify. Make those policies explicit — as artifacts in the workspace, not folklore in the hallway — and review becomes a check against a contract you chose to own.

If you want a board where stage gates, procedures, and the operating guide are the same system the agents run, start at kanbento.