AI agents for business: what works in practice

Most pages about AI agents for business are lists of products. That is the wrong place to start. A business does not need an agent because agents exist. It needs a recurring piece of work completed more reliably, with less waiting and a clear owner when something goes wrong.

We build and run agents inside real operations. Across one production platform, 5,329 task-runs over four months finished at a 98 percent success rate. The lesson was not that the model had become infallible. Most failures came from ordinary systems around it: expired credentials, rate limits, slow APIs, and missing data. Business agents succeed or fail at the workflow boundary, not in the demo.

AI agents for business start with the work

The best first agent is a recurring job with a clear input, a reviewable output, and a cheap failure. If you cannot describe those three things, the workflow is not ready for an agent.

"Help our business with AI" is not a brief. Neither is "build a sales agent." A workable brief sounds like this:

• Every Monday, read the completed campaign data and prepare the performance report.
• When a product-image batch arrives, validate the source files and prepare the approved output package.
• After a meeting, turn the transcript into decisions, owners, and follow-up material.
• When a monitoring queue finds a customer question, draft a response for a person to approve.

Each sentence names a trigger, the systems involved, and what done means. None asks the agent to "run marketing" or "manage operations." Broad nouns hide the decisions that still need an owner.

I use five questions before choosing a first workflow:

1. What starts the job?
2. Which current facts must be retrieved?
3. Which judgment belongs to the model?
4. What action requires a person or deterministic rule?
5. Where can the finished result be verified?

A weak answer to any one of them becomes a production incident later.

Separate facts from judgment

Code should retrieve measurements, records, and system state. The model should interpret those facts, explain tradeoffs, and draft the part that genuinely needs language or judgment.

This split is the most reusable pattern across the systems we build.

An email-performance agent should not remember last week's revenue. Code pulls the current numbers from the source. The model explains what moved and drafts the report. A product-image workflow should not guess whether every source file exists. A deterministic preflight checks the files and manifest. The model can explain what is missing and propose the next step.

When those roles are mixed, debugging becomes impossible. A wrong number might be stale retrieval, a parsing mistake, or a model invention. When they are separated, the proof path is visible:

source system -> deterministic retrieval -> agent judgment -> reviewable output

The rule is not "never let a model calculate." It is that the business fact should remain traceable to the system that owns it. If a customer, field, campaign, order, or task has an official record, retrieve that record instead of asking the model to reconstruct it from context.

The three agent patterns businesses actually use

Most useful business agents fall into three operating patterns: read and report, draft and approve, or prepare and deliver. The pattern determines the safety boundary.

Read and report

The agent reads current systems and turns them into a brief, report, diagnosis, or recommendation. It does not change the underlying system.

Examples include weekly performance reporting, rank and traffic analysis, account research, inventory summaries, and operational exception reports. This is usually the safest first deployment because the agent's work is visible and reversible. A bad paragraph can be corrected before it becomes an action.

The failure mode is stale or partial data. A report that sounds polished can hide a missing page of API results or a token that stopped refreshing. The fix is not a stronger prompt. The retrieval layer must prove which records and time window it received.

Draft and approve

The agent prepares something that could affect another person, but a human owns the send, post, commitment, or status change.

Examples include customer-response drafts, campaign briefs, meeting follow-ups, content plans, and proposed tasks. This pattern removes the blank page and the repetitive first pass without pretending that communication authority belongs to the model.

The approval must bind to the exact draft. "Approved" cannot mean "the agent may now regenerate something similar and send that." The person approves a specific artifact, recipient, and action.

Prepare and deliver

The agent coordinates a multi-step job that ends in a concrete artifact: a report, spreadsheet, image bundle, data export, or implementation package.

This is where agents begin to look like operations. The job may include source resolution, validation, deterministic processing, analysis, and delivery. Completion is not the model saying "done." The artifact must exist, match the requested identity, and be readable by the person or system that receives it.

That final readback catches a class of failures demos miss. A tool may return "delivered" while the recipient cannot open the file, the wrong version was attached, or the system of record never changed.

Use a narrow permission boundary

An agent should receive the smallest set of data and actions needed for one job. Prompt instructions are useful behavior guidance, but they are not the permission system.

The boundary belongs in code and configuration:

• Read-only credentials for a reporting job.
• A tool allowlist tied to the workflow and identity.
• Separate client workspaces and records.
• Approval before a send, publish, purchase, or destructive write.
• A deny default when the requested action is not recognized.

This is especially important in a multi-client system. A correct answer built from another client's data is still a severe failure. Isolation has to be enforced where files, database rows, tools, and credentials are selected. Asking the model to "remember which client this is" cannot carry that responsibility.

