Designing the First Turn: What Happens Before Any Tool Call

Most attention to agent design goes to the loop — how it iterates, when it stops, what happens when a tool fails. The first turn gets treated as the moment the loop starts. It's the highest-leverage turn in the run, because everything after it inherits the frame it establishes.

Four things are worth doing before any tool is called.

1. Enumerate the work, in a place the loop owns

If the task involves multiple items, the first move should establish what they are, and the result should be stored as structured state rather than left in the conversation.

turn 1: list_work_items(request)
        → 6 items recorded in the run ledger

Everything downstream depends on this: completion checking against a real list, progress reporting, resumption after a restart, and per-item retry. → Without it, "done" is whatever the model decides, and partial work is indistinguishable from complete work.

For a single-item task this is a no-op. For anything list-shaped it's the most valuable turn in the run.

2. Resolve ambiguity before acting, not after

The first turn is the cheapest moment to notice that the request has two readings. Once the agent has taken three actions under one interpretation, switching is expensive and the actions may not be reversible.

Explicitly framing the first turn as an interpretation step — what is being asked, what's ambiguous, what's assumed — surfaces this while it's still free. And any assumption identified here should be recorded, so it appears in the final output rather than being invisible.

interpretation: refund the three unshipped items, not the whole order
assumption:     "the rest of it" refers to the unshipped items
unclear:        whether shipping cost is included → will ask

⚠️ An agent that never states an assumption is not an agent without assumptions.

3. Decide whether to plan, rather than always planning

The first turn is where the plan-or-don't decision belongs, and it should depend on the task's shape:

• Structure known in advance — a checklist, a set of items, a documented procedure → produce the plan. It buys progress tracking, parallelism, and something a human can approve.
• Structure unknown — investigation, debugging, research → don't. State a hypothesis and the next diagnostic step. An elaborate plan built before any evidence will be followed past the point it stops making sense.

Making this a deliberate branch rather than a fixed behavior avoids both failure modes: unplanned execution of structured work, and over-planned execution of exploratory work.

4. Establish the standing context

Whatever must remain true for the whole run gets fixed at turn one, in the structured region the loop regenerates rather than in the conversation:

• The task as stated, verbatim.
• Hard constraints — the ones a later turn must not violate.
• Identifiers the run has committed to.
• The budget: turns and tokens available, so the agent can prioritize as it depletes.

✅ Held as loop-owned state rather than as messages, none of this can be summarized away or trimmed. That single property prevents most long-run failures.

What not to do on the first turn

❌ Call a tool immediately because it's obviously needed. Usually harmless, occasionally the wrong tool for an interpretation nobody checked.

❌ Generate a long preamble. Restating the task in prose costs tokens on every subsequent turn and establishes nothing structural.

❌ Retrieve everything that might be relevant. Turn-one retrieval is the most expensive retrieval in the run, because it's re-sent on every later call. Retrieve when you know what's needed.

🔍 Reading the first turn in a failing trace

When diagnosing a bad run, read turn one first even though the failure appeared at turn twelve.

Common findings: the work list was never established, so completion was a guess; an ambiguity was resolved silently in the wrong direction; a plan was built on an assumption never checked; a constraint was mentioned once and never re-injected.

Each is a first-turn defect that presented as a late-turn symptom, which is why late-turn debugging so often goes nowhere.

The takeaway

The first turn establishes the frame every later turn inherits. Enumerate the work into state the loop owns, surface and record interpretation and assumptions, decide deliberately whether the task warrants a plan, and fix the standing constraints and budget outside the compactable history. Then, when a run goes wrong at turn twelve, look at turn one — that's usually where it went wrong.