How do you keep a ReAct thought grounded in what the observation actually said?

## What grounding means inside the loop A ReAct agent alternates model text and tool text. Grounding is the property that each thought's claims are traceable to observation content rather than to the model's priors or to an earlier paraphrase of its own. It is not a binary: an agent can be grounded at step 2 and thoroughly ungrounded at step 8 because each step restated the previous one slightly more confidently and slightly less accurately. Two distinct mechanisms break it, and they need distinct fixes. ## Mechanism 1: the deciding detail was reduced away Observations are shortened, and the shortening decides what the model can know. Take a Java stack trace of 400 lines cut down to fit a step budget by keeping the last 40 lines. The frames survive; the header line naming the exception type and message — the single most load-bearing line in the whole payload — is gone. The next thought does not stall. It reads the frames, recognises a familiar call path, and produces `Thought: this looks like a null dereference in the mapper`. That is a guess wearing the register of a conclusion, and the following five steps are spent investigating a fault that never occurred. The fix is format-aware reduction: for every payload type you handle, name the spans that must never be dropped. Exception type and message for a trace. Status code and error body for an HTTP response. Column headers for tabular output. Total-count and page metadata for a paginated result. Keep those, then spend the remaining budget positionally or by relevance. The general rule — reduce by relevance, not position — applies here with a stronger constraint: some content is structurally required regardless of relevance scoring. ## Mechanism 2: the thought paraphrases instead of citing Even with a perfect observation in context, a thought that restates content in its own words introduces error. `Observation 2: balance = 41.37 USD, as of 2026-08-11` becomes `Thought 3: the account has about forty dollars` becomes `Thought 6: the account is nearly empty` becomes a final answer that asserts a low balance without a figure or a date. Nothing hallucinated a fact outright; each step was a small, reasonable compression, and the composition is wrong. The countermeasure is a citation discipline in the prompt and, more importantly, in the exemplars: a thought that draws a conclusion from an observation quotes the deciding span or names the observation id. `Per observation 2, balance = 41.37 USD as of 2026-08-11, so the payment will fail.` This costs a handful of tokens and buys three things — the value stops drifting, the final answer is auditable claim by claim, and a human reviewing the trace can spot the exact step where reasoning left the evidence. Exemplars carry more weight than instructions here. The model is continuing a pattern; show it two thoughts that cite, and it cites. ## Verification, not vibes Reading traces by hand does not scale and misses precisely the fluent failures. Three automated checks work well: **Value grounding.** Extract concrete tokens from the final answer — numbers, dates, identifiers, names, error types — and assert each appears verbatim in at least one observation from that run. Unsourced values are the fabrications you care about. The check has false positives (legitimately derived arithmetic) so allow a small annotated exemption list rather than weakening it. **Citation coverage.** Measure the fraction of conclusion-bearing thoughts that reference an observation id or quote a span. A run whose coverage collapses after step 5 is drifting. **Reduction retention.** Replay traces against the full payloads and check whether the reduced observation still contained the span the reference answer depends on. This separates 'the model reasoned badly' from 'the model was never shown the answer', which are different bugs with different owners and are constantly confused in postmortems. ## What grounding does not fix Grounding constrains the model to what the observation said; it says nothing about whether the observation was true. A tool returning stale or wrong data produces a perfectly grounded and perfectly wrong answer. That is why observations carry provenance — source and arguments and timestamp — and why a final answer that cites its observations is more useful than one that merely happens to be right: the citation lets a reviewer challenge the source. ## In an interview The strong answer connects the two mechanisms. Weak candidates propose 'tell the model to be accurate'. Strong candidates say: guarantee the deciding span survives reduction, require citation in the exemplars, then measure value grounding on replayed traces and treat a drop as a regression.