Agents for business: use cases, costs and risks

Agents for business can take a task from start to finish: read a customer's message, look up the order, issue a refund within your rules and reply. That is a different proposition from a chatbot that only answers questions, and it changes what to evaluate: which tasks to hand over, how to get an agent, what it costs and what can go wrong. This guide works through those four questions with sources and a worked cost example. If you need the basics first, start with what an agent is.

Which tasks suit an agent

Anthropic, which says it has worked with dozens of teams building agents, describes the tasks where agents have added the most value as those that "require both conversation and action, have clear success criteria, enable feedback loops, and integrate meaningful human oversight". Its two examples:

• Customer support. Conversations need outside information and actions: tools can pull customer data, order history and help articles, and "actions such as issuing refunds or updating tickets can be handled programmatically". Success is measurable: was the issue resolved?
• Software development. Code can be checked by automated tests, so the agent can iterate on its own work, although Anthropic notes that "human review remains crucial".

The same test applies to any task: can you describe success precisely, can the agent check its own progress, and is there a point where a person signs off?

Do you need an agent at all?

Often not. Anthropic's advice is to find "the simplest solution possible" and add complexity only when needed. In order of complexity:

1. A single, well-designed request to a model, with the right documents attached. Anthropic says this "is usually enough" for many applications.
2. A workflow: fixed steps in code, with a model doing some of them (classify the email, draft the reply, a person approves). Predictable and cheaper to run.
3. An agent: the model decides the steps. Worth it when the path to the answer varies too much to script.

Agents "trade latency and cost for better task performance", so move up this list only when the simpler option demonstrably falls short.

Three ways to get an agent

1. Use the agents inside tools you already pay for. Business plans increasingly include agent features: ChatGPT Business lists workspace agents for custom workflows; Claude's Team plan includes Claude Code and Claude Cowork; Microsoft's Premium plan for individuals includes limited use of agent features for research and analytics. This is the fastest route, with no development, but you are limited to what the vendor supports.

2. Add model steps to an automation platform. Tools such as n8n, Zapier and Make let you chain apps and add model calls as steps, which suits workflows more than open-ended agents.

3. Build on a model provider's API. Most flexible, and the only option when the agent must work inside your own systems. You pay per token for the model, plus your own development and maintenance. Connecting tools through the Model Context Protocol (MCP) reduces the integration work.

What the model calls cost: a worked example

Model usage is the easiest cost to estimate, so here is an illustration. It is a hypothetical support agent, not a measured one, using the prices each provider published on October 26, 2026:

• 5,000 conversations a month;
• 6 model calls per conversation (the agent loop: read, look up, decide, act, check, reply), so 30,000 calls;
• 8,000 input tokens per call (instructions, tool descriptions, history and tool results), 60% of them read from cache;
• 400 output tokens per call.

The figures for Claude Haiku 5.5, Sonnet 5.5, Opus 5.5 and Fable 5.1 include the roughly 30% extra tokens that Anthropic says its newer tokenizer produces. Claude Haiku 4.5 uses the previous tokenizer, so its figure has no adjustment. Cache writes are not included. Two conclusions hold whatever your numbers are:

• The choice of model moves the bill by two orders of magnitude for the same work. Test whether a smaller model handles the task before defaulting to the largest.
• Model usage is often not the biggest cost. Building the integrations, testing the agent on real cases, monitoring it and the staff time spent reviewing its work can each cost more than the tokens.

Try your own figures in our LLM API cost calculator.

What can go wrong

The OWASP Top 10 for LLM applications (2025) names the risks that matter most for agents:

• Prompt injection (LLM01): instructions hidden in an email, document or web page the agent reads can redirect it.
• Sensitive information disclosure (LLM02): the agent can reveal data it can access to someone who should not see it.
• Excessive agency (LLM06): an agent with more permissions than its task needs can do real damage when it makes a mistake or is manipulated.
• Unbounded consumption (LLM10): loops or abuse can run up costs.

Anthropic adds that autonomy brings "the potential for compounding errors" and recommends "extensive testing in sandboxed environments, along with the appropriate guardrails".

Practical guardrails: give the agent the narrowest permissions that work, require a person to approve irreversible or costly actions (refunds above a limit, deleting data, sending external emails), set a maximum number of steps, log every action and review a sample regularly.

If you operate in the EU

Regulation (EU) 2024/1689 already applies to companies that use language models, not just to those that build them. Since February 2, 2025, the regulation has required organisations to take staff literacy measures for staff who use these systems; the 2026 amendment phrases this as measures to "support" their staff literacy. From August 2, 2026, chatbots must be designed so that people know they are talking to a machine unless that is obvious, a duty the regulation places on the chatbot's provider. If an agent makes decisions in areas the regulation treats as high-risk, such as recruitment, further obligations apply from December 2, 2027. See our Regulation (EU) 2024/1689 guide.

A 30-day pilot

1. Pick one task with a clear definition of success and a measurable baseline (for example, the time to resolve a refund request today).
2. Start with the simplest option that could work: a single model request or a workflow.
3. Collect 50 to 100 real past cases and test on those before any customer sees the system.
4. Keep a person in the loop for every action that is hard to undo.
5. Compare against the baseline after 30 days: resolution rate, errors, time saved and total cost, not just the token bill.