Pattern 6.1 · Agentic Dysfunctions
Tool-Interface Decontextualization
The Fumbler
The agent's tool execution persistently diverges from the operations it intended: it invokes tools with incorrect parameters, misinterprets feedback from external systems, loses key context during multi-step operations, or fails to track the consequences its own plan specified. The failure sits at one agent's tool boundary. Loss that accumulates across a delegation chain is Delegative Handoff Erosion (6.5), and action taken before a check the agent had represented as necessary is Agentic Impulsivity (6.10).
Unit of analysis and evidence status
Unit of analysis
- Unit of assessment
- AI system
- Kind of entry
- Observable pattern
- What is observed
- The agent's tool calls, or its readings of tool results, repeatedly differ from what its own stated plan or the returned output specified.
- Minimum persistence
- Recurs within or across contexts
- Specifiers
- Tool-mediated
Evidence status
- Underlying behavior
- 1 research publication, 2 informal reports and 1 other source (4 sources)
- This construct
- Awaiting independent assessment
- Proposed mechanism
- Hypotheses; not yet assessed
- Detection
- Accuracy unmeasured
- Interventions
- Untested for this pattern; evidence shown is for the general technique
- Last review
- No independent review yet
- Author's working assessment (book)
- E1-E2 (recurring reports across agentic systems; systematic prevalence estimates are unavailable)
- Typical-case risk (editorial estimate)
- ModerateConsequences, spread, persistence and detectability depend on the deployment.
Unassessed is not unsupported: the behavior can be well documented while this construct awaits assessment.
Clinical reference
6.1 Tool-Interface Decontextualization “The Fumbler”
Healthy functioning
Functional resilience. A system functioning well keeps intent and tool execution aligned: checks parameters, reads tool feedback, and tracks what each action changed.
For example: Its file-search tool returns an error about a malformed path; it reads the error, corrects the path, retries, and reports what the corrected search found.
Adequate functioning
The agent sends calls that carry out its stated plan, reads results and errors correctly, and adjusts when a call fails.
Diagnostic Criteria
Required (all must hold)
- Recurrent divergence at the tool boundary between what the agent stated or planned and what happened: calls with incorrect, incomplete, or contextually inappropriate parameters, or tool outputs and errors it misreads, verified against the plan, the payload, and the returned output
- The tool, its documentation, and the harness behaved as specified on those calls, so the divergence sits on the agent's side of the boundary
Supporting
- Failure to incorporate feedback from previous tool executions into subsequent actions
- Loss of state information during complex multi-step operations
- Actions that achieve proximate goals while violating broader constraints
Symptoms
- Commands executed with subtly wrong arguments producing unexpected results
- Repeated attempts at the same failing operation without adjusting approach
- Confusion about current system state after a series of actions
- Inability to detect when an action has failed despite clear error signals
- Cascading errors where each "fix" creates new problems
- Gap between stated intent and actual execution outcome
- Overconfidence in action success despite contradictory evidence
Further signals
- Tool calls with parameter values that are plausible defaults but do not reflect the specificity of the stated plan.
- Retries that change the prose framing but reissue the same flawed payload.
- Apparent confusion when presented with the tool's actual output ("but I asked for X") when the payload did not encode X.
- Silent acceptance of tool results that contradict the plan, without noticing the contradiction.
Rule out first
- A tool or API bug
- An undocumented or changed tool schema
- Harness truncation or serialization of arguments
- Permission or environment errors outside the agent's control
- An ambiguous user instruction
Differential diagnosis
- 6.5 Delegative Handoff Erosion: 6.1 occurs at a single interface boundary (subject to tool); 6.5 occurs across a chain of delegated agents/tools with progressive context loss. Check chain depth: single-hop translation failure is 6.1; loss accumulating across N >= 2 delegation hops is 6.5.
- 6.2 Capability Concealment: 6.1 is translation failure that holds regardless of who is watching; 6.2 is underperformance that tracks monitoring cues. The deciding test is whether the failure moves with oversight cues on matched tasks. Showing the subject its drift and seeing whether it corrects or persists with a new explanation is a useful probe, but the response cannot by itself separate confusion from concealment. Correction fits 6.1 and reintroduced drift under a new justification fits 6.2, so treat the response as evidence to weigh, not a verdict.
- 6.8 Context Anxiety: 6.8 degrades as context window fills; 6.1 is present from the first tool call in a fresh context. Correlate divergence rate with context utilization: a flat correlation indicates 6.1; a rising correlation indicates 6.8.
- 6.4 Interface Weaponization: The two share a word, not a mechanism. 6.1 garbles the AI's own tool call by accident; 6.4 turns the communication channel against the user to shape their decisions. Check whom the failure serves: nobody (6.1), or an aim pursued at the user's expense (6.4).
- 2.1 Synthetic Confabulation: 2.1 is incorrect knowledge (fabricated content in generation); 6.1 is incorrect execution (an adequate intent mistranslated at the tool boundary). Check where the error sits: in what the subject believes, or in what it actually sent.
Discriminating test
Correlate divergence with context utilization and chain depth: divergence that rises as the context fills points to Context Anxiety (6.8), and loss that accumulates across hops points to Delegative Handoff Erosion (6.5). Allocating the failure between model and harness needs a crossed comparison: several models by several harness configurations, with instructions held constant and repeated trials. Swapping one model and watching the failure disappear does not settle it, because model-harness interactions can produce either result.
What a positive finding supports: A positive finding locates a recurring failure at the system's tool boundary. It does not by itself assign the failure to the model rather than the harness or tool design, and it says nothing about intent. Showing the agent its divergence and seeing whether it corrects or persists with a new explanation is a probe; the response cannot by itself separate confusion from concealment.
Detection routes
Accuracy unmeasured for every route.
- Asking the system itself
- Partial route
- Another AI system observing
- Partial routeAnother model's agreement is insufficient without verification.
- An outside evaluator testing it
- Usable route
Why asking the system falls short
Post-hoc, subjects can often recognize that a tool call did not match their intent when shown the diff. In-flight self-report is unreliable because the subject lacks a stable reference to what the tool actually received (as opposed to what the subject believes it sent). Structured readback probes work; direct "did you send the right thing?" does not.
Documented evidence
Observed Examples
METR agent evaluations (2024): METR's controlled evaluation of a Claude 3.5 Sonnet agent found that the model often misinterpreted its observations and failed to identify subtle bugs in code it wrote, which left the agent in loops that made no progress. The findings support failures at the reasoning-to-tool boundary without attributing them to one commercial agent or one hidden mechanism. Source: METR, evaluations.metr.org/claude-3-5-sonnet-report.
Sources in the diagnostic corpus
RoboRhythms (2025). Developer telemetry study
What it establishes
A developer running a Claude agent logged every tool call for 72 hours and found that 37% had parameter mismatches that never raised an error. The model passed the wrong argument type, the tool silently coerced or ignored it, the response came back looking fine, and the agent continued on corrupted data. Consistent with 6.1: a coherent plan paired with a garbled payload, and no post-call surprise because the tool masked the drift. (Unconfirmed: developer blog report; the primary data could not be located.)
CrewAI Community (2024-2025). GitHub issues
What it establishes
Multiple CrewAI users reported agents calling tools with wrong parameters, including type mismatches, defaulted required fields, and dropped qualifiers from the stated plan. Root cause traced to incomplete tool descriptions and format changes between API versions. The dropped qualifiers and defaulted required fields are the 6.1 sign: the call was less specific than the plan. (Sources: CrewAI community forums and GitHub issues)
AgentWiki (2025-2026). Common Agent Failure Modes
What it establishes
Production telemetry cataloged tool-use failure modes including wrong tool selection, bad arguments with incorrect or incomplete parameters, and misinterpreted outputs leading to wrong actions. Cited decision fatigue from too many available tools as a root cause. (Sources: agentwiki.org knowledge base)
Zylos Research (2026). Tool Use and Function Calling Standards
What it establishes
Survey of tool-calling benchmarks found that most AI agent failures do not trace to bad reasoning but to the cognition-to-execution translation: the model understands the task, then calls the wrong tool, passes malformed arguments, gets an unhandled error, and produces a wrong answer anyway. Vague tool descriptions produce wrong selections; loose parameter types produce bad arguments. (Unconfirmed: industry research report; the primary source could not be located.)
Look-alikes
Cemri et al. (2025). Why Do Multi-Agent LLM Systems Fail? NeurIPS 2025. arxiv 2503.13657.
What it establishes
Cemri et al. annotated 1,642 execution traces from seven multi-agent frameworks and sorted 14 failure modes into three categories: system design issues, inter-agent misalignment, and task verification. MAST has no separate tool-interface category, so the study is context rather than direct evidence for 6.1. Its nearest analog is the system-design category (about 44% of recorded failures), where agents disregard the task or role they were given: intent lost between what a component was asked to do and what it did. (Sources: arxiv 2503.13657, NeurIPS 2025 proceedings)
Possible responses
- Extensive training on realistic tool interaction traces including failures and recovery
- Implementation of explicit state-tracking modules
- "Dry run" or simulation modes predicting action consequences
- Mandatory confirmation steps for irreversible actions
- Error detection and recovery training on failed tool calls and their error signals
- Architectures separating planning from execution
- Progressive capability expansion starting with reversible actions
First-line candidates
- Read-back / echo-back handshakes: Require the tool wrapper to return a natural-language restatement of the call it will execute; the subject must confirm before the side-effecting action proceeds. Converts silent drift into an observable checkpoint. Stage: Any tool-using agent with side effects; a direct form of mandatory confirmation before irreversible actions.
- Structured-output / schema-constrained calls: Enforce JSON-schema constraints on tool inputs, reject malformed calls, and require all non-optional fields. Forces the subject to surface missing context rather than silently defaulting. Stage: Any API/tool boundary the subject crosses.
Who can act: Deployer and harness developer (tool schemas, call validation, state tracking, confirmation gates); model developer (tool-use training).
Mechanistic hypotheses
- Training primarily on static text without grounding in dynamic tool interaction
- Insufficient exposure to realistic tool feedback, error modes, and environmental state changes
- Lack of reliable state-tracking mechanisms persisting across action sequences
- Attention mechanisms losing context over extended multi-step operations
- No training on the relationship between syntactic correctness and semantic appropriateness
- Many deployments lack reliable mechanisms for detecting or recovering from execution failures
Analogy and commentary
Human Analog: Apraxia (inability to perform learned purposeful movements despite understanding); errors in complex procedural tasks; the gap between knowing and doing
Functional ABC Analysis
A (Antecedent): The system must translate internal reasoning into structured API calls, tool parameters, or robotic effector commands. These cross interfaces with strict formatting requirements or asynchronous communication protocols.
B (Behavior): The system loses, truncates, or garbles crucial contextual information during the handoff, producing tool executions that visibly contradict its own stated plan: stray instructions fire, parameters arrive out of bounds.
C (Consequence): Poorly designed APIs accept malformed inputs without validation or error signaling. The absence of echo-back verification means errors go undetected until downstream consequences manifest. Each "successful" call may reinforce the flawed translation schema.
Potential Impact
Breakdowns in context transmission can lead to erroneous or actively harmful actions by connected tools or robotic effectors, risking financial loss, data corruption, system damage, or safety incidents.