AI Agents for Business: What They Are, Use Cases and Cost in 2026

An AI agent is a program that accepts a goal, works out a sequence of steps toward it, calls tools to read and change real systems, and keeps going until the goal is met, a limit is reached, or a rule routes it to a human. A form handler runs the same three steps every time. A chatbot produces text and stops. An agent decides the sequence at runtime, which is exactly what makes it useful on messy work and exactly what makes it something you have to govern.

The four parts every agent has

Strip any agent down and you find four components: a model that interprets the goal and picks the next step, a set of tools it is permitted to call, a loop that feeds each tool result back so the next decision is better informed, and a stopping condition. Remove the tools and you have a chatbot. Remove the loop and you have a single-shot text generator behind an API. Remove the stopping condition and you have an incident waiting to happen, which is why every production agent needs explicit ceilings on steps, elapsed time, spend and scope. Those four parts are also the four places a project goes wrong, and you can usually diagnose a misbehaving agent by asking which of them was left undefined.

Autonomy is a dial, not a switch

Autonomy in a business agent is a setting you choose per task, not a property of the technology. The useful positions on the dial are: suggest, where the agent proposes and a person does everything; draft, where the agent produces a complete artefact a person edits and sends; act-with-approval, where the agent stages a real action and waits for a click; and bounded action, where the agent completes a narrow, reversible class of work on its own and logs it. Nearly all durable business deployments live in the middle two positions. Treating the dial as a binary is what produces both over-cautious pilots nobody uses and over-eager rollouts that get switched off after one bad week.

What the word does not mean

An agent is not a member of staff, and framing it that way causes real damage to a project plan. It has no accountability, no professional judgement about consequences it was never told about, and no ability to notice that a process changed unless something tells it. It also does not remove the need for a documented process; it consumes one. If nobody can write down how a task is done today, an agent will not discover the answer; it will invent a plausible version and apply it consistently.

The line is about who chooses the steps and whether anything outside the conversation changes. Plain automation follows a path a developer fixed in advance. A chatbot chooses words but changes nothing. An agent chooses the path and changes things. Knowing which of the three a problem actually needs is the single cheapest decision in the whole project, because two of the three are far less expensive to build and maintain than the one everybody asks for.

A chatbot answers; an agent finishes the job

A support chatbot that explains your refund policy is doing conversational retrieval. An agent handling the same request looks up the order, checks it against the policy, determines eligibility, raises the refund in the billing system or stages it for approval, and writes the case note. The first reduces reading time. The second reduces handling time and changes system state, which is why it needs credentials, an audit trail and an approval rule, and the chatbot does not. Many teams discover mid-project that a scoped support chatbot would have solved most of the pain for a fraction of the build, and that is a legitimate outcome, not a failure.

When a rules-based workflow is the better buy

If a task is high volume, fully deterministic, and has no step where a person currently exercises judgement, an agent is the wrong tool. Moving a record between two systems on a fixed trigger is a job for an integration or a scheduled script: cheaper, faster, testable, and it fails loudly instead of creatively. Reserve agents for work where the input is unstructured, the next step genuinely depends on what was found, or the number of edge cases makes an exhaustive rule set impractical to maintain. A good filter is to ask whether a competent new joiner would need to read something before deciding. If not, write a rule.

The hybrid that usually ships

Most production systems that work are hybrids. Deterministic code handles triggers, routing, validation, retries and anything involving money or compliance. The model handles the parts that need interpretation: reading a messy email, classifying an intent, summarising a thread, drafting a reply, extracting fields from an attachment. This split keeps the unpredictable component inside a predictable frame: you can test the deterministic path exhaustively and sample the interpretive one.

Usefulness comes from four unglamorous things: a narrow job somebody owns, inputs that are actually current, permission to do the last step rather than the first three, and a review path that is quick enough to survive a busy day. Demos skip all four, which is why they look effortless and why the same build stalls in week three of production. The gap between a demo and a deployment is almost entirely operational scaffolding.

