reflect: leaked done-tool tail still persists when the model DOES emit a valid tool call (#3013 guard does not fire)

[gvilleg]

Summary

#3013 removed the salvage logic and made reflect fail loudly when a transport can't produce a usable tool call. That correctly covers the Vertex AI gpt-oss case in the PR description.

There is a second, structurally different path that produces the same persisted corruption and which #3013 does not catch: the model emits a well-formed tool call, and the leaked fragment is inside the answer argument value.

Since #3013 also removed the last sanitisation step, that fragment is now written to mental model content verbatim.

Why the new guard doesn't fire

On current main:

• ReflectToolCallError is raised only under if not saw_tool_call (reflect/agent.py, ~L919). In this failure mode saw_tool_call is True — the provider returns a valid tool_calls entry for done.
• The answer is then taken as-is: answer = args.get("answer", "").strip() (~L1268).
• grep -c '_clean_done_answer|</answer>' on main returns 0, so nothing downstream inspects the value.

Net: a valid tool call whose answer string ends in tool-call syntax passes every check.

Observed shape

The answer argument value ends with a fragment resembling XML tool-call syntax (UUIDs redacted):

...ordinary prose ending a sentence.</answer>
<parameter name="memory_ids">["<uuid>", "<uuid>", ...]

Note this is inside the JSON string value of answer, alongside a correctly populated memory_ids array in the same tool call. The model appears to blend two tool-call serialisations mid-generation rather than failing to tool-call.

The result is persisted into mental model content, and re-parsed into structured_content, so a single occurrence corrupts both surfaces.

Frequency and provider

Observed via LLM observability traces on a self-hosted deployment, provider anthropic/claude-haiku-4-5 reached through a LiteLLM proxy (not Vertex/gpt-oss):

• 2026-07-22: 2 occurrences out of ~172 generations, both persisted, each corrupting one mental model
• 2026-07-27: 3 occurrences with this exact shape out of ~830 generations (plus 2 rows with a different, partial JSON shape)

Low rate, but non-zero and recurring across weeks. Two mental models were corrupted with 133 and 49 leaked IDs respectively before it was noticed — the failure is silent, since the refresh reports success.

Why this is worth separating from #3013

The two failure modes need different remedies:

	#3013's case	this case
tool call produced	no	yes, well-formed
detectable at transport	yes	no
current behaviour	raises	persists silently

A saw_tool_call check cannot distinguish them, so closing this needs either validation of the answer value itself, or removal of the boundary the model is crossing.

One possible direction

The leak occurs at the answer → memory_ids parameter boundary. The server already accumulates every retrieved ID during the loop and validates the model's returned IDs against that set, discarding anything unrecognised — so the model's contribution is a subset selection over data the backend already holds.

If those ID parameters were dropped from the done tool, this specific boundary would not exist. That is a design tradeoff rather than an obvious win: it costs model-attributed provenance, and it does not remove other sibling boundaries (a done schema built with directives still carries a required directive_compliance after answer). Raising it as an option, not a recommendation.

Happy to supply redacted trace payloads or test cases if useful.

Related

• refresh_mental_model overwrites a healthy mental model with the "No answer provided." placeholder when reflect fails #2959 / fix(refresh): preserve mental model content when reflect returns no usable answer #2960 — the empty-answer overwrite. Complementary rather than superseded: fix(reflect): fail on unusable tool calls instead of salvaging leaked text #3013 guards the transport boundary, while fix(refresh): preserve mental model content when reflect returns no usable answer #2960 preserves existing content when reflect returns nothing usable for any reason, including non-transport causes such as an iteration limit.

[ebarkhordar]

The #3013 removal is not what makes this persist. I ran the deleted _clean_done_answer against the shape in your trace and it returns the string unchanged.

Extracted the pre-#3013 sanitisers from 6fe0dd6 (the parent of 678ca0e9) and ran them in a clean container (python:3.12-slim, --network none, stdlib only):

=== 3048 observed shape
    stripped? NO
    output is byte-identical to input (184 chars)
=== control: trailing ids colon    -> YES  'The team migrated the billing service.'
=== control: trailing json object  -> YES  'The team migrated the billing service.'
=== control: fenced json           -> YES  'The team migrated the billing service.'

The patterns say why: _TRAILING_IDS_PATTERN wants memory_ids followed by = or :, _LEAKED_JSON_SUFFIX wants a fenced block, and _strip_trailing_id_json_object wants the text to end in }. Your shape is <parameter name="memory_ids">[...], so none of the three match. The strip zoo covered the JSON-flavoured leak, not the XML-flavoured one. That matters for the remedy: reverting #3013 or restoring those helpers would leave both of your corrupted mental models exactly as they are, so this is a gap that predates #3013 rather than a regression from it.

The part I would pull out instead is that the assumption is written down rather than merely absent. agent.py:1265-1267 on current HEAD (cc1eaee):

# ``done`` is a structured tool call: trust its ``answer`` field verbatim.
# Sibling id fields (memory_ids, ...) live in their own arguments and are
# validated separately below -- they can't bleed into a parsed answer string.

and #3013's commit message states the same thing: "A parsed tool call can't bleed its sibling id fields into the answer string." Your traces are a counterexample to that sentence specifically, which looks like the thing to settle before choosing between validating the answer value and removing the parameter boundary.

Your three structural claims hold on cc1eaee:

• ReflectToolCallError is raised only under if not saw_tool_call (agent.py:919, raise at :924, saw_tool_call = True at :988).
• answer = args.get("answer", "").strip() at :1268, with no validation after it.
• Nothing downstream inspects the value. I parsed the module rather than grepping: the only other args.get("answer") is :1547, inside _summarize_input, which builds a log preview.

Not verified: I did not reproduce the generation itself, so I can say nothing about the 2-in-172 rate or which layer blends the two serialisations, and I did not trace the write past ReflectAgentResult into mental_models.content.