The same principle applies to building an AI agent at the SDK level: use a workflow when the sequence is known, and let the model choose steps only where that choice adds value.

Roll out read-only before autonomous

Start with observation, then a read-only canary, then a human-approved action. Broaden autonomy only after the same workflow produces repeatable evidence.

The sequence we trust is:

1. Replay or shadow the current human workflow without changing production.
2. Compare the agent's output with accepted real examples.
3. Run a narrow canary on current data with no write authority.
4. Add one approval-bound action.
5. Verify the result in the destination system.
6. Expand only the part that has earned it.

This is slower than turning on every tool in a demo. It is faster than recovering from one agent that contacted the wrong person or changed the wrong record.

Agriculture makes the need for this sequence obvious. A field report, supplier document, input inventory, crop record, and agronomist decision are different sources with different owners. An agent may help collect, reconcile, or draft around them, but it should not turn incomplete field evidence into an autonomous recommendation. We will publish agriculture case studies when the workflow and evidence can be shown safely. Until then, it is an implementation category, not a claimed result.

Measure finished work, not model activity

A business agent should be measured by accepted outputs, error classes, time to completion, and human correction. Token counts and model messages are operating data, not business success.

One platform we run completed 5,220 of 5,329 tasks over four months. That 98 percent rate is useful because each task had a defined completion state. It would mean little if a "task" were simply a model response.

Across two separate production systems, a later 30-day window landed at $0.97 and $1.01 of model cost per task. Those systems had different workloads and are intentionally anonymous. The close result is interesting, but it is not an industry benchmark. It shows that inference can be measured and that, in these systems, it was cheaper than integration, evaluation, and maintenance. The full AI agent development cost breakdown explains that boundary.

For a new workflow, track at least:

• attempted, completed, and accepted tasks;
• failures by cause, not one combined error rate;
• retries and the work they recover;
• human edits or overrides;
• time from trigger to accepted result; and
• cost per attempted and completed task.

Do not borrow the client's revenue, return on ad spend, crop yield, or customer outcome as the agent builder's result unless the causal link is real and the client has approved publication. Our defensible metric is the work our system completed.

Choose the stack after the boundary is clear

Claude, OpenAI, Codex, MCP, and an Agents SDK are implementation choices. None tells you which business job should be automated or who owns the final decision.

Our existing production platform still uses the Claude Agent SDK. Our personal coding and orchestration workflow has moved to Codex. We build MCP servers where the same tool contract should work across hosts. We are evaluating OpenAI's newer agent architecture in isolation rather than rewriting a working system because the provider changed.

That mix is not indecision. It is architecture following the job.

Choose an SDK after you know whether the application needs a model-controlled loop, persistent sessions, sandboxed compute, approval handling, tracing, or handoffs. Choose the model after you know the quality, latency, and cost required for that step. Choose the business workflow first.

The SEO agents we run in production are one field example. SEO matters here because it supplies thousands of repeated, measurable tasks, not because every business needs an SEO agent.

What a useful first implementation looks like

A useful first business agent has one queue, one source-of-truth path, one reviewable output, and one named owner when it fails.

It should be possible to draw the system on one page. If the first version needs ten agents, several autonomous handoffs, write access across the company, and a new dashboard before it can produce value, the scope is hiding an unmade product decision.

Start with the job people already repeat. Preserve their accepted examples. Make the input current and the output testable. Keep the first action reversible. Then watch where the work actually breaks.

The model will often be the least surprising part.

Frequently asked questions

What can an AI agent do for a business?

An AI agent can retrieve current information, interpret it, use approved tools, and produce a defined result such as a report, draft, diagnosis, or artifact package. The safest first use is recurring work with a clear input, reviewable output, and cheap failure.

What is the best AI agent for business?

There is no universal best agent. The right system depends on the job, data sources, permission boundary, review process, and definition of completion. Choose the workflow first, then select the SDK, tools, and model that fit it.

How do I make an AI agent for my business?

Choose one recurring task, identify the trigger and source systems, separate deterministic data retrieval from model judgment, define the actions that require approval, and verify the final result in its destination. Start read-only and broaden authority only after a canary works.

What should a business automate first with an AI agent?

Start with a frequent task that has consistent inputs, an obvious output, and low-cost mistakes. Reporting, research, classification, draft preparation, and artifact validation are usually better first jobs than autonomous customer communication or financial actions.

How should AI agents be measured?

Measure attempted, completed, and accepted tasks; failure causes; retries; human corrections; completion time; and cost per task. A model response is not automatically a completed business task, so completion must be verified at the artifact, recipient, or system-of-record boundary.