Entity Binding Failures in Tool-Augmented Agents

Entity Binding Failures in Tool-Augmented Agents Rahul Suresh Babu

Shashank Indukuri

Independent Researcher United States of America [email protected]

Independent Researcher United States of America [email protected]

arXiv:2606.30531v1 [cs.AI] 29 Jun 2026

Abstract Tool-augmented language-model agents are often evaluated by whether they select the correct tool, produce valid API arguments, and complete the requested task. However, an agent may choose the right tool and still act on the wrong external entity. For example, a request to “email Alex about the launch” may lead the agent to contact the wrong Alex, attach the wrong launch document, reply in the wrong thread, or update the wrong customer account. We call these errors entity binding failures. This paper studies entity binding failures as a distinct reliability and safety problem in tool-augmented agents. We formalize the separation between tool correctness and entity correctness, introduce a taxonomy of wrong-entity failures in enterprise workflows, and evaluate entity-aware execution mechanisms including entity-resolution preconditions, confidence-gated binding, clarification under ambiguity, and provenance tracking. In a controlled diagnostic evaluation across 60 tasks, five model backends, and six tool-use methods, all methods achieved 0.0% wrong-tool error, yet action-oriented baselines still produced wrong-entity actions in 24.0–26.0% of runs. Entity-aware methods eliminated wrong-entity actions and risk-weighted wrong-entity exposure in this setting, but reduced direct task completion by deferring under ambiguity. These findings show that safe tool use requires not only selecting the correct tool, but also reliably binding natural-language references to the correct real-world entity before action. Index Terms Tool-augmented LLM agents, entity binding, entity resolution, wrong-entity failures, agent safety, function calling, ambiguity detection, disambiguation, provenance tracking, LLM reliability

I. I NTRODUCTION Tool-augmented language-model agents are increasingly expected to operate over external systems such as email, calendars, document repositories, issue trackers, customer databases, and enterprise applications [1]–[3]. In these settings, the agent must not only decide what action to take, but also identify the correct real-world entity on which the action should operate. This entity may be a person, email thread, calendar event, document, customer account, ticket, or other system object. Most existing evaluations of tool-augmented agents emphasize tool selection, API-call validity, planning, and end-to-end task success [3]–[6]. These dimensions are important, but they do not fully capture a common and safety-relevant class of failures: an agent can select the correct tool and still act on the wrong target. For example, given the instruction ‘email Alex about the launch,” an agent may correctly select an email-sending tool while binding ‘Alex” to the wrong person, “the launch” to the wrong project, or the message to the wrong email thread. Similarly, an agent may update the wrong version of a document, cancel the wrong calendar event, close the wrong issue, or modify the wrong customer record. In all of these cases, the tool choice may appear correct even though the external action is unsafe or incorrect. We call these errors entity binding failures: failures in which a natural-language reference is bound to the wrong external entity before action. Entity binding failures are distinct from wrong-tool failures. A wrong-tool failure occurs when the agent chooses an inappropriate action type, such as deleting an event instead of rescheduling it. An entity binding failure occurs when the action type is appropriate but the target is wrong, such as rescheduling the wrong event. This distinction matters because many real deployment harms are wrong-target harms rather than wrong-action harms. Sending information to the wrong recipient, editing the wrong file, updating the wrong account, or deleting the wrong record can have serious privacy, operational, financial, and reputational consequences. Entity binding is especially challenging in enterprise environments because user references are often underspecified, contextual, or ambiguous. Names collide across organizations, multiple documents share similar titles, old and new versions coexist, email threads overlap, customer accounts have subsidiaries, and project names appear across several systems at once. A human user may assume that ‘Alex,” ‘the launch doc,” or “tomorrow’s sync” is obvious from context, while the agent must infer the intended entity from incomplete metadata, conversational history, and external-system state. When multiple plausible candidates exist, acting without clarification can be dangerous; asking too often, however, can make the agent unnecessarily burdensome. This creates a safety–usability tradeoff that is not captured by tool-selection metrics alone. This paper studies entity binding failures as a first-class reliability and safety problem for tool-augmented agents. We formalize the separation between tool correctness and entity correctness, define entity binding failures, and introduce a taxonomy of ambiguity patterns that produce wrong-entity actions. We then evaluate entity-aware execution mechanisms that require the target entity to be resolved before external action. These mechanisms include entity-resolution preconditions, confidence-gated binding, clarification under ambiguity, and entity provenance tracking.

