A production taxonomy for distinguishing conversation, tool use, workflow control, and delegated operational autonomy.
In a production review, “agent” is not a useful description until the execution trace is visible.
A chatbot may repeat a generation before answering. A tool-using assistant may search a system or prepare a draft. A workflow may let a model classify an exception while application code controls the sequence. An operational agent may receive a goal, choose its next steps, observe what happened, and make authorized changes.
All four can be called agentic. They do not delegate the same decisions.
The practical question is not how many times a model runs or how many tools appear in its configuration. It is who chooses what happens next, what state can change, and where control returns to a person or deterministic system.
One label, several architectures
There is no single boundary around the word “agent.” Anthropic describes a broad family of agentic systems and distinguishes predefined workflows from systems in which a model directs its own process and tool use. OpenAI’s guide uses a narrower definition centered on a model managing workflow execution, selecting tools dynamically, and operating within guardrails; it explicitly separates simple chatbots and single-turn model applications from agents.[1][2]
Those definitions are useful, but they answer different questions. For production design, CARM’INK uses the following working taxonomy. It describes dominant control patterns; it is not a universal standard or a maturity ladder. A single product can combine several patterns, and a system with more action authority may still be less self-directed than one with fewer tools.
1. The chatbot loop
The system generates, checks, revises, or continues a response inside a conversation. It may call the model several times. It may even use retrieval behind the scenes. But the user or application still supplies each task, and the loop ends with an answer rather than an independently managed operation.
A loop is not autonomy by itself. Repeated inference can improve an answer without giving the model control of an operational process.
2. The tool-using assistant
The model can request or select tools: look up a record, search a knowledge base, calculate a value, or prepare a proposed update. The host application decides which tools exist, which identity is used, and which requests are authorized.
Tool use can be read-only, action-oriented, or a mixture. A tool call that retrieves a status does not carry the same authority as one that changes a live record. An assistant may also have permission to perform a write, but require an explicit user request or approval for each one.
This is a meaningful step beyond conversation, but the presence of tools alone does not tell us how much initiative the model has.
3. The workflow agent
The model handles uncertain inputs or local decisions inside a path designed by the application. It might classify a request, extract fields, choose among approved routes, or draft a response. Code, policy checks, or a human checkpoint still owns the major transitions.
The model has discretion, but within a defined procedure. The application knows what stage comes next and when the task is complete. Many systems marketed as agents fit this description: they use language-model judgment where it helps, while keeping execution legible and bounded.
4. The autonomous operational system
A goal is delegated rather than a single response requested. The system can choose and sequence steps, inspect the results, adjust its approach, and continue until a stopping condition is met or it needs help. Its authority may include changes to external systems.
“Autonomous” here does not mean unrestricted or free of human oversight. It means the system has been delegated control over some part of the process. The scope of that delegation can be narrow, temporary, and revocable.
These categories overlap. A tool-using assistant may dynamically plan; a workflow agent may operate unattended for a while; an operational system may be tightly limited to read-only tools. The label should describe the system’s actual decision rights, not suggest a simple climb from “basic” to “advanced.”
Count the rights, not the tools
A tool inventory is a poor proxy for agency. OpenAI separates data tools, action tools, and orchestration tools, and notes that tool similarity and overlap can matter more than the raw count.[2] A dozen distinct read operations may expose less operational authority than one tool that can publish, approve, delete, or transfer.
For each deployed system, record five things:
- Initiative: Who chooses the next step—the user, application logic, or model?
- Operation: Can the model observe, recommend, draft, or commit a change?
- Scope: Which records, systems, identities, and permissions are available?
- Persistence: Does execution end with one response, one task, or continue in the background?
- Control and recovery: What causes a pause, escalation, cancellation, or rollback?
This is a clearer production description than “the agent has eight tools.”
The profile makes the boundary visible. It also exposes a design choice that a product label can hide: does “draft” mean the model creates a private proposal, or does it write into a shared system? Production authority lives in those details.
Authority is the consequential boundary
A model can select a tool without being authorized to complete the action. The application and underlying systems should enforce identity, permissions, and policy at the point where an operation executes. Instructions in a prompt are not a substitute for those controls.
Risk depends on what an operation can do, whether it is reversible, what permissions it needs, and what consequences follow. OpenAI’s agent-building guide recommends evaluating tool safeguards along these dimensions and using checks or human escalation for higher-risk operations.[2] That is a more useful basis for governing deployment than calling an agent “advanced” because it can reach many APIs.
Human oversight also needs a precise definition. NIST describes human–AI configurations across a spectrum from fully autonomous to fully manual and emphasizes defining human roles and responsibilities for the system in its operational setting.[3] “Human in the loop” is not a sufficient control description. Teams should specify who can approve, interrupt, override, or resume an operation, what information that person sees, and what happens when no one responds.
A human checkpoint that cannot stop execution is not a meaningful checkpoint. A person asked to review every trivial action may become a rubber stamp. Oversight should be placed where the consequence and uncertainty justify it.
Make “agentic” an operating specification
A credible production claim should be answerable in plain language:
The model may choose the next step within this task. It can read these sources and prepare this class of change. It cannot commit the change without this authorization. It stops when this condition is met, and this person or service can interrupt or recover the run.
That sentence says more than a tool count, a model name, or a product badge. It gives engineers a surface to test and operators a boundary to govern.
“Agentic” is not a capability switch. It is a statement about delegated control. Define the delegation, and the architecture becomes discussable.
References
- Anthropic, “Building effective agents”, December 19, 2024. Cited here for its distinction between predefined workflows and model-directed agents; Anthropic notes that much of the tooling landscape described in the article has since changed.
- OpenAI, “A practical guide to building AI agents”, January 15, 2026.
- National Institute of Standards and Technology, AI Risk Management Framework 1.0, Appendix C: AI Risk Management and Human-AI Interaction, 2023.