The Loop and Goal Workflow: How Long-Running AI Work Actually Finishes

The most important change in coding agents is not that they can write more code in one turn. It is that they can keep working after the first plausible answer.

That sounds like a small difference. It is not.

A normal prompt creates a turn: inspect something, make a change, report back. A long-running workflow creates a loop: inspect the current state, choose the next useful action, execute it, read the result, update the plan, and continue until the work satisfies a stopping condition.

The loop gives an agent persistence. The goal gives that persistence a direction and an end.

Without the loop, a goal is only an aspiration. Without the goal, a loop is only motion.

Codex now exposes that pairing directly through Goal mode. In the ChatGPT desktop app, Codex CLI, or IDE extension, /goal attaches a persistent objective to the active chat and allows Codex to continue working toward it. You can steer, pause, resume, edit, or clear the goal while the work is running.

The feature is useful, but the deeper idea matters more than the command. The goal is becoming a control contract for agent work.

This article reflects the documented Goal mode workflow available on July 20, 2026. Product surfaces and controls may continue to evolve.

The Loop Is the Runtime

Every capable coding agent already works in a small loop, even when the interface hides it.

It reads the request. It inspects files. It forms a hypothesis. It edits something. It runs a command. The command returns new evidence, so the agent revises its understanding and decides what to do next.

In a short task, that loop may fit inside one response. Long-running work makes the loop explicit because the first pass is rarely enough. A migration may compile but fail at runtime. A refactor may pass unit tests but break the production build. A research task may uncover a source that changes the original premise. Each result becomes input to the next cycle.

The durable pattern is:

1. Observe the current state.
2. Choose the next action that reduces uncertainty or moves the work forward.
3. Act within the available tools and permissions.
4. Verify what changed.
5. Compare the evidence with the goal.
6. Continue, recover, ask for a decision, or stop.

The fifth step is where the workflow becomes more than autonomous activity. The agent needs something concrete to compare against. Otherwise, it can confuse effort with progress and progress with completion.

That comparison target is the goal.

A Goal Is More Than a Long Prompt

The Codex documentation recommends putting three things into a goal: the outcome, the constraints, and the verification criteria.

Those three parts answer different questions.

The outcome says what should exist when the work is finished. The constraints define the boundaries the agent must respect while getting there. Verification explains what evidence is strong enough to declare success.

Consider this weak goal:

Improve the checkout flow.

It names a direction, but it does not define an end. The agent could change the copy, reorganize components, rewrite the state layer, or run forever looking for one more improvement.

A stronger goal looks like this:

Remove the checkout page's duplicate submission bug without changing the
payment provider contract. Add a regression test for rapid repeated clicks,
keep the existing analytics events intact, and make the unit tests and
production build pass.

Now the loop has something to steer by. It can inspect the submission path, reproduce the defect, make a bounded change, run the regression test, confirm the analytics calls, build the application, and stop when the evidence matches the objective.

The difference is not prompt polish. It is controllability.

Goal Mode Changes the Stopping Rule

Most chat interactions stop for an interface reason: the model produced an answer. That is a weak stopping rule for real engineering work.

Goal-driven work stops for an operational reason: the completion criteria are satisfied, the task is genuinely blocked, or the human changes the objective.

That distinction prevents one of the most common agent failures—the polished early exit. The agent makes a credible edit, runs one convenient check, and presents the result as finished. The response sounds complete even though the system state is not.

In a well-formed goal workflow, a completed edit is not the finish line. It is an intermediate state. The loop asks what evidence is still missing and keeps going.

This also changes planning. A plan is a proposed route through the work. A goal is the destination and the test for arrival. The route can change when the repository surprises you; the completion criteria should remain stable unless the user deliberately edits them.

That is why /plan and /goal work well together. When the desired outcome is still vague, start by planning and clarifying constraints. Once the result can be expressed as measurable success criteria, turn it into a goal. Planning reduces ambiguity before execution. Goal mode preserves the objective during execution.

The User Still Owns the Mission

Automatic continuation does not mean surrendering control.

The current workflow keeps the goal attached to one chat. Follow-up messages can add context or adjust constraints. The goal can be paused when the workspace will be unavailable, edited when the mission changes, resumed when work should continue, or cleared when it no longer applies. In the CLI, /goal shows the active goal, while /goal edit, /goal pause, /goal resume, and /goal clear manage it.

This is a better interaction model than either extreme. The user does not need to approve every harmless inspection or ask the agent to continue after each test. But the agent also does not get to silently redefine the job.

The most useful steering messages change one of four things:

• new evidence the agent could not discover on its own
• a constraint that was missing from the original goal
• a priority decision between two legitimate paths
• an explicit scope change

Status questions are different. They should reveal the current state without replacing the mission. A good status recap says what has been established, what changed, what verification has passed, what remains, and whether a decision is needed.

