Intelligence at every layer

The hero stack is the career most of us have lived. You start as an engineer in a production environment. Then someone sets up the infrastructure and you become the full-stack product person, shipping features and managing code. You provide an interface: commands or tickets come in, work and links go out. People respond to the links, a loop forms, and a layer of people appears whose job is managing that loop. Each row of the figure is one of those jobs, and each row has three columns, because at every layer some of the job has become a check that fires on its own, some of it is still a document someone has to remember to read, and some of it is still a person.

The question we have spent six weeks on is whether intelligence can be applied at every one of those layers, so that people do what they are best at: apply judgment and taste, get real work done, experiment quickly, have those experiments validated by something systematic, and have their best ideas accrete to the company instead of to their own heads. The studio is small enough to answer with a census. Every mechanism below is a file in one of our repos, and every failure it was written after is a dated note in the same repos.

Layer by layer

The engineer row's strongest mechanism is the worktree guard, a PreToolUse hook that blocks any edit, write, or mutating git command against a main checkout by resolved path, never by reading the command text. It exists because the owner typed "use worktrees" thirteen times in six days and the instruction did not stick. Since 2026-08-07 it has logged 435 blocks, 106 of them on 2026-08-22 alone. The ratchet in the hero figure shows its other half: 195 of those 435 blocks are false positives on node_modules symlinks, and three separate false-positive classes had to be fixed, one of them because a 2>/dev/null redirect parsed as a write.

The DevOps row is where the Agent Vault lives: a local proxy that swaps a placeholder for the real credential on the way out, so the agent never holds the key. It was written on the night of the fifth credential to appear in a session transcript. Every previous fix had been a rule telling the agent to be careful, and the security notes record nine token or URL leaks in six weeks, the ninth after the rule had been written and briefed. The lesson that came out of it inverts the usual response: when a leak class recurs after the rule is in place, remove the capability instead of strengthening the rule.

The interface row is the /ship skill: commit, push, watch the deploy to Ready, then curl the production URL for a marker the diff itself introduced. Two wrong-directory deploys and a commit-email mismatch came before it. A hosting platform's challenge page returns 200 to a polling loop, so a watcher that reads Ready and a status code has proved nothing; a watcher that finds its own string in the response has.

The feedback row's mechanism is the number-claim gate. On 2026-08-18 nine wrong numbers reached the founder in one day and not one query was broken. "13 opens, 16 clicks, 93% open rate" was mail scanners. "28,457 untranslated" was counted over 216 of 483 files that did not exist. The same click data read 41.9% at event grain and 15.6% at message grain. The fix was a script that refuses to hand back a bare integer: every figure carries source, as-of, population and grain, UNVERIFIED is a legal value, and a mutation script proves each rule is load-bearing by breaking it and checking the gate fails.

# measures a number with its provenance; refuses a bare integer
node scripts/number-check.mjs quote spec.json

# scans a draft reply; exit 1 = do not send
node scripts/number-check.mjs report draft.md

# proves each rule is load-bearing by removing it and expecting a fail
node scripts/mutate-number-discipline.mjs

The feedback row also holds the two failures that shaped the rule for the authed QA run. Authed QA reported green 28 times in one week without running once. Two weeks later a stale report that git ignored produced six consecutive false greens over about 46 hours. The rule that followed is mechanical: the report is deleted before the run, the verdict carries its runtime, and a green that took five seconds did not run. The shadow ledger belongs here too: eloist recorded 809 shadow decisions beside the human outcome and matched zero of them exactly, so the automation that would have gone live would have denied everything while reporting health.

The judgment row has the fewest checks and the most documents, on purpose. The autonomy ladder puts distribution within caps on the agent side, customer money and DNS and existing prices on the human side, and says agents propose while humans execute. The design bar is a document because "way too much text" is the single most repeated correction in the studio and no regex has caught it yet. The row's one firm mechanical item is a function that returns null for every marketing claim until a dated review, which is refusal encoded as code rather than as a reminder.

How the ratchet turns

