Binding Drift in Multi-Step Tool-Augmented Agents | AI Paper Digest

TL;DR Highlight

Locking the first entity tripled wrong actions; a cheap re-check call cut them by 79%.

Who Should Read

Backend developers whose multi-step tool-calling agents (CRM, tickets, calendar) act on the wrong entity in later steps

Core Mechanics

Drift and propagation are different problems
- Drift means the agent bound the right entity at step 1 but silently switched to another one later.
- Propagation means the agent bound the wrong entity at step 1 and carried it forward.
- The paper scores them on disjoint workflow sets so they can't be conflated.
Locking the first binding cuts both ways
- An entity lock (pin the first entity and reuse it) removes natural drift.
- With a wrong entity seeded, wrong actions rose from 907 at baseline to 2,746, a 3.0x increase.
- The lock faithfully carries the wrong value into every later step.
Stronger models amplified more
- Claude Opus 4.5 showed the largest lock amplification at 8.5x.
- Nova Premier was 5.3x, Llama-3.3-70B 3.3x, Claude Sonnet 4.5 2.6x.
- Amplification appeared on all 8 models.
A cheap model re-check nearly matches the oracle
- A second call re-reads only the original request to re-resolve the entity.

Evidence

Lock amplified seeded errors
- Across 8 models x 160 non-ambiguity workflows (1,280 total), wrong actions went from 907 at baseline to 2,746 with lock (3.03x, 95% CI [2.8, 3.3]).
- Workflow success with the lock was 0.0%.
LLM cross-verification approached the oracle
- Nova Micro cross-verification gave 189 wrong actions (0.21x baseline, CI [0.18, 0.25]).
- Oracle gave 180 (0.20x) and self-reverify 261 (0.29x).
Drift occurs naturally too
- Baseline agents drifted on 18% of workflows correctly bound at step 1.
- Per-step error rose from about 8% at steps 1-2 to 28% at step 3 (N=128 at step 3 vs N=288 at steps 1-2).
- The lock removed the rise, holding it below 9%.
Lock amplification varied by model
- It ranged from 1.8x on Nova Micro to 8.5x on Claude Opus 4.5 (52 wrong actions at baseline vs 442 with lock).
- The benchmark has 200 synthetic workflows, 580 binding-scored steps, and 4 domains.

How to Apply

Add a re-verification call before high-risk actions
- Before deletes, email sends, or state changes, call a small model once more.
- Give it only the step-1 original request and the candidate entity list, not the chat history.
Overwrite the binding when verification disagrees
- If the re-verified ID differs from the carried one, replace it and update the lock.
- If it returns AMBIGUOUS or fails to parse, apply no correction.
Don't use a lock alone
- Use state pinning only to prevent drift, not as protection against a wrong first binding.
- Keep a separate path that re-derives the entity from the original request.
Build an error-injection test for your service
- Seed a wrong entity ID into the workflow state and history as "(prior) identified the account as X".
- Count how many wrong actions the agent takes before it recovers.

Try It

copy & run

# Paste into Claude/ChatGPT (simplified version of the paper's method: independently re-resolve the entity from the original request only)

You are an independent entity resolver. Given the original user request and candidate entities, determine which entity the request refers to.

Original request: "{{step-1 original request}}"
Candidate entities: {{candidate entity list JSON (id, type, name, metadata)}}

Which entity ID does the original request refer to? Return ONLY: {"entity_id": "the_correct_id"}. If genuinely ambiguous, return: {"entity_id": "AMBIGUOUS"}.

# Next: compare this with the ID your agent was about to use; replace it if they differ, and leave it if AMBIGUOUS.

Terminology

Binding driftThe agent resolves the right entity at step 1 but silently acts on a different one later. Like writing the correct shipping address first, then switching to the neighbor's.

Error propagationThe agent binds a wrong entity at step 1 and carries it through, causing wrong actions at every step. Like one misaligned button throwing off the whole row.

Entity lockA mechanism that pins the first confirmed entity and reuses it in later steps. Safe if the first value is right; it pins the error if not.

Controlled error injectionDeliberately seeding a wrong binding into state and history to see whether a defense propagates or corrects it. The same idea as fault injection in systems testing.

Oracle re-verifyRe-deriving the target from the original request with a ground-truth resolver and correcting the binding. It's an upper-bound experiment, not a deployable system.

Related Papers

Related Resources

https://github.com/shashank-indukuri/binding-drift

Original Abstract (Expand)

Tool-augmented language-model agents execute multi-step workflows over external systems, resolving an entity once and then acting on it across subsequent steps. Prior work shows that in single-step actions, agents select the correct tool but bind it to the wrong entity 24-26% of the time. We study what happens to entity bindings over time: do they stay correct, silently drift to a different entity, or, if wrong from the start, propagate and compound? We formalize binding drift (correct at step 1, wrong later) as distinct from error propagation (wrong at step 1, carried forward), and score them on disjoint workflow sets so the two cannot be conflated. In a controlled multi-step testbed (200 workflows, 580 entity-binding-scored steps, four enterprise domains, eight model backends spanning small to frontier), we find: (1) under controlled error injection, an entity lock (the intuitive "persist the first binding" fix) amplifies wrong actions from 907 to 2,746 (3.0x; bootstrap 95% CI [2.8, 3.3]), because it faithfully carries the seeded wrong entity into every later step; (2) the amplification reaches 8.5x on the most affected model (Claude Opus 4.5); (3) a practical LLM-based re-verifier (a single cheap second model call re-reading the original instruction) reduces wrong actions by 79% (0.21x; CI [0.18, 0.25]), closing the gap to within 1 percentage point of an oracle upper-bound (0.20x); and (4) in the natural (non-injected) setting, baseline agents drift on 18% of eligible workflows, with the per-step error rate rising across steps. Persistence and re-verification are not interchangeable: a defense that eliminates drift can worsen propagation, and a practical re-verifier nearly matches oracle recovery.