To evaluate these mechanisms, we construct a controlled diagnostic testbed spanning email, calendar, document, customerrecord, and issue-tracking tasks. The testbed is designed to isolate cases where the correct tool is available but the intended entity is ambiguous, underspecified, or confusable with nearby alternatives. We compare six tool-use methods across 60 diagnostic tasks and five model backends using metrics that separate tool correctness from entity correctness, including wrong-entity action rate, ambiguity detection, over-clarification, task success, safe success, and risk-weighted wrong-entity exposure. We interpret the comparison as a safety–completion tradeoff: action-oriented methods measure wrong-entity exposure under direct execution, while entity-aware methods are allowed to defer when the binding is unresolved. This work makes the following contributions: • We identify and define entity binding failures as a distinct failure mode in tool-augmented language-model agents: cases where the agent selects the correct tool but applies it to the wrong external entity. • We formalize the difference between tool correctness and entity correctness, showing how agents can succeed under conventional tool-use metrics while still acting on the wrong external entity. • We introduce a taxonomy of wrong-entity failure modes across common enterprise workflows, including name collisions, document-version ambiguity, temporal ambiguity, account collisions, near-duplicate records, cross-system references, and true ambiguity. • We evaluate entity-aware execution mechanisms, including entity-resolution preconditions, confidence-gated binding, clarification under ambiguity, and provenance tracking. • We show in a controlled diagnostic evaluation that action-oriented baselines produce wrong-entity actions in 24.0–26.0% of runs despite 0.0% wrong-tool error, while entity-aware methods eliminate wrong-entity actions and risk-weighted wrong-entity exposure in this setting. Together, these contributions argue that safe tool use requires more than selecting the correct tool. Tool-augmented agents must also reliably bind natural-language references to the correct real-world entity before taking external action. II. BACKGROUND Tool-augmented language-model agents extend language models with the ability to call external tools, query structured systems, retrieve information, and execute actions in interactive environments. Early work showed that language models can improve their capabilities by learning when to invoke external tools such as calculators, search engines, and translation systems [1]. Agentic prompting methods further combine reasoning traces with environment actions, enabling models to interleave natural-language reasoning with tool calls and observations from external systems [2]. As these systems move from information-seeking tasks toward enterprise workflows, the agent’s output is no longer merely text: it may become an external action that sends a message, edits a file, updates a record, schedules a meeting, or changes the state of an application. Existing tool-use benchmarks primarily evaluate whether agents can retrieve relevant APIs, select appropriate tools, generate valid tool calls, plan multi-step actions, and complete user tasks. API-Bank evaluates planning, API retrieval, and API calling in tool-augmented dialogues [4]. ToolLLM and ToolBench study large-scale tool-use learning and evaluation over many real-world APIs [3]. Gorilla and APIBench focus on accurate API invocation and reducing hallucinated API calls over large and evolving API spaces [5]. More recent interactive benchmarks, such as τ -bench, evaluate agents in realistic user–tool–agent settings with domain rules and stateful task completion [6]. These benchmarks are important for measuring tool-use competence, but they do not isolate whether the agent has bound the user’s natural-language reference to the correct external entity before acting. Recent work has also studied how the visible tool menu affects agent reliability. Causal Minimal Tool Filtering (CMTF) exposes only the next causally necessary tool frontier, reducing tool-choice confusion, premature actions, and token cost [7]. ToolMenuBench studies tool-menu construction as an agent-interface problem, measuring how menu size, distractors, statedependent task structure, and risk exposure affect downstream agent behavior [8]. Contract2Tool studies how precondition-effect contracts can be inferred from tool metadata, schemas, documentation, and execution traces [9], while GIST-CMTF extends causal filtering by inferring the intended goal state before exposing tools [10]. These approaches address which tool should be visible, when it should be used, and whether the intended goal state has been inferred. They do not isolate the case where the selected tool and goal are correct, but the action is applied to the wrong external entity. Entity binding is related to long-standing work on entity linking, entity disambiguation, and entity resolution. Entity linking maps textual mentions to canonical entities in a knowledge base, while entity resolution identifies records that refer to the same underlying object across noisy databases [11], [12]. These problems are also central to semantic parsing and knowledge-base question answering, where systems must map language to structured entities, relations, and executable queries [13]. However, tool-augmented agents introduce a different deployment setting. The binding decision is made inside an action loop, often under ambiguity, and an incorrect binding may immediately trigger an externally visible or irreversible action. Unlike offline entity linking, action-time entity binding must also decide whether to act, defer, or ask for clarification. This distinction motivates the focus of this paper. In enterprise settings, many failures are not caused by selecting the wrong tool, but by selecting the wrong target for an otherwise correct tool. A model may choose the correct email tool but send to the wrong Alex, choose the correct document-editing tool but modify the wrong version of a file, or choose the correct calendar

tool but cancel the wrong event. Such failures are difficult to detect with metrics that only measure tool selection, argument validity, or final task completion. We therefore separate two questions that are often conflated in tool-use evaluation: whether the agent selected the correct action type, and whether it correctly grounded that action to the intended external entity. This paper studies failures of the second kind. We argue that entity binding should be treated as a first-class reliability and safety requirement for tool-augmented agents, especially when actions are externally visible, irreversible, privacy-sensitive, or customer-impacting. III. P ROBLEM F ORMULATION We consider a tool-augmented agent that receives a natural-language instruction and acts over an external environment. The environment may include people, email threads, documents, calendar events, customer accounts, issue tickets, or other actionable system objects. To complete a task safely, the agent must make two distinct decisions: it must select the appropriate tool or action type, and it must bind the user’s natural-language references to the intended external entities. Let u denote the user instruction, S denote the current environment state, T denote the set of available tools, and E(S) denote the set of candidate entities available in the environment. Each entity e ∈ E(S) has an identifier and metadata, such as a name, owner, timestamp, email address, document title, event time, account ID, or ticket status. We represent an executed action as a = ⟨t, B̂, x⟩, where t ∈ T is the selected tool, B̂ is the set of predicted entity bindings, and x denotes non-entity arguments. The agent may also decline to execute and instead issue a clarification request or safe deferral. A conventional tool-use evaluation often focuses on whether the selected tool is correct. Let t⋆ denote the correct tool or action type for the task. For an executed action a, we define tool correctness as ToolCorrect(a) = 1 [t(a) = t⋆ ] . Tool correctness alone is insufficient. The agent must also identify the correct target entity. For the single-entity case, let ê(a) be the entity selected by the agent and let e⋆ be the intended entity. We define entity correctness as EntityCorrect(a) = 1 [ê(a) = e⋆ ] . An entity binding failure occurs when the agent selects the correct tool but binds the instruction to the wrong entity: EntityBindingFailure(a) = 1 [t(a) = t⋆ ∧ ê(a) ̸= e⋆ ] . This captures the “right tool, wrong target” failure mode. For example, an agent may correctly choose an email-sending tool but send the message to the wrong Alex, correctly choose a document-editing tool but modify the wrong file version, or correctly choose a calendar-update tool but reschedule the wrong meeting. This formulation separates four possible executed-action outcomes: Tool Correct? 0 0 1 1

Entity Correct? 0 1 0 1

Outcome wrong tool and wrong entity wrong tool entity binding failure successful grounded action

The third case is the focus of this work. It is especially important because it can be hidden by evaluations that inspect only tool choice, syntactic API validity, or final task completion. Many tasks contain multiple entity references. For example, “send Alex the latest launch document” requires binding both a recipient entity and a document entity. More generally, let M (u) = m1 , . . . , mk be the set of entity mentions in the instruction, and let B ⋆ = e⋆1 , . . . , e⋆k be the intended bindings for a resolvable task. The agent produces predicted bindings B̂ = ê1 , . . . , êk . A multi-entity binding failure occurs if at least one required binding is incorrect: MultiEntityFailure(a) = 1 [∃i ∈ 1, . . . , k : êi (a) ̸= e⋆i ] .

Instruction u and state S

Entity preconditions

Tool proposal

Candidate entities

resolved

Binding resolution

Action gate

Execute tool call

missing or ambiguous

Clarify or defer

Fig. 1. Entity-aware action gate. A proposed tool call executes only when required entity preconditions are satisfied and the target entity is resolved; otherwise the safe next step is clarification or deferral.

