When I review AI projects across enterprises, the same confusion comes up over and over: people use the word “agent” for systems that span six orders of magnitude in complexity. A scripted FAQ bot and a multi-agent research system are both called “agents” in marketing decks, and that linguistic collapse makes it almost impossible to have a useful conversation about cost, risk, or capability. I borrowed the autonomous-vehicle industry’s trick of defining discrete levels and applied it to AI agency. The result is the five-level framework I use in every architecture review.
The 5 Levels of AI Agency: From Simple Bots to Autonomous Agents
In this article, I will walk you through Level 0 through Level 5 of AI agency, with worked examples at each level, current market position, capability per level, and the risk profile that determines what you should and should not deploy. I will be opinionated about which level fits which problem, because the most expensive mistake I see teams make is targeting the wrong level of agency for their use case. Over-shooting is wasteful and dangerous. Under-shooting leaves value on the table.
By the end, you should be able to point at any AI system in your organisation and tell me, with confidence, which level it sits at, why, and whether that is the right level for the job.
Why levels of agency matter
The reason to define levels is that agency is not free. Each level above the previous one adds capability but also adds cost, complexity, latency, and risk. If you do not name the levels, your team will silently overshoot, and you will discover the overshoot only when the production bill arrives or the system causes an incident.
“The autonomous-vehicle industry needed SAE levels because the same word, ‘autopilot’, meant very different things to different people. AI agency has the same problem. Naming the levels is a precondition for designing them.”
The five-level framework I use is not the only one in circulation. Andrej Karpathy, OpenAI, Anthropic, and various academic groups have all published their own versions. They are broadly compatible, but I prefer the version that emphasises tool use and multi-agent coordination because those are the operational dimensions that drive cost and risk in practice.
Level 0: rule-based chatbots and scripted systems
Level 0 systems use no LLM. They follow scripted decision trees, regex patterns, or rule-based logic. The classic 2010s customer support chatbot is Level 0. So is most of what people called “RPA” five years ago.
Strengths:
- Deterministic and predictable
- Cheap to run
- Easy to audit and certify
- Familiar to compliance and risk teams
Weaknesses:
- Cannot handle natural language variation
- Brittle to small changes in user phrasing
- Cannot reason about novel situations
- Maintenance burden grows linearly with the number of intents
Level 0 still has a place in 2026. For high-volume, low-variability tasks where determinism matters more than flexibility (regulatory disclosures, structured form filling), Level 0 is often the correct choice. The mistake is using Level 0 for tasks where users actually need to express themselves in natural language.
Level 1: LLM question and answer
Level 1 systems use a large language model to answer questions or produce content based on a prompt, without tool use or multi-step planning. ChatGPT in its basic chat mode is the canonical Level 1 system. So is most “AI search” and most early generative AI features in SaaS products.
Strengths:
- Handles natural language flexibly
- Produces high-quality content for many tasks
- Simple to integrate (one API call)
- Low latency relative to higher levels
Weaknesses:
- Limited to the model’s training data
- Cannot access live information
- Cannot take action on behalf of the user
- Hallucinates when uncertain
Level 1 is the right answer for content production, drafting, summarisation, and general Q&A where the user is going to take the resulting content and act on it themselves. Most consumer AI features sit at this level, and most should.
I see teams over-engineer Level 1 systems by adding agentic layers that do not provide value. If the task is “summarise this article,” you do not need an agent. You need a Level 1 system with a good prompt.
Level 2: LLM with tools
Level 2 systems augment the LLM with the ability to call tools. The model can search the web, query a database, look up an order, or fetch a file. The tool calls are typically single-step (one tool per interaction), and the control flow is straightforward.
Strengths:
- Accesses live information
- Can act on specific user requests
- Significantly more useful than Level 1 for many real workflows
- Still bounded enough to be predictable
Weaknesses:
- Tool selection errors become a real failure mode
- Latency increases (tool calls add round trips)
- Integration burden grows with the number of tools
- Authorisation becomes a meaningful concern
Level 2 is where most production “AI features” in enterprise SaaS sit in 2026. Salesforce’s Einstein, Microsoft Copilot, and most vertical AI products are Level 2 systems with carefully selected tool sets.
“Most teams that say they are building agents are really building Level 2 systems. That is fine. Level 2 is genuinely useful and much more shippable than Level 3 and above.”
Level 3: multi-step planners
Level 3 is where agentic behaviour begins in earnest. A Level 3 system plans a sequence of steps, executes them, observes the results, and adjusts the plan based on what happens. This is the ReAct loop, the LangGraph state machine, the agentic core of every modern framework.
Strengths:
Can complete complex multi-step tasks
Adapts to intermediate results
Handles tasks too complex for fixed pipelines
Reflects on errors and recovers
Weaknesses:
Significantly higher cost per task (often 10-50x Level 2)
Latency in tens of seconds to minutes
Failure modes are harder to predict
Requires sophisticated observability
This is where most “real” agentic AI deployments operate in 2026. Coding agents like Claude Code, customer support agents like Salesforce Agentforce, and research agents from OpenAI and Anthropic are Level 3 systems.
For the planning patterns that power Level 3, see ReAct, Plan-Execute, Reflection: agent patterns.
Level 4: multi-agent coordinators
Level 4 systems coordinate multiple specialised agents to complete a task. There is usually an orchestrator agent that decomposes the task and assigns sub-tasks to worker agents, which may themselves be Level 3 agents.
Strengths:
- Handles complex tasks with multiple skill domains
- Allows specialisation (a “researcher” agent, a “writer” agent, a “critic” agent)
- Parallelises work where possible
- Provides natural separation of concerns
Weaknesses:
- Significantly higher cost (often 5-20x Level 3)
- Coordination overhead can dominate
- Debugging is genuinely hard
- Failure modes compound across agents
Multi-agent systems are appropriate when the task genuinely benefits from specialisation. They are not a magic upgrade for any Level 3 problem. I see many Level 4 systems that would have been simpler, cheaper, and more reliable as well-designed Level 3 systems.
For an honest assessment, see multi-agent systems collaboration.
Level 5: autonomous goal-pursuit
Level 5 systems are given a high-level goal and pursue it autonomously over long horizons (hours to days), making consequential decisions with minimal or no human oversight. This is the level where the word “autonomous” actually applies.
In 2026, Level 5 is still mostly aspirational for production deployment. The demos exist (Devin’s early demos, some autonomous research agents, certain robotics systems), but the production track record is thin. The failure modes at this level are genuinely difficult: long-horizon planning is hard, irreversible actions accumulate, and the cost of a wrong decision can be enormous.
Strengths in principle:
- Could deliver enormous value if reliable
- Frees humans from oversight entirely
- Enables workflows that no current system can handle
Weaknesses in practice:
- Reliability is poor over long horizons
- Cost can be very high per task
- Risk is hard to bound
- Trust is hard to establish
I am bullish on Level 5 in the medium term and bearish on it for production deployment in 2026. The teams that succeed at Level 5 in the next two years will mostly be the ones who initially deployed it inside heavily sandboxed environments with extensive human verification.
Worked examples at each level
Here is a concrete example at each level for a customer support use case:
| Level | Example | What it does |
|---|---|---|
| 0 | Scripted FAQ bot | Matches user query to a fixed answer set |
| 1 | LLM Q&A over the knowledge base | Generates an answer from the user’s question and a fixed corpus |
| 2 | LLM with order-lookup tool | Answers questions and looks up specific orders on request |
| 3 | Multi-step support agent | Plans a sequence (look up order, check eligibility, issue refund, send confirmation) |
| 4 | Specialist agent ensemble | Coordinates a “triage” agent, a “billing” agent, and a “logistics” agent |
| 5 | Autonomous support manager | Handles the entire support function with minimal human oversight |
Every example above exists in some form in 2026. The market depth is heaviest at Levels 1, 2, and 3. Level 4 deployments are rare but growing. Level 5 in customer support is mostly demos.
Current market position per level
A rough read of where 2026 production deployments concentrate:
- Level 0: still the majority of “chatbot” deployments by sheer count, though declining
- Level 1: ubiquitous; almost every consumer product has at least one Level 1 feature
- Level 2: the dominant pattern for enterprise AI features
- Level 3: the fastest-growing category, where most agentic AI investment goes
- Level 4: a smaller but real category, mostly in specialised domains (research, engineering, complex sales)
- Level 5: experimental, with a few production deployments in narrow domains
The investment dollars and the M&A activity in 2026 are heavily weighted toward Levels 3 and 4. The Level 1 and 2 markets are mature, with most value captured by major vendors. The Level 5 market is open, but few teams are ready to ship there.
Capability and risk by level
I think about capability and risk on a 2D grid rather than a simple ordering. Each level offers more capability but also more risk.
| Level | Capability | Risk | Best fit |
|---|---|---|---|
| 0 | Narrow, deterministic | Very low | Regulatory, structured workflows |
| 1 | Broad content | Low (content errors) | Drafting, summarisation, Q&A |
| 2 | Content + lookups | Moderate (wrong actions on specific records) | Knowledge work with light action |
| 3 | Multi-step workflows | Moderate to high (compounded errors) | Workflow automation, support, coding |
| 4 | Cross-domain workflows | High (cross-agent failures) | Complex research, multi-skill workflows |
| 5 | Long-horizon autonomy | Very high (irreversible decisions) | Niche, sandboxed, high-trust environments |
The risk column is critical. Many teams think about agency in terms of capability and ignore the risk profile. Then they discover, after deployment, that a Level 3 agent with permissions to write to production systems has the operational risk of a senior employee with no judgement.
The cost curve across levels
Cost grows non-linearly with agency level. Order-of-magnitude estimates I track:
- Level 1: fractions of a cent per task
- Level 2: cents per task
- Level 3: tens of cents to dollars per task
- Level 4: dollars to tens of dollars per task
- Level 5: tens of dollars to hundreds per task, with high variance
The cost curve has implications for what economic problems each level can address. A Level 1 system can be free at the margin. A Level 5 system needs to deliver hundreds of dollars of value per task to justify the cost. That immediately narrows the use cases.
“Most failed agentic AI projects I have seen failed not because the technology did not work, but because the per-task cost exceeded the per-task value. Pick a level whose unit economics fit your problem.”
How to choose the right level
When I help teams choose, I work through five questions:
- What is the user’s job? (Receive an artefact, get a lookup answered, complete a workflow, complete a complex workflow, run a function autonomously)
- What is the per-task value? (Tens of dollars? Hundreds? Thousands?)
- What is the cost of an irreversible error? (Recoverable? Significant? Catastrophic?)
- What latency is acceptable? (Seconds? Minutes? Hours?)
- What is the user’s tolerance for being in the loop? (Always? Sometimes? Rarely?)
The answers map fairly cleanly to a level. If the user wants an artefact, value is low, errors are recoverable, latency tolerance is low, and the user is happy in the loop, that is Level 1. If the user wants a complex multi-step workflow completed, value is high, errors are recoverable with guardrails, latency tolerance is high, and the user accepts checkpoint-based oversight, that is Level 3.
The middle cases are the dangerous ones. Treat ambiguity as a reason to pick the lower level and iterate up, not a reason to pick the higher level and hope.
When to climb the levels and when to descend
I push teams to think of the level as a parameter they can change over time, not a fixed property of the project.
When to climb:
- The current level is delivering value and the cost of the next level is justified by unblocked use cases
- Reliability at the current level is high enough that the additional risk of the next level is acceptable
- The team has the observability and evaluation infrastructure to detect failures at the next level
When to descend:
- The current level is delivering poor reliability or unsustainable cost
- The use case turns out to be narrower than originally assumed
- The risk profile of the current level is unacceptable to the business
Descending is not a failure. Some of the most successful AI deployments I have seen started at Level 3 ambition, descended to Level 2 after a reliability review, and have been printing value at Level 2 ever since.
Common anti-patterns
The anti-patterns I see most often:
- Building Level 3 when Level 2 would deliver the same business value at one-twentieth the cost
- Building Level 4 when Level 3 with better tool design would suffice
- Building Level 5 because it makes for a great demo, then quietly never shipping
- Skipping observability and evaluation because “we will add it later”
- Using one level’s evaluation methodology for another level’s system
The deepest anti-pattern is the cultural one: teams that view climbing the agency ladder as a measure of technical sophistication. It is not. The measure of technical sophistication is picking the right level for the problem and shipping reliably at that level

