What is an AI agent in a business context?
Strip the marketing away and an agent is four things working together. Remove any one of them and you have something else.
- A goal. Not a prompt — an outcome. Post every supplier invoice that matches its purchase order. Keep every open deal older than 14 days from going quiet.
- Context. Live access to the records the decision depends on: the CRM, the ERP, the ticket history, the last twelve months of how the process actually ran.
- Tools. The ability to call systems and change them. Query a table, create a ticket, write a field, send a message. This is the part that turns a model into an agent.
- A feedback loop. It checks the result of its own action before continuing, and escalates when the result is not what it expected.
Every term used above is defined in the Black Ops glossary of AI agent and automation terms, including tool use, guardrails and agentic workflow.
How does an AI agent differ from a chatbot and from classic automation?
Three categories get called automation, and they fail in three different ways. This is the distinction that matters when you are deciding what to buy.
| Dimension | Chatbot | Classic automation | AI agent |
|---|---|---|---|
| What starts it | A person types | A defined trigger fires | A trigger, a schedule or its own previous step |
| What it reads | The conversation, sometimes a document set | Exactly the fields it was configured for | Whatever the systems expose, structured or not |
| Unclear input | Asks again or guesses | Fails or writes garbage | Interprets, or escalates below a confidence threshold |
| What it changes | Nothing | The exact records in its rule | Records across several systems, within its permissions |
| What breaks it | A question outside its content | A changed screen, field or format | A process whose rules were never really agreed |
| Maintenance | Content updates | Rebuild on every system change | Tune prompts, rules and thresholds against live output |
| Typical failure | A confidently wrong answer nobody acts on | Silent breakage at 3 a.m. | Doing the right thing on a case that needed a person |
Note the last row. A chatbot’s worst day is an embarrassing answer. An agent’s worst day changes data. That single fact is why the production requirements below are not optional.
What does an AI agent need to survive in production?
Demonstrations need a model and a prompt. Production needs five things, and four of them have nothing to do with AI.
- Integrations with defined write access. Read access is easy. Write access is where the design work is: which objects, which fields, under whose credentials, with what audit trail. Settle it in the scope, not in week three.
- Guardrails in code, not in the prompt. Amount limits, record types that are off limits, actions that always require approval, an explicit refusal path. An instruction to be careful is not a control.
- Human-in-the-loop on the right cases. Targeted, not universal. The agent handles routine volume; exceptions, high-value decisions and anything below a confidence threshold go to a named person with the context attached.
- A baseline measured before launch. Hours per week, error rate, cycle time, share handled without a human. If you cannot state today’s number, you cannot prove anything in eight weeks.
- An owner and a monitor. Someone on your side reads the exception queue weekly. Agents drift when the process underneath them changes and nobody tells them.
Which business functions actually deploy agents?
The same four shapes appear across industries. Input the systems already produce, a decision that follows stateable rules, and a metric that already exists.
| Function | What the agent does | What it reads | Metric that moves |
|---|---|---|---|
| Operations | Intakes documents, matches them against orders, flags mismatches, routes exceptions | ERP records, supplier files, email attachments | Share processed without a human touch |
| Sales | Ranks the pipeline, flags stalled deals, drafts context-aware follow-ups, keeps CRM records current | Deal stage, activity history, past won and lost deals | Response time and stalled-deal count |
| Support | Classifies and routes tickets, drafts replies from real policy, escalates by rule | Ticket history, knowledge base, order status | First-response time, resolution without escalation |
| Finance | Reconciles across systems, chases receivables by aging bucket, produces an exception list | Bank records, ledger, CRM, invoice files | Days sales outstanding, exceptions per cycle |
How do you tell if a process is a good candidate?
Four criteria. A process needs to clear at least three of them to be worth a first deployment.
- Volume. It runs at least daily, ideally 20 or more times a week. Agent cost stays close to flat as volume rises; manual cost does not.
- Repetition. The same shape of input arrives at least 80% of the time. If every case is genuinely unique, there is no pattern to encode.
- Rule stability. The decision rules have changed no more than once or twice in the last twelve months. Rules that change monthly turn the build into a rebuild.
- Error cost that is real but detectable. A mistake costs money, and someone finds out. Errors that are expensive but invisible are the dangerous ones and need a heavier review layer.
| Signal | Good candidate | Fix the process first |
|---|---|---|
| Rules | Someone can state them out loud in under 10 minutes | Two people give two different answers |
| System of record | Exists, even if imperfect | The real status lives in one person’s inbox |
| History | 12 months or more of records to test against | Nothing to test against |
| Exceptions | Under 20% of volume | Exceptions are half the work |
| Measurement | The metric already exists today | Nobody has ever counted it |
A process that lands in the right-hand column is not disqualified. It changes what the first deployment is: consolidation and cleanup, stated in the scope in writing rather than discovered in week three.
What usually goes wrong?
The failures repeat, and almost none of them are model failures.
- The process was never documented. The agent gets built against the procedure manual and meets the real workflow on day one.
- Scope grew mid-build. One process becomes four, the timeline doubles and nothing ships.
- No baseline. The agent works, nobody can prove it, and the budget conversation stalls.
- Everything routed to a human. A review queue nobody has time to clear is a slower version of the original process.
- Guardrails written as suggestions. Permissions live in configuration or they do not exist.
- The team was told, not involved. Adoption failures look exactly like technology failures on a dashboard, and get fixed by rebuilding the handoff, not the agent.
Common questions about AI agents for business
Is an AI agent just a chatbot with extra steps?
No. A chatbot produces text. An agent produces a change in a system of record: an updated deal stage, a posted invoice, a created ticket, a sent message. The moment software is allowed to write rather than only answer, the design questions change completely, because a wrong answer can be ignored and a wrong write has to be reversed.
Do we need a data warehouse before deploying an AI agent?
No. An agent reads whatever interface your systems already expose: a documented API, direct database access, or a scheduled file export. The interface determines whether the agent runs in near real time or on a batch cycle. What actually blocks a deployment is not missing infrastructure, it is a process whose rules nobody can state out loud.
How much control do we keep over what the agent does?
All of it, and it is written down before the build. Guardrails define which systems the agent can write to, which actions require approval, which amounts or record types are out of bounds, and what it can never send without review. A first deployment normally runs with a human approving every outbound action, and the threshold moves only once the numbers justify it.
What happens when the agent gets something wrong?
It should fail into a queue, not into your database. Well-built agents route anything below a confidence threshold to a named person instead of guessing, log every action they took with the input that produced it, and support a rollback path for writes. The measure of a production agent is not its accuracy rate, it is what happens on the cases it gets wrong.
How long does it take to deploy a first AI agent?
Black Ops (blackopss.com) delivers a written scope within 48 hours of the first conversation and runs deployment in 4 weeks, with staging review before anything touches production. The timeline is driven by integration count and data quality, not by model work. A process with one clean API and stable rules lands at the fast end of that range.
Where to go next
If you already know you want automation and need to choose the technology, read the comparison of AI agents, RPA and no-code automation — including the cases where an agent is the wrong answer. If you are building a budget, read what drives the cost of automating a process with AI. If your operation runs in Spanish across the region, read the practical guide to AI automation in Latin America. The anonymized Black Ops cases show three of these deployments end to end.