READY is not LIVE: the stages a loop must name
Coverage, readiness alerts, and public proof are different jobs. A green scorecard that confuses them will celebrate the wrong win.
Get the field notesContents
Most agent loops fail the same way twice: first in production, then in how the team reports on them.
The first failure is operational. Gartner still expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, driven by cost, unclear value, and weak risk controls, not by a shortage of model demos.
The second failure is quieter. A team builds a monitor that turns green, posts an alert that something is "ready," merges a change, and talks as if the customer already saw it. Those are three different claims. When one number stands in for all three, the loop looks healthy while nothing reliable has shipped.
#Three jobs that keep getting merged into one
Loop engineering is the discipline of making recurring agent work trustworthy. That work only holds if you keep the stages separate.
Measure. The loop reads state outside the chat: a scorecard, a queue, a ticket, a deploy SHA. Measure answers "what is true right now," not "what should we write," and not "what the public can open."
Ready. The loop decides that a human (or a later stage) should act. Ready is an alert: a thin cluster, a stalled queue, a verifier that failed. Ready is not a receipt that the action happened.
Live. The loop proves the public outcome: HTTP 200 on the real URL, the title you expected, the deploy you meant. Merged is not live. A green build is not live. A chat saying "done" is not live.
#Coverage is structure, not novelty
This shows up hard in content and product loops that use a scorecard.
A cluster can be "covered" because a landing page and a post both exist. That is a real engineering fact. It is not the same fact as "we published a new article today." Closing a thin score by adding a landing under a months-old post is honest work. Calling it a content ship is not.
The same pattern appears in ops loops. A job can be "covered" because a cron exists and last-run is recent. That is not the same as "the customer received the message," "the invoice is correct," or "the page is on the public site."
Name the metric for what it is:
| Claim | What it proves | What it does not prove |
|---|---|---|
| Covered / green scorecard | Structure exists | That anything new was shipped |
| Ready alert | Someone should act | That they acted |
| Live verify | Public surface matches intent | That the business outcome is good |
#Build the stages as different code paths
In practice, EP treats these as separate stages so they cannot launder each other.
- A monitor may post a READY alert when backlog pressure is real. It does not write marketing copy, open a PR, or merge.
- A craft path writes the change in a real repo and opens a PR. It does not claim the public site updated.
- A live path curls the public URL after deploy, then posts LIVE only when the check can fail.
Watchtower (or whatever your alert surface is) should carry both READY and LIVE as different messages. Operators who only ever hear READY will keep asking where the ship is. Operators who only hear LIVE will miss the queue.
The transport detail does not matter as much as the contract: every stage leaves a receipt, and no stage is allowed to speak for the next one.
#The four questions, sharpened for stage confusion
We already ask whether a loop has external state, an independent verifier, gates on expensive calls, and a receipt trail. Add one more filter before you trust the dashboard:
- When this loop says green, which stage did it actually complete?
- Could that green have passed while the public surface still 404s?
- Could READY fire forever while craft never runs?
- Could merge succeed while LIVE never posts?
A loop that cannot answer those questions is not "almost production." It is a demo with a better status page.
#What to do Monday
- Split your loop vocabulary into measure, ready, and live. Put the words in the receipt, not only in the design doc.
- Make LIVE a separate job that can fail closed: public URL, expected title, deploy SHA if you have it.
- Stop using coverage as a proxy for novelty when the business cares about new work shipping.
- Keep the model out of the stage that only needs curl and a timestamp. Deterministic proof is cheaper and harder to romanticize.
Loop engineering is still the reliability problem, not the intelligence problem. The upgrade is to stop letting one green light stand for three different truths.
See how EP approaches loop engineering as an operating discipline.
#Sources
- Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, June 25, 2025: https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
Get the field notes.
One useful note on AI operations, no hype. A weekly roundup, and we skip any week without something worth sending.
Double opt-in. Unsubscribe any time. Read our privacy notice.
Keep reading
- · 5 min
Loop engineering is a reliability problem, not an intelligence one
Agent loops are not failing because the models are weak. They are failing because nobody built the state, verifiers, gates, and receipts around them.
- · 4 min
Operating an autonomous company is an ops problem, not a magic agent
Autonomy fails when teams add agents without state, gates, verifiers, and receipts. Here is the operating shape that keeps a company in control.
- · 6 min
A running terminal is not a receipt
We wired inbound messages to coding agents by typing into a terminal. It worked immediately, which was the problem. Here's the transport architecture that replaced it, and the three receipts that never imply each other.