A tool can exist in an application’s message object and still disappear before the model sees it. LangChain PR #40758, merged September 23, addresses that gap for provider-native tool changes introduced partway through a conversation.
Richard Scarrott’s pull request explicitly discloses AI-agent assistance, and the merge commit credits open-swe[bot] alongside human contributors. That establishes agent involvement in this work. It does not establish which lines an agent wrote, whether it worked independently, or how much time it saved.
The message object is only the first stop
The OpenAI adapter carries an additional_tools block on a system message, then moves that block into the outgoing Responses input list. Ordinary text remains a message. A system message containing only the tool block leaves no empty message behind.
Placement also decides whether the request should exist at all. The adapter rejects this caller-supplied block on human or tool messages, and rejects it on the Chat Completions path with an instruction to select Responses. Replayed assistant output has a separate exemption from that rejection check. Treating every occurrence of a familiar block name as a new instruction would confuse conversation history with the caller’s authority.
The Anthropic adapter has a different job: preserve supported tool additions and removals in system turns, narrow unsupported content with warnings, and select beta headers for emitted changes and inline definitions. A common message abstraction does not erase provider-specific placement rules.
A transferable skill: assert the serialized boundary
The most useful receipt is the request-payload test suite. It supplies both bare blocks and LangChain’s non_standard wrapper, then checks the exact position of the resulting input item. Other cases check that the caller’s original content was not mutated, that a block-only message vanishes cleanly, and that wrong roles and transports raise errors.
Builders can copy that testing method without copying the feature. Start with a conversation that has a before and an after. Insert the new instruction between them. Inspect the payload at the last serialization boundary, asserting order and role as well as content. Then move the same block to an invalid role and require rejection. Finally replay an assistant turn containing it and check the intended history behavior separately. A test that only checks the original Python object misses the part that failed.
There is a useful reporting trap here too. The pull-request description says a leading Anthropic tool-change block raises. The merged test instead explicitly expects that leading block to be forwarded for provider validation. The implementation agrees with the test. Read the final boundary behavior before promoting a description into a compatibility promise.
We inspected the adapters and tests but did not rerun the upstream suites or call either live provider. These receipts establish intended serialization behavior in the merged source, not availability in every installed package or model. The practical lesson survives that limit: when an agent helps extend an SDK, review what leaves the SDK—not just what its new example puts in.