Frontier judgment, commodity iteration

Every organisation building an internal agentic-coding platform hits the same wall. The model you trust to review changes is the one you cannot afford to have typing all of them. This note describes the delivery pattern we run at Borge Labs to resolve that: frontier models at the judgment gates, lower-cost iteration lanes wired for pilots, explicit human consent before work starts, and two human delivery gates. It is small enough to read in five minutes and concrete enough to copy.

The shape

One work queue on the forge you already run. Issues are the interface, labels are the state machine, and consent is explicit: an issue is untouchable until a human labels it ready. A conductor walks each issue through a fixed ring:

• Plan on the strongest model available. The plan is a spec another model can execute verbatim: files, commands, acceptance criteria, live verification steps.
• Human gate one: a person approves the spec with a label. Nothing builds without it.
• Build on an engine matched to the work. The planner tags each ticket by difficulty. Stronger builders handle the established production path; commodity API and local open-weights lanes are wired for planner-tagged light tiers behind an escalation path.
• Review adversarially, normally by a different model than the builder, again on frontier judgment. Lower-cost pilot builds request a second frontier opinion before approval; if that reviewer is unavailable or its usage is exhausted, the degraded gate is recorded explicitly.
• Human gate two: a person merges the pull request. On our product repositories, merge is deploy.
• Verify live and attach the evidence to the issue before it closes. A change that has not been observed working in production is not done.

The two rules that protect the economics

First: one attempt per tier, then escalate. In the lower-cost lane pilots, when a build fails review, the ticket moves up the ladder with the findings attached, to be rebuilt by a stronger engine. It never iterates against the expensive reviewer, because a weak builder ping-ponging with a frontier reviewer costs more than the cheap build saved. Second: risk outranks difficulty. Anything touching auth, billing, secrets, migrations, deploys or personal data is always built by the strongest engine from a fully approved spec, no matter how small the diff looks.

The reason the split works at all is that agentic building and reviewing have very different token profiles. Building burns tokens in the error loop: explore, edit, run tests, read failures, fix, repeat. Reviewing reads a finished diff against a spec once. So the frontier bill scales with the size of the change, not with the effort it took to produce it. In our setup we estimate the judgment share at roughly one fifth to one third of what frontier-built changes would cost; we are measuring it per lane and will publish the numbers rather than the vibes.

The boundary that makes it safe to automate

The agents live on a credential-bounded host. Its path to product and infrastructure changes is git through scoped bot identities; it can also update queue issues and send operational notifications. Cluster access is read-only, product data stores are not mounted, and observability access is separately scoped and audited. Material sent to coding models must still be synthetic or sanitized. This delivery process requires a human pull-request merge before deploy. The gate is strongest when forge protections also deny direct bot pushes, and those external controls must be verified rather than inferred from a prompt. Prompts are instructions; credentials are boundaries. The result is an audit trail your change-management process already understands: issue, approved spec, pull request, adversarial cross-model review, human merge, live verification evidence.

The same split helps with data residency. Judgment models receive code, approved specs and deliberately sanitized operational evidence. Where material must stay inside a jurisdiction, route it only to an approved in-jurisdiction provider or to a local open-weights model on hardware you control.

If you are building an internal platform

Most internal agentic-coding platforms converge on the same parts list: shared workspaces for citizen and professional developers, a skill or prompt library, an LLM gateway, an MCP catalog, and a paved road to production. This pattern drops into that world without new infrastructure. The queue is your ticket system. The consent boundary and two delivery gates are your change management. The build tiers are model routes in the gateway you already operate. The credential boundary is a workspace profile. What the pattern adds is the discipline that makes the platform affordable and reviewable at the same time: judgment where it matters, iteration where it is cheap, and an escalation ladder so failure costs pennies instead of trust.

Status

This is not a whitepaper pattern. The ring described here has run in our own infrastructure and delivered reviewed, live-verified changes to our own products, with the strongest available frontier model at the gates and the lower-cost lanes piloted underneath. It is currently paused by our own discipline: hardening review showed the conductor and its build workers shared an operating-system identity, so the ring stays off until the controller gets its own. That is the boundary rule above applied to ourselves. Two building blocks are open source today: ai-team, the chat-native spec and stakeholder layer, and ai-dev-team, the supervised execution harness with an honest benchmark story. The conductor itself is a few hundred lines of shell and prompt files over plain forge issues, which is rather the point: the value is the shape, not the software.

Building something like this internally? We have run the whole loop, including the failure modes, and we like comparing notes. Get in touch.