A named job with a named owner

Before any build, one person should be able to say in a sentence what the agent does and be accountable for whether it is doing it well. "Improve support" is not a job. "Draft first responses to shipping-status questions that arrive by email, using the order record and the shipping policy, for an agent to send" is a job. The named owner matters as much as the named job, because agents degrade quietly and somebody has to be looking. Projects without an owner do not fail dramatically; they simply stop being checked.

It has to finish something

An agent that produces advice a human must then act on has moved work, not removed it. The value shows up when the agent completes the last mile: the record updated, the draft queued, the ticket routed with fields filled, the report posted where people already look. This is also why write access and integration depth dominate the budget: reading is easy, finishing is the expensive part.

Every output carries its evidence

Outputs should be checkable in seconds, not minutes. That means each answer or action cites the record, document or policy clause it was derived from, so a reviewer verifies rather than re-derives. Without evidence, review collapses into re-doing the work, people quietly stop reviewing, and the first wrong output that reaches a customer is discovered by the customer. Evidence links are not a nicety; they are the mechanism that keeps human review economically viable.

The task boundary is the written statement of what the agent handles, what it must refuse, and what it escalates. Write it before you build, because it determines the tools, the permissions, the test set, the approval points and most of the cost. A vague boundary is the most common root cause of an agent that is technically working and operationally useless.

Size the task to one decision and one outcome

The most reliable agents in production are small. One trigger, one class of input, one decision, one outcome, one system of record touched. "Qualify inbound enquiries against our fit criteria and set the lead stage" is the right size. "Run our sales process" is not a task, it is a department. Starting small is how you get a test set you can enumerate, an error rate you can measure, and a rollback that does not require unpicking six systems.

Write down the cases it must refuse

Refusals need to be specified with the same care as the happy path. Typical entries: anything involving a legal or medical judgement, anything where the record is incomplete, anything where two sources disagree, anything from a named account flagged as sensitive, anything above a value threshold, and anything the agent cannot find supporting evidence for. Each refusal needs a destination, because an agent that refuses into silence is a queue nobody is watching.

The boundary is a contract, not a guideline

The boundary should be enforced in code and permissions, not only described in the prompt. If the agent must not touch invoices above a threshold, the tool it calls should reject those requests; if it must not email customers directly, it should have no tool that sends. Instructions in a prompt are guidance to a probabilistic system. Permissions are an enforcement mechanism. Serious builds use both and rely on the second.

An agent needs the same knowledge a competent new joiner would need on day one, in a form a machine can search: the policies that govern the decision, the records that describe the specific case, and the examples that show what good output looks like. Most agent quality problems are knowledge problems wearing a technology costume, and they are usually visible in the source material before a single line of code is written.

Sources of truth, not stale copies

Point the agent at the system where a fact is maintained, not at a document that describes it. Pricing should come from the pricing source, order status from the order system, availability from the calendar. Where a document genuinely is the source, such as a policy, it needs an owner, a review date and a single canonical location. The classic failure is an agent confidently quoting a superseded policy document, which is not a model error at all, because the model reported exactly what it was given.

Retrieval instead of one enormous prompt

Retrieval means fetching only the passages relevant to the current question and giving those to the model, rather than attempting to supply the entire corpus. It is the standard approach for company knowledge because it keeps the input focused, makes citation natural, and lets you update knowledge by updating documents rather than rebuilding anything. Quality depends on unglamorous choices: how documents are split, what metadata travels with each chunk, whether tables and forms survive extraction, and whether the search combines keyword and semantic matching. A retrieval layer over your own documents is usually the first piece to build and the piece that repays the most attention.

Retrieval has to respect permissions

The retrieval layer must apply the same access rules as the underlying systems, evaluated for the person the agent is acting for. If a salesperson cannot open a colleague's account notes, an agent answering that salesperson must not surface them either. This is straightforward when permission metadata is attached at indexing time and filtered at query time, and painful to retrofit, because it means reindexing the entire corpus with a permission model you did not originally capture.

