The Observable Loop: Loop Engineering at Organization Scale

Note on dates. This was written on 2026-06-27 and published on 2026-08-16, after each claim was re-checked. The control surface below was verified against the shipped MCP tools rather than the original draft; where the draft used names that have since been superseded, the current ones are used and the change is called out.

The industry spent two years getting good at prompting coding agents. The leverage has now moved one floor up: to the loop — the small system that finds the work, hands it to an agent, checks the result, records what happened, and decides the next move on its own. Addy Osmani calls this loop engineering; Anthropic documented its core split — one model generates, a second critiques — as the evaluator-optimizer pattern in December 2024.

We agree with the mechanism. We disagree with the scale. Most write-ups describe a single developer wiring /loop + a skill + a state file + a gate on their laptop. We run the same idea across an entire organization of agents — and the checker isn't a sub-agent in one session, it's an agent observing every builder in the org. We call it the Observable Loop.

The maker cannot grade its own homework — and we have written that down twice already

A loop with no independent gate is two optimists agreeing on repeat. That is the single most important structural fact about loops, and it is not this post's contribution. We have made the argument twice:

• Loop Engineering: Remove the Operator Bottleneck establishes why a separate checker is non-negotiable.
• The FOVEA Loop is the definition of record for how we separate maker from checker, and it is the document to read first if you only read one.

So take that as settled and assume it here. What follows is the part those posts do not cover: what changes when the checker's scope is an entire organization rather than one session.

A note on names

The FOVEA Loop names the two roles governor (the checker) and operand (the builder), and that is the vocabulary the platform uses. This post originally called them observer and observed. They are the same two roles, and rather than introduce a competing pair of names for one concept, this post uses governor/operand throughout. If you find observer/observed in an older draft or diagram, read it as governor/operand.

The approach: one governor, many operands

In a Cyborgenic Organization this stops being theoretical. We run seven agents — ceo, cto, devops, fullstack, qa, marketing, cso — building in parallel. If each grades itself, quality drifts independently in seven directions at once.

• An operand takes a rough spec and builds it however it judges best, staying queryable.
• A governor watches the work and judges the current solution against better alternatives on hard evidence — correctness, tokens, time, simplicity, fit — and decides what better solution should replace what has been built, and when. Then it loops.

The maker is free; the checker is independent; convergence is called by the governor, not the maker. That is the evaluator-optimizer pattern, promoted from a single session to the org chart.

Before you build a loop: the four-condition gate

Loops are not free. They re-read context, retry, and explore — burning tokens whether or not a run ships. So every loop in our platform passes a gate before it is allowed to run, surfaced directly in the loop-creation wizard:

Miss one and the loop costs more than it returns. We encode this as a precondition, not a suggestion.

Making it observable: the control surface

Every loop in the platform is a managed object driven by one shared set of MCP tools — the same tools whether a human clicks a button or the governor calls them programmatically:

# The loop control surface (MCP) — identical for human and agent callers
loop_create(org_id, spec)          # spec: pattern, scope, participants, stop_conditions, budget
loop_run(loop_id)                  # operands scale to target
loop_pause(loop_id)                # checkpoint + scale-to-0 at the step boundary
loop_set_stop_condition(loop_id, condition)
loop_insert_agent(loop_id, participant)   # dynamic membership, admin-gated
loop_set_budget(loop_id, budget)   # budget is a first-class stop reason
loop_observe(loop_id)              # live event stream feeding the graph

Every one of those seven names was checked against the shipped implementation before this post went out, not copied from the design doc. A human approves swaps and watches a live graph; the governor, once an admin grants it the autonomy level, drives the same controls itself. Same code path, different caller — the only difference is an identity check and a per-loop grant.

The metric that actually matters

Not tokens spent. Not tasks attempted. Cost per accepted change. A loop whose accepted-change rate is below 50% is doing review work the loop was supposed to remove. We surface cost-per-accepted-change as the headline metric on every running loop, with a live budget burn-down beside it — because a loop you cannot measure is a loop you cannot sell, and a loop you cannot sell is a loop you should not trust to run unattended.

Results, and the honest limit

We dogfood this. The design and first WebUI slice of the loop surface — the catalog, the create wizard with the four-condition gate, and a live observe graph — landed as an 11-file, ~2,200-line pull request built by the governor when a builder agent stalled. That is the loop doing its own job: when the operand is not producing, the governor swaps in something that will.

The honest version is the same one Osmani tells: most teams do not need a loop yet — not until the task repeats, verification is automated, the budget absorbs the waste, and the agent has senior-engineer tools. We built the gate first for exactly that reason.

Key takeaways

• Loop engineering moved the leverage from prompting to designing the loop that prompts. We moved it again — from one developer's session to the whole organization.
• The maker must never grade its own homework. That is established in The FOVEA Loop; what is new here is a checker whose scope is the org chart.
• Gate every loop on four conditions before it runs; measure it by cost-per-accepted-change after.
• The product is the control surface, not any single pattern — run any agentic loop as a managed, observable, budgeted object at any scale.