Adding AI Agents to a SaaS Product (Responsibly)

Two numbers frame every AI-agent conversation a SaaS team should be having in 2026. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. The same research estimates that of the thousands of vendors now selling "agentic AI," only about 130 offer genuinely agentic capabilities. The rest are rebranding chatbots and RPA, a practice Gartner calls agent washing.
And yet the competitive pressure is real: Salesforce, SAP, ServiceNow, and Workday have all shipped named agent platforms, and Deloitte's 2026 TMT predictions frames agents as the force reshaping SaaS budgets and customer expectations. So the practical question for a SaaS founder isn't whether the category is coming. It's how to add agents to your product and land in the surviving 60%. As the data below shows, that is mostly a matter of scoping, economics, and security architecture, not model selection.
First: What Actually Counts as an Agent
An agent is a system that takes a goal expressed in natural language, plans steps, executes them using tools (APIs, databases, code, actions inside your product), observes the results, and revises its plan, in a loop, without a human directing each step.
Hold that definition against what's being sold and two useful distinctions fall out.
Agent vs. agent-washed. A support bot walking a decision tree isn't an agent. A rebranded RPA script isn't an agent. Gartner's estimate of roughly 130 real vendors is the market-level version of a product-level truth: calling a feature an agent doesn't make it one, and buyers are learning the difference.
Agent vs. workflow: the distinction that should drive your roadmap. In Anthropic's engineering framing, workflows are systems where LLMs and tools are orchestrated through predefined code paths: your code controls the flow, and the model does bounded work at each step. Agents are systems where the model directs its own process and tool use. Workflows are predictable, debuggable, testable, and cheap. Agents buy flexibility at the price of all four.
Here's the part vendor content won't tell you: most successful "AI agent" features in SaaS products are workflows, and that's not a compromise. It's just good engineering. A "research agent" that always runs the same search, extract, synthesize, and format steps is a workflow with a good name. Start there. Promote a workflow to an agent only when the task genuinely can't be specified as a path.
What the Failure Data Actually Says (and What It Doesn't)
The most quoted statistic in enterprise AI is that 95% of GenAI pilots fail to deliver measurable ROI, from MIT's "GenAI Divide" report, which drew on 52 executive interviews, surveys of 153 leaders, and an analysis of 300 public deployments, set against $30-40 billion in enterprise GenAI spend.
A correction flag before you put it in a boardroom deck: the report was a preliminary, non-peer-reviewed study, and the 95% figure has been heavily mangled in retellings. It measured pilots with no measurable P&L impact under the study's specific definitions, not "AI doesn't work." Treat the number as directional.
What survives scrutiny is more useful than the headline anyway:
- Failures are integration failures, not model failures. MIT calls it the learning gap: the inability to fit AI into workflows, processes, and culture. Gartner's cancellation reasons are the same finding from the other side. Proofs of concept driven by hype, misapplied, and never scoped for the real cost of production.
- The budget goes to the wrong place. Spending concentrates on sales and marketing demos while the measurable returns show up in back-office and operations automation, which is the unglamorous, high-volume, recoverable-error work.
- External help roughly doubles the odds. Pilots built with specialized external partners reached deployment about twice as often as internal builds (roughly 67% vs 33% in MIT's sample). Self-serving for a product studio to quote, so calibrate accordingly, but it's the report's most concrete number.
The takeaway isn't "agents fail." It's that failure has a shape (unscoped ambition, missing integration, no error economics), and a shape is something you can engineer against.
The Klarna Arc: 18 Months of Production Agents, Compressed
No company has run the full experiment more publicly than Klarna, and its arc is the single most instructive case study available.
February 2024: Klarna's OpenAI-powered assistant handled 2.3 million conversations in its first month: two-thirds of all customer-service chats and the workload of roughly 700 human agents, with average resolution time dropping from 11 minutes to under 2.
Mid-2025: Klarna began rehiring human agents. Customer satisfaction had slipped, and CEO Sebastian Siemiatkowski said it plainly: "We focused too much on efficiency and cost... The result was lower quality, and that's not sustainable." The new model is hybrid: AI handles routine volume, while humans own disputes, complex refunds, and financial-hardship cases, with flexible remote agents assisted by AI in every conversation.
Three lessons, none of which is "the technology failed":
- The tech worked; the scope was wrong. The assistant genuinely resolved two-thirds of chats. The mistake was extending autonomy into interactions where empathy and judgment carry the value.
- Cost-per-ticket is a trap as a solo metric. Klarna optimized a cost line and paid on a trust line. Pair every efficiency metric with a quality metric (CSAT on agent-handled conversations, escalation quality) from day one.
- Design the human path as a feature, not a rollback. The end state (AI floor, human ceiling, clean handoffs) is what the initial architecture should have been. Handoff isn't failure; it's the product working.
The Decision Framework: Four Questions Before You Build
Adapted from Anthropic's agent-building guidance, which is unusually candid for vendor material; its first advice is to find the simplest solution and only increase complexity when needed:
| Question | What it's really asking | If the answer is no |
|---|---|---|
| Complexity: is the task multi-step and hard to fully specify? | Could you draw the flowchart? | Build the workflow, you just drew it |
| Value: does the outcome justify higher cost and latency? | Will users wait, and will margins survive? | Use a single LLM call or a cheaper model |
| Viability: is the model actually good at this task type? | Have you tested on your real data, not the demo? | Wait, or narrow the task until it passes |
| Cost of error: can mistakes be caught and recovered? | Is there review, rollback, or a sandbox? | Do not give this task autonomy |
The fourth question does the most work. Run your product's surfaces through it and the roadmap sorts itself:
- Good first agent surfaces: support triage and resolution (high volume, recoverable, measurable), onboarding and setup assistants, data enrichment and hygiene, internal ops copilots, report drafting. Errors are visible and reversible.
- Surfaces that earn autonomy last or never: billing changes, destructive account actions, anything compliance-bound, anything that sends money or messages externally without review. These get workflows with human approval gates, indefinitely.
The Unit Economics Nobody Puts in the Deck
SaaS margins are built on near-zero marginal cost. Agents break that assumption: every interaction consumes tokens, which makes agent features a COGS line. The pricing model you wrap around them decides whether they compound or bleed.
Three economic facts to build on:
Model routing is a real lever. Current published pricing for frontier models spans roughly $1 per million input tokens at the fast tier to $5 at the top general tier, and $5 to $25 per million output tokens (Anthropic's current lineup; competitors are comparable). That's a 5x spread. An agent architecture that routes classification, extraction, and easy turns to a small model and reserves the frontier model for hard reasoning can cut serving cost by more than half with no visible quality change. This is an engineering decision with margin consequences, so make it deliberately.
The market is converging on outcome-based pricing. Look at what shipped products actually charge: Intercom prices Fin at $0.99 per outcome, so you pay when the agent resolves the conversation or completes a configured action, not per attempt. Salesforce's Agentforce bills per conversation on top of Service Cloud seats starting at $175 per user per month. The direction of travel is clear: customers increasingly expect to pay for completed work, which means you need to know your cost per completed task, not per API call, before you can price anything.
Flat seats plus unbounded agent usage is a margin time bomb. If your product charges per seat and your new agent feature has per-use cost, a power user is now a loss center. The viable patterns are metering, credits, outcome pricing, or a capped fair-use allowance, chosen before launch, because repricing after adoption is far more painful. We've broken down the full build-and-run cost structure, including the run-cost line items most quotes omit, in our AI development cost guide.
Security: Design Around the Lethal Trifecta
The "responsibly" part of adding agents is mostly one concept, and it isn't a guardrails prompt. Security researcher Simon Willison, who coined the term prompt injection, named it the lethal trifecta: an AI agent that combines
- access to private data (your customers' records, documents, messages),
- exposure to untrusted content (anything a third party could have written: emails, web pages, uploaded files, support tickets), and
- the ability to communicate externally (send email, call APIs, post webhooks)
is an exfiltration machine waiting for instructions. A poisoned support ticket or crawled webpage can tell the agent to gather sensitive data and send it out. No software vulnerability is required, because the attack is content, and LLMs cannot reliably distinguish instructions from data. Prompt injection has no general solution; anyone selling you one is selling the problem's continued existence.
The practical rules follow directly:
- Never give one agent context all three capabilities. Split them: the agent that reads untrusted content doesn't hold private-data access; the agent that holds private data can't message externally without a human gate.
- Scope tools minimally. An agent that only needs to read order status gets a
read_order_statustool, not database access. - Human approval on irreversible actions. Sending, deleting, paying, and publishing are gated: the agent drafts, and a human (or a strict policy layer) releases.
- Treat all retrieved content as attacker-controlled. Every document, email, and webpage the agent reads is input from a potential adversary, and your architecture, not your system prompt, is the defense.
- Log every tool call. When something goes wrong, the audit trail is the difference between an incident and a mystery. (If your product is also on the receiving end of other people's agents, that's a separate 2026 problem; we've covered the agentic traffic surge and what it does to your analytics and fraud exposure.)
Rollout: Shadow, Assist, Then Bounded Autonomy
Every production-agent success story we've seen (and the Klarna reversal, read in the other direction) follows the same staircase:
- Shadow mode. The agent produces answers or actions; humans still do the work. You measure agreement rate on real traffic with zero customer risk. This stage kills bad agent ideas cheaply, which is its job.
- Assist mode. The agent drafts, a human approves and sends. Throughput rises, error cost stays near zero, and every correction is training signal for your evaluation suite.
- Bounded autonomy. The agent acts alone inside an explicit scope (intents it has proven it handles, thresholds it can't exceed), with automatic escalation to humans and honest metrics: resolution rate under a strict outcome definition (Intercom's "customer confirms resolved or doesn't return" is a good template; beware vanity "deflection" numbers), CSAT split by agent-handled vs. human-handled, cost per completed task, and escalation quality.
Each promotion is earned by measurement, not by demo. Teams that skip to stage three are the ones writing the cancellation memos Gartner is counting.
How We Build This at Keplaris
Our automation and AI systems practice is deliberately workflow-first: we've written before about where automation actually pays off, and our answer to "should this be an agent?" is no more often than clients expect. A scoped workflow that ships in weeks and holds its margins beats an agent that demos well and dies in the risk review. When the four-question framework does say agent, the build order is the one above: minimal tool scope, trifecta-aware architecture, staged rollout, and cost-per-task instrumentation from the first deploy. For the broader model-and-orchestration landscape this all sits in, see our 2026 AI wave briefing.
If you're weighing an agent feature, or holding a quote that promises one in four weeks with none of the above mentioned, talk to us. We'll run your use case through the framework honestly, including the version where the right answer is a workflow at a third of the price.
Frequently asked questions
An AI agent is a system that takes a goal in natural language, plans a sequence of steps, executes them using tools (APIs, databases, code, your product's own actions), observes the results, and revises its plan, in a loop, without a human directing each step. That definition matters because much of what's marketed as an agent isn't one: Gartner estimates only about 130 of the thousands of vendors selling 'agentic AI' offer genuinely agentic capabilities, with the rest rebranding chatbots, RPA, and scripted assistants, a practice it calls agent washing. Many valuable AI features in SaaS products are actually workflows, meaning LLM steps orchestrated along paths your code controls, and that's often the better design.
Default to a workflow, and promote to an agent only when the task demands it. A workflow orchestrates LLM calls along code paths you control: predictable, debuggable, and cheaper. An agent lets the model direct its own process: flexible, but slower, costlier, and harder to test. Four questions decide it, adapted from Anthropic's agent-building guidance: Is the task genuinely multi-step and hard to fully specify in advance? Does the outcome justify higher cost and latency? Is the model actually capable at this task type? And can errors be caught and recovered from? If any answer is no, build the workflow. Most successful 'agent' features in SaaS products today are workflows with good UX.
Not because the models are too weak. Gartner attributes the projected 40%+ cancellation rate to escalating costs, unclear business value, and inadequate risk controls: mostly hype-driven proofs of concept that were never scoped for production. MIT's widely cited GenAI Divide report (the source of the '95% of pilots fail' statistic, worth reading with its methodology in mind; it's a preliminary study built on 52 interviews, 153 survey responses, and 300 public deployments) found the same pattern: failures are integration and workflow failures, a 'learning gap' between the tool and the organization, not model failures. Its most actionable finding: pilots built with external partners reached deployment roughly twice as often as internal builds.
Two cost lines matter, and most planning covers only the first. The build typically runs from tens of thousands of dollars for a scoped workflow-style feature to several hundred thousand for a production agent with tool access, evaluation, and monitoring. The second line is marginal cost: every agent interaction consumes tokens, which makes agents a COGS item in a business used to near-zero marginal cost. Current frontier model pricing spans roughly $1 to $5 per million input tokens and $5 to $25 per million output tokens depending on tier, so routing easy tasks to cheaper models is a real economic lever. Shipped products show where pricing lands: Intercom prices its Fin agent at $0.99 per resolved outcome, while Salesforce's Agentforce bills per conversation on top of Service Cloud seats.
Design around the 'lethal trifecta,' security researcher Simon Willison's name for the combination that makes agents exfiltration machines: access to private data, exposure to untrusted content, and the ability to communicate externally. Any two are manageable; all three in one agent context means a poisoned document or email can instruct the agent to steal data. Prompt injection remains unsolved, so system-prompt pleas are not a defense. Practical rules: never grant one agent context all three capabilities, scope tools minimally, require human approval for irreversible actions (sending, deleting, paying), treat everything the agent reads as attacker-controlled input, and log every tool call. Then roll out in stages: shadow mode, human-approved mode, and only then bounded autonomy with automatic escalation to humans.
Get in touch.
Whether you have questions or just want to explore what's possible, we're here to help.