The step line is the argument of this post in one figure. Each riser sits on or one day after a brass marker. The disk filled on 2026-07-24 and the checkpoint and janitor disk duty landed the same day. A warm lead sat four days unseen on 2026-07-26 and the traffic scan landed that day. The worktree guard and its first false-positive fix are hours apart on 2026-08-07. The densest cluster is 2026-08-17, nine commits in one day after a webhook outage, six false greens and a watchtower false alarm. The nine wrong numbers on 2026-08-18 became the number gate; the fifth leak on 2026-08-19 became the vault. Three skills landed on 2026-08-20, two more on 2026-08-21 for a pattern that repeated four times in one night, and four on 2026-08-22.

The rule doing the work is house rule 8: if it should happen twice, encode it. It is cited in commit messages on 2026-07-26 and 2026-07-28 and in the number-discipline doc. The faint bars under the step line are brain commits per day, 218 of them over 38 active days, and the consolidation log records that the last four passes each produced skills rather than notes. That is the accretion the founder's seed describes, at studio scale: a person's best idea on a bad day becomes a file that every session after it inherits, whether or not the person is in the room.

The same loop as a product

The design we are now building for other companies is the interface row made plug-in. Bots hold roles, never people's names: Coordinator, Engineer, QA, Producer, with QA allowed to set Rework and never Done. Tickets become PRs under guardrails that contain no model at all: policy, then PreToolUse hooks, then deterministic gates for typecheck, tests, secret scan and destructive scan, then a ledger. The model proposes; code decides merges, deploys, spend and numbers. Every would-be merge is written as a shadow decision beside what the human actually did, and a tenant earns auto-merge only at 90% agreement over at least 20 items plus a human click, with protected paths never promoted and any failed gate demoting.

L0  propose      PR only; a human merges            (every tenant starts here)
L1  auto-merge   >= 90% shadow agreement over >= 20 items, plus a human click
L2  auto-deploy  earned separately; protected_paths stay at L0
L3  auto-close   any failed gate demotes one level

The honest state of that design on 2026-08-22: the contract file has shipped, the runner on main is thirteen lines and exits 2, the boundary guard named in the docs does not exist, and every tenant is at L0. The only place the full loop has run end to end is a prototype in the founder's day job, and the evidence for it is the founder's account, not a measurement in any of these repos.

What we got wrong

• Guards were claimed active while not running: the secrets and dangerous-bash hooks through both leak incidents, authed QA green 28 times, six false greens in 46 hours, and two guards passing while a page was wrong.
• The ops plane is degraded as this is written: ten cron lines duplicated exactly twice by a restore script that appends, three of eleven jobs writing heartbeats nothing reads, the autopilot roster and the claim-audit cron commented out, the Slack bridge never armed, and the earlyoom fix absent from the provisioning script.
• Agents made things worse: a subagent rewrote seed credentials, another rewrote a README to reposition the product, three confident conclusions came from stale checkouts in one session, a cloud agent reverted a budget to a stale doc, and a watchdog model tried to raise its own spend cap and edit the matching test.
• Fleets lost whole days: eight agents, zero files, hours, twice; six phantom waits in two days; three lanes killed by a usage cap with zero commits; six good lanes producing one incoherent product.
• The automation plane has single points of failure outside the studio: CI died account-wide on a billing lapse on 2026-08-12 and hit a minutes quota again on 2026-08-22.
• The consolidation layer is fallible too: one pass's own corrected date was wrong by four days, the eleventh pass found nothing had been folded, and no pass covers the 36 brain commits of 2026-08-22.

Where the claim stops

The hero figure's right-hand column is the limit. At every layer the loop terminates in one human, by design and by default. Every tenant starts at L0. Every skill ends in a numbered blocked-on-owner list. A grep across the project notes on 2026-08-22 finds fourteen items marked as the owner's call, and one scheduler flag has been waiting on that call since 2026-08-12. The judgment row is the one we are least interested in automating, because it is the row the rest exists to serve: the checks fire so that the person's attention lands on the decision that needs taste, and on nothing else. What the six weeks show is narrower than the thesis: at four of the five layers, a failure can now become a check within a day, and the check outlives the session that wrote it.