The multimodal PDF turn dropped the user's question out of the final
outbound user message, so the model was handed a document dump with no
question attached. Against aimock's strict mode that surfaced as
`503 no_fixture_match` on turn 2 (turn 1, the image, passed); against a
real LLM it would have silently answered the wrong thing.
Root cause is a serialisation mismatch, not a fixture gap.
`agent_framework_openai._chat_completion_client._prepare_message_for_openai`
emits ONE OpenAI message per `Content` — it builds a fresh `args` dict on
every iteration of its content loop. `_PdfFlattenChatMiddleware` appended
the flattened `[Attached document]` text as a SECOND text `Content` beside
the prompt, so one logical user turn serialised to two consecutive user
messages: prompt-only, then document-only. Anything reading "the current
user turn" off the tail of the list saw only the document.
Merge the flattened document INTO the message's existing prompt text
content instead, so the turn stays a single text content and serialises to
a single user message reading `"<prompt>\n[Attached document]\n<body>"`.
langgraph-python's equivalent agent is green precisely because LangChain
keeps multiple text parts inside one message rather than splitting them.
The merge copies the prompt `Content` rather than mutating it: the
middleware restores the original `contents` list after the model call, and
that restore only undoes the list swap — an in-place mutation would leak
the raw PDF body into the AG-UI MESSAGES_SNAPSHOT and render it in the
user's chat bubble.
Also dedupe identical flattened blocks. The page's `LegacyConverterShim`
appends a legacy `binary` mirror alongside every modern attachment part, so
the same PDF arrives twice and its body was being sent to the model twice.
No fixture change: the existing `userMessage` match key is correct and is
what the corrected request shape satisfies.