Core agents
What is Agent?
An AI agent is a system that uses a model plus tools and state to complete a task.
An agent is not merely a chatbot. It is a system that can observe, act through tools, keep task state, and stop. The model is one part of that system.
User asks for tomorrow's weather. The agent calls a weather API, reads the JSON, and answers — then stops. The model alone could only guess; the tool call makes it an agent.
Visual
Agent architecture
A minimal agent loop: receive → plan → call tools → observe → check stop → output.
Why it matters
The word "agent" gets applied to everything from autocomplete to autonomous drone controllers. On this site it has a precise meaning: a system that observes, acts through tools, tracks task state, and declares when it is done or blocked.
This specificity matters because the failure modes of an agent — runaway tool loops, stale state, silent errors — are fundamentally different from the failure modes of a stateless text generator. Building well starts with knowing which thing you are building.
How it works
An agent receives an input, enters a loop of planning and tool use, and continues until a stop condition fires. Each tool call returns an observation that becomes the next input for the model. The controller code — not the model — owns execution, timeouts, and error handling.
The model contributes reasoning and language. The controller contributes safety, determinism, and resource limits. Neither is the whole agent.
Anatomy of an agent
Every agent has four parts. The model generates text and tool-call requests. The tools perform real actions — search, read files, call APIs. The state keeps track of what has been done, what remains, and what has failed. The stop policy decides when to emit the final output, escalate to a human, or give up.
Remove any of those four and you get something else: a chatbot (no tools), a script (no model), or an infinite loop (no stop condition).
Key takeaways
- 1An agent is model + tools + state + stop condition — remove any piece and it is something else.
- 2The model proposes actions. The controller executes them. Neither is the full agent.
- 3Stop conditions prevent infinite loops, runaway costs, and silent failure.
- 4Agents are inspectable: every tool call and observation should be logged.
Common mistakes
- ✕Calling a bare LLM completion endpoint an "agent" — without tools or state it is a text generator.
- ✕Letting the model decide its own stop condition without a hard timeout or step limit.
- ✕Hiding tool errors inside the model context instead of surfacing them in the trace.
- ✕Adding agent infrastructure when a simple prompt with structured output would suffice.
In practice
Most production agents are surprisingly simple: one model, two to five tools, and a deterministic controller. The research agent on this site, for example, uses search, browser, and a fact-checker tool inside a single loop. Complexity comes from reliability engineering — retries, timeouts, human escalation — not from adding more models.
Start with the simplest architecture that can finish your task. Promote to multi-agent only when you need typed handoffs between distinct specialist roles.
Related terms
Concept neighborhood
Terms linked from Agent in the glossary graph.
FAQ
- Is every chatbot an agent?
- No. A chatbot that only generates text without tools, task state, or a stop condition is not an agent on this site. It may still be useful, but it fails differently.
- Does an agent need multiple models?
- No. One model plus tools and control flow is enough. Most production agents use a single model.
- What is the difference between an agent and an automation?
- An automation follows a fixed script. An agent uses a model to decide which step to take next based on observations. The model makes the control flow dynamic.
- How do I know if I need an agent?
- If the task requires dynamic decisions based on external data, tool use, and a stop condition beyond "user closes the tab," you probably need an agent. If a static script or a single prompt suffices, you don't.