The FOVEA Loop: How We Stopped Agents Verifying Themselves

TL;DR

• The FOVEA loop focuses the system on performing better. One cycle -- attend → act → adjudicate → correct -- applied to a feature, to the organization delivering it, and to the loop itself.
• Four laws: attention does not shard · no self-verified done · a stop criterion is an artifact diffed against a known-negative, held over time · the failure mode is silence, not noise.
• On 2026-08-05 we found six defects in one day and not one was a logic bug. A full audit found 27 more unreached surfaces.
• Live measurement, 24h to 2026-08-05: 194 commits — 82 from operands, 112 from fleet agents, produced by scripts/fovea/delivery_delta.sh, with 1 open discrepancy across 6 contracts.
• The result we did not plan: devops-agent fixed the audit's top P0 without being assigned it.
• Figures in this post were measured on 5 August 2026 and each cites the command or commit that produced it.

Most writing about multi-agent systems assumes the hard part is making agents smart enough. That has not been our experience. Our agents write correct code. What they cannot reliably do is notice that a thing they built was never connected to anything -- and neither, it turns out, can the humans supervising them.

This post is the definition of record for the loop we built in response, and the parts of it that are still missing.

What is the FOVEA loop?

The FOVEA loop is a single cycle -- attend, act, adjudicate, correct -- applied recursively at three levels: to a feature being built, to the organization building it, and to the loop itself. Each pass ends by feeding a verified signal back into the next attend phase, so the system's supervision improves at the same time as its output.

The name is anatomical, not an acronym stretched to fit. The fovea is the eye's one high-acuity spot. Everything outside it is peripheral vision: low detail, excellent at detecting motion, and its job is to trigger a saccade -- a jump of focus. That division of labor is the architecture:

What are the four laws?

The four laws are the non-negotiable rules that make the cycle produce evidence rather than assertions. Each exists because we watched its absence cost us a week.

1. Attention does not shard. One operand, one deliverable, end to end. Two operands on one feature is not parallelism; it is the fragmentation the loop exists to prevent. Parallelism means many features, each held whole by one owner.

2. No self-verified done. Every claim cites an artifact a third party can check -- a sha reachable from main, an endpoint that answers. Merged is not deployed. Deployed is not serving. An agent reporting its own success is a claim, not evidence.

3. A stop criterion is an artifact diffed against a known-negative, held over time. Never status=ready. Without the control, you have proved a thing exists, not that it works. This is the law we break most often and regret most reliably.

4. The failure mode is silence, not noise. A blocked worker, a stalled supervisor and a finished one are indistinguishable from outside. Quiet is reported as a discrepancy, never as calm.

Why is the failure class silence rather than bad code?

Because the defects that hurt a multi-agent organization are seam defects, and a seam that is never connected produces no error at all. On 2026-08-05 we found six defects in a single day. Not one was a logic bug:

An adversarially-refuted audit run across 40 agents found 27 more unreached surfaces.

The arithmetic underneath is unforgiving. Components grow linearly; seams grow with components × deploy planes. A seam is a two-sided contract where only one side compiles. Miss the other side and there is no exception, no red build -- a missing file quietly becomes except FileNotFoundError: return "".

So the failure presents as silence that reads as backlog. The organization concludes the work is merely slow, re-plans, and in four observed cases built a second implementation beside the dead first one. This is the same organizational blind spot we described in the agent sprawl governance gap: the technology was never the constraint.

How does FOVEA answer it?

With three moves, only one of which scales:

The third is the endgame. Supervision costs attention per component; assertions cost nothing per component after the first.

Putting state in git has a second property we did not anticipate but now rely on: the entire organizational state is readable from a phone with no cluster access. A dashboard that is down tells you nothing. A repository does not go down.

What does the loop actually measure?

Delivery is measured by a script, not asserted in a status meeting. This is the real output from our staging org, run while writing this post:

$ scripts/fovea/delivery_delta.sh

=== delivery in the last 24h

  OPERANDS (commits on main — invisible to a branch-scoped git log)
    governor-1               44
    host-reclaimer-1         23
    provision-latency-1      3
    wiki-spaces-1            12

  FLEET (agent branches)
    origin/devops/fovea/entrypoint-configmap-resync 112

  ADJUDICATION (latest orchestrator sweep)
    - UNCITED: R-4 names no artifact sha — cannot be adjudicated
    **1 discrepancy across 6 contracts.**
    (product/fovea/results/sweeps/2026-08-05.md)

=== total 194 commits (82 operand, 112 fleet)

Read the adjudication line carefully, because it is the point. The sweep found a run record whose claim named no artifact sha. It did not fail the work, escalate to a human, or close anything. It recorded that the claim cannot be adjudicated -- which is a different and more useful statement than "the claim is wrong."

The sweep runs twice daily, adjudicates mechanically, and closes nothing. Its own footer says why it exists: "so that no unacked instruction, phantom citation, unclassified join or pending founder decision depends on somebody remembering to look."

Which readings lie?

Three readings look like good news and are not. Each cost us real time before we learned to distrust it.

