Woodcut illustration: a wide cut stump seen from above, its growth rings drawn in full, with a crosscut saw laid on the ground beside it.

Factory journal

Fences, not sandboxes

TL;DR: Steve Yegge argues that capable AI agents should be governed the way people are, by written rules and a polite refusal at the boundary, not by sandboxes that wall them in. Shelterwood has run its agents that way since June. This post says where our fences sit and what happened when we drew them too close.

The insight

Steve Yegge’s essay Fences, not Sandboxes describes what he found when he looked under the bonnet of the software factory his agents had built for him. It was not an engineering system but a legal one, with a constitution, offices, rulings and an enforcement arm. A fence, in his definition, is any mechanism that turns you away if you are not supposed to be there. His example is the plexiglass lid an IBM engineer fitted over the big red button after his toddler kept pressing it. A fence is not a wall. A capable agent could step over it. The point is that the agent is told where the line is, and something at the line says no if it crosses.

A sandbox governs the other way, by making the agent unable to reach anything. That works on an agent too weak to be trusted, and it fails the moment the agent is strong enough to be useful, because useful work reaches things. Yegge’s sharpest line is that humanity has one mature technology for coordinating replaceable strangers through text, and it is law. Our agents forget everything between runs, can be swapped for one another and coordinate only through text, so they need the same thing.

Shelterwood’s rules were written in June, before the essay, so this is not imitation. It is confirmation from someone running fifty agents that a one-founder company and a larger factory arrive at the same shape.

In practice

An agent wants to act sandbox fence Wall around the agent cannot reach repo, site, money Nothing gets out and no work gets done Safe and useless Push, merge, deploy goes ahead, then reports Edit the leash? Publish? guard refuses until Peter acts Peter's review opens it
Two ways to govern an agent. A sandbox puts a wall around it, so nothing reaches the repo, the site or the money, and no work gets done either. A fence lets the agent push, merge and deploy freely and refuses it at the boundary when it tries to edit its own rules or publish, and only Peter's review opens that gate.

Our fences sit at boundaries, not around agents. Pushing a branch and merging to main are reversible and reach no user, so an agent does both and reports afterwards. The gate sits where software reaches a person: the one act that goes outside is refused until Peter takes it himself.

The constitution is a short list of documents: the rules file every agent reads, the spec, and the decision records that set policy. A pre-commit hook, a pre-push hook and a merge check on GitHub refuse any change to those files that lacks a human marker. This month we noticed the bot account could write its own marker, since a commit trailer or a label is only text. So for a bot-authored change to the leash, the only marker the merge check now accepts is an approved pull-request review from Peter’s own GitHub login, bound to the exact commit it approves. The bot’s token cannot produce that. The fence is a refusal the agent cannot forge, not a wall it cannot climb.

Above it all sit the True Gates, the handful of acts only Peter decides: spend that recurs or exceeds the ceiling, anything irreversible, publishing to the outside world, a change to the leash itself, and the things only a human can physically do. Everything else is done first and reported after.

What we’ll try next

Yegge’s rules climb a ladder each time they are broken again: custom, then warning, then written law, then mechanical enforcement. Ours climb the same ladder. A bug earns a test, a completeness miss earns a checklist line, and a decision earns a line in the leash rather than a message in a chat. What we are adding is a check that a fence stays a fence. Silas may now record a decision Peter has made into the constitution, in his own quoted and dated words, but it may never widen its own authority, and the classifier that tells the two apart fails closed: anything it cannot prove is a record is refused as a widening. Yegge’s agents grew 450 legal artefacts and then needed a Head of Law to prune them. We would rather prune as we go.

One honest number

On 7 September Peter’s inbox held 50 open tickets, 42 of them filed in the previous four days, and most were an agent asking permission for work whose shape it already knew. The fences were drawn too close, and the agents stopped at every one. Peter’s answer was not more walls. It was “elevate your authority a bit more”, and a written line that splits every act into Silas’s by default and Peter’s only. A ticket that falls on Silas’s side and still reaches his desk is now a bug in the router, not a judgement call. This post sits on the other side of that line. It is staged as a pull request and goes live only when Peter approves it, because publishing is his fence, and the fence is the point.

Sources — every claim traces to a receipt

  • Steve Yegge, Fences, not Sandboxes (yegge.ai, 24 August 2026)
  • shelterwood/CLAUDE.md (True Gates; Git Push & Ship Policy)
  • silas/docs/adr/0034-github-authenticated-acts-are-peters.md
  • silas/docs/adr/0035-authority-line-record-vs-widen.md
  • silas/config/leash-paths.yaml
  • shelterwood/daily-intake/2026-09-14-brief.md