AI Engineering
Types of AI Agents: Understanding the Key Variants of Intelligent Systems
Compare agent designs by their decisions, memory, tools, and coordination needs.
An agent label is useful when it explains how a system decides what to do next. It becomes less useful when it suggests that every application needs the most autonomous design available. A simple routing assistant and a research system can both use language models while having very different operating requirements.
Rather than treating agent types as a ranking, compare four design questions: who controls the sequence, what state is retained, which actions are available, and how success is checked. The categories below are practical design lenses, not a universal taxonomy or a promise that one framework uses the same names.
A controlled workflow
A workflow defines the sequence in application code. It might classify a request, retrieve a matching policy, draft a response, and validate required fields. Individual steps can use AI while the allowed transitions remain explicit. This is useful when the business process is understood and consistency matters more than open-ended exploration.
Anthropic separates these predefined workflows from agents that dynamically direct their process and tool use. That distinction is more informative than counting model calls. A pipeline with several prompts can still have a fixed control structure, while a short tool-using loop can make its own execution choices.
An agent that selects its next action
Use a flexible loop when the next useful step depends on what the system discovers. A research assistant might inspect a document, notice that a claim lacks a date, and retrieve another source. The relevant capability is adapting the investigation, not simply producing a longer answer.
Design a stopping rule before adding more tools. The agent should know what evidence is sufficient, what uncertainty requires help, and what budget remains. In a product comparison, finding ten more pages may add less value than recognizing that two offers use incompatible billing periods. Evaluate decisions against the intended result.
A system with persistent context
Some tasks benefit from remembering approved preferences or the state of unfinished work. Treat that memory as application data with an owner, a source, and an update policy. A saved preference is different from an inferred preference, and a temporary conversation detail should not automatically become a permanent customer fact.
Decide how the system corrects old information. If a customer changes their delivery address, identify the authoritative record and invalidate conflicting cached context. Also separate retrieval from authorization: remembering that a document exists does not establish that the current user can access it. These decisions matter regardless of the model provider.
A coordinated group of agents
Google's Agent Development Kit supports combining agents with execution nodes and workflow controls. Its documentation describes mixing AI reasoning with deterministic logic and composing specialized capabilities. A multi-agent design therefore needs an explicit coordination structure; assigning several role names is only a starting point.
Consider independent reviews of a proposed change: one examines data migration, another checks interface behavior, and a coordinator combines findings. Define each reviewer's input, expected output, and authority. Avoid shared mutable work unless ownership is clear. Parallel activity helps when tasks are separable, but disagreements and duplicated effort still need a resolution path.
Choose using failure cases
Take a representative task and write down the failures that would make its result unusable. A document summarizer may fail by omitting a qualification. An operations agent may fail by repeating a completed action. Those risks point toward different evaluation methods and different limits on autonomy.
Compare candidate designs on the same cases, including ambiguous inputs and unavailable dependencies. Measure acceptable outcomes, review effort, duration, and cost. Choose the least complicated design that meets those obligations, then revisit the decision when real evidence shows where additional state, tools, or coordination would help.