perf(langchain): stop inlining agent state into tool-dispatch Sends

[Sydney Runkle (sydney-runkle)]

Summary

Stop inlining the full agent state into every tool-dispatch Send in create_agent. Dispatch with the bare list form Send("tools", [tool_call]) and let ToolNode hydrate ToolRuntime.state from graph channels at tool-execution time.

Depends on langchain-ai/langgraph#7594 which teaches ToolNode to read channel state via CONFIG_KEY_READ when given a bare tool-call list. uv.lock pins that branch for CI while the langgraph PR is in flight — this pin will be reverted to a published langgraph version before merge.

What was happening

Before this change, every pending tool call produced a Send whose payload was:

ToolCallWithContext(
    __type="tool_call_with_context",
    tool_call=tool_call,
    state=state,   # ← the FULL agent state dict, including messages list
)

For any agent that runs many turns, state["messages"] grows linearly with the conversation. Every super-step that dispatches tools serializes that whole list into every Send, and those Sends live forever in the checkpointer's __pregel_tasks writes. The result is O(N²) __pregel_tasks storage across a run.

What changed

• libs/langchain_v1/langchain/agents/factory.py:
  • _make_model_to_tools_edge now returns Send("tools", [tool_call]) — no inlined state.
  • Drops the ToolCallWithContext import.
• libs/langchain_v1/pyproject.toml + libs/langchain_v1/uv.lock:
  • Temporary [tool.uv.sources] pin on langgraph, langgraph-prebuilt, langgraph-checkpoint to the companion PR branch so CI exercises both changes end-to-end. Revert after langgraph release.

Why it's safe

• Same snapshot semantics as before. Send is emitted at the end of the model super-step and consumed at the start of the tools super-step; channels by that point reflect every write from the model super-step (including the new AIMessage). Parallel tool tasks all see the same values since sibling writes don't land until end-of-super-step.
• Legacy ToolCallWithContext input path is preserved in ToolNode — no-op for any external caller still constructing it by hand.

Test plan

• tests/unit_tests/agents/ — 738 passed, 2 skipped, 1 xfailed
• ruff check . / ruff format . — clean
• mypy langchain/agents/factory.py — clean
• Before/after benchmark (below)

Benchmark

Script runs create_agent with a mock GenericFakeChatModel and two tools (write_file, edit_file). Each of the N turns dispatches 2 tool calls. After the run, the InMemorySaver is inspected for bytes stored under __pregel_tasks — the channel that carries the tool-dispatch Send payloads.

N	TASKS before	TASKS after	ratio
5	87.6 KB	4.7 KB	18.6× smaller
10	335 KB	9.4 KB	35.7× smaller
25	2.05 MB	23.7 KB	86.5× smaller
50	8.14 MB	47.6 KB	171× smaller
100	32.5 MB	95.3 KB	341× smaller
200	130 MB	192 KB	677× smaller
500	815 MB	482 KB	1,691× smaller

Growth shape:

• Before: per-Send bytes scale with current messages length (full state is inlined), so total TASKS across N turns = Σ(2 × k) for k=1..N ≈ O(N²).
• After: per-Send bytes are constant — just the tool_call dict. Total TASKS is O(#dispatches), completely independent of conversation length. In this bench with ~2 dispatches/turn: 940–964 bytes per turn across N=5..500, essentially flat.

An agent that makes 100 tool calls in a single turn pays the same TASKS cost as one that makes 100 across 50 turns — which is the semantically correct behavior.

Note: the messages channel is unchanged by this PR — it's still the dominant storage term (growing O(N²) via add_messages). TASKS was a second, compounding cost sitting on top of it; at N=100 it added 40% on top of messages, at N=500 it added 67%. After the fix, TASKS is a rounding error regardless of N.

[codspeed-hq]

Merging this PR will not alter performance

✅ 2 untouched benchmarks
⏩ 13 skipped benchmarks¹

---

_{Comparing sr/tool-call-context-fix (9b4ca6e) with master (78546e9)²}

Footnotes

1. 13 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on master (aac258e) during the generation of this report, so 78546e9 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