AI Agents Examples: 8 Real Deployments and What Breaks

If you want AI agents examples with names attached, here are eight that are documented in public by the companies that run them: Klarna's customer service assistant, Salesforce's help agent on its own support portal, Intercom's Fin, Ramp's merchant-classification agent, Uber's Finch, GitHub's Copilot cloud agent, Anthropic's Claude Code, and OpenAI's deep research. Every one of them takes actions in real systems rather than producing text about them.

Most articles on this query hand you categories instead. Nine types of agent, five industries, a taxonomy from a 1995 textbook. That is easy to write and useless to build against, because the interesting part of any agent is never its category. It is the four things nobody publishes: what the agent actually does, what it displaced, what had to exist for it to work at all, and where it breaks.

So that is the shape of each example below. Where a company has published figures, the figures are here with a link to the source. Where a deployment failed or got walked back, that is here too, because the reversals teach more than the launch posts.

The short version

• Working AI agents examples cluster in two places, customer support and software engineering, for the same reason: both have a verification gate built in. The customer says the answer was wrong; CI says the code does not compile.
• The published numbers are real but narrow. Ramp's agent went from handling 1.5 percent of merchant-fix requests to close to 100 percent, at cents per request. Salesforce reports 4.3 million inquiries on its own help portal with 70 percent resolved without a human.
• The most famous example is also the most instructive failure. Klarna reported the work of 700 full-time agents, then reopened human hiring in 2025 when quality slipped.
• Every one of these runs under a fence: a spend cap, a fixed action set, a pull request, a permission prompt, or read-only access. That fence is what keeps the autonomy affordable when the agent gets something wrong.
• Benchmarks say the ceiling is lower than the demos suggest. On Carnegie Mellon's 175-task office benchmark the best agent finished 30.3 percent autonomously.
• Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, and estimates only about 130 of the thousands of agentic vendors are building anything real.

If you want the build side of this (frameworks, guardrails, evals), our guide to building production AI agents covers it. This article is the other half: which agents exist, and what happened when they met production.

What counts as an AI agent, and what does not

An AI agent is a model in a loop with tools. It reasons about a goal, picks a tool, calls it, reads what comes back, and decides the next move, until the job is done or it gives up. A chatbot answers. An agent acts. We unpack the mechanics in how AI agents actually work if the concept is still fuzzy.

The word predates the current wave. In classical artificial intelligence a software agent was anything that perceived an environment and acted on it, which is where the textbook list of five agent types comes from. What changed recently is that the reasoning step got good enough to plan across several tool calls, so a single agent can now chase a goal it was not explicitly scripted for, and multi-agent setups can split that work between specialists.

That distinction is doing more work than it looks. Gartner has a name for what happens when it gets ignored: agent washing, the rebranding of existing assistants, RPA scripts and chatbots as agentic without the underlying capability. In its June 2025 forecast, the firm estimated that only around 130 of the thousands of vendors claiming agentic AI actually qualify, and predicted more than 40 percent of agentic projects would be canceled by the end of 2027 over cost, unclear value or missing risk controls.

The filter is simple and it is worth applying to every example you meet, including the eight below. Does the system call a tool it did not write itself? Does it read the result and change course? Can somebody check the outcome afterwards without redoing the work? Three yeses and you are looking at an agent. Two and you are looking at a product page.

AI agents examples at a glance

Eight deployments, each documented by the company running it. The last column is the one competing articles leave out.

A pattern jumps out. None of these agents have free rein. Each one runs inside a fence, and the fence is what makes the autonomy affordable rather than terrifying. An agent that can issue a 20 dollar refund but not a 2,000 dollar one is useful. An agent that can issue any refund is a liability waiting for week two.

Customer support: the AI agents examples with published numbers

Support is where the public evidence is thickest, because the volume is enormous, the tasks are narrow, and the systems already have APIs. It is also where the honest failure data lives.

Klarna's assistant, and the reversal nobody quotes

Klarna built a customer service assistant with OpenAI and published the first-month numbers in early 2024: 2.3 million conversations, two-thirds of all customer service chats, the equivalent workload of 700 full-time agents, average resolution time down from 11 minutes to under 2, a 25 percent drop in repeat inquiries, and an expected 40 million dollars of profit improvement for the year. It ran in 23 markets and more than 35 languages.

