When a client asks us whether they need an "AI agent," they usually mean one of three different things without knowing which one. Sometimes they want a chatbot that answers questions. Sometimes they want a system that monitors their email and takes actions. Sometimes they want a fully autonomous workflow runner that handles an entire process without human input. These are meaningfully different things — and building the wrong one for a process is how AI projects end up sitting unused.

This note defines what an agent is, draws the lines between agent types, and gives you a framework for deciding which type your process actually needs.

A working definition

An AI agent is a software system that perceives its environment, makes decisions based on what it perceives, and takes actions to achieve a defined goal — without requiring a human to direct each step.

The key word is actions. A chatbot that answers questions is responding to input; it's not acting on the world. An agent that reads an email, classifies it, updates a CRM record, and sends a follow-up — that's acting. The distinction matters because agents need write access to systems, they need defined boundaries, and they need a way to surface edge cases they can't handle. Chatbots need none of these.

Three components define an agent:

  • Perception: the ability to receive and interpret input (email, form submissions, database events, API calls)
  • Decision logic: rules or a model that determines what to do based on the input
  • Action capability: the ability to write to systems, send messages, trigger workflows, or call APIs

Remove any one of these and you no longer have an agent.

Four types, not a spectrum

Most writing on AI agents describes a "spectrum of autonomy" from fully supervised to fully autonomous. This framing is technically accurate but operationally unhelpful — it doesn't help you decide what to build.

A more useful taxonomy for business processes is by action scope: what is the agent permitted to do, and what requires human confirmation?

Type 1 — Read and flag. The agent reads inputs, identifies patterns or anomalies, and flags them for a human. No writes, no sends. This is the safest starting point for any new process and useful where errors are expensive. Example: an agent that reads incoming contracts and flags any that are missing a renewal clause.

Type 2 — Read, decide, and draft. The agent processes input, makes a decision, and prepares an output — but a human reviews before anything is sent or written. Good for processes where volume is high but judgment errors are costly. Example: an agent that classifies inbound support tickets, drafts a response, and queues it for a human to approve before sending.

Type 3 — Read, decide, and act within scope. The agent handles the full process for defined patterns without human review. Escalates outside its defined scope. This is the most common type we build. Example: an agent that handles lead intake — classifies, scores, books a meeting, sends a confirmation — but escalates anything that doesn't match known patterns to a sales rep.

Type 4 — Full autonomy within a bounded system. The agent handles everything within a defined system without human touchpoints, including edge cases, and only flags for human review in exceptional circumstances. Appropriate for well-understood, low-risk processes with good error detection. Example: an agent that runs nightly reporting — pulls data, generates summaries, distributes — with no human in the loop unless a data source is unavailable.

Choosing the right type for your process

The choice isn't about how much you trust the technology. It's about the cost of errors and how well the process is defined.

Ask three questions about your process:

What's the cost of an error? If the agent sends the wrong follow-up email to a prospect, that's recoverable. If it routes a contract to the wrong counterparty, it might not be. The higher the error cost, the lower the autonomy type you should start with.

How well-defined is the process? If you can write down every step, every decision point, and every exception, you have enough definition for a Type 3 or 4 agent. If your team disagrees on how the process works, start with Type 1 and use the agent's output to surface the disagreements.

How frequently does the process involve exceptions? Every process has edge cases. The question is what proportion of cases fall outside the normal pattern. If it's more than 20%, you need a well-designed escalation path before you can trust the agent with the full volume.

Three mistakes to avoid

We see these consistently across companies that have tried and failed to build agents before reaching us.

Building Type 4 when the process needs Type 2. Full autonomy sounds appealing, but most processes aren't ready for it. Starting with too much autonomy means errors accumulate before anyone notices — and by the time they do, trust in the agent is gone.

Skipping the escalation design. Every agent needs a clear answer to the question "what happens when this falls outside my scope?" An agent without a well-designed escalation path either halts the process or makes a guess. Neither is acceptable in a production system.

Treating the agent's scope as permanent. An agent built for today's process needs to be tunable as the process evolves. If the logic is opaque — if you can't inspect why the agent made a particular decision — you can't adjust it when something changes. Build for inspectability from the start.