AI agents for business are software that uses a language model to decide its next step and call tools, such as a ticketing system or ERP, to finish a task. The ones that hold up in production are narrow: one job, a definition of done, a short tool list, limits enforced in code, and a handoff to a person.
An agent that can do anything is an agent nobody can trust with something. Below: what an agent is, business examples, a good-fit table, and what real guardrails look like.
- Production agents do one job with a definition of done, a short tool list, a log of every step and a clear handoff to a person.
- "Agentic AI" is the umbrella. Anthropic separates workflows, which follow predefined code paths, from agents, which direct their own steps.
- Use an agent only where the steps vary from case to case. Otherwise, build a workflow.
- Limits belong in code and permissions, not in the prompt. OWASP traces excessive agency to too much functionality, permission or autonomy.
AI agents vs agentic AI: what an agent actually is
Start with the correction. "Agentic AI" isn't a bigger kind of agent. It's the umbrella term. Anthropic's engineering guide, Building effective agents, groups all the variations as "agentic systems" and then draws the line that matters:
- "Workflows are systems where LLMs and tools are orchestrated through predefined code paths."
- "Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
OpenAI's A practical guide to building agents defines agents as "systems that independently accomplish tasks on your behalf," and says applications that don't let the model control the workflow, such as "simple chatbots, single-turn LLMs, or sentiment classifiers," are not agents.
| Chatbot | Workflow | Agent | |
|---|---|---|---|
| Who decides the next step | The person asking | Your code, in a fixed order | The model, within limits you set |
| Example (illustrative) | Answers a policy question with a citation | Every invoice is read, matched to its PO and posted, the same way each time | Works a refund ticket, choosing which records to check and what to do next |
| Best for | Questions | Steps that never change | Steps that vary case by case |
In our view, many projects pitched as agents would be better built as workflows. Anthropic recommends "finding the simplest solution possible, and only increasing complexity when needed," and adds: "This might mean not building agentic systems at all." If your process runs the same steps every time, start with AI workflow automation.
AI agents explained: what a production agent has
An agent that holds up has six things. None of them is a better prompt.
- One job with a definition of done. "Resolve duplicate-charge refund tickets" is a job. "Help the finance team" isn't.
- A short, explicit list of tools, each with the narrowest permission that works: read payment history, issue a refund up to a limit, reply on the ticket.
- Limits enforced in code. "Never refund more than the limit" in a prompt is a request. A payment account that can't exceed the limit is a control. OWASP is direct: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not."
- An evaluation set from real past cases, including the awkward ones, run before launch and after every change. OpenAI's guide starts with "Set up evals to establish a performance baseline."
- A log of every step: what the agent read, which tool it called, what came back, and why it stopped. Anthropic says agents need "ground truth" from the environment at each step.
- A clear handoff to a person, with a named owner and a case summary. OpenAI's guide says actions that are "sensitive, irreversible, or have high stakes should trigger human oversight until confidence in the agent's reliability grows," naming "authorizing large refunds" among its examples.
AI agents examples for business operations
Four common business applications, all illustrative. Each has a done state and a defined handoff.
| Job | Tools it may use | Done when | Hands off to a person when |
|---|---|---|---|
| Duplicate-charge refund tickets | Ticket, payment history, refunds up to the auto-refund limit | The duplicate is refunded and the customer told | The refund is over the auto-refund limit, or no duplicate is found |
| Invoice exception chasing | The failed match, PO and receipt, email | The invoice matches, or the exception is closed with a reason | The fix needs a PO change, or nobody replies after the second reminder |
| Collections follow-up drafts | Account notes, payment history, approved templates | A draft waits in the collector's queue | Always: a person approves every message, and disputed accounts are flagged, not drafted |
| Vendor onboarding checks | Submitted forms, the onboarding checklist, email | The file is complete and routed for approval | Bank details are new or changed, every time |
The agent reads and chases. Anything that moves money past a limit or changes bank details goes to a person.
AI agents for business automation: good fit, or not yet?
| Good fit | Not yet |
|---|---|
| The steps vary from case to case | The steps never change, so build a workflow |
| Actions are reversible, or capped in code | One wrong action can't be undone |
| Plenty of resolved past cases to test against | Outcomes nobody recorded |
| The systems have APIs or stable screens | The data lives in inboxes and people's heads |
| A named person owns the exceptions | Exceptions land with whoever notices |
Old systems without APIs are a common blocker; legacy software automation and integration covers the options. If the data is split across systems that don't talk to each other, start with connecting disconnected business systems.
AI agent guardrails: what they are, with an example
AI agent guardrails are the limits that hold even when the model is wrong: which tools the agent has, what permissions those tools carry, which actions need a person's approval, and when it must stop.
The OWASP Top 10 for LLM Applications 2025 names the failure they prevent. LLM06:2025 Excessive Agency is "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction." OWASP says the root cause "is typically one or more of: excessive functionality; excessive permissions; excessive autonomy."
| Root cause (OWASP) | What it looks like | Guardrail for the refund agent (illustrative) |
|---|---|---|
| Excessive functionality | The payment tool can also void invoices and change payout accounts | A tool that only refunds an existing charge |
| Excessive permissions | The tool runs under an admin account | A service account capped at the auto-refund limit |
| Excessive autonomy | Large refunds go out unchecked | Anything over the limit goes to a person's queue |
OpenAI's guide suggests rating each tool low, medium or high risk, weighing write access, reversibility, permissions and financial impact, then pausing or escalating before the risky ones run. Anthropic recommends "extensive testing in sandboxed environments, along with the appropriate guardrails." For what tends to go wrong before launch, see why AI projects fail.
Choosing the first agent: where the 30-day assessment fits
The hard decision is which job to give an agent first, and whether it should be an agent at all. The 30-day assessment settles that before anyone builds. It's fixed in scope, at a price agreed before work starts. Week 1, we agree the scope, with a go or no-go decision before any access is given. Week 2, under an NDA and with read-only access, we trace the process: the systems it touches, the permissions each step would need, and the past cases an evaluation set could come from. Week 3, our senior engineers verify it with the people who do the work and capture the exceptions nobody wrote down. Week 4, written findings and a readout to the decision makers.
The findings set out where the process stands and the practical options, including a plain workflow, a smaller scope or no build at all. They name which AI agent and automation tools fit your stack and which would be hype for your case, show where handoffs and approvals slow the work whatever the technology, and give a phased roadmap with durations. The findings are yours. Your team can build from them, or we can build it as a separate project with its own scope and price. Either way, they stand on their own. Our guide to business process automation services covers what a build involves.
Send one sentence about the process you'd hand to an agent first, and the systems it runs through. If a narrower check would answer the question, we'll tell you that instead.