An AI agent is a language model that uses tools in a loop to complete a task. Anthropic draws a useful line between agents and workflows: a workflow follows code paths someone wrote in advance, while an agent chooses its own steps and tool calls. Most published lists of AI agent ideas describe workflows and call them agents. It’s a wrong approach because the two fail in different ways and cost different amounts to run.

Companies now run agents in customer support, incident response, business analytics, regulated case preparation, code migration, document review, and multilingual communication. Researchers at UC Berkeley, Stanford, UIUC, and IBM Research documented 86 such systems across 26 domains in a study published at ICML 2026. Their catalogue is the best available answer to what a company should build.

The agents that reach production run a small number of steps and stop. A person checks the output before anything irreversible happens. They start read-only, inside the company, on a task where somebody can tell whether the answer was right. Teams give up autonomy on purpose, and that is why their systems survive.

What Separates an AI Agent Idea That Ships From One That Dies

Melissa Pan and her co-authors set out to answer a question the industry had been guessing at: what do agents that serve real users look like? They interviewed 20 deployment teams, surveyed 306 practitioners, and filtered the results down to 86 systems running in production or final pilot across 26 domains. The work ran from April to November 2025 and was accepted at ICML 2026 as an oral presentation.

Four properties separate the systems that shipped from the ones that stalled: bounded tasks, human verification, fast correctness signals and tolerance for latency.

The task has edges. Sixteen of the 20 interviewed teams built structured workflows rather than open-ended planning. Sixty-eight percent of deployed agents run fewer than ten steps before human intervention, and nearly half stop before five. Long autonomous chains largely stayed in prototypes.

Someone verifies the output. Three quarters of deployed systems use human review as the primary evaluation method. The authors treat this less as a temporary limitation and more as a durable design principle.

Correctness becomes visible quickly. A code migration agent can get a verdict from a test suite in seconds. An insurance workflow may not reveal a mistake for months. The faster the feedback loop, the faster the system can improve.

Minutes are acceptable. Two thirds of deployed agents tolerate response times of minutes or longer. For many operational workflows, a five-minute agent is still faster than waiting for a person to pick up the task later.

One caveat: the authors present these figures as qualitative evidence, not fixed prevalence estimates. The samples are geographically concentrated and subject to participation bias, so the percentages are best read as direction rather than measurement.

Eight AI Agent Ideas for Business, Ordered by Shortest Path to Production

1. The internal support agent that answers or escalates

Engineering teams answer the same platform questions repeatedly. A support agent can handle the routine ones from internal documentation and escalate anything uncertain or unresolved into the existing ticket queue.

Tencent deployed this approach on its Big Data platform in September 2025. During a seven-day sample of live queries, the agent resolved 33.5% without creating a ticket, with an average end-to-end response time of 15.05 seconds. The team reported a 20.8% reduction in online ticket volume. Because production logs were subject to privacy constraints, the system used open-weight models running on Tencent's own infrastructure rather than closed third-party APIs.

The use case is attractive because performance is easy to measure: either the agent resolves the question or it becomes a ticket.

Signal to watch: deflection rate against the existing ticket baseline.

What kills it: stale documentation. An agent grounded in an outdated runbook can produce an answer that is well-sourced, confident and still wrong.

2. The incident triage agent that proposes and never acts

An alert fires. The agent pulls the telemetry, reasons about the cause, drafts a diagnosis and a proposed fix, and stops. An engineer decides whether to run it.

Read-only is the entire design. It removes the blast radius rather than managing it, which is why six of the twenty teams the Berkeley group interviewed use the same constraint as their primary security control. One of their cases runs a site reliability agent that generates bug reports for engineer review without touching production. Another has engineers executing on the agent's recommendation rather than the agent executing on its own.

On-call time is expensive, and the work is well documented, which makes this one of the cheapest first builds available.

Signal to watch: time from alert to an accurate first diagnosis. 

What kills it: observability data the agent cannot reach. If the answer lives in a dashboard nobody exposed through an API, the agent will guess.

3. The analytics agent that shows its work

Someone in the business asks a question that takes an analyst twenty minutes of spreadsheet work. The agent queries read-only endpoints, joins the results, and returns the answer along with the endpoints it called, the parameters it used, and the computation it ran.

The provenance panel is what makes this deployable in a regulated company. IBM Research and IBM Consulting piloted a generalist agent called CUGA in a talent acquisition workflow from mid-2025, connected to 13 read-only analytics APIs. On their domain benchmark it reached 87% task accuracy, with 95% of responses carrying provenance logs and an average latency of 11.2 seconds. Valid-first-try rate rose from 62% on a plain baseline to 79% with the full architecture. Analysts rated reproducibility 4.6 out of 5.

Read the IBM numbers for what they are. The team describes the system as under consideration for production rollout rather than in production, states that the results were not tested for statistical significance, and presents its efficiency estimates as projections from simulated workflows. The benchmark figures are solid. The business-impact figures are the team's own forecast.

A second data point from a different company points the same way. Tencent runs a business intelligence system across its finance, advertising, and cloud units for dozens of enterprise clients, reporting over 93% accuracy on SQL generation and query times falling from minutes to seconds.

Signal to watch: the share of answers an analyst accepts without re-running the query. 

What kills it: an agent that invents a number when the endpoint does not exist. IBM's analysts said the thing that earned their trust was watching it decline questions it could not answer.

4. The bounded case-preparation agent

Take a regulated process that already exists on paper and hand each step to an agent, leaving the sequence fixed.

