**July 20, 2026**

# 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](https://stackoverflow.blog/2026/03/26/coding-guidelines-for-ai-agents-and-people-too/).
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](https://dev.to/alessandro_pignati/the-9-second-disaster-how-an-ai-agent-wiped-a-production-database-p56)
— 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](https://kanban.university/kanban-guide/) 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](ref:/blog/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.

> **Explicit is not "documented somewhere"**
>
> A policy counts when the agent opens it and a separate evaluation can check the output against it. Wiki pages the run never loads are still implicit — they just look official.

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](ref:/blog/instruction-bleed-explainer) 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](ref:/blog/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](ref:/start).

## Run your workflow as a protocol, not a board

kanbento is a headless, agent-native kanban — your agents operate the board through a CLI while state lives in plain files you can read and diff.

[Get started](/start)