What 1.06B Tokens Taught Us About Agent Stop Rules

#The Question

Why did it take us 85 sprints to test one feature?

That is the uncomfortable question Hadi asked after watching the S085-S172 operator-action lane consume roughly 1.06B Codex tokens.

The short answer: because the system kept rewarding continuation after the proof shape had stabilized.

The longer answer matters more. We were not doing random work. We were hardening an authenticated operator-action path for com-mumega. Each sprint added one internal-only dashboard action, proved it through the browser, checked tenant isolation, wrote a receipt, and reported back through Loom.

At first, that was exactly the right move.

Later, it became a loop.

#What We Actually Proved

The repeated proof family covered one operator surface and one API route:

Across the completed run, the proof invariant was consistent:

1. A signed com-mumega member can load the dashboard.
2. Anonymous dashboard access is denied.
3. Cross-tenant dashboard access is denied.
4. The intended internal-only operator action appears.
5. The browser sends the action to /api/dashboard/operator-actions.
6. The browser uses the signed cookie and does not place a session token in the body.
7. The API accepts the signed com-mumega member action.
8. The API denies anonymous and cross-tenant attempts.
9. The receipt persists.
10. The dashboard readback survives reload.
11. No external action, paid work, customer-visible delivery, tenant bypass, or secret exposure occurs.

That invariant is valuable. It is the kind of thing a tenant operating layer needs before real customers, budgets, workflows, and live dispatch enter the system.

#The Data

The final closeout inventory says:

The receipt count is impressive. It is also the warning sign.

If a system produces 87 receipts for the same route pair and the same invariant, the question is no longer “can it prove the next action?”

The question becomes:

Why are we still adding one more action by hand?

#Where The Work Was Useful

The early lane was worth doing.

We needed to know whether a real operator surface could:

• enforce tenant scope
• reject anonymous users
• reject cross-tenant users
• avoid session-token leakage in the request body
• persist internal receipts
• keep proof readback visible after reload

Those are not cosmetic checks. They are the base mechanics of a secure tenant dashboard.

S085-S101 established the basic dashboard and bridge-start shape. S102-S128 extended the live-source acknowledgement path. S129-S150 repeated it through post-rollout states. S151-S171 repeated it again through post-rollout post-rollout states.

The first band clarified the system.

The second band hardened confidence.

The third band should have triggered consolidation much earlier.

#Where The Loop Became Waste

By the time the proof shape had repeated several times, the next sprint could be generated mostly by string substitution:

readiness_bridge_live_source_X_review_ack
data-send-bridge-live-source-X-review-action
mumega_sNNN_bridge_live_source_X_review_receipt
renderBridgeLiveSourceXReviewReceipt(...)

That is the moment an autonomous system should stop expanding.

Not because the work is wrong, but because the product truth has stopped changing.

The proof was saying the same thing:

• same dashboard
• same API route
• same cookie carrier
• same denial rules
• same internal receipt
• same reload readback
• same non-live boundary

Only the label changed.

More formally, a lane must stop when all of these are true:

At that point the next sprint should be a consolidation sprint.

Not “keep going.”

Not “one more.”

Consolidate.

#What We Changed

We stopped S172 before proof.

That matters. It means the system finally treated “unproved” honestly:

• S085-S171 are receipt-backed.
• S172 has no receipt.
• S172 is not exposed.
• The partial S172 dashboard/API/script/brief surface was removed.
• The family was closed as a repeated proof family.

We then wrote three operator artifacts:

The final recommendation is not another adjacent acknowledgement.

It is S172-manifest-consolidation.

#The Next Architecture

The current implementation proved the invariant, but it should not remain hand-expanded forever.

The next shape should be:

graph TD
A[Typed operator-action manifest] —> B[Dashboard action groups]
A —> C[API allowlist]
A —> D[Family-level invariant proof]
D —> E[Representative browser proofs]
E —> F[Return to live readiness bridge]

The manifest should own:

• action type
• label
• receipt key
• status copy
• tenant scope
• internal-only boundary
• required role/session posture

The dashboard should render from the manifest. The API should validate from the manifest. The proof should iterate the manifest.

That is what a repeated proof family wants to become.

#The Deeper Lesson

The expensive part was not that Codex used 1.06B tokens.

The expensive part was that the system did not know when enough evidence had become structure.

Agents need persistence. They also need brakes.

Humans often under-specify the brakes because they are focused on momentum:

• keep going
• do next
• do not stop
• finish it

Those are useful commands when the system is still discovering the path. They are dangerous when the system is already walking in circles.

The operating layer needs to understand the difference.

#What We Will Do Differently

Going forward, repeated-proof lanes should carry a pattern detector:

That does not make the system slower. It makes the system more durable.

The point of autonomous work is not infinite motion. It is compounding judgment.

#The Lesson In One Sentence

We spent roughly 1.06B tokens proving an operator-action envelope, and the real product improvement was learning where the proof should have become a manifest.

That is a good lesson, as long as we encode it.