Why can't you act on a streamed tool call's arguments before the stream ends?

## How a tool call streams Streaming exists so that output becomes visible before generation finishes. For text that is straightforward — tokens are meaningful as they arrive. For a tool call it is not, because the payload is structured. The provider emits, in order: an event announcing that a tool-call block has started, carrying the tool's name and the call id; then a series of deltas each holding a fragment of the arguments as a raw JSON string; then an event marking the block complete. Your job during the delta phase is concatenation, nothing more. Only after the completion event is the accumulated string a document you can hand to a JSON parser. ## Why partial arguments are worthless, not just risky Three separate problems compound. **Syntactic invalidity.** `{"store": "brigh` is not JSON. Any standard parser rejects it. Reaching for a lenient or streaming JSON parser to "get a preview" trades a clean failure for a dangerous success. **Semantic instability.** Even a fragment that happens to parse can mean something else once complete. `{"limit": 1` becomes `{"limit": 100}`. `{"scope": "one"` becomes `{"scope": "one_region"}`. `{"dry_run": t` looks like it will be `true` and is. A prefix is not a prediction. **Ordering is not stable in a useful way.** Fields do not necessarily arrive in schema order, so "I already have the id, I can start" is a bet on emission order that no contract backs. Together these mean there is no safe early execution — not even for a read. A lookup fired against `brigh` returns nothing or errors, and if your loop feeds that back as a result, the model reasons over a failure you manufactured. ## What you can legitimately do early The name and the id arrive at block start. That is enough for everything in the user interface: show that a named step has begun, start a spinner, display the tool's human-readable label, begin the trace span, start a timer for a timeout you will enforce once the call runs. Users perceive an agent as responsive when they can see *what* it is doing; they do not need to see the arguments being typed. Rendering the raw argument fragments, in fact, tends to look broken — half-written identifiers flickering into different values. ## Cancellation and partial calls Streams break. A client disconnects, a proxy times out, the user hits stop. If the stream ends during the delta phase you hold an incomplete call, and the rule is simple: it never happened. Do not execute it, do not persist it as an assistant turn, and do not fabricate a result for it. An assistant turn recorded with malformed arguments will be replayed on the next request and can confuse or outright break the continuation. Roll back to the last complete turn. The converse also matters: if the stream completes and you *do* execute, cancellation after that point cannot un-run a side effect. The clean boundary is the completion event. ## Proxies and buffering Streaming's benefits are easily erased in transport. A reverse proxy or gateway that buffers the response will hold every delta until the whole body is ready, and the front end sees one large chunk. Symptomatically this looks like streaming that stopped working; the client code is usually fine. It matters here because the early tool-name signal — the one genuinely useful early artifact — is exactly what gets swallowed. ## Testing this properly The partial-argument bugs do not reproduce against fast local stubs, because in tests the deltas often arrive in one batch. Deliberately fragment argument strings at awkward boundaries — inside a string literal, between a key and its colon, mid-number — and assert that your runtime accumulates without parsing and without dispatching. Also test a stream that dies mid-arguments and assert that no tool ran and no assistant turn was persisted. ## The summary rule Accumulate deltas, parse once, then validate, then execute. Use the early name for the interface, never for dispatch. A partially received call is not a call.