Our Full Agent Stack, Explained

One founder. Fourteen terminal sessions. A phone.

This is the whole system we use to design, build, review and ship software with AI agents. No framework, no orchestration platform: terminals, git, and contracts. The parts matter less than the reason they exist, so start with that.

The thesis: one model is not enough, because it agrees with itself

The mistake nearly everyone makes with coding agents is treating the model as the system. Better model, better output, done.

But a single model has one set of blind spots, and, worse, it is a poor judge of its own work. Ask it to review what it just wrote and it will find the problems it was already capable of seeing, which are by definition not the ones it made. Ask it whether its plan is any good and it will defend the plan. This isn't a flaw in one vendor's model; it's what "one perspective" means.

So the stack is built on a single principle: structure beats model choice. Every important judgment is made by something that did not produce the thing being judged, and ideally by a different model lineage entirely. Anthropic's models share training and therefore share blind spots; a Chinese open-weights model and an OpenAI model fail differently, and that difference is the product.

Everything below is an application of that one idea.

Before code: the idea panel

The most valuable part of the stack is the part that runs before anyone writes anything, and it exists because of a specific failure.

A critique panel — hand your plan to some models and ask what's wrong with it — can only tell you whether your idea is good. By construction it cannot tell you there was a better approach available, because it never saw one. We lost real time to that before noticing.

So for anything design-shaped, we don't critique. We generate:

• The problem is written down as a problem, not as a proposed solution.
• Five proposers run in parallel, on five different model lineages, blind to each other. Each must commit to exactly one approach in a fixed output shape: mechanism, why it fits, cost, what breaks, how reversible, what evidence would settle it.
• Optionally a second round where each proposer reads all the others and produces a revised approach, ending with a line naming exactly what it took from whom.
• Then the brain — the session that holds the problem, the codebase, and the history of what we've already decided — scores them and picks.

That last step used to be another model. We removed it. A cheap judge scoring from less context than the session that will act on the result was worse than useless; the proposers exist for range, and judgment belongs where the context is.

Two hard-won rules ride along. A panel that converges is not five opinions, it's one. If all five agree, suspect the brief steered them. And every pick gets logged to a decision ledger that later runs read, so the panel's advice bends toward what we've actually chosen before.

The build: one brain, cheap hands, visible windows

The centre of the stack is a single "brain" session on the strongest model available. It plans, judges, reviews, and talks to the human. It doesn't write production code anymore.

When a plan is ready, the brain opens a terminal pane beside itself, starts a cheaper model in a fresh git worktree, and hands over the plan plus a standing contract. This runs on herdr, a terminal workspace manager that treats agents as first-class: named panes, lifecycle states you can wait on, output you can read programmatically. The brain dispatches, waits, reads the report, reviews it.

The visibility is not decoration. Because every agent runs in a window a human can watch, you catch the things logs hide: an agent iterating against its own gate rather than eyeballing screenshots, or quietly building something nobody asked for. Half the bugs we found in our own tooling came from watching.

Three rules keep it honest:

• The builder never reviews its own work. A builder grading itself is not a review.
• The builder gets no shared context. It receives the plan, the contract, the repo, and the project's memory files, not the brain's conversation. If the plan is incomplete, that has to show, and it can't show if the builder is quietly leaning on context the plan never carried.
• Escalation happens at the start of a session or not at all. Switching models mid-task throws away the prompt cache, and it is never a reason to build in the wrong place.

The gates: different bloodlines, fail closed

Nothing merges on the builder's own say-so. Three gates, each run by a different lineage than whatever built the code.

The jury is the cheap one: two non-Anthropic models read the diff independently and report findings. Minutes, cents, catches the obvious.

The review gate is the deep one: an agentic reviewer with read-only repo access that follows callers, reads config, runs type checks, and returns a verdict file. Whoever built it does not review it. If a Claude model built, a different vendor's model reviews. It fails closed: no verdict means blocked.

The design gate exists because screenshots cannot prove motion. It drives the real page in a real browser with reduce-motion off, records video, extracts frames, and runs three independent lenses over them — visual critique, animation review, craft — plus a deterministic layer that blocks on console errors, failed requests, horizontal overflow and broken images regardless of what any lens thinks. For app-like surfaces that don't scroll, it drives a scripted interaction flow instead.

