AI Agents for Business: Opportunities, Limits, and Use Cases

Table of contents

• Chatbot, workflow, agent: three different things sold under one label
• Four questions to decide whether you need an agent
• Use cases by business function
• Five concrete risks, not generic ones
• Who is liable when the agent gets it wrong: the Air Canada case
• Minimum viable governance: levels of autonomy and controls
• From pilot to production: four gating criteria
• Common mistakes
• Next step

An AI agent is not a smarter chatbot. It is a system that, given a goal, decides what steps to take and uses tools (query the CRM, draft and send a message, update a record, issue a refund) to get there. That ability to act is what makes agents valuable and what makes them risky. A chatbot that gets it wrong gives a wrong answer. An agent that gets it wrong can take a wrong action.

Our position: most needs in a mid-sized company are better served by rules and fixed workflows, some of which include AI steps. An agent earns its place when the path cannot be set in advance, the outcome can be verified, and the cost of an error is bounded. And whenever one is deployed, accountability stays with the company. This article covers the whole business: support, sales, operations, finance, and internal services. For the marketing-specific view, see AI Agents for Marketing: When to Implement and When to Hold Off.

Chatbot, workflow, agent: three different things sold under one label

The market calls almost any AI product an “agent.” Before evaluating a vendor, separate three concepts.

The two leading labs agree on the essentials. OpenAI describes agents as systems that independently accomplish tasks on your behalf, where an LLM manages workflow execution and makes decisions, and which have access to tools to interact with external systems, always operating within clearly defined guardrails. It adds a useful precision: applications that integrate LLMs but don’t use them to control workflow execution, such as simple chatbots, single-turn LLMs, or sentiment classifiers, are not agents. Anthropic separates workflows, orchestrated through predefined code paths, from agents, where the LLM dynamically directs its own process and tool usage.

The practical consequence is that “we have an agent” says nothing about the risk level. The list of actions it can take, and the permissions it holds, does. To see how this applies to one concrete sales flow, read AI marketing automation: from inquiries to opportunities.

Four questions to decide whether you need an agent

OpenAI suggests prioritizing workflows that have resisted traditional automation, with three signals: complex decision-making involving judgment and exceptions (its example: refund approval in customer service), rules that have become unwieldy and costly to maintain (vendor security reviews), and heavy reliance on unstructured data (processing a home insurance claim). Its explicit advice is to validate that your use case meets these criteria clearly, and otherwise a deterministic solution may suffice.

We add a management condition of our own. An agent is justified if you can answer yes to all four questions:

1. Can the path not be fixed in advance? If it can, a workflow is cheaper, faster, and easier to audit.
2. Can you verify whether the result is correct? Anthropic notes that coding agents work well in part because solutions can be verified with automated tests. Without a way to verify, you will not know when the agent degrades.
3. Is the cost of an error bounded and, ideally, reversible? If not, the action must go through human approval.
4. Do volume and value justify configuring, evaluating, and supervising it? An agent is not a product you install. It is a process you operate.

Use cases by business function

The table lists plausible examples and, for each, the autonomy level we recommend at the start. It is a decision aid, not a promise of results: value depends on data quality, process design, and supervision.

Look at what the working cases share: unstructured information, decisions with exceptions, and an output you can verify. And what the failing cases share: a promise of “full autonomy” with no clear way of knowing whether the agent is right.

Five concrete risks, not generic ones

1. Compounding errors. An agent that makes a small mistake at an intermediate step can build the following steps on top of it. Anthropic warns of higher costs and the potential for compounding errors in agents, and recommends extensive testing in sandboxed environments with appropriate guardrails. Countermeasures: step limits, intermediate validation, and checkpoints.

2. Excessive permissions and manipulation. The OWASP project lists “Excessive Agency” (LLM06:2025) among the risks of LLM applications. It arises when a model can call functions or interface with other systems and is granted too much functionality, too many permissions, or too much autonomy, and it can lead to damaging actions from unexpected, ambiguous, or manipulated outputs, whether the cause is a model error or a prompt injection attack. Its recommended mitigations include minimizing the tools available, avoiding open-ended tools such as shell commands, limiting permissions to what is essential, and requiring human approval for high-impact actions. For risks specific to agentic systems, the OWASP GenAI Security Project published the Top 10 for Agentic Applications 2026 on December 9, 2025, built with input from more than a hundred specialists; it is a technical reference for your security team or vendor.

3. Liability. The company answers for what its agent says and does. See the next section.

4. Transparency toward the customer. If the agent interacts with people, there are transparency obligations and expectations. In the European Union, Article 50(1) of the AI Act requires people to be informed that they are interacting with an AI unless that is obvious from the context. Even where no such rule applies, hiding it erodes trust; we cover this in how to use AI to win customers without losing authenticity.

5. Drift and cost. Agents depend on models, tools, and data that change. Without a set of test cases and periodic review, quality can degrade unnoticed and resource consumption can creep up. It is not a dramatic risk, but it is the most common one.

Who is liable when the agent gets it wrong: the Air Canada case

