Interest in AI agents for business is rising, but interest isn't a use case. Whether an agent belongs in a particular business depends less on the technology than on the work: whether it has a clear outcome, whether the information it needs can be reached, whether its actions can be bounded, and whether someone can tell when it gets things wrong. This article looks at where agents can fit, where they don't, and what has to be true first.
The attention is measurable. A June 2026 study published by Truelogic, based on DataForSEO's Google search data for the United States, reported that searches for "AI agents for business" grew 210% year on year. That figure measures growth in searches in one country — curiosity, not results — which is why the questions below matter more than the trend.
- An agent is worth considering for work that needs judgement across several steps — reading, looking things up, deciding what to do next — and whose outcome can be checked.
- It needs the right information and a bounded set of tools: what it may read, what it may change, and what must go to a person.
- It is a poor fit for work that rules already handle, for processes without reliable data, and for high-impact actions that can't be reviewed.
- Before building one, a business needs a defined process, reachable data, integrations, approval boundaries, a measure of success and an owner after launch.
- Start with the workflow. Often the right first step is cleaner data or plain automation; an agent comes later, if at all.
An agent is a language model that chooses its next step and acts through tools — what an AI agent is explains its parts. That ability is only useful when the work around it meets a few conditions.
"Handle customer emails" isn't an outcome. "For each order enquiry, find the order's status and draft a reply with the facts, for a person to send" is. A clear outcome says what the agent should produce, when it has finished, and what a wrong result looks like. Without one, there is nothing to build towards and nothing to evaluate.
An agent decides from what it can read. If the information a person uses for the task lives in someone's head, in an unshared spreadsheet or in a system with no way in, the agent works from less than the person does — and still produces an answer. The question isn't whether the data exists somewhere, but whether it can be reached reliably, and whether it is current.
A good candidate can be done with a small, specific set of actions: read these records, search this knowledge base, create a draft, add a note, ask for approval. If doing the task properly would need broad access to many systems, or the ability to take irreversible actions alone, the risk grows faster than the value. OWASP's guidance on Excessive Agency is to limit the extensions an agent can call "to only the minimum necessary".
Someone — a reviewer, a rule further down the process, the next person in the chain — must be able to tell whether the agent was right. Tasks with verifiable outputs are good candidates: a correctly completed record, a draft that cites the right order, a match that can be confirmed. Tasks whose errors stay invisible until much later are not.
These areas often contain work that meets those conditions. Whether a particular process does depends on the business. Every example below is hypothetical.
Work that consists of collecting information from several places and summarising it: preparing a briefing on a prospective supplier, or compiling an account's history before a renewal meeting. The agent searches, reads and assembles; a person uses the result. Because the output is a document someone reviews, errors can be caught — provided the agent shows where each fact came from.
Hypothetical: a procurement team asks an agent to prepare a one-page profile of each new supplier from its website, its public filings and past correspondence, citing the source of every statement. The team reviews each profile before any decision. The agent saves gathering time; it doesn't make the decision.
Requests written in people's own words, where the answer depends on looking something up: an order's status, an account question, an employee asking about a policy. The agent interprets the request, queries the relevant system or knowledge base, and drafts a response — or resolves the simple cases within limits.
Hypothetical: an internal IT helpdesk agent reads tickets, checks the knowledge base and the user's device record, and answers common questions. Password resets stay in the existing self-service flow. Anything involving access rights goes to a person, with the agent's findings attached.
Back-office processes usually have an exception queue: the mismatched invoice, the order with an incomplete address, the delivery that didn't arrive. The standard path is usually best handled by deterministic automation. An agent can help with the exceptions, by investigating them and preparing a resolution for someone to approve.
Hypothetical: when an order fails address validation, an agent checks the customer's previous orders and messages, proposes a corrected address and drafts a message to the customer. A person confirms before anything changes.
Incoming enquiries vary in quality and detail. An agent can read each one, look up the company, compare it with the criteria the sales team uses and prepare a summary with a suggested priority. The criteria have to be written down for this to work — which is often valuable in itself.
Hypothetical: enquiries from a website's contact form are summarised and tagged against three written criteria, with the agent's reasons for each tag. A salesperson decides whom to call. The agent never emails a prospect on its own.
Some tasks consist of pulling together information held in several systems — the CRM, the project tool, the finance system — and producing something from it: a weekly account status, a project risk summary, a handover note. The agent's value is in crossing systems that a person would otherwise open one by one.
Hypothetical: every Monday, an agent compiles for each active project its open tasks, the hours logged against budget and any overdue invoices, and flags inconsistencies for the project lead. It reads from three systems and writes to none.
What these examples share: the agent prepares, investigates or drafts; consequential actions go through a person or through existing deterministic processes; and the output can be checked.
- Work that rules already handle well. If the steps are fixed and the inputs structured, automation is cheaper, faster and more predictable. AI agents vs automation covers that decision in detail.
- Tasks without reliable data. If the information is incomplete, contradictory or out of date, an agent produces confident output on a bad basis. Fix the data first.
- Unrestricted high-impact actions. Payments, contract changes, deleted records, messages that commit the business: if the design needs the agent to do these alone, the design is the problem.
- Mistakes that are unacceptable and can't be reviewed. Where an error would cause serious harm and there is no realistic way to check each output before it takes effect, the uncertainty that comes with any language model is a reason not to use one there.
- Processes too poorly defined to evaluate. If the people who do the work today can't agree on what a good result is, an agent can't be measured against anything. Defining the process comes first.
- A defined process. The steps, inputs, expected outputs, exceptions and who handles them — written down, not assumed.
- Data and context. The information the task needs: reachable, current and of known quality. Where the knowledge sits in documents, retrieval has to find the right passages reliably.
- System integrations. Controlled ways for the agent to read from and write to the systems involved, usually through APIs — not copy and paste, and not open access to a screen.
- Permissions. For each tool, the minimum access the task needs and nothing more: read access by default, write access only where it is required.
- Approval boundaries. The actions that always go to a person, decided in advance and enforced by the system rather than by the agent's instructions. OWASP recommends human-in-the-loop control "to require a human to approve high-impact actions before they are taken."
- Evaluation criteria. A set of real or realistic cases with known correct outcomes, and a threshold the agent must meet before it is used — and again after each change.
- Monitoring. A log of every step and tool call, regular review of samples of completed work, alerts on failures, and limits on steps and cost.
- Ownership. A named person or team responsible for the agent after launch: reviewing its output, updating its instructions and tools as the business changes, and deciding when to pause it.
The last point is the one most often missing. Models change, systems change and processes change; an agent that nobody owns degrades quietly.
The most reliable way to arrive at a useful agent is not to start with one. Start with a workflow that costs time or causes errors, and map it: the trigger, the steps, the information each step uses, the decisions, the exceptions and the hand-offs.
Then look at each step. Most will be rules, and those are automation. Some will turn out to be data problems, and those are fixed at the source. A few will genuinely require reading unstructured input, investigating and choosing what to do next. Those are where an agent might belong — and because the rest of the workflow has been mapped, they arrive with defined inputs, defined outputs and a clear place for human review.
Working this way also makes "we don't need an agent" a normal, useful outcome rather than a failed project. Anthropic's guide to building agents recommends the same order of thinking: "finding the simplest solution possible, and only increasing complexity when needed."
Answer these before building or buying an agent. Wherever the answer is "we don't know", that is the next piece of work.
- What decision or task should the system handle? One sentence, with a clear finish line.
- What information does it need? Where does that information live, how current is it, and how good is it?
- Which systems can it access? Through which integrations, and with which credentials?
- What actions may it take? The complete list of tools, each with the narrowest permissions that work.
- Which actions require approval? Who approves them, and how quickly?
- How do we detect failure? Wrong outputs, failed tool calls, loops, unexpected costs — what alerts whom?
- What does success look like? Measured how, on which test cases, compared with how the work is done today?
- Who owns it after launch? Who reviews its work, maintains it and can switch it off?
An agent's usefulness comes almost entirely from what it is connected to. A model in a chat window can talk about your business; an agent with controlled access to your order system, your knowledge base and your ticketing tool can do part of the work inside them.
That access is the difficult part, and the part that deserves the most care. Each connection is a tool: a defined operation, such as "look up an order by its number" or "create a draft reply", with its own permissions, its own validation and its own log. Designing those tools — what each may read, what each may change, what happens when the system behind it is slow or returns an error — is most of the work of a dependable agent. It is where developing AI agents that operate across business systems actually happens.
Connections also widen the attack surface. Anything an agent reads through them — customer messages, documents, web pages — can contain text written to change its behaviour, which OWASP describes as indirect prompt injection. Bounded tools and approval boundaries are what stop that from becoming an unwanted action.
Often the honest result of the checklist is that an agent would be premature. A business may first need:
- Cleaner processes — agreed steps and a shared definition of a good result.
- Better data — records that are complete, current and kept in one place.
- Integrations — systems that can be reached through stable interfaces.
- Deterministic automation — the predictable parts of the workflow automated, which often removes much of the work an agent was meant to do.
- Clearer ownership — someone accountable for the process, and later for the agent.
None of that work is wasted. Each piece makes the business easier to run on its own terms, and each one is something a future agent would need anyway.
AI agents can fit into a business where work needs judgement across several steps, where the information can be reached, where actions can be bounded and where results can be checked. They don't fit where rules already work, where the data isn't reliable, or where high-impact actions would go unreviewed. The useful question isn't "where can we use an agent?" but "which part of this workflow, if any, needs one?" — and answering it starts with the workflow.
Checked on 2 October 2026.
- Truelogic — AI Agent Searches Quadruple Task AI Queries in 2026 Study (Lilach Bullock, 14 June 2026; DataForSEO historical search data for Google in the United States)
- Anthropic — Building effective agents (December 2024)
- OWASP — LLM01:2025 Prompt Injection
- OWASP — LLM06:2025 Excessive Agency
