When is a hand-written ReAct text protocol still better than native tool calling?

## The two ways to express the same loop ReAct describes a *pattern*: reason, take an action against the environment, read the observation, reason again. That pattern is protocol-neutral. There are two ways to express it. **As a text protocol.** You write a prompt that declares three labelled blocks, show a few complete exemplar trajectories, configure a stop string at the observation boundary, and write a parser that pulls the action out of the generated prose. Your runtime executes it and appends the real result as text. **Through a structured interface.** The provider accepts a list of tool definitions alongside the conversation. When the model decides to act, it emits a structured call rather than prose; generation halts at that boundary automatically; your runtime executes and returns the result as a structured result message. No labels, no stop string, no parser. Both run the same loop. What differs is who owns the encoding. ## Why structured is the default now By mid-2026 the structured route wins on almost every axis for mainstream hosted models: - **The model was trained for it.** Post-training targets this format directly, so compliance is far higher than for a convention you invented in a prompt. - **The boundary is enforced, not conventional.** The API stops at the call. The model cannot write the observation, because the observation is not a place in the text it can reach. - **Arguments are data.** You get typed fields rather than a substring you must interpret, and schema violations become a checkable condition rather than a regex surprise. - **The scaffolding disappears.** The few-shot block, the stop string, the label constants and the parser all go away. That is a large amount of prompt and code deleted. The practical consequence is that the text protocol is now mostly of *conceptual* importance — you should understand it because it explains what the structured interface is doing, not because you will usually build with it. ## Where text still wins Four situations genuinely favour hand-written text. **Models without dependable tool calling.** Small open-weight or locally hosted models vary enormously in how reliably they emit structured calls. Some follow a plain-text convention with a couple of exemplars far more consistently than they follow a schema. If your deployment constraint is a model on your own hardware, measure both; do not assume the structured path is available in practice just because it is nominally supported. **Action spaces that are not function-shaped.** A shell command, a patch, a query in a domain language, a sequence of edits — these have their own grammar. Wrapping them in a single string parameter of a schema is not a design win; it just relocates your parsing problem into an argument. Sometimes the honest encoding is the native one. **Portability and control of the transcript.** A text protocol is provider-agnostic by construction. If you run the same agent across several models, or you want one canonical trace format for evaluation, replay and later training data, owning the encoding has real value. The moment you have decided to fine-tune on trajectories, a stable text format you control becomes an asset rather than a liability. **Teaching, research and harnesses.** Where the point is to inspect and manipulate the reasoning surface directly — ablations, custom decoding, curriculum work — the transparent format is the whole point. ## The cost you accept with text Parse failures do not go away; they become your permanent operational burden. You need a repair path — return a parse-error observation naming the expected format and let the model retry, with a cap on retries — and you need to instrument the failure rate, because it silently degrades when you change models or edit exemplars. You also carry the fabricated-observation risk, which the structured interface eliminates by construction. ## What does not change Everything interesting survives the switch. You still decide which tools exist and how they are described. You still decide when the loop stops. You still handle oversized results, errors, retries and untrusted tool output. You still need the model to reason before acting — with structured calling that reasoning lives in the assistant's ordinary text output, or in a provider's extended-thinking surface, rather than after a `Thought:` label. Candidates who believe native tool calling replaced ReAct have confused the protocol with the pattern; the loop is the same loop. ## How to answer this in an interview Lead with the default — structured, because the model was trained on it and the boundary is enforced. Then name the two or three specific constraints that would push you back to text, and be explicit that choosing text means owning a parser and a repair path forever. That combination of a clear default plus honest exception conditions is what the question is testing.