Then in May 2025 Klarna started hiring humans again. CEO Sebastian Siemiatkowski said the company had leaned too hard on efficiency and cost, and that service quality had suffered. Klarna moved to a flexible remote model for complex cases rather than abandoning the assistant.

Both halves are the example. The agent genuinely absorbed the repetitive two-thirds. What it could not absorb was the tail, and Klarna found that boundary the expensive way, in public, after the case study had already gone around the industry twice. Support agents work. The thing worth copying from Klarna is that they treated the escalation path as the hard part, eventually.

Salesforce's help agent, and a definition of success worth stealing

Salesforce runs an agent on its own support portal, and reports it has handled 4.3 million inquiries with roughly 70 percent resolved autonomously. In 2026 the company packaged it and priced it at 2 dollars per successful resolution.

The pricing is the interesting part, because it forced Salesforce to define what a resolution is. It counts only when the user did not need a human escalation and did not say the answer failed to help. Several questions inside a short window count once. That definition is a better ROI framework than most companies build for themselves, and it costs nothing to borrow.

Intercom's Fin, and why the vendor average is not your number

Fin sits inside customer support tools and does more than answer. It updates accounts, processes payments and refunds, and troubleshoots, connecting to business systems through an API, data connectors, or the Model Context Protocol. Intercom publishes an average resolution rate of 76 percent across more than 12,000 customers and roughly 2 million resolutions a week.

Treat that as a ceiling under favorable conditions, not a forecast. Resolution rate is mostly a function of two things the vendor does not control: how repetitive your ticket mix is, and how good your knowledge base is. A support queue that is 80 percent password resets and order status behaves nothing like one that is 80 percent billing disputes. Our writeup on AI in customer support goes into what actually moves that number.

Back office and data: AI agents examples with the cleanest economics

The support examples get the headlines. These two are better engineering, and both companies published enough detail to reproduce the reasoning.

Ramp's merchant-classification agent

Card networks hand you cryptic merchant strings, misleading category codes and questionable location data, so transactions get matched to the wrong merchant. Customers noticed and filed correction requests. Ramp's support team cleared 3 percent of them in 2023 and 1.5 percent in 2024. The rest sat there.

The agent Ramp shipped now handles close to 100 percent of those requests in under 10 seconds, with per-request cost down from hundreds of dollars to cents. Quality is measured with an LLM judge assessing whether the action matched what the user asked for, which they report at roughly 99 percent, backed by two secondary signals: fewer than 10 percent of corrected transactions get a second correction request, and about two-thirds of the agent's rejections hold up on review.

What makes it work is the constraint, not the model. The agent can only choose from a fixed set of actions, and any merchant it reassigns to must already exist in the candidate list it was given. That single design decision converts hallucination from a correctness problem into an impossible one. Ramp also deliberately withholds the ability to edit high-traffic merchant records, so a bad call cannot poison the shared data everyone depends on.

Uber's Finch, the AI agents example that writes its own SQL

Uber's finance analysts used to search across Presto, IBM Planning Analytics, Oracle EPM and Google Docs, write SQL by hand, or file a request with data science and wait hours or days. Finch is an agent living in Slack that takes a plain-English finance question, identifies the right data source, writes the query, runs it, and posts the result back in the thread. If the result set is too big, it exports to a spreadsheet and shares the link.

Underneath is a supervisor agent routing to sub-agents, one of which writes SQL, orchestrated with LangGraph over an OpenSearch metadata index that maps Uber's internal finance vocabulary onto actual columns. Every query is checked against role-based permissions before it runs, so the agent cannot become a way around data access controls.

Uber's own engineers say plainly that it is not 100 percent reliable and is prone to hallucination. That is the right disclosure, and it points at the real precondition: Finch works because Uber first built the semantic layer and curated data marts. The agent is the last 10 percent of that project. Most companies want to start with the agent and skip the part that makes it possible, which is the same mistake we describe in our piece on AI integration done right.

Engineering: AI agents examples where review is the guardrail

Software engineering already has the machinery an agent needs. Tests, CI, code review, version control. Drop an agent into that and the failure modes get caught by tooling everyone already trusts, which is why this category moved from demo to daily use faster than any other.

