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 of the stream. 2. **text-delta(s)**. Preamble tokens the model emits before deciding to call a tool. There may be none 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**. The SDK runs your tool on the server and the result arrives. The model has not seen this yet. 5. **text-delta(s)**. In a second step, the model reads the tool-result and emits the final natural-language answer, token by token. This step runs only if `stopWhen` allows more than one step. 6. **finish**. Closing part with the finish reason and usage tokens. Two ordering rules matter most. Tool-result always comes after tool-call (the model emits the request first, your runtime fulfills it). The final answer text comes after the tool-result (the model has to read the result before composing the answer). Any other order 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 follows the request-response pattern of tool use. **start** opens the stream. **text-delta** parts before the tool call are optional. They show up when the model emits a preamble like 'Let me search for that' before calling the tool. In many tool-using flows there are none. The model goes straight to the tool-call. **tool-call** is the model's request: tool name and arguments. The arguments can stream first as `tool-input-start`, `tool-input-delta` and `tool-input-end` parts. **tool-result** comes after the SDK runs your tool's `execute` function on the server. It carries the data the model needs for the final answer. A tool-call always comes before its tool-result, because the result is the response to the call. After the tool-result, `streamText` starts a second step: a new model call that includes the result. This needs `stopWhen` set above one step (the default `isStepCount(1)` stops after the tool result). The final **text-delta** parts are that answer, streamed token by token. **finish** closes the stream with the finish reason and total usage. The failure modes: final text before tool-result (the model has nothing to ground in), tool-result before tool-call (impossible), or no finish (the UI never knows the response is complete). The listed order is the only valid 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). Describing the dish before the plate arrives would be guessing, so the final text waits for the tool-result. 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 AI SDK's streaming text-generation function. Its stream is a typed sequence of parts (start, text-delta, tool-call, tool-result, finish, plus several variants). What the model and your runtime do forces the order.

For a one-tool flow, each ordering rule has a reason. 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.

The model may write some text, then requests a tool, waits for the result, and then writes the answer from that result. The stream parts follow the same sequence.

What each stream part carries

In AI SDK 7 the full event stream is result.stream. Besides the six parts in the list, each model call is wrapped in start-step and finish-step, and each block of text is wrapped in text-start and text-end.

start

It is emitted once at the top. The client uses it to set up a new assistant message frame in the UI.

text-delta

These are incremental token chunks. The new text is in the text property. The same part type is used for both preamble text (before the tool) and final answer text (after the tool). The only difference is position.

tool-call

This is the model's invocation request. When the provider streams tool input, the AI SDK emits input parts first for richer UI rendering:

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

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

tool-result

The SDK runs the tool's execute function on the server and emits the result. It carries toolCallId (matching the call) and the tool output. If execute throws, a tool-error part appears instead.

finish

It is emitted once at the end. It carries the finishReason (for example stop, length, content-filter, tool-calls or error) and totalUsage with input and output token counts. Each finish-step carries that step's usage. The client uses it to close 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.
Coding assistants built on streamText with code-execution tools show 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.