Why is regex-parsing a ReAct Action line brittle compared to structured tool calls?

## Where the text format came from ReAct was introduced as a *prompting* technique. Nothing about the model was special; the prompt showed a few exemplars in a fixed shape — a Thought line, an Action line, an Observation line — and the model continued the pattern. To make the Action line executable, the harness read it back with a regular expression or a hand-written parser, extracted a tool name and an argument blob, and dispatched. That design was necessary because models of that era had no other channel for expressing a call. It is still relevant. Any model without native tool-calling support, and plenty of local or open-weight deployments, are driven this way, so an interviewer asking about it is asking about a real fallback path, not history. ## The failure is a grammar problem Free text has no grammar that the model is obliged to respect. The parser assumes one anyway — that arguments sit between `[` and `]`, that values are wrapped in double quotes, that the action fits on one line. The moment the *content* of an argument contains one of those delimiters, the assumption breaks. The dangerous version is not the parse error. It is the parse that succeeds with the wrong span. Given a value-extracting pattern like `(\w+)="([^"]*)"` and the line `Action: lookup_user[note="he said "urgent" twice"]`, the regex is perfectly happy: it captures `note` with the value `he said `, stops at the first inner quote, and finds no further matches. Nothing raised. The tool runs with a truncated note. The observation comes back plausible, the model reasons on it, and the wrong answer is downstream of a bug the logs do not show as a bug. Other variants of the same problem: a bracket in user text ending the argument list early; a JSON blob nested inside the brackets confusing a greedy versus lazy quantifier; a multi-line argument (a code snippet, a log excerpt) where the parser is line-oriented; a stop sequence that fires in the middle of an argument because the argument happened to contain the token that ends an action. ## Types are lost too A text parse yields strings. The tool wanted an integer `limit`, a boolean `include_archived`, a float threshold. Somewhere a coercion layer guesses, and guessing has edge cases: `"0"` versus `"false"` versus `""`, a leading zero on an ID that must stay a string, a number large enough to lose precision. None of this is visible in the action line, so a schema cannot be enforced at the point of generation — only afterwards, on values that already lost information. ## What structured tool calling changes Modern hosted models emit the call as structured data rather than prose. The tool's arguments are declared as a schema up front, and the decoder is constrained so the emitted object conforms — required fields present, types correct, enum values drawn from the allowed set. The harness receives a parsed object. Quoting, escaping, nesting, multi-line strings and unicode are the serializer's problem, and serializers are correct in a way ad-hoc regexes are not. That removes an entire class of silent corruption. It removes none of the semantic class. A constrained decoder will happily produce `{"service": "billing-api", "window": "7d"}` for a service that does not exist or a window the backend rejects, because those facts are not expressible in the schema. Structured output guarantees *shape*, never *truth*, and that distinction is exactly what a good answer draws. ## When you are stuck with text If you must parse, reduce the surface. Ask for a single fenced JSON object as the argument blob rather than key-value pairs, so you delegate to a real JSON parser instead of a regex. Prefer a delimiter unlikely to appear in content, and require escaping in the exemplars. Validate the parsed result against the schema regardless — the parse succeeding is not evidence it parsed the right span. Treat a parse failure as a first-class outcome with its own message, and count it: a rising parse-failure rate after a prompt edit is a regression, not noise. Most importantly, prefer erroring to guessing. A parser that raises on ambiguous input is strictly safer than one that returns a plausible truncation, because only the first one is visible. ## What interviewers are checking That you can name the specific mechanism — delimiters appearing inside argument values — rather than saying "regex is fragile"; that you identify the *silent* truncation as the real hazard; and that you know structured tool calling fixes the structural class without touching the semantic one.