AI Agents Need Breakpoints

Earlier today, I had a Codex queue filled with small annotation requests. Behind them sat a much larger instruction: build an OCR system.

I wanted the annotations to finish first. The result might show that OCR was the wrong abstraction, that only a narrow set of cases needed it, or that an evaluation should come before implementation. I added another queued message:

“Stop after completing the previous task. Do not continue until I explicitly tell you to proceed.”

Codex processed the message and continued to the OCR request.

My first reaction was that the agent had ignored a clear instruction. On closer inspection, that is probably the wrong description of what happened. The stop message was itself a queued turn. Once that turn completed, the system still had another turn ready to start.

The scheduler started the next turn

Codex documents Steer as input to the current run and Queue as a message saved for the next run. Pending messages can be edited, reordered, sent, or deleted. The documentation does not describe a durable pause between them.

That product model explains the behavior without requiring the model to disobey anything. The model receives one turn at a time. A scheduler or client decides when the next turn begins. Text inside one turn cannot reliably bind the component operating outside it.

I cannot see enough of the internal dispatch path to name the exact component that advanced my queue. I do not need to. The interface let me queue an executable message, not create a state that the runtime had to preserve. The sentence said “stop,” but the queue had no non-executable representation of that boundary.

My first draft made too much of this distinction. I had delegated the annotation work, but not the decision to begin OCR implementation. The queue preserved the order of my requests and lost that one important qualification.

I noticed the same limitation in the settings around pending work. I could not mark one queued request to begin in plan mode, assign another request to a different model, or give a later task a different reasoning effort. Those may be interface limitations rather than limits of the underlying Codex runtime. Either way, the pending item carried the prompt but not the full execution contract I had in mind.

The missing primitive is an approval gate

The control I wanted already has familiar names elsewhere: an interrupt, approval gate, callback, or human-in-the-loop transition. OpenAI’s Agents SDK can surface a tool call as an interruption, serialize the run state, and resume only after approval or rejection. LangGraph interrupts persist graph state and wait for external input. GitHub Actions environments can hold a downstream job behind a protection rule.

Those examples changed the claim I wanted to make. Agent frameworks and workflow engines already know how to stop. What was missing in the conversational queue I used was a gate on the transition between two executable turns.

For this use case, I would keep “breakpoint” as the user-facing metaphor and use more precise terms underneath it. The gate is the authority boundary. The checkpoint is the persisted state saved there.

The intended flow was simple:

Annotate → Summarize → [AWAITING APPROVAL] → Implement OCR

The approval state belongs on the edge between two turns, not as another turn in the queue. When the summary completes, the scheduler should record awaiting_approval and refrain from creating a start event for the OCR turn. The interface can show the completed artifacts and the next pending request. I can then continue, cancel, rewrite the prompt, or change the next turn’s model, mode, effort, and permissions. A release event—not another interpretation by the model—makes the OCR turn eligible to start.

The Codex app-server suggests a fairly contained implementation path. It treats threads and turns as explicit primitives. A client begins work with turn/start, and that call can override settings such as the model, working directory, and sandbox policy. From that interface, I infer that a client-side gate could hold the next call rather than requiring a change to the agent loop itself.

The reliability test is equally concrete. There should be no turn/start for the downstream request before a recorded release event, and the waiting state should survive a reconnect, restart, or retry. If the user changes the next turn while waiting, the system should start the revised version rather than the stale one.

A gate between turns is not enough

There is an important limit to this design. Preventing the OCR turn from starting does not guarantee that the annotation turn will stay inside its intended phase.

The current turn may already have permission to edit the repository. If Codex decides that writing OCR code would help it finish the annotations, it could cross the boundary before the scheduler ever reaches the gate. The prompt can describe the scope, but the same filesystem and tool permissions may cover both analysis and implementation.

For consequential work, I would add a second control around the active turn. I think of it as a capability envelope: the writable paths, tools, network access, side effects, cost, or run time available during this phase. Codex already uses sandbox and approval policies at the operating-system and tool boundary. The same idea could keep an analysis phase from quietly becoming an implementation phase.

The scheduler gate would hold the next turn. The capability envelope would limit the current one. Either control would help on its own; together, they would make “analyze, then return to me” something the product can guarantee.

I would not put a gate after every task. Most queued work is ordinary follow-up work, and forcing approval between every turn would remove much of the value of an agent. The useful boundary is where the evidence from the current task can change the instruction, permissions, cost, or risk of the next one. The user should place that boundary explicitly; the agent can recommend one, but the interface should make clear whether the runtime is actually waiting.

For now, I am changing how I use the queue. I will queue the annotations and the summary, but not the OCR implementation. After I read the result, I can continue in the same thread or start a separate implementation task with the settings it needs. If the annotation result could change whether OCR should exist, OCR does not belong in the queue yet. That is less convenient than the workflow I wanted, but it is the only boundary I can enforce from the interface today.

---

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.