Agents in production
Agent infrastructure
AI agents examples in production: coding, customer-facing, internal ops, vertical, and embedded SaaS agents — what they do, where they break, and why.
Most articles answering "what are some AI agents examples" run through the same shortlist: a coding assistant, a research assistant, a customer support bot, maybe a browser agent. The examples sit on the surface. They tell you what agents look like in a demo, not what they look like at month nine of a production deployment inside a real B2B SaaS company.
This piece does the opposite. We'll work through the categories of agents teams are actually shipping — coding, customer-facing, internal operations, vertical-specific, and platform-embedded — and for each one we'll get specific about what they do, where they break, and what separates the deployments that survive from the ones that quietly get rolled back. Pontil's view, stated upfront: the examples that hold up in production are the ones whose tool layer was designed deliberately. The model matters less than people think. The reach matters more.
Five sections follow. Coding agents. Customer-facing agents. Internal operations agents. Vertical agents. And the embedded agents SaaS platforms are now building into their own products — the category most relevant to anyone reading this.
Coding is where agents work best, and it's not close. GitHub Copilot, Cursor, Anthropic's Claude Code, and Cognition's Devin all ship real software changes for real teams every day. Some of them write the change. Some of them open the pull request. Some of them run the tests, read the failures, and try again.
The reason coding agents work isn't that the models are smarter on code. It's that the surface they act on is unusually agent-friendly. A codebase is text. A test suite returns a deterministic pass/fail. A linter returns structured output. Git is a clean, versioned API for state. Every action the agent takes has a clear contract, an obvious failure signal, and a cheap rollback. That's the dream environment for an agent — and it's almost nothing like the environment inside a typical enterprise SaaS product.
Within coding itself the examples split into three rough tiers. Inline completion (Copilot, Cursor's autocomplete) is the most reliable; the agent suggests, the human accepts or rejects in real time. Chat-based pair programming (Cursor's Agent mode, Claude Code) is next; the agent makes multi-file changes, the human reviews a diff. Autonomous task completion (Devin, OpenAI's Codex agent) is the frontier; the agent takes a ticket and works it end to end. Reliability drops as autonomy rises. Every team running an autonomous coding agent in production has learned to constrain its scope hard — small tickets, well-defined acceptance criteria, mandatory human review before merge.
The lesson coding agents teach the rest of the field is uncomfortable. These agents work because their tools are good. Take the same model, give it a worse surface to act on, and the demos stop looking magical.
The second-largest category of production agents is customer-facing — support deflection, sales qualification, and onboarding assistance. Intercom's Fin, Sierra, Decagon, and Zendesk's AI agents all sit here. So do dozens of in-house builds at SaaS companies that decided not to use a vendor.
These agents do three things well. They answer factual questions whose answers live in a knowledge base. They triage and route. They handle the long tail of low-value tickets — password resets, plan changes, billing-history lookups — that human agents resent. Where they get into trouble is the moment a customer asks them to do something inside the product. "Can you cancel my subscription for me?" "Can you move my account to the team plan?" "Can you remove this user?" These are the actions that determine whether the agent is a chatbot with retrieval or an agent in any meaningful sense.
And this is where the structural problem we've written about elsewhere shows up. The product can cancel a subscription — there's a button in the UI that does it. The agent needs to do the same action through an API. About half the time, the API for that action either doesn't exist, exists in a stale internal form, or exists but doesn't honour the same permission checks the UI does. The team then has three choices: rewrite the API (slow, expensive), build a bespoke connector to that one action (fragile, doesn't compound), or scope the agent down to read-only. Most teams pick option three and call it a soft launch. That's why so many customer-facing agents feel oddly limited compared to the marketing.
For a longer treatment of why this stall is structural rather than tactical, see our piece on the AI applications gap inside enterprise SaaS.
The agents getting the least press are the ones doing the most real work. Internal operations agents — finance close, IT ticket triage, HR onboarding, security alert triage, sales-ops data hygiene, procurement workflows — are deployed in volume at large companies, mostly built in-house or on top of LangChain, LlamaIndex, or CrewAI, and almost never written about.
A representative example: a finance team's month-end close agent that reads transactions out of NetSuite, reconciles them against Stripe and the bank feed, flags exceptions, drafts the journal entries, and routes anomalies to a human. A representative IT example: a triage agent that reads a Jira ticket, classifies it, checks Okta for the user's group memberships, runs three diagnostic queries, and either resolves the ticket or assigns it. A representative security example: an alert-triage agent that takes a Splunk alert, pulls context from CrowdStrike and the cloud provider's audit log, and writes a draft incident report.
These agents work for a specific structural reason: the company owns the systems involved, the systems usually have APIs, and the team building the agent has the authority to extend those APIs when they don't. The boundary is internal. There's no third party telling the team they can't add the endpoint they need. The agents that fail in this category fail for the same reason they fail elsewhere — some critical action lives only in a UI, or behind an undocumented internal service, or in a vendor SaaS whose API doesn't expose it. But the rate at which teams can clear those obstacles is much higher when the systems are theirs to change.
There's a useful read-across here for SaaS vendors: the things your customers' internal-ops agents can't do inside your product are the things they'll eventually pressure you to expose. That pressure is already showing up in procurement, and it's part of why agent-readiness is becoming a commercial differentiator in enterprise SaaS.
Vertical agents are purpose-built for a specific industry workflow. Harvey for law. Hippocratic AI for healthcare patient outreach. Ironclad's contract agents. EvenUp for personal injury claims. Bland and Retell for voice. Whatever your industry, there are now between three and thirty startups building agents inside it.
The interesting pattern: most successful vertical agents are not built by domain experts who learned AI. They're built by AI teams who hired domain experts and then went very deep on one workflow. Harvey didn't try to be a general legal agent — it focused on document review, drafting, and research, and got those three things to a quality bar a senior associate would accept. Hippocratic didn't try to replace clinicians — it focused on non-diagnostic patient-facing workflows like post-discharge follow-up calls, with narrow scripts and clear safety rails. The vertical winners are the ones who picked one chokepoint and refused to leave it.
The failure mode is the opposite. Teams that try to build a horizontal vertical-agent platform — "an AI agent for any healthcare workflow" — almost always stall, because every individual workflow requires a different set of tools, integrations into a different EHR or PMS, a different compliance posture, and a different evaluation harness. The platform never gets good enough at any one thing to displace the specialist. This isn't an AI lesson. It's the same lesson vertical SaaS taught us fifteen years ago.
The fifth category is the one most of this audience cares about: agents inside an established SaaS product, built and shipped by the company that owns the product. Salesforce's Agentforce. HubSpot's Breeze. ServiceNow's AI Agents. Workday's Illuminate agents. Atlassian's Rovo. Notion AI. Asana's AI Studio. Every major B2B SaaS platform has either shipped an embedded agent product or announced one.
This is also the category with the widest gap between what's announced and what's actually live. The marketing pages show an agent that books meetings, updates records, generates reports, and orchestrates work across the product. The shipped version, in most cases, summarises text, drafts content, and answers questions about what's already in the system. The gap isn't dishonesty. It's the API gap. The product can do a thousand things. The API exposes a fraction of them. The agent can reach only what the API exposes. The team has been told, reasonably, that rewriting the API to match the UI is a multi-year project. So the agent ships with the reach it has, and the roadmap fills with "deeper actions coming in Q3."
This pattern is the reason Pontil exists, so we should be honest about it: we are biased here. But the pattern is also independently observable. Look at any embedded SaaS agent that launched in the last eighteen months, and look at the actions it can take versus the actions a power user can take in the UI. The delta is the agent integration debt, and there's a method for measuring it.
The teams getting embedded agents right share three habits. They map the product's full action surface before scoping the agent — not just the API surface, the product surface, the things a real user can actually do. They invest in the tools layer as a first-class part of the build, not an afterthought. And they treat tool maintenance as part of the SDLC, not a side project, because every product change that breaks a tool quietly breaks the agent. For more on why this layer keeps eating the project, see the orchestrator obsession piece.
Four of the five categories above stall for the same reason: the agent needs to reach something that lives in a product, and the product's API doesn't expose it. Coding agents mostly dodge this because their surface is a codebase. Everyone else hits it.
Pontil sits in the tools layer of the agent stack. We're a Tools-as-a-Service platform — we make SaaS products accessible to AI agents by generating, running, and maintaining the tools that bridge what a product can do and what its API currently exposes. We work against the codebase you have, not the API rewrite you don't have time for. Tools execute as the authenticated user, so permissions and audit trails behave correctly. And because maintenance is automated, the tools stay current as the product changes — which matters more than anything else over a two-year horizon.
If the gap between your product's UI and your product's agent is the thing keeping your roadmap honest, we'd be glad to walk through how it works.
The most useful thing about looking at agents across categories is seeing how much of what determines success has nothing to do with the model. Coding agents work because their tools are clean. Internal-ops agents work because the team controls the systems. Vertical agents work when they refuse to sprawl. Customer-facing and embedded SaaS agents struggle in the same way for the same reason: the tools layer is underbuilt, and the product surface the agent needs to act on is mostly invisible to it.
If your team is mid-build, the question worth asking isn't which model to use or which framework to adopt. It's whether the actions you want the agent to take exist as tools, whether those tools are maintained as the product changes, and whether they execute under the right identity with the right permissions. If the answer to any of those is no, the demo will work and the production rollout won't.
Which means the more honest version of "what are some examples of AI agents in production" is: agents that succeed look like the ones whose owners stopped treating tools as plumbing.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
