An AI agent is a software system that uses an AI model as its decision-making core, calls tools to take actions, and works toward a goal across multiple steps. The model is not generating text in isolation. It is steering a loop: deciding what to do next, executing it, reading the result, and deciding again. The agent ends when the goal is met, when the user is asked for help, or when it hits a budget limit.
The simplest mental model: a chat assistant answers a question. An agent answers a question and then does the work that the answer described. If you ask a chatbot for the cheapest flight, it searches the web and tells you. If you ask an agent, it searches the web, narrows the options, fills in a booking form, and gets to checkout before asking you to confirm.
The piece that confuses people: the model is the same in both cases. The difference is what the system around the model can do. An agent has tools (functions, APIs, browser access), a loop (model decides, system acts, result feeds back), and usually some form of memory. Strip those away and you are back to a chat assistant. Add them and you have an agent.
In 2025 and 2026 the term has been stretched by marketing. Some products labeled agents are really chat with a couple of integrations. Some are full autonomous loops that run for hours. A useful filter when evaluating a system: how many steps does it take without human input, how rich is its tool set, and how does it handle errors? Real agents handle multi-step plans and recover from failure. Tool-augmented chat handles single-step tool use within a conversational interface. Both are useful. They are not the same architecture.
The reason the category matters now is that foundation models in late 2024 and 2025 became reliable enough at planning and tool use to make production agents feasible. Earlier attempts (think AutoGPT in 2023) demonstrated the pattern but the underlying models were not strong enough to keep agents on track. The current generation of models from Anthropic, OpenAI, and Google can run multi-step loops with reasonable reliability for narrow tasks, which is why every major platform is shipping agent products.
The agent's central loop has four phases that repeat. First, the model gets the current state: the goal, the conversation or task history, the available tools, and any retrieved context. Second, the model decides on the next move. This is usually one of: call a tool with specific parameters, ask the user a clarifying question, or finish the task. Third, the system executes the chosen action. Tool calls hit real APIs or run real code. User questions pause the loop until the user responds. Fourth, the result of the action is appended to the state and the loop runs again.
The control logic around this loop is where production engineering lives. You set a maximum step count to prevent runaway loops. You set a token budget to prevent runaway cost. You catch errors from tool calls and feed them back to the model so it can recover. You decide when to summarize old context to keep the window manageable. You log every step for debugging and for evaluation.
The model is interacting with the loop through a structured interface. Modern foundation models from Anthropic, OpenAI, Google, and others support tool use natively: you provide a list of available functions with descriptions and parameter schemas, and the model returns either text or a structured tool call. The application code interprets the tool call, runs the function, and returns the result in a format the model knows how to read.
Memory in an agent comes in two forms. Working memory is the context window during a single run, which holds steps and results until the task ends. Long-term memory persists across runs, usually backed by a database or vector store. The agent can write to long-term memory ("note that this user prefers JSON output") and read from it on future runs ("last week's investigation found X, do not repeat it"). Most production agents use both, though long-term memory introduces complexity around when to store, what to retrieve, and how to reconcile contradictory entries.
Tools are functions exposed to the agent with a name, a description, and a parameter schema. The model uses the description and schema to decide whether and how to call each tool. The quality of these definitions has more impact on agent behavior than almost anything else, including the choice of model.
A useful tool description is specific. "search_database" is too vague. "search_customer_records_by_name_or_email" is much better. The model now knows exactly when to reach for it. Vague tools produce confused agents that pick the wrong one or call several when one would have worked.
Parameters should be typed and documented. A "date" parameter should specify whether it expects ISO 8601, what timezone applies, and how to express ranges. Missing this detail leads to malformed calls that the agent then has to debug, which costs steps and produces errors.
Error returns should be informative. If a tool fails, the message returned to the model should explain why (timeout, missing permission, invalid argument) so the model can adjust. Terse error messages cause loops where the agent retries the same broken call.
Tools that overlap functionality cause indecision. If you have "search_documents" and "search_knowledge_base" and they do roughly the same thing, the model will sometimes pick one and sometimes the other inconsistently. Consolidate where you can.
A small set of well-designed tools beats a large set of mediocre ones. Five clear tools usually outperform fifteen sloppy ones. When you find your agent struggling, the answer is often to simplify and clarify the tool layer rather than to ask for a smarter model.
The simplest pattern is a single agent with a tool set, running a basic loop. This is right for narrow workflows: a coding agent for one repository, a support agent for a single product line, a research agent for a specific topic. Most production agents are this shape.
The supervisor-worker pattern adds a coordinator agent that delegates subtasks to specialized agents. A research project manager might spawn one agent to gather sources, another to analyze them, and a third to synthesize. This works when the subtasks are clearly different and parallelism helps. It is overkill when the work is sequential and a single agent could handle it.
The graph pattern (popularized by LangGraph) treats the agent as a directed graph of nodes, where each node is a function or model call and edges encode control flow. Nodes can be conditional, can loop, can pause for human input. This pattern is useful when the workflow has a known structure with branches and you want explicit control over the path the agent takes.
The reactive pattern is for agents that respond to events rather than running goal-directed loops. A monitoring agent that watches a system and acts when something happens. A workflow agent that wakes up when a trigger fires. These agents have shorter loops and clearer boundaries than goal-directed agents and are often more reliable as a result.
The choice between patterns is driven by the workflow's shape, not by what is fashionable. Simple workflows want simple architectures. Forcing a multi-agent or graph architecture onto a simple problem usually adds bugs and cost without adding capability.
Coding agents are the most mature category. Cursor, Claude Code, GitHub Copilot Workspace, Cognition's Devin, and others can read codebases, edit files, run tests, and iterate. Tasks range from one-line fixes to multi-file refactors. The reason coding works as a domain: tests give the agent fast, accurate feedback on whether it succeeded, and version control makes errors easily reversible.
Customer support agents handle inbound tickets across email, chat, and helpdesk systems. Intercom Fin, Zendesk AI, Decagon, and many internal builds use foundation models with tools for retrieving knowledge base articles, looking up customer data, and updating ticket status. The well-engineered ones resolve a substantial fraction of routine tickets without human help and escalate cleanly when out of scope.
Research agents browse the web, read documents, and synthesize findings. ChatGPT's Deep Research, Anthropic's Computer Use research mode, and Gemini Deep Research are productized versions. Companies use them for competitive intelligence, market research, due diligence, and literature review. Output quality depends heavily on source diversity and the agent's judgment about what to include.
Operations agents handle internal workflows: finance reconciliation, IT helpdesk tickets, sales operations, marketing reporting. These are usually narrow with well-defined inputs and outputs, which makes them well-suited to the agent pattern.
Personal assistants are the highest-aspiration use case. Plan my week, find me a flight, schedule the meeting, file my expenses. Some of this works in 2026 (booking flights, scheduling meetings on connected calendars) and some still does not work reliably (handling complex preferences, dealing with novel situations). The category is improving fast.
Latency is the headline trade-off. A multi-step agent loop adds seconds for every step. A 10-step agent might take 30 to 90 seconds end to end. For interactive use cases this is too slow, and the design has to compensate (streaming progress, parallelizing where possible, doing expensive steps in the background).
Cost can balloon. Each step uses tokens, and the context grows as the loop runs. A poorly bounded agent can produce surprising bills. Setting per-task budgets and circuit breakers is part of operating these systems.
Reliability is not deterministic. The same goal can produce different action sequences across runs. Most of the time the variation is fine; sometimes the agent picks an unusual path that breaks downstream assumptions. Rigorous evaluation against representative tasks is the only way to keep this under control.
Safety matters more than for chat. An agent with write access to systems can do real damage. Standard practice is now: explicit user permission for irreversible actions, sandboxing for code execution, separate scopes for read versus write tools, audit logs for everything. These are basic operational requirements, not optional polish.
Open-endedness is where agents fail most often. Goals like "improve our marketing" or "fix our hiring process" are too broad. The agent flounders. Good agent design means narrowing the goal, defining the success criteria, and providing the tools that match the workflow.
A model that calls a single tool in a basic loop. You give it a goal, it decides whether to call the tool, the tool returns a result, and the model produces a final answer or calls again. With a foundation model that supports tool use, this is roughly fifty lines of code in Python or TypeScript. There is no need for a framework or sophisticated orchestration to get the basic pattern working. The reason to add frameworks is when complexity grows: multi-step loops with state management, multiple specialized agents that need to coordinate, persistent memory across runs, observability and tracing across long workflows. Until those needs are real, a basic loop is often the right starting point and avoids carrying framework dependencies you have not yet earned.
A workflow has a fixed sequence of steps defined by code: do A, then B, then C. An agent has a goal and a set of tools, and the model decides which tools to use in which order. Workflows are predictable. Agents are flexible. The two are converging in practice. Modern orchestration frameworks let you write agentic workflows where some steps are fixed and others let the agent choose. This hybrid often works better than pure agency or pure workflow: the deterministic parts are reliable, and the agent handles only the parts that genuinely need flexibility. For a customer support example, the workflow might fix the steps "fetch customer record, identify ticket type, route to handler", and the handler step is where the agent decides what to do.
You need an evaluation set: a list of representative tasks with expected behavior or outcomes. Run each task through the agent, capture the trace, and score the result. Score on multiple dimensions: did it complete the task, did it use the right tools, did it stay within budget, did it ask reasonable clarifying questions. Tools like LangSmith, Langfuse, and Braintrust support agent-specific evaluation patterns. Without an eval set you cannot tell whether changes to the agent are improvements or regressions. Building one is annoying upfront but pays back fast. Start with twenty tasks. Run them weekly. Add new tasks when you find failure modes in production. Within a few months you have a meaningful regression test.
The frontier models from Anthropic (Claude Sonnet 4.6, Claude Opus 4.6), OpenAI (GPT-5 family), and Google (Gemini 2.5) are all strong choices for agent work as of 2026. They differ in subtle ways. Claude tends to follow instructions and use tools precisely. GPT models are strong at reasoning and broad task variety. Gemini integrates well with Google ecosystem. For high-volume or cost-sensitive use cases, smaller models like Claude Haiku, GPT-4 Mini, or Gemini Flash can handle simpler agent loops at much lower cost. The pattern that often works: a smaller model for routing and simple tasks, with escalation to a larger model for hard ones. Open-weight models like Llama 3.1 and Qwen are usable for agents but typically lag the frontier in tool use precision and reasoning.
Yes, and many teams do. The agent loop is simple enough that writing it directly against the foundation model API is reasonable. You define your tools, you set up the loop, you handle errors, you log traces. The advantage is no framework dependency, full control, and no abstraction tax. The disadvantage is you reinvent some pieces (state management, memory, multi-agent coordination) if your needs grow. A reasonable rule: start without a framework if your agent is single-purpose and the workflow is simple. Move to a framework like LangGraph or the Anthropic Agent SDK when you have measurable benefit from doing so: complex orchestration, persistent state across runs, or significant multi-agent coordination. Do not adopt a framework as a default just because it exists.
Short-term memory is the context window during a single agent run. The model sees recent steps, tool results, and any retrieved context. As the loop runs, this context grows, and at some point you need to summarize or trim it to stay within the window limit. Long-term memory persists across runs. Common patterns: a vector database storing semantic notes the agent can retrieve later, a structured store for facts (user preferences, past decisions), and an event log of actions taken. The agent reads from long-term memory at the start of a run and writes to it as it learns. Designing what to store and what to retrieve is harder than it sounds; too aggressive and you fill context with irrelevant history, too cautious and the agent forgets useful information. Most teams iterate on memory design over months as patterns emerge.
Agents that take actions in real systems can cause real damage. The standard defenses are layered: typed permissions per tool (read versus write), explicit user approval for irreversible actions, rate limits on dangerous operations, sandboxes for code execution, and audit logs for every action. These are not optional features; they are required infrastructure for any agent operating in production. Beyond technical guards, organizational practice matters. Define what an agent is allowed to do. Define who reviews its behavior. Define how incidents are handled. Treat agent deployment with the same rigor as deploying any system that can affect customers or finances. The teams that skip this work tend to find out the hard way when something goes wrong.
A well-designed agent gets the error message back from the failed tool call, includes it in the next step's context, and the model decides what to do: retry with different parameters, try a different tool, ask the user, or give up. The quality of error messages matters; vague errors lead to retry loops, while specific errors give the model what it needs to recover. Setting limits prevents pathological loops. A maximum number of consecutive failures, a maximum number of steps overall, a hard timeout. When these fire, the agent stops and reports back rather than running forever. This is mundane engineering but it is what separates agents that work in production from demos that look good and fail in real use.
Cost is the sum of tokens consumed across all steps in the loop. A typical interactive agent task might use 5,000 to 50,000 tokens of context across its steps, depending on tool results and conversation length. At frontier model pricing this is anywhere from a few cents to a couple of dollars per task. At small model pricing it can be a fraction of a cent. The scale that bites is high-volume agent deployment. An agent handling 100,000 tasks a day at $0.50 each is $50,000 a day, which adds up fast. Cost optimization patterns include using smaller models where they suffice, caching common tool results, minimizing unnecessary back-and-forth, and pruning context aggressively. Teams without these in place are surprised by their first month's bill.
The trajectory points toward more reliable agents on more workflows with better tool ecosystems. Models are getting better at planning and tool use. Frameworks are maturing in ways that make production-grade agents easier to build. Vertical agents are emerging for specific industries with deep tool integration and tuned prompts. The realistic expectation is not autonomous AGI replacing all knowledge work. It is many specialized agents quietly handling parts of business workflows, with humans supervising the edges. Where this lands depends on how well operational and safety problems get solved. The technology gains alone are not enough; the surrounding infrastructure of evaluation, observability, governance, and integration has to keep pace.