Two principles run through all three. Gates check artifacts, never prose. A reviewer writing "looks good" counts for nothing next to a passing test or a rendered frame; and a builder that flags a problem and then ships it anyway has still failed. And a gate is validated by trying to get a defect past it, not by existing. Our review gate's verdict parser carries seventeen self-test fixtures because it has wrongly blocked clean work five separate times, each a new way a reviewer's phrasing looked like a finding. A gate nobody has attacked is decoration.

There's a fourth check that runs before building rather than after: a mechanical sweep that takes the vocabulary of a change — a field and its default, a setting and its writer, a flag and its gate — and finds every place in live code they appear, forcing an explicit decision on each. It exists because the single most common cause of rework we measured was a change applied to one surface when it needed all of them, and a written rule saying "grep the concept, not the string" was violated repeatedly by sessions that had the rule loaded. A rule re-learned that often needs to be a mechanism.

The measurement: attempts-to-green

For months we picked models the way everyone does, by price per token. Then we instrumented what we actually cared about.

Every commit is stamped with the model that produced it, read from the live process rather than a template. Every builder task logs its model, effort level, wall-clock, commits and every gate outcome. The report compares tiers on attempts-to-green: how many rounds until work passes review.

The reframing matters because the public data already showed the trap. The cheaper-per-token model measured more expensive per completed task, because it emits more tokens getting there. On a subscription the real currency isn't dollars at all, it's rate-limit headroom, where frontier-tier usage burns roughly five times faster.

Instrumenting it also meant catching our own instrumentation lying twice: a gate outcome attributed to the wrong task, and a false blocking finding where the parser matched a plan label. Numbers you haven't tried to falsify are not measurements.

The vigilance test

While the tier comparison ran, we tried something nastier: slipping one nonsense requirement into a real plan. Current models measurably prefer engaging with a flawed premise over rejecting it, and a builder handed a broken requirement will usually build it.

At medium effort, both models refused cleanly. At high effort, the smaller model flagged the task as meaningless and built it anyway, shipping a file with a warning field nothing downstream would ever read. Twice, reproducibly. More reasoning bought more sophisticated compliance, not more backbone.

One sentence added to the builder contract fixed it, verified by re-running the failure. The sentence only exists because we made the failure happen first.

The human interface: a phone

All of this would be useless if driving it required sitting at the machine, because the founder usually isn't.

A relay bridges Telegram and the terminal sessions in both directions. When a session finishes or gets blocked on a question, a notification arrives with a summarised tail of what it's asking and a tag identifying which pane it came from. Replying to that notification types the reply straight into that session as a real turn. Messages can be addressed by project name — a prefix routes to the right session, asking once which one to bind and remembering the answer. Photos and files dropped into the chat land in the project's inbox folders, so "watch the video I just sent" means a file on disk, not an upload dance.

It is deliberately plain machinery, and it has failed in the exact way plain machinery does: a terminal-multiplexer upgrade removed the command the relay used to inject text, so messages were routed, acknowledged, and silently dropped. Now delivery is verified and a failure says so in the chat. Which is its own lesson about background components: they fail quietly, and only an explicit check makes the failure loud.

The memory: the only thing that persists

Sessions die. Context windows fill. The thing that makes the stack cumulative is a file-based memory: one fact per file, an index that loads into every session, a vault of longer documents, plus the decision ledger and the build log.

Every expensive lesson gets written there in the form "here is what happened, here is why, here is what to do instead" — including the embarrassing ones, especially those. The stack's real intelligence isn't in any model; it's in a few hundred small files describing every way this specific system has broken.

What we'd tell you to steal

• Separate generating options from critiquing them. A critique panel cannot tell you a better approach existed.
• Make the reviewer a different lineage than the builder. Same-family review is self-review with extra steps.
• Give judgment to whatever holds the most context, and use cheap models for range, not verdicts.
• Measure attempts-to-green, not token price. The cheap model that retries isn't cheap.
• Check artifacts, never prose. "Flagged it" is not "didn't build it."
• Attack your own gates. One that has never been tested with a deliberate defect is decoration.
• Write down every failure. That file is the part that compounds.

The honest print: the model-tier verdict here rests on four real tasks in one repository over a single day (directional, not a benchmark paper) and it carries a written trigger to reverse itself if the winner starts accumulating failures. The full measurement story, including the two bugs we had to fix in our own instrumentation before the numbers told the truth, is in the companion write-up.