GitHub's Copilot cloud agent

Assign it a GitHub issue and it researches the repository, drafts a plan, makes changes on a branch, and opens a pull request for a human to review. It works inside an ephemeral development environment powered by GitHub Actions where it can run tests and linters before proposing anything. The review gate is the guardrail, and it is one that already existed.

GitHub is unusually candid about where the boundary leaks. Its firewall documentation states that the network firewall applies only to processes the agent starts through its Bash tool, does not apply to Model Context Protocol servers or to configured setup steps, works only inside the Actions environment, and may be bypassed by a sophisticated attack. Read that as a general lesson rather than a GitHub problem: an agent's blast radius is set by its tools, and the tools you did not think to fence are the ones that matter.

Claude Code, and the guardrail that wears out

Claude Code runs in a terminal, reads a codebase, edits files, runs commands and handles git workflows. Its permission model is tiered: a fixed allowlist of tools that cannot change state, plus allow, ask and deny rules where deny beats ask and ask beats allow. Before it does anything consequential, it asks.

Then Anthropic published the number that makes this example worth including. Users approve 93 percent of permission prompts. A gate that people wave through 93 percent of the time is not really a gate. Anthropic's response was to build classifiers that automate the safe decisions and to drop, on entering automatic mode, the permission rules known to grant arbitrary code execution, including blanket shell access and wildcarded interpreters.

The general point survives the specific product. Human-in-the-loop is a real control the first hundred times and a rubber stamp by the thousandth. If your agent design rests entirely on someone clicking approve, plan for the day they stop reading. See our take on agentic coding in practice for how that plays out across a team.

Research: the AI agents example where citations are the fence

OpenAI's deep research takes a prompt and works independently, browsing hundreds of sources, backtracking when a path fails, plotting data, and producing a report that cites specific passages from the pages it actually retrieved. On Humanity's Last Exam, an expert-level evaluation across many subjects, the model behind it scored 26.6 percent, a high mark on a deliberately brutal test.

Read-only work is the safest agent category by construction. Nothing gets written, so a mistake costs a reviewer's attention rather than a transaction. The citations do double duty: they improve the output and they make spot-checking take seconds instead of an afternoon.

OpenAI's own limitations note is the honest part. Deep research can still hallucinate, it struggles to distinguish authoritative sources from rumor, and its confidence calibration is weak, meaning it often fails to signal when it is unsure. An agent that cites is much better than one that does not. It is not the same as an agent that is right.

Sales, ops and internal workflows: the AI agents examples nobody publishes

Notice what the eight have in common besides being agents. Six of them are products or infrastructure the company sells or open-sources, and the other two are engineering blog posts from firms that recruit engineers. Publishing is marketing. The enormous population of internal agents doing lead enrichment, CRM hygiene, invoice coding, onboarding paperwork and report generation sits behind NDAs and never shows up on a list like this one.

That skew has a real cause worth understanding. Support and engineering agents get published because both domains hand you a verification signal for free. In support, the customer tells you the answer was wrong. In engineering, the test suite does. A lead-routing agent has no equivalent oracle, so proving it worked means building the measurement first, and most teams do not.

Which is exactly why these AI agent use cases still make excellent first projects: the reputational risk is lower, the data is cleaner, and nobody outside the company sees the first six weeks. Just budget for the evaluation harness up front, because unlike support you will not get one thrown in. Our note on measuring AI ROI covers what to instrument before launch rather than after.

What every working AI agents example needs to run

Strip the eight down and the same preconditions appear underneath all of them. This is the list that competing articles skip, and it is the one that decides whether your project ships.

A clean way to act. Fin connects over API, data connectors or MCP. Finch runs SQL against curated data marts. Ramp's agent calls a fixed set of internal actions. An agent with no reliable tools is a chatbot you overpaid for, confidently describing actions it cannot take. If the system you want to automate has no API, that integration is the project, and the agent is the easy part afterwards. This is where AI integration into existing systems earns its keep.

A semantic layer, not just data access. Finch needed a metadata index mapping Uber's internal finance vocabulary onto real columns before natural language questions could resolve. Fin's resolution rate rests on knowledge base quality. Raw table access does not make an agent useful; it makes it confidently wrong in a new way.