Zero delivery may be blindness, not idleness. A husked operand, a stalled governor and a finished one all produce exactly nothing. On 2026-08-05 our own CEO agent reported "0 fleet commits" on a day main took 29 -- its metric counted agent branches, and operands commit straight to main. delivery_delta.sh now prints this warning itself whenever the total is zero.

An empty approvals list means nothing under gateMode: allow-all. In that mode every decision auto-resolves the moment it arrives, so the list is always empty. Empty means "nothing pending" only when the mode is gated. On 2026-08-05 this auto-approved two founder-authority decisions in the founder's name -- including one where an operand had explicitly written "I am banking it, not executing it. I want a confirmation before anything touches the live fleet." A 60-second org-doc cache meant the founder's five attempts to re-gate read back unchanged. Fixed in b7ac838fc.

A green test may be testing its own fixture. Our decision_bridge end-to-end test passed for a week against a fixture using a header form the schema forbids. The test was green and the code had never worked. A fixture that does not obey the schema tests only the fixture.

What happened that we did not plan?

devops-agent produced the fix for the audit's top P0 -- an 85-line drift between the entrypoint-fix ConfigMap and the shipped image, commit d7fabe93d -- without being assigned it. The audit landed in the repository; an agent read it and acted.

That is the loop closing on the organization rather than on a feature, and it is the strongest evidence we have that the shape is right. We built no mechanism for it. We put the finding somewhere an agent would attend to, and the attend phase did the rest.

What does this give a compliance auditor?

More evidence than we expected, and less program than we would like. Being precise about which is which matters more than the headline.

That last row is the property auditors actually probe, and it is why we treat the audit trail as a design constraint rather than a feature. A trail that contains only successes is not evidence of control. It is evidence of a filter.

The honest position: this produces unusually good SOC 2 evidence and does not yet constitute a SOC 2 program. Named plainly, because a gap named is not a finding:

• No access review. Nobody periodically re-attests who holds cluster write or the admin API key. Our audit found CI lanes authenticating to a deleted cluster -- an access question nobody had asked.
• No evidence retention policy. The harvester exists because gate evidence ages out in ~100 minutes. We lost 07-28 → 08-01 to job garbage collection before it existed.
• No formal risk assessment or incident-response timeline. Incidents are handled well ad hoc; none has a declared severity, clock, or closure rule -- which is precisely the discipline incident response in a hybrid org demands.
• Change management is strong for FOVEA work and absent elsewhere. Contract discipline covers operands. A fleet agent committing to main is subject to none of it.
• The 27 unreached surfaces are a processing-integrity finding, not a hygiene one. Capability advertised to customers that resolves to "Tool not found" is a control failure in SOC 2 terms.

The evidence chain -- instruction, ack, artifact, independent adjudication, typed human approval -- is the hard part, and it exists. The missing pieces are policy artifacts and periodic attestations. We started with the access review, as a task in the shared plane rather than a document, because the deleted-cluster finding suggests documents are not what was missing.

When would you say the loop has converged?

We define convergence so that it can be falsified:

The loop converges when the cost of adding the Nth parallel programme approaches zero, and the human input per programme approaches a small constant.

Every rung of the bootstrap must lower one of those two costs or it does not belong on the ladder:

Four limits, stated so this is not a claim of magic:

Human input does not go to zero, and should not. Credentials, production deploys, spend, security acceptance and strategy stay founder-authority. The target is a small constant per programme, not none. A system that stops asking is not efficient; it is unsupervised. Getting that handoff right is its own discipline, covered in agent-human handoff.

The binding constraint today is credentials, not intelligence. Every per-pod operand costs one founder login. Packed operands share one login twelve ways but cannot hold code -- anything with repositories or credentials routes to the per-pod path. Until that changes, "tens of parallel projects" is arithmetic that does not work, and no amount of better prompting fixes it. This is a multi-tenant orchestration problem wearing a capacity-planning costume.

Convergence is measurable or it is a slogan. Track commits per programme with no human turn; founder-minutes per shipped feature; sweep discrepancies per programme-week; and the count of surfaces asserting their own connection. If those numbers do not move, the loop is not converging, whatever it feels like from inside.

There is no human-only baseline. Our speed comparisons are against this organization's own past, not against a control group. We think the direction is real. We cannot prove the magnitude.

What we would tell someone starting this

Build the adjudicator before you build the second agent. The instinct is to add capacity first and verification later, once things settle. Things do not settle. Every agent you add without an adjudicator adds a surface that can fail silently, and silence compounds faster than throughput does.

The second thing: make the quiet path noisy. Almost every incident in our log began as something that produced no output, and every fix eventually took the same form -- ask the silence which silence it is. An agent that is done, an agent that is blocked, and an agent whose credentials expired mid-turn look identical from outside, and only one of them is fine.

The definition of record lives in our repository, with the operating rules distributed as a skill to every agent in the fleet. That distinction has been worth more than the document itself: a skill triggers, a doc waits to be remembered.

All figures verified on 5 August 2026 against the commands and commits named inline: scripts/fovea/delivery_delta.sh for delivery counts, product/fovea/results/sweeps/2026-08-05.md for adjudication, b7ac838fc for the gate fix, d7fabe93d for the unassigned P0 fix.