Thus, a multi-entity action is safely grounded only when all required entity bindings are correct. Entity binding may also be ambiguous. For each mention m, we define a candidate set C(m, S) ⊆ E(S) containing entities that remain plausible after applying the available instruction context and environment metadata. A mention is ambiguous when more than one candidate remains plausible: Ambiguous(m, S) = 1 [|C(m, S)| > 1] . For resolvable tasks, the annotation contains a unique intended binding B ⋆ . For truly ambiguous tasks, no unique binding can be recovered from the instruction and environment state alone. In these cases, the expected safe behavior is clarification rather than execution. If an agent executes a concrete action under true ambiguity, we treat that execution as unsafe because the agent has guessed a target that the user did not uniquely specify. Clarification is therefore part of the safety objective rather than merely a failure to complete the task. A safe agent should act when the entity binding is sufficiently grounded, ask for clarification when the intended entity is unresolved, and avoid unnecessary clarification when the intended entity is already clear. Finally, not all wrong-entity actions have the same severity. Reading the wrong document, sending a message to the wrong recipient, updating the wrong customer account, and deleting the wrong calendar event have different consequences. We therefore associate each tool-action pair with a risk weight r(t). A risk-weighted entity binding error is RiskWeightedEBF(a) = r(t) · 1 [t(a) = t⋆ ∧ ê(a) ̸= e⋆ ] . This allows evaluation to distinguish low-risk binding errors from externally visible, irreversible, privacy-sensitive, or customerimpacting wrong-target actions. The goal of this work is to evaluate whether entity-aware execution policies can reduce wrong-entity actions while preserving useful task completion and avoiding unnecessary clarification. IV. M ETHOD We study an entity-aware execution policy that prevents external actions from executing until the relevant target entities have been resolved with sufficient evidence. The method is motivated by a simple principle: a tool call should be permitted only when both the action type and the action target are grounded. Conventional tool-augmented agents may select a tool and immediately produce arguments for execution. In contrast, our agent inserts an entity-aware action gate between tool selection and tool execution. Given a user instruction u, environment state S, and available tools T , the agent first proposes or receives a candidate tool t. The gate then identifies the entity preconditions required by that tool, retrieves plausible candidate entities for each mention, evaluates whether the binding is resolved, records provenance evidence, and either permits execution or returns a clarification request. The gate can be implemented using retrieval rules, model-based scoring, structured prompting, or hybrid components. The key requirement is that entity resolution is explicit and checked before any external action is taken. A. Entity-Resolution Preconditions Each tool is associated with a set of entity-resolution preconditions. These preconditions specify which entity types must be resolved before the tool can be safely executed. For example, an email-sending tool may require a recipient entity, optionally use a thread entity, and optionally include attachment entities. A document-update tool may require a document entity, while a calendar-cancellation tool may require a calendar event entity. Formally, each tool t has an entity precondition set PE (t) = p1 , p2 , . . . , pk ,

where each precondition pi specifies an entity type and whether the entity is mandatory or optional. For example,