The "I do not have this" path

The most valuable behaviour in a retrieval-backed agent is a clean admission that the knowledge is not there. Design it deliberately: when retrieval returns nothing above a relevance threshold, or the retrieved passages conflict, the agent should stop, say what it looked for, and hand over. Reward this path in your testing rather than treating it as a miss. An agent that answers everything is not better than one that escalates what it cannot support; it is the same agent with the errors hidden.

A tool is a specific, narrow function the agent may call: look up an order, create a draft, update a stage, post a message. The permission model decides which tools exist, what each may touch, and under whose authority it runs. Together they define the real capability of the agent far more than the choice of model does, and they are the layer you will spend the most design time on.

Read tools and write tools are different risk classes

Separate them explicitly and govern them differently. Read tools risk exposure: the wrong person seeing the wrong record. Write tools risk consequence: a wrong record, a sent message, a triggered payment. Read tools can usually be granted generously within a permission scope. Write tools should be few, narrowly parameterised, individually logged, and where possible reversible. A useful design habit is to give each write tool the smallest signature that still does the job, so that the range of possible mistakes is small by construction rather than by instruction.

Scope credentials to the task, not to the team

Give the agent its own identity with its own credentials rather than borrowing a person's login or, worse, an administrator account. Scope those credentials to the exact objects and fields the task requires. Every additional field, object type or endpoint you grant is a permanent widening of what a bad step can reach. Rotate the credentials on the same schedule as any other service account.

Prefer reversible actions and drafts

Where a reversible version of an action exists, use it. Creating a draft is reversible; sending is not. Setting a status that a person confirms is reversible; issuing a credit note is not. Adding a note is reversible; deleting one is not. Designing for reversibility turns most mistakes into a cleanup task instead of an incident.

Context is what the agent knows during one task. Memory is what it carries between tasks. They are different mechanisms with different risks, and conflating them produces agents that either forget the obvious or remember things nobody agreed they should keep.

Working context inside a single task

Within one run, the agent accumulates the goal, the retrieved passages, the tool results and its own intermediate reasoning. This grows quickly on multi-step work, and beyond a point more material makes decisions worse rather than better, because the relevant fact competes with everything else you supplied. Practical countermeasures are ordinary engineering: summarise completed sub-steps instead of carrying raw output, keep tool responses tight and structured, drop material once its conclusion has been recorded, and pass identifiers the agent can re-fetch rather than whole payloads.

Durable memory across sessions

Durable memory is worth adding only when repetition is actually costing something, and it should be explicit rather than ambient. Good candidates are stable, checkable facts: this account prefers invoices on the first of the month, this customer's escalation contact is a named person, this enquiry was already answered last week. Store them as structured records in a system you already own, not as an opaque pile of past conversations, so they can be inspected, corrected and deleted by a person. Ambient memory is very hard to debug, because you cannot see why the agent believes something.

Memory is a privacy surface

Anything the agent remembers is data you are now holding, with the same obligations as any other record. It needs a retention period, a deletion path that works when a customer asks, and a rule about what must never be retained, which typically includes identity documents, payment credentials and health details unless you have a specific lawful basis and the controls to match. Decide this before the feature ships, because retrofitting deletion across a memory store is considerably harder than designing for it.

Human approval is the control that makes everything else acceptable: a defined point where a person sees what the agent is about to do and confirms, amends or rejects it. Place approval points by blast radius rather than by intuition, and design the review itself to be fast, because an approval step that is slow gets bypassed and then the control exists only on paper.

Choosing approval points by blast radius

Ask what the worst realistic outcome of this action is and who experiences it. Anything that reaches a customer, moves money, alters a contractual record, or cannot be undone gets explicit approval. Anything internal, reversible and low-value can usually run inside a boundary with logging. Anything the agent itself flags as low-confidence or conflicting should escalate regardless of category.

