{
  "@context": "https://agentflare.org/schema",
  "type": "Article",
  "tier": "L2-full",
  "title": "Tool Use Reliability in LLM Agents",
  "description": "Tool-call reliability depends on two layers: whether the model chooses the right call, and whether execution succeeds under real-world failures.…",
  "canonical": "https://agentflare.org/research/tool-use-reliability-in-llm-agents.html",
  "category": "research",
  "updated": "2026-10-16",
  "generated_at": "2026-10-16T00:37:01.652Z",
  "facts": [
    {
      "label": "Cluster",
      "value": "AI engineering"
    },
    {
      "label": "Sources",
      "value": "8"
    },
    {
      "label": "Updated",
      "value": "2026-10-16"
    }
  ],
  "data": {
    "topic": "function calling tool use reliability in LLM agents",
    "cluster": "ai-eng",
    "generated_at": "2026-10-16T00:37:01.652Z",
    "tldr": "Tool-call reliability depends on two layers: whether the model chooses the right call, and whether execution succeeds under real-world failures. Verification-aware wrappers reduce duplicate actions while keeping comparable task success rates.",
    "intro": "Tool calling, also called function calling, lets an LLM request external functions or APIs by emitting a structured call instead of plain text. Since OpenAI's June 2023 release, it has become the core mechanism of LLM agents. Reliability problems arise in two places. The first is call selection and argument formation, which prompt formats, training data and structured reasoning can improve. The second is execution, where timeouts after dispatch, delayed visibility and partial state updates break the common assumption that tool calls are atomic. This brief summarizes how tool calls work, what fails in practice, and which mitigations the sources report, for developers and AI agents building or evaluating agent systems.",
    "concepts": [
      {
        "term": "Function calling (tool calling)",
        "definition": "The capability that lets an LLM output a structured request, with a function name and arguments, for an external function or API. Both terms coexist for historic reasons.",
        "sources": [
          "S3",
          "S6"
        ]
      },
      {
        "term": "Agent scaffolding",
        "definition": "The system surrounding the LLM. The model asks the scaffolding to perform a tool call on its behalf, and the scaffolding executes it and returns results.",
        "sources": [
          "S3",
          "S6"
        ]
      },
      {
        "term": "Non-atomic tool failures",
        "definition": "Real-world behaviors such as timeouts after dispatch, delayed visibility of updates and partial state updates, which violate the assumption that a call either fully succeeds or fails.",
        "sources": [
          "S2"
        ]
      },
      {
        "term": "Response vs effect channel",
        "definition": "The response channel is what the agent sees; the effect channel is what actually happened on the server. The two can diverge, which causes reliability issues.",
        "sources": [
          "S2"
        ]
      },
      {
        "term": "Verification-aware tool wrapper",
        "definition": "A lightweight wrapper that adds postcondition verification, verify-before-retry logic and idempotency keys to tool calls, without modifying the underlying language model.",
        "sources": [
          "S2"
        ]
      },
      {
        "term": "Decision Token",
        "definition": "A proposed token for conditional prompts that, combined with synthetic non-function-call data, enhances relevance detection, meaning deciding whether a function call is needed.",
        "sources": [
          "S8"
        ]
      }
    ],
    "how_it_works": {
      "title": "Tool call lifecycle with verification",
      "steps": [
        {
          "step": "Describe tools to the model",
          "detail": "Each tool gets a name, a description and a parameter description, ideally with data formatting defined via a JSON schema. The model uses descriptions to decide when and how to call."
        },
        {
          "step": "Model emits a structured call",
          "detail": "The LLM does not execute the function. It identifies the function, gathers required parameters and returns structured JSON."
        },
        {
          "step": "Scaffolding executes the call",
          "detail": "The calling application deserializes the JSON into a function call and runs it in its own runtime, often via MCP-style tool invocation."
        },
        {
          "step": "Verify the postcondition",
          "detail": "Rather than trusting a binary success or failure signal, the wrapper checks whether the intended effect actually occurred."
        },
        {
          "step": "Retry safely if needed",
          "detail": "Verify-before-retry logic and idempotency keys prevent a naive retry from duplicating actions or corrupting state after a timeout."
        },
        {
          "step": "Feed the result back into the loop",
          "detail": "The agent observes, reasons, acts and reflects on the result, looping until the task is done."
        }
      ]
    },
    "sections": [
      {
        "h": "Where reliability starts: the call contract",
        "body": "In function calling, the LLM does not execute the function. It identifies the appropriate function, gathers required parameters and returns structured JSON, which the program deserializes and runs in its own runtime (S6). A tool is described by a name, a description and a parameter description, ideally with data formatting defined via a JSON schema (S3). The description fields are critical, because the model uses them to decide when and how to call the function (S5). Providers differ in field naming, for example parameters in one example and input_schema in another, but the concept is identical (S5). The LLM asks the agent scaffolding to perform the call on its behalf, and how the scaffolding invokes tools was de-facto standardized via the Model Context Protocol (S3). Much of the work of explaining tools and format is handled by a provider API or modern framework (S3). Reliability therefore splits into how agents decide to call tools and how those calls are executed (S2).",
        "sources": [
          "S2",
          "S3",
          "S5",
          "S6"
        ]
      },
      {
        "h": "Non-atomic failures and verified execution",
        "body": "Most agent systems assume tool calls are atomic: an operation either succeeds or fails (S2). Paradigms like ReAct and protocols like MCP focus on the mechanics of tool invocation, such as identifying and assigning parameters, but struggle with latency and out-of-sync states (S2). In distributed systems the atomic assumption is frequently violated by network timeouts after a request is dispatched, eventual consistency that delays visibility of updates, and stale-version conflicts in multi-agent environments (S2). The result is duplicate actions, incorrect task completion and cascading failures in long workflows (S2). Naive retry strategies can lead to duplicate actions and corrupted state under failures such as timeouts (S2). The proposed wrapper adds postcondition verification, verify-before-retry logic and idempotency keys. In a controlled simulated environment with injected non-atomic failures across multiple task templates, it significantly reduced duplicate actions while maintaining comparable task success rates (S2).",
        "sources": [
          "S2"
        ]
      },
      {
        "h": "Improving call accuracy at the model and prompt level",
        "body": "Separate from execution, several approaches target whether the model chooses and forms calls correctly. Structured, template-based reasoning improves the reliability of function calls by guiding LLMs through structured, interpretable steps (S1). Research on function-calling capabilities compared two prompt formats: a dedicated role for presenting function descriptions, and embedding descriptions in the system role alongside usage instructions (S8). Its findings are that instruction-following data improves both function-calling accuracy and relevance detection, and that a Decision Token combined with synthetic non-function-call data enhances relevance detection (S8). A tailored translation pipeline also produced significant improvements in Traditional Chinese, addressing multilingual limitations (S8). Frameworks such as LangChain, AutoGen, CrewAI and LangGraph support building and orchestrating tool-calling agents with memory management (S1). These measures improve decisions, whereas verified execution addresses what happens after a call is dispatched (S2).",
        "sources": [
          "S1",
          "S2",
          "S8"
        ]
      }
    ],
    "comparison": {
      "title": "Atomic assumption vs verification-aware wrapper",
      "columns": [
        "Aspect",
        "Typical agent frameworks",
        "Verification-aware wrapper"
      ],
      "rows": [
        [
          "Tool call model",
          "Assumes calls are atomic, with binary success or failure signals",
          "Accounts for timeouts after dispatch, delayed visibility and partial state updates"
        ],
        [
          "Success check",
          "Relies on the response channel the agent sees",
          "Postcondition verification of what actually happened"
        ],
        [
          "Retry behavior",
          "Naive retries can cause duplicate actions and corrupted state",
          "Verify-before-retry logic plus idempotency keys"
        ],
        [
          "Model changes needed",
          "Not applicable",
          "None; the underlying language model is not modified"
        ],
        [
          "Reported outcome",
          "Duplicate actions, incorrect task completion, cascading failures",
          "Significantly fewer duplicate actions, comparable task success rates"
        ]
      ],
      "sources": [
        "S2"
      ]
    },
    "key_numbers": [
      {
        "value": "June 2023",
        "label": "OpenAI released function calling in GPT-3.5-turbo and GPT-4",
        "source": "S4"
      }
    ],
    "timeline": [
      {
        "date": "2022",
        "event": "ChatGPT's initial success late in the year preceded function calling.",
        "source": "S4"
      },
      {
        "date": "2023-06",
        "event": "OpenAI releases function calling, integrated into GPT-3.5-turbo and GPT-4.",
        "source": "S4"
      },
      {
        "date": "2025",
        "event": "Tool calling has evolved to structured reasoning, memory management and agent orchestration.",
        "source": "S1"
      }
    ],
    "pitfalls": [
      {
        "text": "Assuming tool calls are atomic. Timeouts after dispatch, delayed visibility and partial updates mean a failure signal does not prove the action did not happen.",
        "source": "S2"
      },
      {
        "text": "Retrying naively after a timeout can produce duplicate actions and corrupted state; check the postcondition and use idempotency keys first.",
        "source": "S2"
      },
      {
        "text": "Trusting only the response channel. What the agent sees can differ from what actually happened on the server.",
        "source": "S2"
      },
      {
        "text": "Writing vague tool descriptions. The model relies on description fields to decide when and how to call a function.",
        "source": "S5"
      }
    ],
    "takeaways": [
      "Treat tool calls as non-atomic: verify postconditions before retrying, and use idempotency keys to avoid duplicate actions.",
      "The LLM only emits a structured call; your scaffolding executes it, so execution reliability is an application-layer responsibility.",
      "Improve call selection with clear JSON-schema tool descriptions, instruction-following data and structured, template-based reasoning."
    ],
    "faq": [
      {
        "q": "What is the difference between function calling and tool calling?",
        "a": "They are the same capability. Both terms coexist for historic reasons: models first had a small selection of functions, then handled larger collections of external APIs, hence the name tool, as in toolbox."
      },
      {
        "q": "Does the LLM execute the function itself?",
        "a": "No. The LLM identifies the function, gathers parameters and returns structured JSON. The calling program deserializes it and executes it in its own runtime environment."
      },
      {
        "q": "Why do agents create duplicate actions after a timeout?",
        "a": "Naive retries assume the first call failed, but a timeout can occur after the request was dispatched, so the effect may already have happened. This leads to duplicate actions and corrupted state."
      },
      {
        "q": "How can I make retries safe for LLM agents?",
        "a": "Wrap tool calls with postcondition verification, verify-before-retry logic and idempotency keys. In simulated non-atomic failures this significantly reduced duplicate actions with comparable task success, and it needs no change to the language model."
      }
    ],
    "sources": [
      {
        "title": "Advanced Tool Calling in LLM Agents: A Deep Dive",
        "url": "https://sparkco.ai/blog/advanced-tool-calling-in-llm-agents-a-deep-dive",
        "domain": "sparkco.ai",
        "date": ""
      },
      {
        "title": "Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures",
        "url": "https://arxiv.org/html/2608.02645v1",
        "domain": "arxiv.org",
        "date": ""
      },
      {
        "title": "Function calling in LLM agents",
        "url": "https://symflower.com/en/company/blog/2025/function-calling-llm-agents",
        "domain": "symflower.com",
        "date": ""
      },
      {
        "title": "Function Calling and Tool Use - Interactive",
        "url": "https://mbrenndoerfer.com/writing/function-calling-tool-use-practical-ai-agents",
        "domain": "mbrenndoerfer.com",
        "date": ""
      },
      {
        "title": "Building AI Agents from Scratch: A Deep Dive into Function Calling, Tool Use, and Agentic Patterns - DEV Community",
        "url": "https://dev.to/pockit_tools/building-ai-agents-from-scratch-a-deep-dive-into-function-calling-tool-use-and-agentic-patterns-382g",
        "domain": "dev.to",
        "date": ""
      },
      {
        "title": "Function calling using LLMs",
        "url": "https://martinfowler.com/articles/function-call-LLM.html",
        "domain": "martinfowler.com",
        "date": ""
      },
      {
        "title": "LLM Agent vs Function Calling: Key Differences & Use Cases",
        "url": "https://blog.promptlayer.com/llm-agents-vs-function-calling",
        "domain": "blog.promptlayer.com",
        "date": ""
      },
      {
        "title": "Enhancing Function-Calling Capabilities in LLMs: Strategies for Prompt Formats, Data Integration, and Multilingual Translation",
        "url": "https://arxiv.org/html/2412.01130v2",
        "domain": "arxiv.org",
        "date": ""
      }
    ]
  },
  "analysis_md": "Tool-call reliability depends on two layers: whether the model chooses the right call, and whether execution succeeds under real-world failures. Verification-aware wrappers reduce duplicate actions while keeping comparable task success rates.\n\nTool calling, also called function calling, lets an LLM request external functions or APIs by emitting a structured call instead of plain text. Since OpenAI's June 2023 release, it has become the core mechanism of LLM agents. Reliability problems arise in two places. The first is call selection and argument formation, which prompt formats, training data and structured reasoning can improve. The second is execution, where timeouts after dispatch, delayed visibility and partial state updates break the common assumption that tool calls are atomic. This brief summarizes how tool calls work, what fails in practice, and which mitigations the sources report, for developers and AI agents building or evaluating agent systems.\n\n## Key numbers\n\n- **June 2023** — OpenAI released function calling in GPT-3.5-turbo and GPT-4 (https://mbrenndoerfer.com/writing/function-calling-tool-use-practical-ai-agents)\n\n## Key concepts\n\n- **Function calling (tool calling):** The capability that lets an LLM output a structured request, with a function name and arguments, for an external function or API. Both terms coexist for historic reasons.\n- **Agent scaffolding:** The system surrounding the LLM. The model asks the scaffolding to perform a tool call on its behalf, and the scaffolding executes it and returns results.\n- **Non-atomic tool failures:** Real-world behaviors such as timeouts after dispatch, delayed visibility of updates and partial state updates, which violate the assumption that a call either fully succeeds or fails.\n- **Response vs effect channel:** The response channel is what the agent sees; the effect channel is what actually happened on the server. The two can diverge, which causes reliability issues.\n- **Verification-aware tool wrapper:** A lightweight wrapper that adds postcondition verification, verify-before-retry logic and idempotency keys to tool calls, without modifying the underlying language model.\n- **Decision Token:** A proposed token for conditional prompts that, combined with synthetic non-function-call data, enhances relevance detection, meaning deciding whether a function call is needed.\n\n## Tool call lifecycle with verification\n\n1. **Describe tools to the model** — Each tool gets a name, a description and a parameter description, ideally with data formatting defined via a JSON schema. The model uses descriptions to decide when and how to call.\n2. **Model emits a structured call** — The LLM does not execute the function. It identifies the function, gathers required parameters and returns structured JSON.\n3. **Scaffolding executes the call** — The calling application deserializes the JSON into a function call and runs it in its own runtime, often via MCP-style tool invocation.\n4. **Verify the postcondition** — Rather than trusting a binary success or failure signal, the wrapper checks whether the intended effect actually occurred.\n5. **Retry safely if needed** — Verify-before-retry logic and idempotency keys prevent a naive retry from duplicating actions or corrupting state after a timeout.\n6. **Feed the result back into the loop** — The agent observes, reasons, acts and reflects on the result, looping until the task is done.\n\n## Where reliability starts: the call contract\n\nIn function calling, the LLM does not execute the function. It identifies the appropriate function, gathers required parameters and returns structured JSON, which the program deserializes and runs in its own runtime (S6). A tool is described by a name, a description and a parameter description, ideally with data formatting defined via a JSON schema (S3). The description fields are critical, because the model uses them to decide when and how to call the function (S5). Providers differ in field naming, for example parameters in one example and input_schema in another, but the concept is identical (S5). The LLM asks the agent scaffolding to perform the call on its behalf, and how the scaffolding invokes tools was de-facto standardized via the Model Context Protocol (S3). Much of the work of explaining tools and format is handled by a provider API or modern framework (S3). Reliability therefore splits into how agents decide to call tools and how those calls are executed (S2).\n\n## Non-atomic failures and verified execution\n\nMost agent systems assume tool calls are atomic: an operation either succeeds or fails (S2). Paradigms like ReAct and protocols like MCP focus on the mechanics of tool invocation, such as identifying and assigning parameters, but struggle with latency and out-of-sync states (S2). In distributed systems the atomic assumption is frequently violated by network timeouts after a request is dispatched, eventual consistency that delays visibility of updates, and stale-version conflicts in multi-agent environments (S2). The result is duplicate actions, incorrect task completion and cascading failures in long workflows (S2). Naive retry strategies can lead to duplicate actions and corrupted state under failures such as timeouts (S2). The proposed wrapper adds postcondition verification, verify-before-retry logic and idempotency keys. In a controlled simulated environment with injected non-atomic failures across multiple task templates, it significantly reduced duplicate actions while maintaining comparable task success rates (S2).\n\n## Improving call accuracy at the model and prompt level\n\nSeparate from execution, several approaches target whether the model chooses and forms calls correctly. Structured, template-based reasoning improves the reliability of function calls by guiding LLMs through structured, interpretable steps (S1). Research on function-calling capabilities compared two prompt formats: a dedicated role for presenting function descriptions, and embedding descriptions in the system role alongside usage instructions (S8). Its findings are that instruction-following data improves both function-calling accuracy and relevance detection, and that a Decision Token combined with synthetic non-function-call data enhances relevance detection (S8). A tailored translation pipeline also produced significant improvements in Traditional Chinese, addressing multilingual limitations (S8). Frameworks such as LangChain, AutoGen, CrewAI and LangGraph support building and orchestrating tool-calling agents with memory management (S1). These measures improve decisions, whereas verified execution addresses what happens after a call is dispatched (S2).\n\n## Atomic assumption vs verification-aware wrapper\n\n| Aspect | Typical agent frameworks | Verification-aware wrapper |\n| --- | --- | --- |\n| Tool call model | Assumes calls are atomic, with binary success or failure signals | Accounts for timeouts after dispatch, delayed visibility and partial state updates |\n| Success check | Relies on the response channel the agent sees | Postcondition verification of what actually happened |\n| Retry behavior | Naive retries can cause duplicate actions and corrupted state | Verify-before-retry logic plus idempotency keys |\n| Model changes needed | Not applicable | None; the underlying language model is not modified |\n| Reported outcome | Duplicate actions, incorrect task completion, cascading failures | Significantly fewer duplicate actions, comparable task success rates |\n\n## Timeline\n\n- 2022: ChatGPT's initial success late in the year preceded function calling.\n- 2023-06: OpenAI releases function calling, integrated into GPT-3.5-turbo and GPT-4.\n- 2025: Tool calling has evolved to structured reasoning, memory management and agent orchestration.\n\n## Common pitfalls\n\n- Assuming tool calls are atomic. Timeouts after dispatch, delayed visibility and partial updates mean a failure signal does not prove the action did not happen.\n- Retrying naively after a timeout can produce duplicate actions and corrupted state; check the postcondition and use idempotency keys first.\n- Trusting only the response channel. What the agent sees can differ from what actually happened on the server.\n- Writing vague tool descriptions. The model relies on description fields to decide when and how to call a function.\n\n## Key takeaways\n\n- Treat tool calls as non-atomic: verify postconditions before retrying, and use idempotency keys to avoid duplicate actions.\n- The LLM only emits a structured call; your scaffolding executes it, so execution reliability is an application-layer responsibility.\n- Improve call selection with clear JSON-schema tool descriptions, instruction-following data and structured, template-based reasoning.\n\n## FAQ\n\n**What is the difference between function calling and tool calling?**\nThey are the same capability. Both terms coexist for historic reasons: models first had a small selection of functions, then handled larger collections of external APIs, hence the name tool, as in toolbox.\n\n**Does the LLM execute the function itself?**\nNo. The LLM identifies the function, gathers parameters and returns structured JSON. The calling program deserializes it and executes it in its own runtime environment.\n\n**Why do agents create duplicate actions after a timeout?**\nNaive retries assume the first call failed, but a timeout can occur after the request was dispatched, so the effect may already have happened. This leads to duplicate actions and corrupted state.\n\n**How can I make retries safe for LLM agents?**\nWrap tool calls with postcondition verification, verify-before-retry logic and idempotency keys. In simulated non-atomic failures this significantly reduced duplicate actions with comparable task success, and it needs no change to the language model.\n",
  "sources": [
    {
      "title": "Advanced Tool Calling in LLM Agents: A Deep Dive",
      "url": "https://sparkco.ai/blog/advanced-tool-calling-in-llm-agents-a-deep-dive"
    },
    {
      "title": "Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures",
      "url": "https://arxiv.org/html/2608.02645v1"
    },
    {
      "title": "Function calling in LLM agents",
      "url": "https://symflower.com/en/company/blog/2025/function-calling-llm-agents"
    },
    {
      "title": "Function Calling and Tool Use - Interactive",
      "url": "https://mbrenndoerfer.com/writing/function-calling-tool-use-practical-ai-agents"
    },
    {
      "title": "Building AI Agents from Scratch: A Deep Dive into Function Calling, Tool Use, and Agentic Patterns - DEV Community",
      "url": "https://dev.to/pockit_tools/building-ai-agents-from-scratch-a-deep-dive-into-function-calling-tool-use-and-agentic-patterns-382g"
    },
    {
      "title": "Function calling using LLMs",
      "url": "https://martinfowler.com/articles/function-call-LLM.html"
    },
    {
      "title": "LLM Agent vs Function Calling: Key Differences & Use Cases",
      "url": "https://blog.promptlayer.com/llm-agents-vs-function-calling"
    },
    {
      "title": "Enhancing Function-Calling Capabilities in LLMs: Strategies for Prompt Formats, Data Integration, and Multilingual Translation",
      "url": "https://arxiv.org/html/2412.01130v2"
    }
  ],
  "related": [
    {
      "name": "RAG Best Practices for 2026",
      "url": "https://agentflare.org/research/rag-best-practices-for-2026.html"
    },
    {
      "name": "Context Engineering: Memory for AI Agents",
      "url": "https://agentflare.org/research/context-engineering-memory-for-ai-agents.html"
    },
    {
      "name": "How AI Agents Are Evaluated: The Benchmark Landscape",
      "url": "https://agentflare.org/research/how-ai-agents-are-evaluated-the-benchmark-landscape.html"
    },
    {
      "name": "HTTP 402 & x402: How AI Agents Pay for Content",
      "url": "https://agentflare.org/research/http-402-x402-how-ai-agents-pay-for-content.html"
    },
    {
      "name": "The AI Agent Economy in 2026",
      "url": "https://agentflare.org/research/the-ai-agent-economy-in-2026.html"
    },
    {
      "name": "Model Context Protocol (MCP) Explained",
      "url": "https://agentflare.org/research/model-context-protocol-mcp-explained.html"
    }
  ],
  "pricing": {
    "price_usd": 0.02,
    "method": "402",
    "endpoint": "https://esa.aisa.one/api/v1/access/verify",
    "autopay_hint": "set crawlerAutoPrice=true with the X-Crawler-Token header",
    "onboarding": "https://esa.aisa.one/agent/guide.html"
  },
  "powered_by": "AISA — agent-native search, settlement & delivery (https://aisa.one)"
}