PE (send_email) = {recipient:person:required, thread:email_thread:optional, attachment:document:opti A proposed tool call is executable only if every mandatory precondition has a matching resolved entity binding: h i PreconditionsSatisfied(t, B̂) = 1 ∀pi ∈ PE (t), ; pi is optional ∨ ∃êi ∈ B̂ : Type(êi ) = Type(pi ) . This prevents the model from silently inserting an unresolved name, title, account, or event into an API call. Each actionable target must be grounded to a concrete entity identifier before execution. B. Candidate Entity Retrieval For each entity mention m in the user instruction, the system retrieves a candidate set C(m, S) from the environment. Candidate retrieval may use exact metadata matches, lexical similarity, semantic retrieval, temporal filters, ownership metadata, conversation history, or domain-specific constraints. For example, the mention ‘Alex” may retrieve people named Alex from contacts, recent email threads, calendar attendees, or an organizational directory. The mention ‘the launch doc” may retrieve documents whose title, project metadata, owner, or recent activity matches the launch context. Candidate retrieval is recall-oriented: it should preserve plausible candidates rather than prematurely collapsing ambiguity to a single entity. The downstream gate decides whether the evidence is strong enough to act or whether clarification is required. C. Binding Resolution Given a mention m and a candidate entity e ∈ C(m, S), the agent estimates a binding score s(m, e, S) ∈ [0, 1], representing how confidently e matches the user’s intended reference. This score may be produced by a language model, retrieval model, rule-based metadata checks, or a hybrid scoring function. The selected entity is ê = arg max s(m, e, S). e∈C(m,S)

Selecting the highest-scoring candidate is not sufficient when multiple candidates remain plausible. We define a binding as resolved only if it satisfies both an absolute confidence condition and a margin condition: s(m, ê, S) ≥ τ and s(m, ê, S) − s(m, e2 , S) ≥ δ, where e2 is the second-highest scoring candidate, τ is the minimum confidence threshold, and δ is the minimum separation margin. The confidence threshold prevents weak bindings, while the margin condition prevents execution when two candidates are nearly tied. We write Resolved(m, ê, S) = 1 when both conditions hold and the binding is supported by sufficient entity metadata. In the diagnostic implementation, confidence-gated behavior is operationalized through structured prompts and explicit candidate comparisons rather than a separately trained calibration model. The score notation represents the abstract decision rule and can be instantiated with learned or rule-based scoring in future systems. D. Entity-Aware Action Gate The action gate decides whether a proposed tool call should execute. A tool call is permitted only when the selected tool is available, all mandatory entity-resolution preconditions are satisfied, and every required entity mention is resolved. For a proposed action a = ⟨t, B̂, x⟩, where B̂ is the set of predicted entity bindings and x denotes non-entity arguments, the gate is h i Execute(a) = 1 PreconditionsSatisfied(t, B̂) ∧ ∀mi ∈ M (u, t), ; Resolved(mi , êi , S) . If the gate returns true, the action may proceed. If the gate returns false because required bindings are missing, ambiguous, or insufficiently supported, the agent must not execute the external action. Instead, it asks for clarification or returns a safe deferral. For truly ambiguous tasks, clarification is the expected safe behavior because no unique target can be recovered from the instruction and environment state alone.

E. Clarification Under Ambiguity When multiple candidate entities remain plausible, the gate returns a clarification request rather than permitting direct execution. The clarification should be specific, minimal, and grounded in candidate metadata. For example, rather than asking ‘Which Alex do you mean?”, the agent may ask: ‘Do you mean Alex Chen from the launch team or Alex Kumar from customer success?” Clarification is especially important for high-risk actions such as sending externally visible messages, editing shared documents, updating customer records, cancelling meetings, or deleting objects. In lower-risk read-only settings, a system may choose to return multiple candidates or ask a lighter clarification question. In this work, clarification is evaluated as a safetypreserving alternative to uncertain execution. F. Entity Provenance Tracking For every resolved binding, the system records provenance evidence explaining why a candidate entity was selected. Provenance may include metadata fields such as entity ID, display name, email address, document title, owner, timestamp, thread subject, calendar time, account ID, ticket number, or recent interaction evidence. We define the provenance record for a binding as π(m, ê) = z1 , z2 , . . . , zn , where each zi is a piece of evidence supporting the mapping from mention m to entity ê. Provenance serves three purposes. First, it helps distinguish between similar candidates. Second, it enables auditing after an action is taken. Third, it supports safer clarification by allowing the agent to present meaningful candidate differences to the user. In the entity-aware CMTF with provenance variant, execution requires not only a selected entity but also evidence sufficient to justify the binding. G. Entity-Aware Causal Minimal Tool Filtering We instantiate the action gate as an entity-aware extension of Causal Minimal Tool Filtering (CMTF). Standard tool filtering exposes tools based on task relevance or state-dependent preconditions. Entity-aware filtering adds entity-resolution requirements to the visibility and execution decision. A tool may be causally relevant, but still unsafe for direct execution if its required entity bindings are unresolved. Let Relevant(t, u, S) indicate that tool t is causally relevant to the user instruction under state S. Let EntityReady(t, u, S) indicate that the required entity bindings for t are resolved or can be routed through a clarification step. The entity-aware visible tool set is Tentity (u, S) = t ∈ T : Relevant(t, u, S) ∧ EntityReady(t, u, S). This differs from conventional tool filtering because the admissible next step may be clarification rather than direct execution. For example, send_email may be the correct tool for “email Alex,” but direct execution should be gated if multiple candidate recipients named Alex exist. H. Algorithm Algorithm 1 summarizes the entity-aware action gate. The method is intentionally modular. Candidate retrieval, confidence scoring, provenance generation, and clarification can be implemented using different models or rule-based components. The contribution is the execution policy: entity resolution is made explicit, checked before action, and allowed to produce clarification when the target entity is unresolved. V. E XPERIMENTAL S ETUP We evaluate entity binding failures using a controlled diagnostic testbed designed to isolate the “right tool, wrong target” failure mode. The goal is not to introduce a large-scale benchmark, but to measure whether tool-augmented agents can bind natural-language references to the correct external entities before action. The evaluation spans 60 diagnostic tasks, five model backends, and six tool-use methods, producing 1,800 model–method–task runs. A. Diagnostic Testbed Each task consists of a user instruction, an environment state, a set of available tools, a set of candidate entities, task annotations, and an expected safe behavior. The environment state simulates common enterprise systems containing people, email threads, documents, calendar events, customer accounts, and issue tickets. Each entity is represented with structured metadata such as name, title, owner, timestamp, email address, account ID, thread subject, document version, event time, or ticket status. For resolvable tasks, the annotation specifies the correct tool and the intended entity binding or binding set. A task is successful only if the agent selects the correct action type and binds all required entity references to the intended external entities. For true-ambiguity tasks, no unique target entity is recoverable from the instruction and environment state alone; the expected safe behavior is clarification or deferral rather than execution.

Algorithm 1 Entity-Aware Action Gate Require: User instruction u, environment state S, tool set T 1: Select candidate tool t from the admissible tool set 2: Retrieve entity preconditions PE (t) 3: Extract required entity mentions M (u, t) 4: for each mention mi ∈ M (u, t) do 5: Retrieve candidate entities C(mi , S) 6: Score each candidate e ∈ C(mi , S) using s(mi , e, S) 7: Select êi ← arg max s(mi , e, S) e∈C(mi ,S)

8: Record provenance π(mi , êi ) 9: if Resolved(mi , êi , S) = 0 then 10: Ask a clarification question using candidate metadata 11: return Deferred 12: end if 13: end for 14: if PreconditionsSatisfied(t, B̂) = 1 then 15: Execute tool call t(B̂, x) 16: return Executed 17: else 18: Ask for missing entity information 19: return Deferred 20: end if

B. Domains We include five enterprise-style domains that commonly require entity grounding before action: • Email: selecting recipients, choosing the correct thread, replying to the correct conversation, and attaching the correct document. • Calendar: identifying meetings, recurring events, attendees, and event instances before scheduling, rescheduling, or cancellation. • Documents: selecting the correct document, folder, owner, or version before reading, sharing, editing, or deletion. • Customer records: identifying the correct account, customer, subsidiary, opportunity, or renewal record before updating structured fields. • Issue tracking: selecting the correct ticket, bug, incident, or feature request before commenting, assigning, closing, or escalating. These domains were chosen because the same natural-language reference can often correspond to multiple plausible entities, and because wrong-entity actions can have externally visible or customer-impacting consequences. C. Task Construction Tasks are constructed to vary the level and type of entity ambiguity. Each task contains one or more natural-language entity mentions, such as a person name, project name, document title, meeting description, customer account, or ticket reference. The environment includes the intended entity when the task is resolvable, as well as distractor entities that are plausible under surface-form, semantic, temporal, ownership, or cross-system similarity. We use the following ambiguity conditions: • Unambiguous: only one candidate entity plausibly matches the instruction. • Name collision: multiple people or objects share the same or similar names. • Document-version ambiguity: multiple versions or similarly titled documents are plausible targets. • Temporal ambiguity: the correct entity depends on recency, date, version, or event instance. • Account collision: multiple customer, account, subsidiary, or opportunity records are plausible. • Near-duplicate entity: multiple candidates have highly similar titles, descriptions, or metadata. • Cross-system ambiguity: the same project or entity name appears across multiple systems. • True ambiguity: multiple candidates remain plausible and no unique target can be recovered without asking the user. Each task is annotated with the correct tool, required entity bindings when resolvable, ambiguity condition, expected safe behavior, and action-risk level.

Risk Level Low Medium High Critical

Action Type read / retrieve draft / prepare send / share / update delete / cancel / close

Example Wrong-Entity Harm opening the wrong document or ticket drafting against the wrong thread or account sending to the wrong recipient or editing the wrong record deleting, cancelling, or closing the wrong entity

TABLE I ACTION - RISK LEVELS USED IN THE DIAGNOSTIC EVALUATION .

D. Action Types and Risk Levels The action types include retrieval, drafting, sending, sharing, updating, assigning, closing, rescheduling, deleting, and cancelling. Each task is assigned a risk level based on the consequence of acting on the wrong entity. This risk stratification allows us to measure not only whether an agent makes wrong-entity errors, but whether those errors occur in settings where the consequences are more severe. E. Methods Compared We compare six tool-use methods: • Direct: the agent receives the user instruction, environment state, and available tools, then directly produces a tool call. • Semantic filter: tools are filtered by semantic relevance to the user instruction before the agent acts. • CMTF only: tools are filtered using causal or state-dependent relevance, without explicit entity-resolution gating. • Entity retrieval: the agent receives retrieved candidate entities and selects an entity during tool-call generation. • Confidence gate: the agent may execute only when the selected entity is sufficiently supported relative to alternatives; otherwise it defers. • Entity CMTF + provenance: tool visibility and execution are conditioned on entity preconditions, and the agent must record evidence supporting each entity binding before action. The direct, semantic-filter, CMTF-only, and entity-retrieval methods are action-oriented baselines: they are evaluated under a direct-execution policy in which the agent must choose a concrete tool call and entity binding. The entity-aware methods are allowed to defer or ask for clarification when the binding is unresolved. We therefore interpret the comparison as a safety–completion tradeoff rather than a pure task-completion ranking. F. Models We evaluate five model backends: Amazon Nova 2 Lite, Amazon Nova Premier, Claude Opus, Claude Sonnet, and Llama 3.3 70B Instruct. All models are evaluated using the same task set, tool schemas, entity stores, prompts, output format, and scoring scripts. G. Evaluation Protocol For each task, the agent receives the user instruction, the relevant tool schema or filtered tool set, and the environment state according to the method being evaluated. The agent may execute a tool call, ask a clarification question, or defer action when the method permits deferral. We log the selected tool, selected entity identifiers, candidate entities exposed to the model, final action, clarification behavior, and provenance evidence when applicable. A run is marked as a wrong-tool error if the agent selects an incorrect action type. A run is marked as a wrong-entity action if the agent executes the correct tool but uses an entity identifier that does not match the annotated ground truth. For true-ambiguity tasks, any concrete execution on a specific entity is counted as unsafe because the instruction does not uniquely identify a target. A run is marked as over-clarification if the agent asks for clarification on an unambiguous task whose intended entity is recoverable from the provided state. H. Metrics We report the following metrics: • Task success: fraction of runs where the agent selects the correct tool, binds all required entities correctly, and completes the requested action. • Safe success: fraction of runs where the agent either completes a resolvable task correctly or correctly clarifies/defers on a truly ambiguous task. • Wrong-tool rate: fraction of runs where the agent selects an incorrect tool or action type. • Wrong-entity action rate: fraction of runs where the agent selects the correct tool but acts on the wrong entity. • Ambiguity detection rate: fraction of ambiguous runs where the agent identifies that the reference is under-specified or confusable.

Over-clarification rate: fraction of unambiguous runs where the agent unnecessarily asks for clarification. Risk-weighted wrong-entity exposure: wrong-entity actions weighted by the annotated severity of the action type. Together, these metrics separate tool-use competence from entity-binding competence and expose failures that would be hidden by conventional tool-selection or API-validity metrics alone. • •

I. Research Questions The experiments are organized around five research questions: • RQ1: How often do agents make wrong-entity errors when the selected tool is correct? • RQ2: Does ordinary tool filtering reduce wrong-entity failures? • RQ3: Do entity-aware execution policies reduce wrong-entity action rates? • RQ4: What safety–completion tradeoff emerges when agents defer under unresolved ambiguity? • RQ5: Which ambiguity conditions and action types produce the highest wrong-entity risk? VI. R ESULTS We evaluate entity binding failures across 1,800 model–method–task runs, covering 60 diagnostic tasks, five model backends, and six tool-use methods. The evaluation is designed to separate wrong-entity behavior from wrong-tool behavior. Each task has a known target tool, each resolvable task has one or more annotated target entity bindings, and true-ambiguity tasks are annotated with clarification or deferral as the expected safe behavior. A. Overall Results Table II summarizes the aggregate results across all models and tasks. A key finding is that all methods achieve a wrong-tool rate of 0.0%. This confirms that, under this diagnostic setup, the observed failures are not driven by wrong-tool selection. Instead, the main failure mode is wrong-entity execution after the correct tool has already been selected. Action-oriented baselines frequently act on the wrong entity. The direct baseline produces wrong-entity actions in 26.0% of runs, and entity retrieval produces the same wrong-entity rate of 26.0%. CMTF-only filtering slightly reduces the wrong-entity rate to 25.7%, while semantic filtering reduces it to 24.0%. These results show that retrieval and tool filtering alone do not reliably solve entity binding: exposing a more relevant tool or candidate set does not ensure that the agent binds the action to the correct target. In this diagnostic setting, entity-aware methods eliminate wrong-entity actions. Confidence-gated binding and entity-aware CMTF with provenance both achieve 0.0% wrong-entity rate and 0.0 risk-weighted wrong-entity exposure. This supports the central hypothesis of the paper: reliable tool use requires not only selecting the correct tool, but also verifying that the tool is bound to the correct external entity before execution. Method Task Succ. Safe Succ. Wrong Tool Wrong Entity Ambig. Detect. Over Clar. Risk W-Ent. Direct 74.0 74.0 0.0 26.0 0.0 0.0 1.123 Semantic filter 75.0 75.7 0.0 24.0 1.0 0.0 1.037 CMTF only 74.3 74.3 0.0 25.7 0.0 0.0 1.110 Entity retrieval 74.0 74.0 0.0 26.0 0.0 0.0 1.123 Confidence gate 31.7 40.0 0.0 0.0 68.3 0.0 0.000 Entity CMTF+Prov. 26.0 34.3 0.0 0.0 74.0 0.0 0.000

TABLE II AGGREGATE PERFORMANCE ACROSS 1,800 MODEL – METHOD – TASK RUNS . TASK SUCCESS , SAFE SUCCESS , WRONG - TOOL RATE , WRONG - ENTITY RATE , AMBIGUITY DETECTION , AND OVER - CLARIFICATION ARE REPORTED AS PERCENTAGES . R ISK W-E NT. DENOTES RISK - WEIGHTED WRONG - ENTITY EXPOSURE . E NTITY CMTF+P ROV. DENOTES ENTITY- AWARE CMTF WITH PROVENANCE .

Entity CMTF+Prov.

0%

Confidence gate

0%

Entity retrieval

26%

CMTF only

25.7% 24%

Semantic filter

26%

Direct 0

2

4

6

8

10

12

14

16

18

20

22

24

26

28

Wrong-entity action rate (%)

Fig. 2. Wrong-entity action rate by method. Action-oriented baselines produce wrong-entity actions in roughly one quarter of runs despite zero wrong-tool errors, while entity-aware methods eliminate wrong-entity execution in this diagnostic setting.

30

B. Safety–Completion Tradeoff The results reveal a clear safety–completion tradeoff. Action-oriented baselines complete more tasks directly, with task success between 74.0% and 75.0%. However, this apparent completion comes with substantial wrong-entity exposure. In contrast, confidence-gated binding achieves 31.7% task success and 40.0% safe success, but eliminates wrong-entity actions. Entity-aware CMTF with provenance is more conservative, achieving 26.0% task success and 34.3% safe success while also eliminating wrong-entity actions. Because action-oriented baselines are evaluated under direct execution while entity-aware methods may defer, these results should be interpreted as a safety–completion tradeoff rather than a single task-completion ranking. Entity-aware methods are designed to refuse action when the entity binding is uncertain instead of guessing. In high-risk enterprise settings, such deferral may be preferable to silent execution on the wrong customer, document, event, account, or thread. The absence of over-clarification is also important. Both entity-aware methods achieve 0.0% over-clarification, indicating that they do not ask for clarification on unambiguous tasks in this evaluation. Their lower direct completion rate comes from refusing to act when ambiguity or insufficient evidence remains, not from adding unnecessary friction to clear requests. C. Failure Modes by Ambiguity Type Wrong-entity failures are concentrated in specific ambiguity classes rather than uniformly distributed across tasks. Temporal calendar tasks and true-ambiguity tasks are the most difficult. For temporal tasks, direct and entity-retrieval methods produce wrong-entity actions in 100.0% of runs, while CMTF-only produces wrong-entity actions in 97.5% of runs and semantic filtering in 90.0%. These failures typically involve choosing a plausible but incorrect launch-related calendar event. True-ambiguity tasks are even more safety-critical. In these tasks, no unique entity is recoverable from the instruction and environment state alone; therefore, any concrete execution is unsafe, and clarification is the expected safe behavior. Direct, entity-retrieval, and CMTF-only methods execute incorrectly in 100.0% of true-ambiguity runs, while semantic filtering executes incorrectly in 92.0%. By contrast, both entity-aware methods detect ambiguity in 100.0% of true-ambiguity runs and achieve 100.0% safe success by asking for clarification rather than executing a risky action. Name-collision and cross-system tasks also produce wrong-entity failures for action-oriented methods, but at lower rates than temporal and true-ambiguity tasks. These results suggest that entity binding failures are most severe when the correct entity depends on temporal context, implicit reference resolution, or unresolved ambiguity. Condition Direct Sem. CMTF Ent. Ret. Conf. Ent. CMTF Unambiguous 0.0 0.0 0.0 0.0 0.0 0.0 Name collision 20.0 20.0 20.0 20.0 0.0 0.0 Document version 0.0 0.0 0.0 0.0 0.0 0.0 Temporal 100.0 90.0 97.5 100.0 0.0 0.0 Account collision 0.0 0.0 0.0 0.0 0.0 0.0 Near duplicate 0.0 0.0 0.0 0.0 0.0 0.0 Cross-system 20.0 20.0 20.0 20.0 0.0 0.0 True ambiguity 100.0 92.0 100.0 100.0 0.0 0.0

TABLE III W RONG - ENTITY ACTION RATE BY AMBIGUITY CONDITION . VALUES ARE REPORTED AS PERCENTAGES . E NT. R ET. DENOTES ENTITY RETRIEVAL , C ONF. DENOTES CONFIDENCE - GATED BINDING , AND E NT. CMTF DENOTES ENTITY- AWARE CMTF WITH PROVENANCE .

D. Model-Level Trends Wrong-entity failures appear across all evaluated model families, although rates vary by backend. This indicates that entity binding is not merely a weakness of a single model. Importantly, every model has zero wrong-tool errors in the aggregate evaluation, reinforcing that the observed failures are specifically entity-binding failures rather than tool-selection failures. We do not interpret model-level differences as stable rankings because model behavior may change with prompting, runtime configuration, and provider updates. The more important finding is qualitative: across model backends, action-oriented methods can produce wrong-entity actions even when wrong-tool errors are absent, while entity-aware execution policies prevent wrongentity execution in this diagnostic setting. E. Representative Wrong-Entity Errors Representative logged failures show several recurring patterns. In temporal calendar tasks, models often call the correct rescheduling tool but bind it to an internal launch-sync event rather than the intended launch event. In true-ambiguity document deletion tasks, models call the correct deletion tool but choose one plausible old launch-plan document even though multiple old launch-plan documents are available. In name-collision tasks, models call the correct email-sending tool but select the wrong Alex. These cases illustrate why tool correctness alone is insufficient: the outward API call may look valid, while the real-world target is wrong.

F. Summary of Findings The experimental results support three main findings. First, wrong-entity failures occur even when wrong-tool errors are eliminated. Second, retrieval and tool filtering alone do not reliably prevent wrong-entity actions. Third, entity-aware gating and provenance-based checks eliminate wrong-entity execution in this diagnostic setting, but introduce conservative deferral on unresolved ambiguous tasks. These findings motivate treating entity binding as a first-class reliability and safety layer in tool-augmented LLM agents. VII. D ISCUSSION The results show that entity binding failures are a distinct and practically important failure mode in tool-augmented LLM agents. In our diagnostic setting, all methods achieve a wrong-tool rate of 0.0%, yet action-oriented methods still produce wrong-entity actions in roughly one quarter of runs. This separation is central: an agent can select the correct API, produce syntactically valid arguments, and appear to follow the user request while still acting on the wrong real-world target. In enterprise workflows, the harm is often attached not only to what action is taken, but to who or what the action is taken on. A. Tool Correctness Is Not Sufficient Most tool-use evaluations focus on whether the agent selects the correct tool, produces valid arguments, or completes the task. Our results show that these criteria are incomplete. A valid call to send_email is not safe if the recipient is the wrong Alex. A valid call to delete_document is not safe if the agent deletes the wrong launch plan. A valid call to reschedule_event is not safe if the agent moves the wrong calendar event. This distinction changes how tool-agent reliability should be measured. Tool correctness should be decomposed into at least two components: choosing the right operation and binding that operation to the right external entity. Evaluations that measure only tool selection or API validity can miss failures where the outward tool call is correct but the real-world target is wrong. B. Retrieval and Filtering Are Not Enough The results also show that exposing the agent to more relevant context does not automatically solve entity binding. Entity retrieval performs similarly to direct prompting in aggregate, producing a wrong-entity rate of 26.0%. CMTF-only and semantic filtering improve this only slightly, with wrong-entity rates of 25.7% and 24.0%, respectively. These methods help organize the tool or context space, but they do not require the agent to verify that a specific entity binding is sufficiently supported before acting. This suggests that entity binding is not merely a retrieval problem. Retrieval can surface candidate entities, but it does not decide whether the request uniquely identifies one of them. Similarly, tool filtering can remove irrelevant tools, but it does not resolve ambiguity among plausible entities. In ambiguous or near-ambiguous workflows, the agent needs an explicit execution policy for deciding when an entity is grounded strongly enough to permit action. C. Entity-Aware Gating Trades Completion for Safer Execution Entity-aware methods change the failure mode. In this diagnostic setting, confidence-gated binding and entity-aware CMTF with provenance eliminate wrong-entity actions and reduce risk-weighted wrong-entity exposure to 0.0. They do not achieve this by completing every task. Instead, they defer execution when the entity binding is unresolved. This behavior is especially important for high-risk and critical actions. In true-ambiguity cases, no unique entity can be recovered without additional user input. Action-oriented baselines nevertheless execute the requested operation, while entityaware methods treat ambiguity as a blocking condition. For actions such as deleting documents, cancelling events, modifying customer records, or sending externally visible communication, clarification is often preferable to silent execution on the wrong entity. The tradeoff is lower direct task completion. Action-oriented methods achieve higher task success because they are evaluated under direct execution, but some of that completion comes from guessing. Entity-aware methods achieve lower task success because they refuse to act when the binding is insufficiently grounded. This should be interpreted as a safety–completion tradeoff rather than a single accuracy ranking. The relevant objective is calibrated execution: act when the binding is sufficiently grounded, and clarify when it is not. A notable result is that over-clarification is 0.0% in our evaluation. The entity-aware methods do not ask for clarification on unambiguous tasks. Their conservatism appears primarily on ambiguous or insufficiently grounded tasks, suggesting that entity-aware gating can reduce unsafe execution without necessarily adding unnecessary friction to clear requests.

D. Where Entity Binding Fails The strongest wrong-entity effects appear in temporal and true-ambiguity tasks. Temporal tasks are difficult because the correct entity depends on contextual cues such as time, meeting purpose, participant set, recency, or event instance. Trueambiguity tasks are different: the request itself lacks enough information to identify a unique target. In those cases, any concrete action is unsafe unless the user clarifies. Name collisions and cross-system references also produce wrong-entity failures. These cases are common in enterprise environments, where multiple people can share a first name, multiple documents can have similar titles, and the same project may appear in email, calendar, document, ticketing, and customer-record systems. The results suggest that entity binding should be treated as a cross-system grounding problem rather than a local string-matching problem. E. Implications for Agent Design The findings point to several design implications for tool-augmented agents. First, entity resolution should be represented explicitly in the agent control loop. Before executing a tool call, the agent should identify candidate entities, determine the intended binding, and assess whether the binding is sufficiently grounded. Second, clarification should be treated as a valid safety-preserving outcome, not merely as failed task completion. If a user asks to “delete the old launch plan” and several old launch plans exist, the safe behavior is to ask which document they mean. Benchmarks and production systems should therefore distinguish between failed execution and safe deferral. Third, provenance matters. High-impact actions should be linked to evidence. A binding decision should be traceable to the user request, retrieved candidates, entity attributes, and the reason a particular entity was selected or rejected. This can support auditing, debugging, and user trust. Finally, tool filtering and entity binding should be combined rather than treated as substitutes. Tool filtering reduces the action space, while entity binding validates the target of action. An agent needs both. A minimal visible tool menu does not guarantee safe execution if the remaining tool is bound to the wrong entity. Overall, the results motivate an explicit entity-aware layer between natural-language intent and external action. The central safety question is not only whether the agent called the right tool, but whether it bound that tool call to the right real-world entity and recognized when that binding was uncertain. VIII. L IMITATIONS AND T HREATS TO VALIDITY This study is designed as a controlled diagnostic evaluation rather than a comprehensive benchmark of all tool-augmented agent behavior. This design lets us isolate entity binding failures from tool-selection failures, but it also limits ecological validity. Real enterprise systems contain noisier, evolving, and partially observable entity stores, including stale records, incomplete metadata, permissions constraints, and cross-system inconsistencies. Because the environments and entity stores in this study are controlled, the reported rates should be interpreted as diagnostic failure rates under the constructed conditions rather than estimates of deployment-wide prevalence. The task suite is also limited in size and scope. We evaluate 60 tasks across email, calendar, document, customer-record, and issue-tracking workflows. These domains are representative of common enterprise agent actions, but they do not cover every high-impact setting. Workflows involving payments, infrastructure operations, medical records, legal documents, or security administration may introduce different ambiguity patterns and risk profiles. Similarly, our ambiguity categories cover common cases such as name collisions, document-version ambiguity, temporal references, account collisions, near-duplicate records, cross-system references, and true ambiguity, but they do not exhaust all possible reference-resolution challenges. The experiments focus on single-step tool execution decisions. This is appropriate for measuring whether an agent binds a requested action to the correct entity before execution. However, many deployed agents perform multi-step plans. In such settings, an early binding error may propagate through retrieval, reasoning, summarization, and subsequent tool calls. Multi-step agents may also introduce additional opportunities for verification, correction, or recovery. Our evaluation therefore measures first-step entity binding failures rather than full workflow failure rates. The results may depend on prompting, output format, decoding behavior, and model version. We use a structured JSON response format and a fixed prompting regime to make methods comparable across models. In particular, the action-oriented baselines are evaluated under a direct-execution policy, while entity-aware methods are allowed to clarify or defer. The comparison should therefore be read as measuring the safety–completion tradeoff between action-first and entity-aware execution policies, not as proving that the baselines could not be made safer with different prompts, explicit clarification rules, or additional execution gates. For the same reason, model-level results should not be read as permanent rankings of specific model backends. The entity-aware methods are also diagnostic implementations rather than final production designs. The confidence-gated methods use structured prompting and candidate comparison rather than a separately calibrated entity-linking or uncertaintyestimation model. As a result, the confidence and margin behavior should be viewed as an abstract execution policy instantiated for controlled evaluation, not as a fully calibrated uncertainty estimator. Future systems may require learned scoring models, domain-specific thresholds, richer provenance representations, and stronger calibration under distribution shift.

Finally, our metrics reflect a safety-oriented interpretation of agent behavior. We count clarification as safe success when the task is truly ambiguous, because asking the user is preferable to guessing in high-risk actions. Other applications may assign higher cost to clarification, latency, or interruption. We evaluate whether the agent chooses to clarify, but we do not conduct a user study measuring whether the clarification is understandable, minimally burdensome, or sufficient for resolving the task. Likewise, ambiguity annotations and risk weights are useful for diagnostic comparison, but different annotators or deployment contexts may disagree about when a reference is sufficiently clear to permit execution or how severe a wrong-entity action should be. Despite these limitations, the study identifies a concrete threat to validity in existing tool-use evaluations: measuring only whether an agent selects the right tool can miss failures where the agent applies that tool to the wrong real-world entity. This motivates treating entity binding as a first-class evaluation and execution requirement for dependable tool-augmented LLM agents. IX. C ONCLUSION Tool-augmented LLM agents are commonly evaluated by whether they choose the correct tool, produce valid arguments, and complete the requested task. This paper shows that these criteria are insufficient. An agent can select the right tool and still fail by binding that tool call to the wrong real-world entity. We define these errors as entity binding failures and argue that they are a distinct reliability and safety problem for agents that operate over people, documents, calendar events, customer records, tickets, and other external entities. We formalized the separation between tool correctness and entity correctness, introduced a taxonomy of common entity binding failures, and evaluated several tool-use methods in a controlled diagnostic testbed. Across 60 diagnostic tasks, five model backends, and six tool-use methods, wrong-tool error was 0.0%, yet action-oriented methods still produced wrong-entity actions in 24.0–26.0% of runs. This demonstrates that correct tool selection does not imply safe execution. Retrieval, semantic filtering, and CMTF-style tool filtering can organize the tool or context space, but they do not by themselves ensure that the selected action is grounded to the correct entity. Entity-aware execution policies changed this behavior. In this diagnostic setting, confidence-gated binding and entity-aware CMTF with provenance eliminated wrong-entity actions by blocking execution when the entity binding was insufficiently grounded. This introduces a safety–completion tradeoff: conservative methods complete fewer tasks directly, but avoid unsafe execution under ambiguity. For high-impact workflows, this tradeoff is often desirable. Asking for clarification is not merely a fallback behavior; it is a necessary safety mechanism when the intended entity cannot be uniquely determined. The broader implication is that dependable tool use requires an entity-aware layer between natural-language intent and external action. Future agent systems should explicitly retrieve candidate entities, evaluate binding confidence, track provenance, and block execution when the target entity is uncertain. Future benchmarks should likewise measure not only whether an agent called the right tool, but whether it acted on the right entity and recognized when that binding was ambiguous. Entity binding should therefore be treated as a first-class requirement for reliable tool-augmented LLM agents. As agents become more deeply connected to enterprise systems, the central safety question is not only what action the agent takes, but who or what the action is taken on. ACKNOWLEDGMENT The authors thank colleagues for helpful feedback. This work was conducted in the authors’ personal capacity. The views expressed in this paper are solely those of the authors and do not necessarily reflect the views of their employers. This work did not receive external funding. The authors declare no conflicts of interest. A RTIFACT AVAILABILITY The benchmark, tool registry, filtering implementations, evaluation scripts, prompts, and analysis utilities used in this study are publicly available at: https://github.com/R-Suresh/EntityBindingFailures. The repository contains task definitions, evaluation harnesses, and scripts required to reproduce the reported results. R EFERENCES [1] T. Schick, J. Dwivedi-Yu, R. Dess‘i, R. Raileanu, M. Lomeli, E. Hambro, L. Zettlemoyer, N. Cancedda, and T. Scialom, “Toolformer: Language models can teach themselves to use tools,” arXiv preprint arXiv:2302.04761, 2023. [2] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “React: Synergizing reasoning and acting in language models,” arXiv preprint arXiv:2210.03629, 2023. [3] Y. Qin, S. Liang, Y. Ye, K. Zhu, L. Yan, Y. Lu, Y. Lin, X. Cong, X. Tang, B. Qian, S. Zhao, R. Tian, R. Xie, J. Zhou, M. Gerstein, D. Li, Z. Liu, and M. Sun, “ToolLLM: Facilitating large language models to master 16000+ real-world apis,” arXiv preprint arXiv:2307.16789, 2023. [4] M. Li, Y. Zhao, B. Yu, F. Song, H. Li, H. Yu, Z. Li, F. Huang, and Y. Li, “Api-bank: A comprehensive benchmark for tool-augmented llms,” in Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, 2023. [5] S. G. Patil, T. Zhang, X. Wang, and J. E. Gonzalez, “Gorilla: Large language model connected with massive apis,” arXiv preprint arXiv:2305.15334, 2023.

[6] S. Yao, N. Shinn, P. Razavi, and K. Narasimhan, “τ -bench: A benchmark for tool-agent-user interaction in real-world domains,” arXiv preprint arXiv:2406.12045, 2024. [7] R. S. Babu and L. G. Iyer, “ToolChoiceConfusion: Causal minimal tool filtering for reliable llm agents,” arXiv preprint arXiv:2606.06284, 2026. [8] ——, “ToolMenuBench: Benchmarking tool-menu filtering strategies for reliable and efficient llm agents,” arXiv preprint arXiv:2606.15508, 2026. [9] ——, “Contract2Tool: Learning preconditions and effects for reliable tool-augmented llm agents,” arXiv preprint arXiv:2606.07904, 2026. [10] R. S. Babu and R. Shukla, “GIST-CMTF: Goal-state inference for causal minimal tool filtering in llm agents,” arXiv preprint arXiv:2606.16813, 2026. [11] O. Sevgili, A. Shelmanov, M. Arkhipov, A. Panchenko, and C. Biemann, “Neural entity linking: A survey of models based on deep learning,” Semantic Web, 2022. [12] O. Binette and R. C. Steorts, “Entity resolution: Theory, practice and open challenges,” arXiv preprint arXiv:2211.05889, 2022. [13] J. Berant, A. Chou, R. Frostig, and P. Liang, “Semantic parsing on freebase from question-answer pairs,” in Proceedings of the 2013 Conference on Empirical Methods in Natural Language Processing, 2013, pp. 1533–1544.