한 줄 프롬프트가 Agent Turn이 되기까지

Key takeaways

• The Enter input is not a model call but a turn scheduling event.
• The submit boundary branches to empty input, exit command, local command, queued input, and model query.
• If you don't decide how to handle new input when there is a turn in progress, the runtime state can easily be broken.
• Direct input and queued input must be normalized to the same internal type.

The topic of this article is the Enter key. To exaggerate a bit, the stability of a product-type AI agent begins with how the Enter key is interpreted.

For the user, all it means is “I typed the prompt and pressed Enter.” However, from the runtime perspective, this event should not be a direct model API call. First, we need to decide whether this input is an empty input, a termination command, a local command, a queue item to be appended to an ongoing turn, or a new model query.

This boundary will be called submit boundary here.

1. Why submit boundary is needed

Suppose the model stream is still in progress and the user enters a new prompt. By sending this input directly to a new model call, two loops can simultaneously modify the same message history and screen state.

The results are usually not good.

• The second response is mixed in between the first model response.
• The tool request/result order is broken.
• It becomes unclear which turn the user-approved task belongs to.
• The transcript is stored in an unrecoverable order.

Therefore, the submit boundary is a gate that determines “Can it be executed now?”

2. Atomicity in one turn

In agent, turn is not just a simple user message. The turn includes input normalization, model stream, tool request, permission decision, tool result, final assistant message, and cost history.

1# How to read: The items below are summarized examples to quickly check the action flow.2raw prompt3→ normalized turn4→ model stream5→ tool request6→ permission decision7→ tool result8→ model continuation9→ final answer10→ ledger flush

If a new turn modifies the same state before this flow completes, atomicity is broken. So the submit boundary should have states likeidle,dispatching,running, andfinishing.

3. Input branching rules

At the submit boundary, the input roughly branches to one of the following:

If you don't make this branch clear, your command and prompt will get mixed up. In particular, sending a slash-style command as a normal prompt or, conversely, misinterpreting a normal prompt as a local command breaks the user experience.

4. Guard and queue design

The most important thing in submit boundary is guard. A guard protects “whether the current runtime can start a new turn.”

Another important thing is queue. If a new input is unconditionally discarded when there is a turn in progress, usability is bad, and if it is executed immediately, the state will be broken. Therefore, a queue is needed.

5. Submission flow through concept code

The code below is not the original implementation, but newly written code for explanation purposes.

1# How to read: Conceptual code that describes runtime boundaries, not a clone of the actual implementation.2class ExecutionGuard:3    # Initializes runtime dependencies and state storage that the object will reference in later steps.4    def __init__(self):5        self.state = "idle"6        self.owner = None7 8    # Checks if the current turn can take execution and locks it into the dispatching state.9    def reserve(self, turn_id):10        if self.state != "idle":11            return False12        self.state = "dispatching"13        self.owner = turn_id14        return True15 16    # Converts the turn that is ready for input to the actual running state.17    def mark_running(self):18        self.state = "running"19 20    # When the turn with execution rights ends, the guard returns to the idle state.21    def release(self, turn_id):22        if self.owner == turn_id:23            self.state = "idle"24            self.owner = None25 26# Branches raw input to one of ignore, interrupt, local action, or model turn.27async def submit_input(raw_entry, runtime):28    draft = TurnDraft.from_raw(raw_entry)29    route = classify_submission(draft, runtime)30 31    if route.kind == "ignore":32        return33 34    if route.kind == "interrupt":35        runtime.abort_current_turn(route.reason)36        return37 38    if route.kind == "local_action":39        await runtime.local_actions.run(route.action)40        return41 42    if runtime.guard.state != "idle":43        runtime.pending_turns.append(draft)44        runtime.shell.notice("Executes after the current turn ends.")45        return46 47    if not runtime.guard.reserve(draft.turn_id):48        runtime.pending_turns.append(draft)49        return50 51    try:52        runtime.guard.mark_running()53        prepared = await runtime.input_pipeline.prepare(draft)54        await runtime.agent_loop.run(prepared)55    finally:56        runtime.guard.release(draft.turn_id)57        await drain_pending_turns(runtime)

The important part here is thatreserve()is called before input normalization. This is because the normalization process itself can be asynchronous. If another input is received in the meantime, both turns can start simultaneously.

6. AI utilization developer perspective

Developers using AI coding agents must check what policy the tool uses when new input is entered.

In particular, attachments and editor selections must be left as snapshots at the time of queue. If the file state at the time of execution is re-read, it may differ from the user's intended context.

7. Agent developer perspective

When creating an agent, problems quickly arise if direct input and queued input are handled through different code paths. The first prompt you enter will process the attachment, the queued prompt will lose the attachment, and so on.

Therefore, it is recommended to convert both toTurnDraftand then make them pass through the sameexecute_turn().

1# How to read: Conceptual code that describes runtime boundaries, not a clone of the actual implementation.2def to_turn_draft(text, source, attachments=None, mode="chat"):3    return TurnDraft(4        id=new_id(),5        text=text,6        source=source,7        attachments=list(attachments or []),8        mode=mode,9        captured_at=now(),10    )

Additionally, you must distinguish between the context scope of the first input and subsequent queued input. Context pollution can occur if you blindly attach rich context, such as editor selections, current diffs, or temporary attachments, to all queued inputs.

8. Practical checklist

1# How to read: The items below are summarized examples to quickly check the action flow.2Submit Boundary Checklist3 4[ ] Enter input does not immediately lead to a model API call.5[ ] Input branches to local action, interrupt, queue, and model query.6[ ] When there is an active turn, the new input processing policy is clear.7[ ] Direct input and queued input use the same TurnDraft type.8[ ] guard reservation occurs before asynchronous normalization.9[ ] Attachments and editor context are preserved as snapshots when needed.10[ ] There is logic to drain the pending queue after the turn ends.

Failure case: When Enter immediately makes a model call

Without a submit boundary, even the simplest input window can create complex bugs. Let's say the user sends the first prompt and enters a second prompt while the model response is being streamed. If the runtime connects Enter directly tocreateModelCall(), two calls read and write the same history at the same time. The second call starts before the tool result of the first call has come in, the two responses are mixed on the screen, and the cancel button doesn't know which call to stop.

This problem may not be visible in testing. This is because happy paths that are entered only one at a time will pass. Actual users do not wait and add additional comments, cancel incorrectly sent prompts, or enter local commands such as/status. Submit boundary does not consider all of these inputs as the same event, but branches to an action that matches the current runtime state.

Implementation example: submit decision table

This table is not a UI document but a runtime contract. The input window, command parser, and model loop must share the same decision. In particular, local commands should not enter the model context, and queued prompts should only have the necessary context snapshots. Otherwise, when the user says, “Continue based on the code I selected earlier,” there will be a problem of reading the editor selection that has already changed.

Checklist application results

When reviewing submission boundaries, we check three things: First, see if we schedule an active turn guard before input normalization. Second, check whether the queued input passes the sameTurnDrafttype as the direct input. Third, check that cancel and local commands do not pollute the model message history. If these three things are correct, the agent will not lose its order even if the number of inputs increases.

finish

The Submit boundary may seem small, but it is the central boundary of the agent runtime. With this layer, input, command, queue, cancel, and model loop will not conflict with each other.

In the next article, we will see how raw input that passes the submit boundary is converted into a model-visible message. This process is input normalization.