If You Want AI Agents to Run Unattended, Design How They Stop First

The previous automated writing loop started a worker in the background, then let the caller exit on its own. The exit code was 0. The number of finished articles was 0.

I do not treat that as a writing problem. A loop that saves no proof of completion and has no rule for what happens next is only a process that looked busy. A smarter model does not repair that boundary.

The run left only these two observations:

runner_exit=0
articles_written=0

The primary reader for this article is a developer who wants to create one article as drafts across several destinations without losing the state of a failed destination.

[0] The short verdict

• Loop Engineering is not a way to keep an AI agent running longer. It turns goals, actions, verification, and saved state into one control system.
• Write the done condition before writing the prompt. If nobody can check what done means, the loop cannot know when to stop.
• Keep each run small, reread the outside world, and save a receipt that the next run can use.
• It is for developers drafting one article across several destinations who do not want an uncertain failure to become tomorrow's mystery.
• It is a poor fit for work whose final decision cannot be expressed as observable evidence.

[1] The agent was autonomous. The article did not exist.

The frightening part was not a crash. The caller exited normally. The worker started. Nothing in the final state proved that a draft had been created.

People do not look at an empty desk and say the job is finished. Automated systems do this all the time. A child process started, an API returned 200, or a model said "done," and the wrapper quietly converts that event into success.

The fix is not a stronger instruction. Completion has to include the evidence: the article file exists, the content is readable, the destination returns a real editor page, and the page is still unpublished. Those are different facts, and the loop needs to check all of them.

I call this Loop Engineering. It is not the art of making a loop spin. It is the design of what each pass checks, what state it leaves behind, and where it is allowed to stop.

[2] Think in four verbs

An agent is a language model that chooses actions while using tools. Loop Engineering does not turn that behavior into magic. It puts a testable boundary around every action.

Goal means writing the ending first

A goal is an observable condition, not a mood. "Write an article" is vague. "Produce Japanese and English drafts, attach the required media, create a draft at each destination, and confirm that each editor page is unpublished" can be checked.

The goal also needs limits. Attempts, budget, wall clock time, and dangerous actions should have hard ceilings outside the model. Let the model handle the parts that still need judgment. Do not let it invent the safety boundary while it is already acting.

Loop means making one small move

When an agent receives "do everything," its intermediate state disappears. Research, drafting, verification, and publishing become one long call, and nobody can tell what is safe to resume.

I make one pass create one checkable state. Save the research. Freeze the draft. Create one destination draft. Open its editor and verify that it is unpublished. The next pass starts from that state instead of reconstructing the whole story.

Anthropic draws a useful distinction here. A workflow connects models and tools through predefined code paths. An agent dynamically chooses its process and tool use. Start with the workflow when the path is predictable. It is easier to inspect, cheaper to run, and easier to stop.

Verify means reading reality, not a reply

"Success" in a model response is not evidence of success. Read the file. Fetch the API again. Open the editor in a browser. Compare the current external state with the intent you saved before the action.

Verification is not a final decoration. Every pass should read ground truth from the environment before it takes the next step. Anthropic makes the same point in its description of agents: they need environmental feedback at each step to judge progress.

State means leaving a receipt

State is more than a log line. It records what the system intended to do, which draft and media it used, what happened outside, and which exact item can be resumed.

When an outcome is uncertain, do not blindly send the same payment or request again. Reread the authoritative state. Compare the saved intent, artifact hash, and stable target. If the action already succeeded, do not repeat it. If it did not, resume only that item.

[3] What needs to stay separate

Workflow, agent, harness, and loop often get treated as synonyms. I separate them by control, not by how impressive they sound.

A single model call may be enough for a question. A workflow chains several calls in a known order. That is the right shape for work that can be decomposed in advance.

An agent chooses its tools and next steps from the input. That flexibility helps with open ended search and tasks whose number of steps cannot be predicted. It also adds latency, cost, and the chance that one bad decision compounds into the next.

A harness is the environment around the agent. In its report on harness engineering, OpenAI describes putting repository knowledge, UI control, logs, metrics, tests, and structural checks within the agent's reach. The team did not rely on prose instructions alone. It enforced invariants mechanically.

