The practical way to understand the types of AI agents is to classify them on two separate axes: what they can do and how much authority they have. For example, a CRM system could use AI to classify a contact from supplied company and job-title fields, then send a high-fit result to a representative for review. That is a task-specific, context-aware capability with an approval boundary, not one exclusive agent type.
There is no universally accepted list of mutually exclusive agent types for business buyers. Use fixed rules for explicit conditions, bounded AI for interpretation, and an agent when a task needs adaptive steps across tools. Decide separately whether the system may recommend, draft, or act.
What are the types of AI agents?
An AI agent is a system that can use information and configured tools to pursue a defined task, often by selecting or coordinating more than one step. An assistant primarily responds to a user’s request with information or generated content. A fixed workflow follows predetermined steps. These distinctions can blur in products, so classify the configured behavior rather than relying on the product label. HubSpot distinguishes Breeze Assistants, which primarily answer or generate information, from Breeze Agents, which can follow defined steps and perform configured actions. HubSpot’s overview of assistants and agents describes those product roles.
Ask two questions before choosing a label:
- Capability and coordination: Is the system applying a fixed rule, interpreting one bounded task, using permitted context, adapting across several tool calls, or coordinating multiple agents?
- Authority: Does it suggest an action, prepare a draft for approval, perform reversible actions, or act within bounded permissions and escalate exceptions?
A system can be task-specific, context-aware, and partly autonomous at the same time. The familiar labels reactive, limited-memory, theory-of-mind, and self-aware are conceptual categories, not a definitive business-product taxonomy. Theory-of-mind and self-aware agents are research or hypothetical concepts, not ordinary commercial options. An emotionally responsive interface does not establish formal theory-of-mind capability.
Classify an agent by both what it can do and what it is authorized to do. Capability and authority are separate design decisions.
How an AI agent moves from a request to an action
A typical run begins with a user request or business event, gathers permitted context, selects a task or next step, calls configured tools, checks the returned results, and either performs an authorized action or hands the case to a person. Autonomy is bounded by the tools and permissions configured for that agent, its policies and stop conditions, validation, and escalation rules.
Keep three records distinct. A business event is what started the work, such as a contact being submitted. An agent run is one attempt to handle that event. A tool call is an individual interaction with a CRM, repository, or other system during the run. One run may make several tool calls, and a retry may create another run for the same source event.
ReAct is a documented research pattern that alternates reasoning, actions, and observations. It helps explain how an agent might adjust after a tool response; it is not evidence that a named commercial product uses ReAct internally. Google Research’s ReAct overview describes the research pattern.
A practical framework for classifying agent operating models
The capability axis describes the work pattern. The authority axis describes the permission to act. These choices are related, but neither determines the other.
| Capability pattern | Suitable task | Action boundary | Fallback |
|---|---|---|---|
| Deterministic rules | Route a complete form by an explicit field value | Apply the specified rule only | Send unmatched or incomplete cases to an owner |
| Task-specific AI | Classify an email or contact using supplied evidence | Return a bounded label or draft | Review missing, conflicting, or invalid output |
| Context-aware, multi-step agent | Use permitted records and tool results to determine the next step | Call only configured tools; gate consequential actions | Escalate failed tools or out-of-scope requests |
| Multi-agent orchestration | Coordinate distinct roles or systems when separation adds value | Define each role, shared state, and handoff | Route coordination conflicts to an owner |
Use deterministic rules
When inputs and outcomes are explicit and stable, rules are easier to inspect and test. Apply them to routing, required-field checks, deduplication, and thresholds.
Consider bounded AI or an agent
Use AI to interpret unstructured material with a constrained output. Consider an agent when several tool results can change the next step. Add multiple agents only when distinct roles need to coordinate.
For example, if a rule can route a lead based on a known territory field, an agent adds little. If a person must interpret a paragraph of business context, a bounded classifier may help. If the task must retrieve records, compare them, and choose a follow-up based on the results, an agent may be justified.
Three documented examples and what their workflows do not prove
These examples show different bounded workflows, not interchangeable products. Product names, availability, permissions, and behavior depend on configuration and may change. The validation and exception controls marked as proposed below are implementation recommendations, not claims about universal vendor behavior.
| Trigger and input | AI job and output | Validation and destination | Fallback and owner |
|---|---|---|---|
| HubSpot Breeze ICP example: contact fields such as company size, industry, job title, country, and lead source | Return High fit, Medium fit, or Low fit with a reason | HubSpot documents a conditional high-fit action for representative review. Proposed controls validate required fields and allowed labels before routing. | Missing or conflicting evidence goes to Needs review. A sales representative or CRM workflow owner handles the case. |
| Salesforce Agentforce: a user request, conversation, data change, or configured automation trigger | Use relevant context, select a configured action, and return or execute it within scope | Actions may use flows, Apex, APIs, prompt templates, or predictive models. Permissions, validation rules, and human escalation govern the destination. | Tool, permission, or scope failure preserves execution status and routes to the Salesforce administrator or workflow owner. |
| GitHub coding agent: an assigned issue or prompt in a configured repository | Work in repository context and create or update a pull request | Repository tests, security checks, policy, and pull-request review govern whether changes proceed. | Failed checks or an out-of-scope change returns to the maintainer, who requests changes or rejects the pull request. |
For the HubSpot example, the documented output labels, reason, and conditional high-fit review action come from HubSpot’s agent-creation guide. The example is a prompt and intended behavior, not a complete production schema or external integration. Proposed validation can require relevant fields, reject labels outside the three allowed values, and send missing or conflicting data to a review queue. Do not attribute a confidence threshold, retry policy, or duplicate-prevention mechanism to the example. For CRM configuration and system-of-record boundaries, see HubSpot systems consulting and CRM systems consulting.
Salesforce describes Agentforce agents as working with triggers, context, configured actions, guardrails, and escalation. Its action documentation distinguishes deterministic calls from tools that a language model may select. The exact behavior depends on implementation, licensing, and permissions; configured actions are not unrestricted access. See the Salesforce Agentforce overview and action reference.
GitHub documents coding-agent work that can start from an issue or prompt and result in a pull request for review. This is an example of bounded coding work, not a general-purpose business agent. GitHub’s coding-agent documentation describes the workflow and policy considerations. Separately, Thomson Reuters describes CoCounsel Legal as supporting specialized legal research and document-analysis workflows with citations and professional review. That makes it an example of domain-specific legal AI, not proof that every interaction is autonomous. CoCounsel Legal product information.
How to choose the right type of AI agent
Start with the workflow, not the agent label. Identify how repeatable the task is, whether inputs are structured, how many systems it touches, what an error would affect, and whether the action can be reversed. Then choose the least complex capability and the minimum authority that can complete the job.
- Use rules when the decision is explicit, repeatable, and based on defined fields.
- Use bounded AI classification when the input needs semantic interpretation but the output can be checked against a known set of values.
- Use an agent when the task needs multiple tool calls and the next step depends on what those tools return.
- Use multi-agent orchestration only when separate roles or work streams need coordination that one narrowly scoped agent cannot handle cleanly.
Before planning a write, name the system of record and the person accountable for the destination action. If downstream logic depends on exact fields or enumerated labels, define a structured output contract and validate it in the receiving system. A prompt requesting JSON does not, by itself, guarantee valid JSON or enforce a schema.
For example, the following is a proposed result shape for a contact-classification workflow, not a HubSpot-published schema:
{
"classification": "High fit",
"reason": "The supplied industry and company size match the stated criteria.",
"source_record_id": "contact-4821",
"agent_run_id": "run-2026-1042",
"configuration_version": "icp-v3",
"review_status": "Pending"
}In this illustrative contract, validate that the classification belongs to the allowed set, required identifiers are present, the configuration version is recorded, and the reason refers only to supplied evidence. The receiving workflow can send a valid high-fit result to representative review. It should not silently change lifecycle stage, lead status, or ownership unless the business has separately defined and authorized that mapping.
- The job and its stop condition are clear.
- Required data is available with the right permissions.
- The output can be checked against fields, values, or evidence.
- The action is reversible, or an approval threshold is defined.
- The system of record and action owner are named.
- A person owns missing data, tool failure, and out-of-scope requests.
Controls that make an agent usable in a real workflow
Apply access controls before prompting. Expose only the tools and data needed for the task, check required fields before execution, validate output values before write-back, and use deterministic checks before high-impact actions. Require human approval for consequential or difficult-to-reverse changes. Define who handles each exception and retain a run and action record so operators can reconstruct what happened.
Preventing duplicate processing requires more than searching for a matching record before creating one. Give each source event a stable identifier and each execution its own run identifier. Make downstream writes idempotent, so replaying the same source event does not create another business record. When concurrent workers can process an event, enforce uniqueness in the database or use an atomic upsert. A lookup followed by a create can race: two workers may both find no record and then create duplicates.
Keep data grains distinct in logs. A source event is not an agent run, and a run is not a tool call. Store their identifiers separately, alongside the destination record ID where available. A proposed CRM event key might combine tenant ID, workflow ID, provider event ID, and source record ID. A run key should add a unique execution ID, while a tool-call record should add a tool-call ID and sequence number. These are illustrative data-model recommendations, not vendor-published schemas.
Likewise, conversation context, temporary run state, CRM records, retrieved knowledge, user preferences, and execution history are different forms of memory, with different access, retention, and deletion implications. Do not describe an agent as having memory without specifying which of these forms is retained.
Measure operations without assuming a benchmark: completion rate, exception rate, duplicate rate, review turnaround, and error severity can show whether a bounded pilot is working. Compare results with a baseline for the same workflow and record the period and definition used. Keep raw runs and tool calls separate from reported summaries. A daily aggregate should not overwrite the underlying events, and a contact or deal event should not be confused with an aggregate metric.
A staged path from workflow assessment to bounded autonomy
Document the current workflow and its owner first, then measure its baseline. Decide whether explicit rules, AI assistance, or an agent is justified. Pilot a low-risk, reversible task with defined inputs, an output contract, permissions, a fallback, and review criteria. Test missing fields, invalid output, tool failure, repeated events, and concurrent processing before widening access. Review action and exception records before increasing authority or removing an approval step.
Current Deloitte research discusses expanding agentic-AI adoption alongside governance, infrastructure, data, talent, and operational-readiness challenges. It does not establish that every organization should use the same autonomy model. Deloitte’s State of AI in the Enterprise research provides broader context. For teams assessing a bounded use case, AI agent consulting can support workflow and operating-model planning.
The practical choice is the least autonomous model that reliably completes the defined job: rules for explicit conditions, bounded AI for interpretation, and an agent when adaptive, multi-step tool use is genuinely required.