Among documented decisions on liability for a conversational AI, one of the most discussed is Moffatt v. Air Canada, 2024 BCCRT 149, decided on February 14, 2024 by British Columbia’s Civil Resolution Tribunal in Canada.

The facts, as stated in the decision itself: a customer asked the airline’s chatbot about fares after a family member died, and the chatbot told him he could apply retroactively for a bereavement fare. The airline’s actual policy did not allow it. He bought the ticket relying on that information and the airline later refused a refund. Air Canada argued, among other things, that the chatbot was a separate legal entity. The tribunal rejected that, reasoning that a chatbot is part of the company’s website and that Air Canada is responsible for all the information on it, whether it comes from a static page or a chatbot. It found negligent misrepresentation and ordered Air Canada to pay C$812.02 in total: C$650.88 in damages, C$36.14 in pre-judgment interest and C$125 in tribunal fees (paragraph 44 of the decision).

Three cautions in reading it. It is a small-claims tribunal decision, not binding precedent, and its reach depends on jurisdiction. The chatbot in that case only answered questions; it was not an agent taking actions. And the amount is modest. What matters is the reasoning: neither technical complexity nor a system’s autonomy shifts responsibility away from the company that puts it in front of the customer. If that holds for a chatbot that only talks, the reasonable expectation for an agent that acts is higher, not lower. None of this is legal advice; consult an attorney.

Minimum viable governance: levels of autonomy and controls

You don’t need a department to govern an agent. You need an explicit decision about how much autonomy it has and which controls come with it. We propose four levels.

To sequence these decisions, a widely known reference is NIST’s AI Risk Management Framework (AI RMF 1.0), released January 26, 2023, voluntary, and organized around four functions: Govern (who decides and who answers), Map (what it is used for and in what context), Measure (how performance and risks are assessed), and Manage (what is done about identified risks). NIST released a Generative AI Profile (NIST-AI-600-1) on July 26, 2024, and its page notes that the AI RMF is being revised as part of the White House AI Action Plan, so check for the current version (page checked October 9, 2026).

For a mid-sized company’s agent, that framework translates into five simple decisions:

• Govern: a named owner for each agent and a list of what it can and cannot do.
• Map: the process, the data it touches, the people affected, and what happens if it fails.
• Measure: a set of test cases with known answers and a periodic review of real samples.
• Manage: failure thresholds that escalate to a person, a kill switch, and an incident log.
• Document: which model, which version, which tools, and which permissions it has at any given time.

From pilot to production: four gating criteria

A well-designed pilot limits scope (one process, one channel), defines in advance what success means, and stays at level 0 or 1 while you measure. Before granting more autonomy, we recommend requiring:

1. Results measured against a set of test cases and against human decisions, with each error analyzed.
2. Actions and permissions reviewed: nothing the agent doesn’t need.
3. An escalation and stop procedure that has been tested, not just written.
4. An owner accountable for outcomes, and legal review wherever customers, employees, or personal data are involved.

Common mistakes

• Buying “an agent” before defining the process. Without a documented process, the agent automates ambiguity. It is the same lesson as the three preconditions before automating.
• Starting with the highest-impact case. Start where errors are cheap and reversible.
• Granting broad permissions “to make it work.” It is the classic origin of excessive agency.
• Measuring only time saved. Also measure errors, escalations, and the satisfaction of the people affected.
• Forgetting the customer. If the customer doesn’t know they are talking to an AI, or can’t reach a person, the savings are paid for in trust.
• Treating adoption as a technology project. It is a change in process and responsibilities; we cover it in how to implement AI in a mid-sized company without burning your budget.

Next step

If you are evaluating AI agents for your company, we start with what matters before the technology: which processes have the right characteristics, what level of autonomy is reasonable, and what governance they need. Learn about our AI Agents service or get in touch.

Sources

• OpenAI (2025). A practical guide to building agents. cdn.openai.com
• Anthropic (2024). Building effective agents (December 19, 2024). anthropic.com
• OWASP GenAI Security Project (2025). LLM06:2025 Excessive Agency, in OWASP Top 10 for LLM Applications 2025. genai.owasp.org
• NIST (2023). AI Risk Management Framework (AI RMF 1.0) and NIST (2024) Generative AI Profile (NIST-AI-600-1). nist.gov
• British Columbia Civil Resolution Tribunal (2024). Moffatt v. Air Canada, 2024 BCCRT 149 (February 14, 2024). decisions.civilresolutionbc.ca (the decision’s original text; the tribunal’s server may block automated downloads).
• OWASP GenAI Security Project (2025). OWASP Top 10 for Agentic Applications for 2026 (December 9, 2025). genai.owasp.org
• European Union. AI Act, Article 50: Transparency obligations (consolidated text, AI Act Service Desk). ai-act-service-desk.ec.europa.eu
• European Commission (2026). AI Act: regulatory framework for AI (updated August 3, 2026). digital-strategy.ec.europa.eu

Editorial note: this article offers general management criteria and is not legal advice. Sources verified as of October 9, 2026.