Agents encode their tool-call graph: a new residual-stream monitoring surface

What is this?

On May 25, 2026, Tianda Sun and Dimitar Kazakov (University of York) published Tool-Call Dependency Structure is Linearly Decodable in LLM Agent Residual Streams on arXiv. The finding is narrow but sharp: when a tool-using agent runs, the dependency structure linking its tool calls — which earlier call’s output feeds which later call’s argument — is written into the model’s internal activations in a form a simple linear probe can read back out.

The authors ran Qwen3-32B as the policy of an agent on the retail split of τ-bench, a multi-turn tool-agent benchmark, and trained a low-capacity logistic-regression probe on the frozen residual stream. It recovered the pairwise call-dependency edge at AUROC 0.869, well above every control they tried. To their knowledge this is the first structural probe of an agent’s runtime tool-call dependency graph, rather than of static code or chain-of-thought text.

How it works

Each agent trajectory induces a directed graph: an edge from call i to call j exists whenever i’s output supplies an argument to j. The authors build that graph from an independent oracle, then ask whether it is present in the activations.

They log the residual stream across all 65 representation layers at every assistant decode boundary, then train an L2-regularised linear probe on the mean-pooled activations at the two calls’ boundary tokens. The edge becomes linearly decodable by roughly layer 14. Three checks make the result hard to dismiss: a Hewitt–Liang random-label control (the probe beats it by +0.304 AUROC), a conditional-probing positional baseline so the signal is not just call ordering (it beats that by +0.0775), and a counterfactual that corrupts identifier values versus perturbing graph structure — the probe tracks abstract topology, not the specific IDs. Per-layer activation patching shifts a later, non-patched probe readout, evidence that the representation propagates through the network rather than being read off passively. The non-positional signal replicates on three further multi-hop benchmarks and fades to nothing in single-shot planning, where call order alone already predicts dependency.

Crucially, the authors are explicit that their claims concern representation, not behavioural control: patching moved the probe’s readout but did not move the agent’s realised tool choice.

Why it matters

Tool-mediated control-flow hijacking — indirect prompt injection that redirects which tools an agent calls and how their outputs chain together — is one of the dominant agent threats. Until now, defenders mostly watched the outside of the agent: the emitted tokens, the tool calls that actually fired, the text of the reasoning trace. This work suggests the intended call structure is also legible from the inside, in a linear subspace, before and independently of the surface output.

That is a new monitoring surface. It sits alongside prior activation-based defenses — task-drift detection from activations, and per-step probes for whether a tool is needed or which one — but targets something they do not: the relational structure between calls. If an operator can reconstruct the dependency graph the model “intends” and compare it against what executed, a mismatch is a candidate signal that something rewrote the plan.

The honesty caveats matter as much as the result. This is a decodability finding on one primary domain and two model families, not a deployed detector, and representation is not behaviour. It is a foundation for defense, not a defense.

Defenses

For teams running self-hosted, white-box agents, the practical takeaways are about where to invest, not a drop-in tool.

1. Treat internal activations as an observability surface, not just the output. The intended tool-call graph appears to be linearly accessible; a probe over the residual stream is a plausible place to look for hijacked execution structure.
2. Layer it with existing activation defenses. Combine call-graph probing with task-drift detection and per-step tool-need probes — they cover complementary failure modes.
3. Do not confuse a probe with a control. Decoding the intended graph tells you what the model represents, not what it will do. Any detector needs its own thresholds, false-positive budget, and adversarial evaluation before it gates anything.
4. Remember the deployment boundary. This requires access to internal activations, so it is available only to self-hosted or model-provider deployments — API-only consumers cannot run it.
5. Keep enforcement out of the model. Internal signals are for diagnosis; the authority to allow or deny a tool call should still live in a deterministic, out-of-model policy, not in a probe reading the agent’s own mind.

Status

Item	Reference	Date	Notes
First structural probe of an agent’s runtime tool-call graph	arXiv 2605.25310 (Sun & Kazakov, University of York)	2026-05-25	Qwen3-32B on τ-bench; edge AUROC 0.869; representation-only claim
Converging line: tool calling linearly readable and steerable	arXiv 2605.07990	2026	Reads/steers the chosen tool; complementary per-step signal

The one-line version: an agent’s tool-call dependency graph is written into its activations in a linearly readable way — promising as a defensive monitoring signal for hijacked execution, but a representation finding, not a finished detector, and never a substitute for out-of-model authorization.