A support manager I know pulled up a spreadsheet last winter and found 40 tickets closed overnight. Nobody had been on shift. One agent had read each ticket, checked the order history, refunded three customers under £50 and queued the rest for a human with a one-line summary attached to each.
That gap between talking and doing is where most useful AI agent examples live. The software reads, decides and acts in a loop until the job is finished or it hits a wall it can’t climb. Here are examples from real deployments, including the boring parts and the ways they fail.
What separates an agent from a chatbot with better branding
A chatbot maps one message to one reply. An agent maps a goal to a sequence of actions. It gets tools, a plan, a way to check its own output, and a stopping condition.
The real difference shows up in tool access. Ask a chatbot to change a shipping address and it writes back a polite explanation. Ask an agent wired into the order system and it edits the record, emails the customer and updates the warehouse note. Same underlying model, completely different blast radius, which is why what AI agents actually do and where they break spends as much time on permissions as on prompts.
Six AI agent examples doing real work
1. Support triage that clears the boring 60%
Intercom’s Fin and Zendesk’s agent tooling are the most visible examples. The pattern is consistent across both: the agent handles password resets, order tracking, address changes and refunds below a threshold, then escalates anything involving legal language, churn risk or an obviously furious customer.
Klarna made headlines saying its assistant did the work of roughly 700 support staff at peak, with resolution times falling from about 11 minutes to under 2. The company later rebalanced toward human agents for complex cases. That walk-back is the honest part of the story, and it tells you more about deployment than the original statistic did. Narrow scope, hard escalation rules, a human owner watching the queue.
2. Coding agents that open pull requests
Claude Code from the team behind Claude, Cursor’s agent mode, GitHub’s Copilot coding agent and Devin all run roughly the same loop: read an issue, find the relevant files, write a patch, run the test suite, open a PR, respond to review comments.
The good ones are judged on whether tests pass, not on how elegant the diff looks. Teams I’ve spoken to get the most value from small, well-scoped tickets: a single failing test, a dependency bump, a flaky selector in an end-to-end suite. Hand the same agent a vague architectural request and you’ll spend longer reviewing than writing.
3. Sales research agents that fill the CRM before the call
Nobody enjoys the 20 minutes before a discovery call spent hunting through LinkedIn, filings and old email threads. An agent can pull funding rounds, headcount changes, recent product launches and past correspondence, then draft a briefing note and log it against the account.
Output quality depends almost entirely on which sources it can reach. Give it CRM access plus web search and you get something usable. Give it search alone and you get a summary of the company’s own About page, which the salesperson could have read themselves.
4. Finance agents matching invoices to purchase orders
Three-way matching between invoice, purchase order and delivery note is tedious, rule-based and high volume. That combination makes it close to ideal. The agent pulls the invoice, finds the PO, compares line items and tax treatment, then either clears it or flags the mismatch with a reason.
At one mid-sized distributor, the agent cleared around 70% of invoices with no human touch and routed the rest with notes like “quantity on line 3 doesn’t match the delivery note”. The AP team still approved everything above €5,000. Sensible limit, sensible result.
5. QA agents that click through the checkout
Browser-using agents run the flows a human tester would: add to basket, apply a discount code, check out as a guest, try a card that should decline. When something breaks, they file a ticket with a screenshot and the exact step where it died.
This is one of the few categories where running the agent 40 times a day genuinely beats a person doing it twice a week. Regressions surface in hours rather than at the next release.
6. Procurement agents that chase quotes
Need six supplier quotes for a component? The agent emails each one from a template, chases the non-responders after 48 hours, normalises the replies into a comparison table and hands it over. Negotiation stays with a human. The chasing, which nobody wants to do, doesn’t.
Smaller AI agent examples you can set up in a week
Not every deployment needs a platform team and a security review. These are the ones I’d suggest to a small business owner chasing a first win:
- Inbox triage. Reads incoming mail, labels it, drafts replies for your three most common requests and leaves them in Drafts for review.
- Onboarding. Creates accounts in the tools you actually use, books first-week meetings and posts a checklist in the new hire’s channel.
- Competitor watch. Visits 25 pricing pages every Monday, notes what changed and posts a diff to Slack.
- Meeting follow-up. Turns a transcript into action items, assigns owners from the attendee list and drops them into the project tracker.
- Renewal reminders. Checks contract dates, drafts a nudge 60 days out and escalates if nobody replies within a week.
Self-hosting matters more than people expect here, purely on cost. Open-weight families like Meta’s Llama models can run a triage agent on your own hardware, which keeps customer data in-house and turns a per-seat bill into a fixed one.
Where these examples fall apart
Most failures are unglamorous. A 12-step task where each step succeeds 95% of the time finishes correctly less than half the time. Stale context. A tool that returns HTTP 200 with an error message buried in the body. A permission that’s one notch wider than it needed to be.
Two fixes cover most of it. Give the agent a way to verify its own output, whether that’s a test suite, a schema check or a rule like “the totals must reconcile”, so a bad step gets caught before it compounds. Then cap the loop. An agent that retries four times and escalates is far more useful than one that retries forever. The mechanics are set out in how to build AI agents that actually finish the job, and the short version is that verification beats cleverness every time.
Judging an example before you copy it
Vendor demos are shot on clean data with a friendly task. Ask three questions instead. What share of tasks reach a verifiable end state without a human? What happens on the messy cases? Who gets paged when it goes wrong at 2am?
Public benchmarks won’t help much either, because your tickets, your invoice formats and your codebase are the hard part. A better signal is a short list of tools scored on completion rather than conversational charm, which is roughly the method behind the best AI agents judged by what they actually finish.
Picking the first one to copy
Look for a task that meets four conditions. It repeats weekly. It has a clear definition of done. A mistake is recoverable. Somebody already owns the outcome and will notice if it drifts.
Invoice matching qualifies. So do inbox triage and regression testing. “Improve our marketing” does not, and an agent handed that brief will quietly burn a budget producing plausible nonsense.
Then narrow the tools before you widen the task. Give the agent read access for the first fortnight, log every action it takes, and read the log yourself. You’ll usually find the weak point is a missing verification step or a tool returning garbage, not a model that’s too small. Fix that, then grant write access to one system at a time.
The examples above share a trait worth copying. None of them are trying to be general. Each does a narrow job, checks its own work, and hands off cleanly when the job turns weird.