One of the Berkeley study's cases automates how clinicians prepare and obtain insurance approval. The agent moves through coverage lookup, then medical necessity review, then risk identification. It works autonomously inside each subtask while the order and the objective stay locked. That pattern describes most of what reached production: teams adapting a documented business process into an agent workflow, rather than building an autonomous worker and hoping it finds the process itself.

You are not designing a sequence here. You are automating one your compliance team already wrote down, which is why this idea survives review meetings that kill more ambitious proposals.

Signal to watch: preparation time per case, and the rate at which reviewers change the agent's output. 

What kills it: slow feedback. When the only real verdict arrives months later as a denied claim, you cannot iterate. Build a proxy check before you start.

5. The sandboxed migration agent

Upgrade a runtime version, migrate a framework, or refactor a service against a target. The agent generates the change, tests it in a mirrored sandbox, and merges only after verification passes.

Software has something no other domain on this list has: a fast automated oracle. Compilation and test suites tell you within seconds whether the agent was right. That is why iteration here runs faster than anywhere else, and why one of the study's cases is the only system in the whole sample permitted unconstrained exploration. Its team allows that freedom because everything happens inside a sandbox with rigorous verification before anything merges.

That same case, a version migration for a large data-processing framework, is also one of the few running a fine-tuned open model. The team chose it because inference costs on high-volume workloads were prohibitive and they already owned the GPUs.

Signal to watch: share of generated changes that pass the existing suite unmodified. 

What kills it: a test suite that does not cover the thing you are migrating. The agent will produce green builds and broken behaviour.

6. The document-against-rulebook agent

Incoming documents get checked against a standing set of rules. Contracts against a playbook, specifications against a standard, safety data sheets against a regulation. The agent flags exceptions and a person judges them.

The Berkeley catalogue includes a materials safety and regulatory analysis agent doing this work. The profile fits the pattern well: high volume, well-defined rules, exception-based output, and a human who owns every call that matters.

Handle the access controls before you handle the model. Sixty-nine percent of the deployed agents in the study retrieve confidential or sensitive data, and this idea sits squarely in that group.

Signal to watch: confirmed exceptions caught, measured against exceptions your reviewers found afterwards. 

What kills it: a rulebook that lives in three people's heads. If nobody has written the rules down, the agent has nothing to check against and you are building an expensive opinion generator.

7. The multilingual customer communication agent

The most requested idea on this list and the one most likely to end badly. It belongs here with the evidence attached.

Two of the study's cases cover communication automation across languages and dialects, including one in automotive. These sit among the small group of deployments that require real-time responsiveness, and their teams report latency as their hardest engineering problem. Five of twenty cases needed real-time speed. Everyone else got to optimise for quality instead.

Then there is the record. Klarna announced in February 2024 that its assistant had handled 2.3 million conversations in its first month, two-thirds of the company's customer service chats, cutting average resolution time from 11 minutes to under 2. 

In May 2025, chief executive Sebastian Siemiatkowski told Bloomberg the company had pushed too far on cost and produced lower quality, and Klarna reopened hiring for support roles. Klarna then disputed the reversal framing, telling Forbes that its assistant was by then doing the work of over 800 roles, that it had never removed human support, and that it still worked with several thousand outsourced agents. Read all three statements before you copy the strategy from any one of them.

The liability question has an answer too. In Moffatt v. Air Canada, 2024 BCCRT 149, the British Columbia Civil Resolution Tribunal rejected the airline's argument that it was not responsible for what its chatbot told a customer. Tribunal member Christopher Rivers called that argument "a remarkable submission" and found the airline had failed to take reasonable care over the chatbot's accuracy. A tribunal ruling carries less weight than a court judgment. Treat it as a signal, and note how loud the signal is.

Signal to watch: resolution rate split by intent complexity. A blended average hides the failures that damage you. What kills it: measuring cost per contact and nothing else.

8. Being reachable by other companies' agents

The last idea is not an agent you build. It is a surface you expose, so that agents acting for your customers can find you, compare you, and buy from you.

This stopped being speculative in 2026. The International Monetary Fund documented the launches in an April note on agentic payments. OpenAI's Instant Checkout, running on the Agentic Commerce Protocol, introduced a 4% transaction fee on agent-led conversions in early 2026. Google launched its Universal Commerce Protocol in January 2026 with checkout inside Search AI Mode and Gemini for retailers including Etsy and Wayfair. Visa and Mastercard both shipped agent frameworks built around verifying which agent is acting for whom.

Underneath sit two open standards, both now governed by the Linux Foundation. One connects an agent to tools. The other connects agents to each other, and passed 150 supporting organisations at its April 2026 release.

Agent-mediated purchasing became a priced distribution channel this year. Whether your catalogue and your policies are machine-readable is now a commercial question rather than a technical one.

Signal to watch: whether an agent can retrieve your pricing, availability and returns policy without a human reading a web page. 

What kills it: nothing yet, which is the reason to look at it now.

How Codebridge Approaches This

We build AI agents as an implementation service, architecture first, and the client owns the code at the end of it. Our roots are in Big Four consulting, which shapes how we scope: we start from the process and the verification loop, not from the model.

The evidence above points at the same conclusion we reach on most engagements. The teams that get agents into production win by bounding the problem correctly and by building a way to tell whether the output was right. Model selection is the easy part, and the frameworks change every quarter anyway.

If you have a candidate workflow and want a second opinion on whether it has the four properties in the table above, book a 30-minute call. We will tell you if the answer is no.