Which steps AI agents can own comes from the process itself. Walk one critical process case by case. Steps with checkable outcomes, reversible actions and known inputs are candidates for an agent. Steps that are irreversible, high-stakes or new to everyone stay with a person. Where that line falls is the most important design decision in any agent project.
Plan AI agents for business around a process the business already runs, because the models change every few months and the process does not. An operations leader needs a way to look at that process and say which parts of it an agent can be trusted with, which parts it cannot, and what has to be true before it goes live.
What is an AI agent, in operational terms?
An AI agent is software that works toward a goal by deciding its own next step. OpenAI's practical guide to building agents defines agents as "systems that independently accomplish tasks on your behalf," and describes two traits: a language model manages the workflow and recognizes when it is done or has failed, and the agent selects tools to gather context and take actions, "always operating within clearly defined guardrails." Anthropic's engineering guidance separates agents, where the model directs its own process and tool use, from workflows, where models and tools follow "predefined code paths."
In a business, an agent is only as good as what it is given:
- A goal tied to a case. Resolve this inquiry, match this invoice, update this record.
- Tools. Read and write access to the systems the case touches: the CRM, the billing platform, the ticketing queue, the document store.
- A workflow. The steps, hand-offs and stop conditions the agent works inside, described in the entry on the AI agent workflow.
- Limits. What it may change, how much, and what needs approval: its guardrails.
- A person. The named owner of the cases the agent should not settle: the human in the loop.
What makes an agent an "enterprise" agent has less to do with the model than with the surroundings. At a company with thousands of staff, the agent touches systems of record that other teams depend on, its permissions pass through security review, its actions need an audit trail, and the people whose work it changes have managers, procedures and sometimes contracts that define who does what. An agent that ignores those realities can still impress in a demo; it will not get through its first month in production.
Two neighboring categories cause most of the confusion. An AI assistant helps a person who stays accountable for each result; an agent owns a step of the process. The full comparison is in AI agent vs AI assistant. Robotic process automation follows a fixed script and repeats it exactly; agents read and interpret. RPA vs AI agents sets out when each wins, and the answer is often both.
What can an AI agent own in an operation?
An agent can own a step when its inputs can be read, its outcome can be checked, and its mistakes can be caught or undone before they matter. Everything else belongs with a person, at least until evidence says otherwise.
| Dimension | An agent can own the step when | Hand the case to a person when |
|---|---|---|
| Inputs | They arrive as text, documents or records the agent can read and verify | They are missing, contradictory, or need a phone call to clarify |
| Decision rule | The right answer follows from policy, history and the record | The answer depends on discretion, negotiation or a policy exception |
| Reversibility | The action can be undone cheaply, or is held until approved | The action is irreversible: a payment out, an account closed, a claim denied |
| Value at stake | It sits under a threshold the business has set | It crosses that threshold |
| Verifiability | A reviewer could confirm the result was correct | Nobody could tell until much later whether it was right |
| Novelty | The case resembles the past cases the agent was tested on | The case is new, or the agent reports low confidence |
| Relationship | The outcome is routine for the customer or supplier | The outcome carries a relationship or reputational risk |
| Regulation | Rules allow automated handling with an audit trail | Rules require a named human decision |
Applied to real processes, the agent's share tends to be the reading, gathering and routine resolution: classifying incoming requests, pulling the records a case needs, matching documents against each other, drafting standard replies, updating statuses, and making routine changes within limits. The person's share is the cases that need authority to decide: the disputed charge, the unusual refund, the customer who is about to leave, the record that two systems disagree on. In a carrier's order fallout queue, for example, the agent can diagnose the rejected step and propose the fix, while a SIM change that looks wrong goes to a trained person; AI in telecom works through that split for carrier operations.
OpenAI's guide goes further, suggesting agents for work with "nuanced judgment, exceptions, or context-sensitive decisions," while putting high-risk actions, ones that are "sensitive, irreversible, or have high stakes," under human oversight. In an operation that means the agent prepares the judgment call and a person releases the high-stakes ones. The guide also names a second trigger for human intervention: exceeding failure thresholds, such as repeated failed attempts at the same task.
How do you tell the two apart before you build?
By looking at real cases before anyone writes a prompt. Teams that skip this step build an agent for the process as it is documented, then discover the process as it is lived.
Start with a sample of recent cases from the queue, including the ones people complain about. Sort each case by what it took to resolve it:
- A rule settled it. The answer followed directly from a field, a table or a policy. These steps may not need an agent at all; a deterministic script or an integration can handle them, and Anthropic's guidance to find "the simplest solution possible" applies.
- A reader with context settled it. Someone had to read an email, compare two documents, check the history, and then the answer was clear. These are agent steps.
- Authority settled it. Someone had to decide: waive a fee, approve an exception, make a call that a policy does not cover. These cases go to a person, and the design question is how fast they get there and with what attached.
Then write the hand-off specification before building anything. For each kind of case that goes to a person, name the trigger, the owner, the context they need to see, and the time they have to act. If the operation cannot agree on those four things on paper, it will not agree on them once an agent is live and cases are piling up.
Three questions settle most disagreements at this stage:
- If the agent gets this wrong, who notices, and when? If the answer is "the customer, next month," the step is not ready for an agent.
- Can the action be held until checked? Many steps that look too risky become safe once the agent prepares the change and a person releases it.
- Is the policy written down? Agents expose undocumented policy fast. Better to find the gaps in a workshop than in production.
What does an AI agent need around it to run in production?
More than the agent. The model is the part that changes fastest and matters least to whether the system holds. The parts that matter:
- A defined workflow with steps, permitted tools, hand-offs and stop conditions. Anthropic notes that it is common to add stopping conditions "such as a maximum number of iterations" to keep control.
- Action guardrails in code and permissions. The OWASP GenAI Security Project lists "Excessive Agency" (LLM06:2025) among the top risks for LLM applications and traces it to excessive functionality, permissions and autonomy. Each one has a plain remedy: fewer tools, narrower access, approval for high-impact actions.
- A designed human loop. Triggers, owners, context and response times, with the reviewers' decisions feeding back into the system.
- Integration with the systems of record. An agent that cannot write back to the CRM or billing platform produces suggestions, and suggestions pile up.
- An evaluation set. Real past cases with known right answers, including hostile and malformed inputs, rerun every time the prompt, the tools or the model change.
- Observability. A log of what the agent read, what it decided, what it did and what happened next, readable by an operations lead and an auditor.
- An owner in operations. Someone accountable for the agent's results the way a team lead is accountable for a team's.
Where AI decisions affect people's rights or safety, regulation adds weight to the human loop. Article 14 of the EU AI Act, which applies to high-risk systems listed in Annex III from December 2027 and to those covered by Annex I from August 2028, requires that such systems can be "effectively overseen by natural persons," including the ability to override their output and to interrupt them. Even outside that scope, the article reads well as a design checklist. Testing these surroundings against real cases is the Harden step of the method set out in the AI implementation guide.
Why do enterprise AI agent projects stall?
The likeliest reasons have little to do with the model.
- The demo used clean cases. An agent that handles the tidy majority of a sample looks finished. The operation's real workload sits in the remainder, and nobody designed for it.
- Nobody owns the exceptions. The agent escalates, and the escalations land in a shared inbox. Within weeks, the queue is longer than before the agent arrived.
- Permissions were set for convenience. Broad access gets the pilot running faster and becomes the reason security will not approve production.
- Success was measured on the wrong thing. Counting conversations or licenses says little. The measures that matter are cases completed without a person, the share routed to people and why, errors found after the fact, time to resolution, and how often reviewers overturn the agent.
- It was run as a project. Projects close at launch, but an agent in production needs someone to watch it, tune it and decide what it takes on next, the same way any part of the operation does.
The broader argument about why AI work stalls between pilot and production is made in AI pilot to production. For agents specifically, most of the fixes come back to the same place: decide the split between agent and person before building, and give that split an owner.
How should a large company start with AI agents?
With one process. Pick one that is manual and critical: important enough that improving it matters to the business, specific enough that off-the-shelf software has not solved it, and complex enough that a script would drown in its exceptions. The AI for business operations guide covers how to choose it, and the business process automation guide covers why the whole process, not the task, is the unit to automate.
Then work it in order. Manthle's AI engineers use five steps for this: See the process as it actually runs, case by case; Rethink it so the agent and the person each do the part they are suited to; Engineer the AI system around it, with a person on the exceptions; Harden it against real cases, limits and failures; and Run it with the client's team. The order matters more than the names. Skipping straight to the third step is the quickest way to stall.
Scope the pilot so it can become the operation. That means real cases from the first week, the real exception owners in the loop, and measures agreed in advance: completion without a person, routing to people, errors, resolution time and reviewer overrides. When the pilot works on those terms, it does not need to be rebuilt for production. At Manthle, a pilot on one process that works becomes a monthly operations contract, because by then the system is already part of how the work gets done.