Building AI Agents: Tool Use Patterns That Actually Work

What an agent actually is

Strip away the marketing and an AI agent is an LLM that calls tools in a loop until it decides it is done. The tools are functions you define — search the database, send an email, query an API. The loop is bounded by step count, time, or completion criteria.

Everything else — memory, planning, multi-agent orchestration — is layered on top. Get the base loop right before adding layers.

Tool design is the work

A well-designed tool has a single responsibility, a strict input schema, and a response shape the model can reason about. Bad tools — tools that do too much, return ambiguous data, or have weak schemas — make every agent fail in the same way.

Test tools in isolation before composing them. If a tool returns 'success' for an empty result and the model interprets that as 'task complete', the bug is in the tool, not the model.

Approval gates for irreversible actions

Any tool with an irreversible side effect — sending a message, charging a card, deleting data — needs a human approval gate by default. AI SDK supports this via the needsApproval pattern; LangChain and others have equivalents.

The cost of skipping this is a single bad agent run that sends 10,000 wrong emails. Approval gates do not slow down agents in steady state because most agent steps are read operations.

Step count is a real budget

Agents loop. Without a hard step limit, a confused agent loops forever, costs you money, and eventually surfaces as a timeout instead of a meaningful error. Cap step counts at 50 for most tasks, 200 for complex research workflows. Above that, redesign.

Track step counts per task type. An agent that suddenly needs twice as many steps to complete a familiar task is a regression signal — investigate before the next deploy.

Memory is mostly a search problem

Agent memory is over-marketed. In practice, useful agent memory is a retrieval system over past conversations and outcomes — exactly the RAG pattern. The vector database is the memory; the LLM does the recall.

Conversation summarization is the simplest useful memory pattern. Summarize after every 20–50 turns; keep the summary in the system prompt; let recent turns flow normally.

Multi-agent is usually premature

The multi-agent pattern — multiple specialized agents collaborating — is fashionable. It is rarely necessary. A single well-designed agent with the right tools handles most workflows. Adding more agents adds coordination overhead, more failure modes, and more cost.

The clearest case for multi-agent is when you genuinely have separate authority domains (one agent has access to financial systems, another does not). Otherwise, ship the single-agent version first.