On this page
What Is an AI Agent?
An AI agent is a program that uses a language model to decide and act — calling tools, reading files, and iterating until a task is done. Learn how they differ from chatbots.
Quick answer
- An AI agent is a program that uses a language model to decide and act: it calls tools, reads files, and iterates until a task is done.
- The difference from a chatbot is autonomy — an agent takes multiple steps toward a goal without asking permission each time.
- Agents combine tools, memory, and model-driven planning; that combination is also what makes them risky.
- The same agent capabilities now ship inside coding tools like Claude Code and Cursor.
- “Agent” describes a capability, not a product category.
What is an AI agent?
An AI agent is a software program that uses a language model to decide what to do and then does it: it can call tools, read and write files, run commands, call APIs, and keep working toward a goal across many steps. The defining trait is autonomy — the agent plans and executes without a human approving every action, stopping only when it needs input or hits a limit. This is different from a chatbot, which generates a response and stops. Agent behavior is what powers modern AI coding tools that edit your codebase, run tests, and fix what breaks without you pasting each step.
How is an AI agent different from a chatbot?
A chatbot is a loop: you send a message, it returns a reply. An agent is a loop with effects: it observes, decides, acts through tools, observes the result, and decides again. Concretely, an agent can run git diff, read a failing test’s output, edit three files, run the tests again, and report back — without you touching anything. The practical consequence: a chatbot’s mistakes stay in the chat, while an agent’s mistakes happen in your repository, your cloud account, or your production system. That is why agentic software gets a security review that chatbots never needed.
What can an AI agent do?
Three capabilities separate agents from plain models. First, tool use: the model can call functions, run commands, and hit APIs, and the results feed back into its next decision. Second, memory: the agent can keep state across steps — what it already tried, what failed, what the user asked for — instead of starting fresh each turn. Third, multi-step planning: the agent can break a goal into sub-tasks, execute them in order, and recover when one fails. Coding agents add a fourth: they operate on a real filesystem and version-control history, which is why they can make large, coherent changes instead of returning code snippets.
What are the main types of AI agents?
The classical taxonomy — simple reflex, model-based reflex, goal-based, utility-based, and learning agents — describes academic agents. For someone building with AI in 2026, the useful classification is practical: single tool-using agents (one model with access to tools, like Claude Code), browser and UI agents that operate websites on your behalf, and multi-agent systems where several agents coordinate on one workflow or codebase — each with its own coordination problems, which the multi-agent coding failure modes describe. Every type shares the same core: a model deciding, tools acting, and a loop connecting them.
Why are AI agents risky?
Agents are risky because they combine capabilities that are individually harmless. Simon Willison’s “lethal trifecta” names the combination: access to private data, exposure to untrusted content (a web page it reads, an email it processes, a prompt hidden in tool output), and the ability to take external actions. A chatbot with all three is still a chatbot — a model with tools, memory, and autonomy is an agent, and each capability multiplies the damage the others can do. Prompt injection is the attack that exploits this: untrusted content instructs the agent to misuse its own tools.
Where this bites vibecoders
If you build with AI coding assistants, you are already running agents — Claude Code, Cursor’s agent mode, and similar tools edit files, run commands, and install packages autonomously. The vibecoder failure mode is granting maximum autonomy with no guardrails: letting the agent run destructive commands, install unverified packages, or read secrets it then pastes into a prompt. The fix is scoping: run agents in a sandboxed or version-controlled environment, review what tools they’re allowed to call, and treat their output like any other untrusted input until verified.
Where AI coding assistants get this wrong
- Describing themselves as “just autocomplete,” hiding the fact that they can run commands and modify files.
- Granting themselves tool access (shell, package install, file writes) without a permission boundary.
- Processing untrusted content — web pages, emails, tool output — that can contain injected instructions.
- Overstating their reliability: an agent that “did it” has not verified anything unless it ran tests.
- Scaling to many parallel agents without coordinating file access, causing conflicts and lost work.
Checklist
- Know what tools your agent can call — shell, filesystem, APIs — and scope them to the minimum.
- Run agents in an environment where damage is recoverable: git, sandboxes, staging, throwaway credentials.
- Treat every dependency an agent installs as unverified until checked against the registry.
- Review agent actions before they touch production, or restrict autonomy to non-production systems.
- Assume agent output is wrong until tests, logs, or review prove otherwise.
FAQ
What is the difference between an AI agent and a chatbot?
A chatbot answers. An agent acts: it has tools it can call, memory of what it has done, and the autonomy to take multiple steps toward a goal — reading files, running commands, calling APIs — without asking for permission at every step. Claude Code and Cursor’s agent mode are agents; a support chat widget is a chatbot.
What are the main types of AI agents?
Classically: simple reflex, model-based reflex, goal-based, utility-based, and learning agents. In practice today, the useful distinction is simpler: single tool-using agents (one model with tool access), browser agents that operate a UI, and multi-agent setups where several agents share one codebase or workflow — each with its own conflicts and security surface.
Why are AI agents risky?
Agents combine three capabilities that are individually fine and dangerous together: access to private data, exposure to untrusted content (web pages, emails, tool output), and the ability to take external actions. Simon Willison’s “lethal trifecta” — private data plus untrusted content plus outbound actions — is the model that explains most agent security incidents.
Does an AI agent need to be a separate product?
No. Agent capabilities are now a mode inside tools you already use: Claude Code runs as an agent, Cursor and Copilot have agent modes, and most coding assistants can call tools and iterate. The interesting questions are about how much autonomy you grant and what the agent can touch, not which vendor calls it an agent.
Related topics
- What Is Agentic AI Security?
- What Is MCP (Model Context Protocol) and Why Does It Need Securing?
- What Is the “Lethal Trifecta” for AI Agents?
- What Is Multi-Agent Coding (and Why Do Agents Conflict With Each Other)?
- What Is Context Engineering?
- What Is Prompt Injection?