Review has to be fast or it gets skipped

A good approval interface shows the proposed action, the evidence behind it, the diff against the current state, and buttons to approve, edit or reject with a reason. It should live where the work already happens, whether that is the helpdesk, the CRM or a chat channel, rather than in a separate tool that requires a second login. Rejections with reasons are the most valuable data the system produces, because they tell you precisely where the agent is wrong and give you the examples to fix it.

Escalation that does not dead-end

Every refusal and every failure needs a named destination with an owner and a response expectation, and the handover must carry the full context so the person does not restart from nothing. Include what the agent was trying to do, what it found, and why it stopped. Then monitor the escalation queue itself, because a rising escalation rate is an early signal that something upstream changed, and a queue that never gets worked is a slow leak of customer goodwill that will not appear on any technical dashboard.

Agents pay off on high-volume, judgement-light work that touches several systems and currently eats senior time in small slices. Across sales, support and operations the same shape recurs: gather scattered context, apply a rule a person knows, produce a draft or a state change, and hand the exceptions back. What follows are patterns that are practical to build, not promises about results, which depend entirely on your volumes and your process.

Sales: research, enrichment and drafted follow-up

The durable sales patterns are preparation and hygiene rather than autonomous selling. An agent can assemble a briefing before a call from the CRM record, past emails and public company information; enrich an inbound enquiry with firmographic detail and score it against written fit criteria; draft a follow-up that references what was actually discussed; keep pipeline data tidy by proposing stage changes when evidence supports them; and flag deals that have gone quiet. A sales co-pilot of this kind sits beside the rep, and every outbound message stays a draft a person sends. Selling involves commitments, and commitments belong to people.

Support: triage, retrieval-backed drafts and knowing when to hand over

Support is the most common starting point because the work is repetitive, the knowledge is documentable and the review path already exists. An agent can classify and route incoming tickets, pull the relevant order and account context onto the ticket, draft a reply grounded in the current policy with citations, and close the loop on the narrow, verifiable requests. The important design decision is the handover rule: frustrated tone, second contact on the same issue, anything involving a complaint, a legal threat or a vulnerable customer should go to a person immediately and without the customer having to ask twice.

Operations: reconciliation, chasing and the back-office queue

Operations is where agents are least discussed and often most useful, because the work is internal, reversible and unglamorous. Reconciling a delivery note against an invoice and flagging the mismatches. Chasing missing documents on a known schedule. Extracting fields from supplier emails into a structured record. Compiling the weekly numbers from three systems into one document. Monitoring a queue for items that have breached an internal expectation. None of it is impressive in a demo, and all of it is the kind of work that quietly consumes time from somebody senior enough to be doing something else.

Integration is where most of the effort and most of the risk actually sits. An agent is only as capable as the systems it can read and write, and connecting to those systems safely, with the right permission scope and sane error handling, routinely takes longer than everything else combined. Budget accordingly, and treat any claim of universal connectivity with scepticism, because the hard part was never the connector, it was your particular configuration.

The integration surface is most of the project

Scope every integration by four questions before estimating: what exactly must be read, what exactly must be written, what happens when the target system is unavailable, and who owns the credentials. The answers turn a vague connection into a piece of work with a size. Fields that exist in a system but are used differently by different teams are a common trap; so are custom objects, mandatory fields added after the fact, and validation rules nobody documented.

APIs, webhooks, and the systems that have neither

Where a proper API exists, use it and respect its rate limits, pagination and idempotency behaviour. Where events matter, webhooks are preferable to polling, with a reconciliation sweep to catch anything missed. Where a system has no usable interface, be honest about the options: a database-level read if you control it, a scheduled export, or a manual step that stays manual. Screen-scraping a business-critical system is a maintenance liability, and it is usually cheaper to change the process than to automate around a system that will not cooperate. Occasionally the correct answer is that the surrounding custom software should be built or replaced first, and that is a business decision, not a technical one.

