The spec is the interface

How I hand work to agents outside a codebase: a short document with the decision already made, the copy already written, and the accuracy rules that stop the mistakes I can predict.

Most of what I do with agents now is not coding. It is delegation, and delegation keeps turning out to be a writing problem.

When I want something done — a block added to this site, a set of facts checked, a piece of research turned into a page — I do not describe it in a chat. I write a short document with a stated audience, “the coding agent working in this repo”, and I make every decision in it that I would otherwise be asked about later. Where it goes. How long it is. What it must not become. Then the copy, written out, because copy is a decision too. Then the part that matters most.

The accuracy rules

Every spec ends with a section of things the agent must not say. Not style notes: claims. These are lifted from a spec I wrote for one block on this site, about three small open-source libraries from years ago.

docs/rubygems-open-source.mdaccuracy rules, as written
  1. One library is mine alone. It is the one to lead with.
  2. The other two list five authors and were published under a team organisation. Do not present these as solo work. The word “team” must stay in the copy.
  3. Do not describe the password library as security tooling or imply any security expertise. It is a hackathon utility.
  4. Download counts include mirrors and CI pulls. Say “roughly”. Do not present them as users. Do not add a live counter.

Numbers will drift. Hardcode them as approximations; do not fetch at build time for three static entries.

None of those rules would occur to an agent on its own, and every one of them is a mistake an agent would make confidently: rounding a team effort up to a solo one, calling a toy “security tooling”, presenting a mirror’s downloads as readers. The rules are cheap to write because I can predict them, and the predicting is the actual work.

Why it holds

The same shape runs through the delivery team on my own product: a story is not ready until its acceptance criteria say what “done” means and a check says what it must not touch. And it runs through this site, which a small set of agents maintains behind a rule that nothing may be said about me that is not true. In every case the interface is a document, the document holds the decision, and the agent holds the typing.

What I have stopped doing is explaining things twice. What I have started noticing, and hold loosely, is that the quality of what comes back tracks the quality of what went in, and that the part that went in is mine.

In the index underagentsprocessguardrails