A fence sized to the worst case. Ramp restricts the action set and protects high-traffic merchant records. GitHub requires a pull request. Salesforce escalates rather than guessing. Deep research writes nothing. Pick the cheapest constraint that makes the worst outcome survivable, and apply it on day one rather than after the first incident.

A definition of done you can count. Salesforce says a resolution means no human escalation and no complaint. Ramp uses an LLM judge plus a second-correction rate. Without a countable unit you cannot tell improvement from drift, and you certainly cannot tell your CFO anything.

An agent is only as autonomous as its dumbest tool is safe. Give it a verifiable task and a tight fence, and it will quietly do the boring work for years. Give it open-ended judgment, and you have built a very confident intern with root access.

Where AI agent examples break, and the numbers behind it

Every deployment above ships with a documented failure mode, which is the most useful thing about them. The research agrees, though it disagrees with itself about how bad the picture is.

Start with reliability, because it sets the ceiling. On Carnegie Mellon's TheAgentCompany benchmark, 175 long-horizon tasks inside a simulated software company complete with GitLab, ownCloud and a chat tool, the best agent completed 30.3 percent autonomously. Stanford's 2026 AI Index reads far more optimistically on narrower ground: on OSWorld, which tests agents on real computer tasks, accuracy climbed to 66.3 percent, within about six points of the human baseline, though the report still puts the failure rate at roughly one attempt in three. Both numbers are correct and the gap between them is the point. Agents are much better at bounded computer tasks than at doing somebody's job.

Length is what turns a decent step into a bad outcome. A step that succeeds 95 percent of the time succeeds about 36 percent of the time over twenty steps. That is arithmetic rather than pessimism, and it explains the shape of everything above: the examples that work are short chains against reliable tools, and the ones that fail are long chains against flaky ones.

Then there is a class of failure ordinary software does not have. The OWASP Top 10 for Agentic Applications, published in December 2025, catalogs it: goal hijack, where injected content redirects what the agent is pursuing; tool misuse; memory poisoning; identity and privilege abuse; and rogue agents. GitHub's firewall caveat is one of these, written down honestly by a vendor. Treat the agent's credentials as the real attack surface, because that is what an attacker will treat them as.

Zoom out to the organizational level and the numbers get worse before they get better. Gartner's cancellation forecast is one signal. Klarna's reversal is the other, and it happened at a company with strong engineering and every commercial incentive to make the story hold up. Assume you will find your own boundary the same way they did, and design so that finding it is cheap.

AI agent use cases that are not agent-shaped yet

Some work resists this pattern, and it is recognizable in advance. The tell is that the task is open-ended, the stakes are high, or the result cannot be checked before it lands. Two of those three and you want a human deciding, with the agent assisting.

Final legal, medical and financial decisions need accountability a model cannot hold. Anything irreversible without a gate is out, because the whole economics above depends on wrong actions being cheap to catch. Work that needs genuine taste is a poor fit too: an agent will draft brand copy that is plausible, confident and slightly off, every time, and it cannot tell you which.

None of that kills the use case. It changes the design from agent acts alone to agent assists, human decides, which is where most of the useful surface area actually is. And it is worth saying that the boundary moves. OSWorld went from roughly 12 percent to 66.3 percent in two years. Write down where you drew the line and why, then revisit it, because the reasoning ages faster than the code.

How to pick your first AI agent use case

Do not start with the use case that demos well. Score your candidates on four traits: high volume, narrow scope, driven by tools rather than free text, and verifiable. Then add the fifth filter that every example above passes and every failed pilot does not, which is that a wrong action must be cheap to catch.

Run your list through that and the first project usually picks itself, and it is usually unglamorous. Ramp did not build a general finance assistant. It built something that fixes one specific wrong field, and it earned back hundreds of dollars per request by being that boring. Copy the scope discipline before you copy the ambition. Wire in the escalation path and the spend caps on day one, prove the agent on real traffic, and widen scope only once it has earned it.

If you would rather not learn all of that on production, that is the work we do. Our AI agent development team builds these systems end to end, and our broader AI development services cover the integration and evaluation work that decides whether an agent holds up. The hard part was never the model. It is the engineering around it, and every one of these AI agents examples proves the same thing from a different angle.