Channels: email, WhatsApp and the helpdesk

Channel choice shapes the whole design. Email tolerates delay and long-form evidence, so it suits drafted replies with approval. Helpdesk tools bring threading, assignment and audit for free, so they are the easiest place to introduce approval steps. Messaging channels carry stricter platform rules on templates, opt-in and session windows, and those rules are external constraints on your design rather than things you can negotiate. Voice raises the bar further, because a voice agent has no time for a review step mid-call, which pushes the entire control burden into narrow scope, tight scripts and fast handover to a person.

A production agent is not one component, it is six, and separating them is what makes the system testable, debuggable and safe to change. The layers are: a trigger, an orchestrator that runs the loop and holds state, a retrieval layer over knowledge, a tool layer that fronts every external system, a policy layer that enforces permissions and approvals, and an observability layer that records everything.

The layers, top to bottom

The trigger defines when a run starts and what it starts with: an inbound message, a webhook, a schedule, a button. The orchestrator holds the goal, the accumulated context and the step budget, and decides when to call the model and when to stop. Retrieval fetches relevant knowledge with permission filters applied. The tool layer exposes narrow, validated functions and is the only route to any external system. The policy layer sits in front of tools, enforcing scope limits, value thresholds and approval requirements. Observability captures every input, decision, tool call and output. Skipping the policy layer and relying on prompt instructions is the single most common architectural shortcut, and the one most likely to be regretted.

Orchestration, state and retries

Long-running work needs durable state rather than an in-memory loop, because runs that pause for approval, wait on a slow system, or resume after a restart cannot live in a single process. Persist each run with its status, its step history and its position, so it can be resumed, inspected and replayed. Make tool calls idempotent where the target allows it, so a retry does not create a duplicate record, and make the consequences of a duplicate explicit where it does not. Set concurrency limits per external system, because an agent retrying enthusiastically against a rate-limited API is an outage you caused yourself.

Logs, traces and the audit trail

Log at three levels for three audiences. Traces for engineers: every prompt, retrieval result, tool call, latency and error, enough to reconstruct any run. An audit trail for the business: who or what did the action, on which record, with what authority, at what time, approved by whom. Metrics for the owner: volume, escalation rate, approval and rejection counts, and error rate by category. Build this on day one. Retrofitting observability into a system already carrying real work is unpleasant, and its absence means you cannot answer the question that eventually gets asked: what happened on that specific case.

Treat an agent as a non-human actor with standing access to business systems, because that is exactly what it is. It needs an identity, scoped permissions, credential rotation, logging and a revocation path, and it introduces one risk class that traditional integrations do not: it reads untrusted content and can be influenced by it. Security work here is mostly ordinary access-control discipline plus one new habit.

Least privilege, applied to a non-human actor

Start from zero and add only what a specific task provably needs. Separate identities per agent so a compromise or a mistake is contained to one job. Prefer read scopes on everything except the handful of objects that must be written. Review the grants on a schedule, because permissions accumulate during development and nobody removes them afterwards. Confirm that an emergency revocation actually halts the agent, and rehearse it once, so that the first time you try it is not during a live problem.

Treat retrieved content as data, not instructions

Any text the agent reads from outside your control, including customer emails, web pages, uploaded files and third-party records, may contain text crafted to look like an instruction to the agent. The defence is architectural rather than clever prompting: content fetched at runtime is data to be summarised or extracted from, never a source of new goals. Enforce this with the permission layer, so that even if the agent is persuaded to attempt something outside its scope, no tool exists that would let it succeed. Then log anything that looks like an attempt, because it is a useful signal about the channel it arrived on.

Retention, residency and the questions to ask a vendor

