Tool Use
Letting a model call real software — a search, a calculator, your database — instead of trying to answer everything from memory.
When not to use it
- When one lookup would do. If your code already knows it needs the weather, call the weather API. Asking a model to decide adds latency, cost, and a chance of it deciding wrong.
- For anything irreversible without a confirmation step. A tool that sends, pays, or deletes should not fire on a model's judgement alone.
- When the tool's output is untrusted. Web pages and user documents can carry instructions the model may follow. If you can't sanitise it, don't hand it to a model with tools.
Reach for something else instead
- Hardcoded calls — if the sequence is known, write the sequence. It's faster, cheaper, and testable.
- Structured output when you only need the model to fill in a form and your code does the rest.
- RAG when the real need was reading documents, not taking actions.
Read more on the blog
- How AI agents actually work: the loop behind the hypeEveryone is building "agents" and almost nobody explains what makes one. Not the marketing, the actual machinery: the loop, the four components, and the single property that separates an agent from a chatbot with a fancy system prompt.
- What is MCP? The standard that wired AI into everythingThe Model Context Protocol went from a November 2024 announcement to the connective tissue of the entire agent era in under two years. Here's what it actually is, the problem it solved, how it works under the hood, and why every major AI lab adopted it, explained plainly, without the sales pitch.
- What is prompt injection, and why is it unsolved?Prompt injection is the number one security risk for AI applications, and researchers treat it as unsolved: not a bug waiting for a patch, but an architectural flaw in how language models work. Here is why a model cannot reliably tell instructions from data, why that makes AI agents dangerous, and what actually reduces the risk.
- How to secure an LLM application: risks and defensesTraditional security rests on a boundary between instructions and data. A language model has no such boundary, because both arrive as one stream of text it cannot tell apart. That single fact determines every defense that works, and every one that does not.
Further reading
- Schick et al. (2023), Toolformer: Language Models Can Teach Themselves to Use Tools — models learning when to call, not just how.
- Yao et al. (2022), ReAct: Synergizing Reasoning and Acting in Language Models — the reason-then-act loop underneath most agent frameworks.
- Greshake et al. (2023), Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — why tool results are an attack surface.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Writing tool descriptions for yourself instead of for the model. It only sees that text; ambiguity there becomes wrong calls at runtime.
- Giving the model twenty tools and blaming it for confusion. Selection degrades with count — group them, or route to a subset first.
- Treating tool errors as rare. In production they're constant, and a model that gets an unhandled exception back will improvise something.
At a glance
Often compared with
Where this sits
25 concepts come first. Understanding it opens up 7 more.
Computed from the prerequisite graph, not assigned. How this works