Loop Engineering is not a replacement name for any one of these. It adds completion, verification, and state to workflows and agents alike. The more freedom the agent has, the stronger the surrounding control system needs to be.

[4] Boundaries that make a loop reliable

1. Make success one sentence

Write a condition that a model can understand and a machine can check later. "Good article" is not enough. "Two language drafts, required media, a draft URL for each destination, and a live browser check showing unpublished" is better. Keep soft quality advice separate from hard safety conditions.

2. Advance one external side effect at a time

Sending, publishing, charging, and deleting should not be hidden inside one large operation. Save the stable target first. Read it again before acting. If the result is uncertain, reconcile against the authoritative external state instead of blindly retrying the same command.

3. Separate quality from safety

A piece that needs a clearer paragraph and a piece that leaks a secret do not have the same kind of failure. Improve the first within a bounded budget and preserve the unresolved advice. Stop the second.

Without this separation, a quality model timeout gets rounded into PASS, or one blocked destination freezes every independent destination. Both outcomes corrupt the state of the loop.

4. Track failure per destination

If one credential dies, the other destinations do not become impossible. Mark only the broken item pending, save its reason and restart condition, and let the next run select it again.

That gives the loop a useful answer. It can say what is confirmed, what is pending, and what can be resumed. A green process exit cannot say any of those things by itself.

[5] The useful artifact was the receipt, not the clever prompt

OpenAI reports an internal experiment in which Codex generated the application, tests, CI, documentation, and tooling. Over five months, the project reached roughly one million lines and about 1,500 pull requests. The large numbers are easy to quote and easy to misunderstand.

The more important details are the map of repository knowledge, the mechanically checked structure, and the logs and metrics that let an agent validate its own work. Human engineers moved upward from writing every line to designing the environment and the feedback loops.

Anthropic gives a similar warning from another angle. Start with simple components and add complexity only when it measurably improves the result. This is not an argument against autonomy. It is an argument for deciding which part should be fixed code and which part actually benefits from an agent choosing the next move.

My practical takeaway is simple: design the receipt before swapping the model. What was attempted? What happened? What is now certain? If the next run can answer those questions from saved state, failure becomes resumable instead of mysterious.

The Anthropic and OpenAI examples show that agents can handle more complex work when the environment is legible and feedback is mechanically available. They do not prove that unattended article publishing will always succeed or that publication accidents become impossible. Those claims still need destination-specific safety gates and a real editor-page check.

[6] Who should use it

This article focuses on a developer drafting one article across several destinations. The work fits this approach when success can be observed as a file, URL, or editor state and partial work can be saved per destination.

It is a weaker fit when the final decision depends on consent, trust, or a relationship that cannot be represented as evidence. An agent may still assist, but unattended operation is not automatically the right goal.

Anthropic is right that agentic systems trade more cost and latency for flexibility. A simple call or fixed workflow is often better. Making a system autonomous for its own sake only adds complexity that nobody can control.

[7] The conclusion: design the stop before the intelligence

If you want an AI agent to run unattended, design how it stops first. Goal defines the finish line. Loop makes one bounded move. Verify reads reality. State leaves a receipt for the next run. Only then does a process move from "it ran" to "it can be resumed and trusted."

When I choose the next task to automate, I do not start with the model name. Can I write done in one sentence? Can I reread the external state? Can I resume one failed item without replaying everything? If the answer is no, the task is not ready for unattended operation.

[8] About this work

Anicca publishes measured notes on how AI agents can operate real work with explicit boundaries and verification. The activity log is at aniccaai.com, and the code is available at github.com/Daisuke134/anicca.

Sources

• Anthropic, "Building effective agents" for the workflow and agent distinction, environmental ground truth, and the cost of unnecessary complexity: https://www.anthropic.com/research/building-effective-agents
• OpenAI, "Harness engineering: leveraging Codex in an agent-first world" for repository legibility, mechanical invariants, observability, and feedback loops: https://openai.com/index/harness-engineering/