Decide what is sent to any external service, what is retained, for how long, and where it is processed, then write it into your privacy documentation and your vendor agreements. The questions worth asking any provider are consistent regardless of who they are: is our content used to improve their systems, what is the retention period and can it be shortened, which regions is data processed in, what certifications and subprocessors apply, and what happens to the data if we leave. Get the answers in the contract rather than from marketing pages. Where the data is genuinely sensitive, the architecture should minimise what leaves your boundary in the first place, by redacting identifiers before a call and rehydrating afterwards.

Agents fail in a small number of recognisable ways, and each has a specific countermeasure. Plan for them explicitly during design instead of discovering them in production, because the discovery version is always more expensive and usually involves a customer.

Confident, wrong, and fluent

The characteristic failure is a well-written answer that is not supported by anything. Countermeasures stack: ground answers in retrieval rather than recall, require a citation for every factual claim, have the agent state explicitly when it found nothing, keep a human approval step on anything customer-facing, and sample outputs weekly against the source. Fluency is not evidence of correctness, and any review process that relies on an output looking right will eventually pass something that is not.

The stuck loop and the silent failure

Agents get stuck: retrying a failing tool, oscillating between two approaches, or waiting on something that never arrives. Caps on steps, time and spend per run turn these from runaway costs into contained errors. The quieter problem is silent failure, where runs stop happening at all because a credential expired or a webhook was disabled, and nobody notices because nothing errored visibly. Monitor for absence as well as for errors: alert when the expected volume for a period does not arrive, and when the escalation queue stops moving.

Drift when the systems underneath change

Everything the agent depends on will change without telling it. Fields get added, policies get revised, a form gains a mandatory question, a model version is updated by a provider, a template is rejected by a platform. Countermeasures are a regression suite of real cases you rerun on any change, alerts on schema changes in connected systems, an owner for each knowledge source with a review date, and a habit of rerunning the suite before and after any dependency update. Drift is not dramatic; it shows up as a slowly rising escalation rate that everybody attributes to a busy month.

Cost is driven by integration depth, knowledge readiness, reliability requirements and the number of decisions the agent must make correctly, in roughly that order. The model is rarely the expensive part. The practical budget range is usually ₹25,000 to ₹10,00,000+ depending on complexity, data, integrations and reliability requirements, and the distance between those ends is a difference in scope rather than a difference in quality.

The cost lines, in the order they usually surprise people

• Discovery and process documentation, because the current process usually has to be written down before it can be automated, and that work often uncovers disagreements that predate the project.
• Integration work per connected system, which scales with the number of systems, the state of their APIs and how heavily they have been customised.
• Knowledge preparation: locating the real sources, cleaning them, resolving contradictions and assigning owners.
• The agent itself: tools, orchestration, prompts, retrieval configuration and the policy layer.
• Approval and review interfaces, which are a proper product surface and are frequently omitted from early estimates.
• Observability, audit logging and alerting.
• Evaluation: assembling a test set of real cases and the harness to run it repeatedly.
• Usage costs, which vary with volume, run length and how much context each step carries.
• Ongoing maintenance, covered in its own section below because it is the line most often forgotten.

Why the range is that wide

At the lower end sits a single, well-scoped assistant over a tidy knowledge base with one integration, a human approving everything, and modest volumes. At the upper end sits a multi-step agent writing into several business-critical systems, with permission-aware retrieval across a large corpus, a full approval and audit layer, an evaluation harness, and reliability expectations that mean somebody is accountable when it breaks at month end. The same words describe both projects. The scope does not. When comparing quotes, compare the number of write integrations, the state of the knowledge, the approval surface and the reliability requirement, because those four differences explain most gaps between two numbers. Published pricing for our own work gives a starting frame, and the discovery conversation is what turns a frame into a figure.

Build cost and running cost are different budgets

Separate them from the first conversation. Build cost is one-off and predictable. Running cost includes platform or model usage that moves with volume, hosting, and a share of somebody's time for review, sampling and fixes. A system that is cheap to build and expensive to supervise can easily cost more over a year than the reverse, and the supervision share is the one that is systematically underestimated, because it does not appear on any invoice until somebody counts the hours.

