Order the stream parts emitted by streamText for one tool call plus a final text response

Order steps·Hard·4.0 · 0·~1 min·Asked atBanana Dev Whylabs

Attempt it

1finish, closing part with finish reason and usage
2tool call, model emits a tool invocation with arguments
3text-delta(s), final natural language tokens after the tool result
4tool result, your server side handler returns the tool output
5text-delta(s), initial reasoning / preamble tokens (if any)
6start, opening part with stream metadata

**Vercel AI SDK's `streamText`** emits a sequence of typed stream parts that a chat UI consumes in order. For a single tool call followed by a final text answer, the canonical sequence is: 1. **start**. Opening part with stream metadata (run ID, message ID). 2. **text-delta(s)**. Preamble or reasoning tokens the model emits before deciding to call a tool. May be zero in tight tool-using flows. 3. **tool-call**. The model emits a tool invocation with arguments. Your UI can show 'calling search(query=...)' as soon as this arrives. 4. **tool-result**. Your server runs the tool and the result arrives. The model has not seen this yet. 5. **text-delta(s)**. The model now reads the tool-result and emits the final natural-language answer, token by token. Typewriter rendering happens here. 6. **finish**. Closing part with the finish reason and usage tokens. The two ordering rules that catch most candidates: tool-result always comes after tool-call (the model emits the request first, your runtime fulfills it), and the final answer text comes after the tool-result (the model has to read the result before composing the answer). Anything else is broken.

**The canonical sequence is start → preamble text-deltas → tool-call → tool-result → final text-deltas → finish.** Each part is a typed object on the stream, and the order is enforced by the request-response pattern of tool use. **start** opens the stream with metadata. **text-delta** parts before the tool call are optional. They show up when the model emits reasoning or a preamble like 'Let me search for that' before calling the tool. In many tool-using flows there are zero preamble deltas; the model goes straight to the tool-call. **tool-call** is the model's request: tool name and arguments, often streamed as deltas itself for argument by argument visibility. **tool-result** comes from your server-side handler after it runs the tool; this part carries the data the model needs to compose the final answer. There is always a tool-call before a tool-result, because the result is the response to the call. After the tool-result, the model resumes generation. The final **text-delta** parts are the natural-language answer that grounds in the tool's output, streamed token by token to the chat UI. Finally **finish** closes the stream with the finish reason (`stop`, `length`, `tool_calls`) and usage stats. The failure modes worth knowing: placing final text before tool-result (the model has nothing to ground in), placing tool-result before tool-call (logically impossible), or omitting finish (the UI never knows the response is complete). The order in the question is the only legal one for this scenario.

TL;DR

start opens the stream, then preamble text-deltas, then the model's tool-call, then your tool-result, then the final text-deltas after the tool returns, then finish closes the stream.

Memory aid

Easy to grasp

Imagine a waiter taking your order. First they say 'good evening' (start). They suggest 'maybe an appetizer' (preamble text). They walk to the kitchen and shout the order (tool-call). The kitchen sends back a plate (tool-result). Then they describe the dish to you (final text after the result). Finally they bow and step away (finish). Reordering steps in real life would be confusing; the same is true for a streamText pipeline driving a chat UI.

Key concepts

LLM Frameworks

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Vercel AI SDK's streamText is the canonical TypeScript-first streaming primitive in 2026 chat UIs. The stream is a typed sequence of parts (start, text-delta, tool-call, tool-result, finish, plus several variants), and the order is forced by what the model and your runtime are actually doing.

The question asks you to put the six parts in the only legal order for a one-tool flow. The senior signal is articulating why each ordering rule is forced rather than memorizing the sequence: tool-result must follow tool-call because it is the response; final text must follow tool-result because the model needs the data; finish must be last because it closes the stream.

Mental model: the model talks, asks, waits, then answers grounded. The stream parts mirror that conversation with your tool runtime.

What each stream part actually carries

start

Emitted once at the top. Carries metadata: messageId, runId, model name, tool registry. The client uses it to set up a new assistant message frame in the UI.

text-delta

Incremental token chunks. Carries textDelta (the new tokens) and messageId. The same part type is used for both preamble text (before the tool) and final answer text (after the tool); the difference is purely positional.

tool-call

The model's invocation request. The AI SDK actually splits this into three sub-parts for richer UI rendering:

tool-call-streaming-start. Tool name is known, arguments are starting.
tool-call-delta. Argument tokens stream in.
tool-call. The complete call object (name, args, toolCallId).

Your UI can show 'calling search(query=...)' progressively as arguments stream.

tool-result

Your server-side handler runs the tool and emits the result. Carries toolCallId (matching the call), the structured result, and optionally a stringified representation. If the tool throws, emit tool-error instead with the error message.

finish

Emitted once at the end. Carries the finishReason (one of stop, length, tool_calls, content-filter, or error), prompt and completion token counts, and per-tool usage data. The client uses it to tear down the message frame and update token-usage state.

Why the order is forced

Wiring this to a UI with useChat

Extensions: multi-tool, parallel, and reasoning

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Next.js AI chatbot template streams exactly this sequence into the UI useChat hook for tool-using flows.
Vercel's v0.dev assistant uses streamText with code-execution tools, the user sees tool-call chips before the tool-result arrives.

What an interviewer would ask next. Try answering before peeking at the approach.

QWalk through what changes when the model decides to call two tools in parallel.

The model emits two tool-call parts close together. Your runtime can dispatch both in parallel; the tool-result parts arrive in completion order, not call order. The stream becomes start → [preamble] → tool-call₁ → tool-call₂ → tool-result₂ → tool-result₁ → final text-deltas → finish (or whatever order the tools resolve in). The model only continues generation after both results arrive.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Placing tool-result before tool-call, or placing the final text-deltas before the tool runs. Final text always follows the tool-result because the model needs to read it.

60 second bullets to scan on the way to the call.

The six canonical stream parts for a one-tool flow
Why tool-result always follows tool-call

Primary sources. Browse if you want the original framing.