Persistence Does Not Mean Permission

Long-running agents can feel more powerful simply because they act for longer. That feeling can blur an important boundary: persistence is not authority.

According to the Goal mode documentation, starting a goal does not broaden the sandbox or approval policy. The agent still operates with the same file access, network rules, and escalation requirements. It pauses when it reaches a decision or action that needs approval.

That is the right design. A goal should make the existing permissions durable across a longer workflow, not quietly expand them.

This matters most when the goal contains a terminal condition such as “deploy the service” or “publish the release.” The agent may be able to prepare the artifacts, run local checks, and produce a release plan without being authorized to change production. The correct loop reaches the approval boundary, reports the verified state, and waits. It does not treat persistence as consent.

Verification Is the Exit Ramp

An agent loop without strong verification has two bad endings. It either stops too early because the output looks plausible, or it keeps circling because nothing can prove the task is done.

The remedy is to design the exit before starting the engine.

For code, verification may include a targeted regression test, the relevant test suite, type checking, linting, a production build, and a review of the final diff. For a visual change, it may require a rendered preview at multiple viewport sizes. For research, it may require primary sources, reconciled dates, and explicit separation between facts and inference. For content, it may require frontmatter validation, link checks, image availability, and a successful site build.

Not every task needs every check. Verification should be proportional to the risk and should test the claim the goal actually makes.

“Tests pass” is not enough when the goal says the page should look correct. “The page looks correct” is not enough when the goal says the migration preserves the API contract. The evidence has to match the promise.

This is why a good loop often alternates between progress and proof. It does not save all verification for the end. Early checks expose false assumptions while the change is still cheap to redirect.

Failure Modes of the Goal Workflow

Goal mode does not rescue a badly framed task. It can make the failure run longer.

The first failure mode is an activity goal: “keep improving the codebase,” “research AI,” or “clean up the app.” There is no stable finish condition, so the agent has to invent one or continue until time, context, or patience runs out.

The second is hidden scope. A goal that says “upgrade the application” may conceal decisions about supported runtimes, dependency boundaries, data migrations, or UI changes. The loop will eventually hit those decisions. They should be surfaced before broad edits begin.

The third is unverifiable success. “Make it better” asks the agent to judge its own taste. “Reduce the median response time below 200 ms under this benchmark” gives it evidence.

The fourth is premature completion. This is the familiar case where the implementation exists but the proof does not. A trustworthy agent should treat missing verification as remaining work, not as a footnote.

The fifth is completion theater: repeatedly rewriting plans, narrating progress, or running low-value checks without reducing uncertainty. A loop should produce state changes or evidence. If it does neither, it is idling with excellent prose.

One Goal per Coherent Workstream

Codex keeps each goal with its own chat context. That makes the chat a natural unit of ownership for long-running work.

Related steps belong together because each cycle depends on the evidence produced by the last one. Independent tasks can run in separate chats, but parallelism needs a filesystem boundary. The official guidance recommends separate Git worktrees when multiple coding chats run at the same time, so two agents do not compete over the same checkout.

This gives us a useful rule: one goal should own one coherent workstream and one integration path.

If two tasks can finish independently, split them. If they must repeatedly coordinate over the same files and acceptance criteria, keep them in one goal or create an explicit integration owner. Parallel loops are only faster when their collisions cost less than the time they save.

A Practical Goal Workflow

For substantial work, I would use the following rhythm.

First, inspect before committing to a route. Learn the repository conventions, current state, available tools, and obvious constraints.

Second, write the goal as outcome, constraints, and verification. If any of those are still unknown, use a planning conversation to resolve them.

Third, start the goal and let the loop build evidence incrementally. The agent should keep a live sense of what is complete, what remains, and what has invalidated the original plan.

Fourth, steer with facts and decisions rather than micromanaging every action. Pause when external access will disappear or when a consequential choice should not be made autonomously.

Fifth, require an honest terminal report. It should state what changed, which verification ran, what passed, what did not run, and whether any risk or follow-up remains.

The final report matters because “done” is not a feeling. It is a claim about the state of the work.

The Real Shift Is From Turns to Outcomes

The loop and goal workflow changes the unit of interaction.

In chat, the unit is the response. In agent work, the unit should be the verified outcome.

That does not mean every request should become a goal. Small, reversible tasks are often better handled in a normal turn. Goal mode earns its keep when the work has several dependent steps, when failures create useful new evidence, when verification may send the agent back into implementation, or when the task needs to survive more than one burst of attention.

The strongest agent is not the one that runs the longest. It is the one that can keep moving without losing the mission, recognize when the evidence is insufficient, stop at real authority boundaries, and finish when the promised result is actually true.

The loop supplies the patience. The goal supplies the judgment.