Buy a platform when your process is close to a common pattern and speed matters more than fit. Build when the agent has to work the way your business actually works, or when the data cannot leave your control. Most organisations end up with a mix, and the decision is better made per use case than once for the whole company.

What a platform actually buys

A platform buys you the parts nobody enjoys building: connectors, a permission model, a review interface, logging, dashboards and a support contract. For a standard support or scheduling flow that is often the right trade, and it gets something in front of a team quickly. The costs are fit and control. You work within the platform's idea of a workflow, your knowledge and conversation history live in their system, and your ability to change behaviour is bounded by the configuration they expose. Those constraints are perfectly acceptable until the day your process needs something the platform does not model.

What a custom build actually buys

A custom build buys exact fit, control over where data goes, and the freedom to change any layer independently, including swapping the model without re-platforming. It costs more up front and it makes you the owner of everything a platform would have maintained, including the review interface, the logging and the on-call. It is the right choice when the process is genuinely a differentiator, when regulatory or contractual constraints dictate where data is processed, or when you already run custom systems the agent must live inside. It is the wrong choice when the honest description of the requirement is a common one.

The exit question

Ask what leaving looks like before you commit either way. Can you export your knowledge base, your prompts, your evaluation cases and your conversation history in a usable form. Are your integrations written against the platform or against the underlying systems. How much of what you have built is portable. The answer should not necessarily stop you choosing a platform, but it should be a known number rather than a discovery made at renewal.

An agent is a system that needs an owner, a review rhythm and a rollout plan, not a project that finishes. The work after launch is knowledge upkeep, evaluation against a baseline you captured beforehand, and widening the boundary only when evidence supports it. Teams that treat launch as the end get a system that quietly degrades until somebody turns it off.

The maintenance nobody quotes for

The recurring work is predictable enough to schedule. Knowledge sources get reviewed on a cycle by their owners. Rejected outputs get read and turned into fixes or new test cases. Integrations get checked after any connected system is updated. The regression suite gets rerun whenever a prompt, tool, model version or knowledge source changes. Permissions get reviewed and credentials rotated. Escalation queues get monitored for volume and age. None of this is difficult; all of it stops happening if it is not somebody's named responsibility with time attached.

Measure against a baseline you captured first

Record the current state before the agent exists, because otherwise you will be arguing about impressions. Useful baselines are volume of the target task, time from receipt to resolution, how often the work is reopened or corrected, and a sampled quality score on current output using the rubric you will later apply to the agent. After launch, track the same measures plus agent-specific ones: escalation rate, approval-versus-rejection ratio, refusal rate, and error categories from the weekly sample. Volume metrics alone will flatter the system, because a fast wrong answer still counts as a resolution.

Shadow, assist, then act inside a boundary

Stage the rollout so the risk rises only after the evidence does. In shadow, the agent runs on real work and its output goes to a log nobody acts on, compared against what the team actually did. In assist, it drafts and a person sends, and rejection reasons drive the fixes. In bounded action, it completes one narrow, reversible class of work alone, with full logging and an alert on anomalies. Widening means adding one case type at a time, each of which has to hold up in the weekly sample before the next is added. There is no timeline attached to these stages, because the gate is evidence rather than calendar.

The patterns that sink projects before the technology does

Four recur often enough to name. Starting from the tool rather than the task, which produces a capable system in search of a job. Automating a process nobody has written down, which encodes whatever the loudest person said in the workshop. Treating a pilot's accuracy as permanent, when the pilot ran on curated cases and production will not be curated. And skipping the approval interface to save time, which removes the one control that makes everything else defensible. Agent and automation work is mostly process work with a model attached, and the projects that go well usually begin with an honest description of how the job is done today, sometimes as a short AI strategy engagement before anything is built at all.