Embedding AI agents in SaaS: 6 product decisions for 2026

An embedded AI agent is a task-specific agent that lives inside a SaaS product and finishes a defined job for the user, end to end, with the product's own data and the user's own permissions. An AI assistant answers and suggests while the user does the work; an embedded agent does the work and hands back a result. Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025.

That forecast puts a deadline on product teams. If your SaaS sells to companies, buyers will start to ask what the product can do without them, and a chat panel does not answer that question. This article covers the six product decisions we make before an agent goes into a SaaS interface: which job it owns, how much autonomy it gets, whose permissions it uses, where people review its work, how its actions are undone, and what it costs to run.

Why do so many agent features stall before launch?

The firm that forecasts the 40% also expects the opposite outcome for a large share of projects. 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. In the same release it estimates that only about 130 of the thousands of vendors selling agentic AI offer real agentic capability. It calls the rest "agent washing": assistants, RPA and chatbots with a new label.

All three causes are product decisions. Cost depends on how often the agent runs and how much context it reads. Business value depends on whether the job it owns is one a customer would pay to stop doing. Risk control depends on permissions, review and undo. A better model fixes none of them.

Why a chat sidebar is the wrong starting point

The quickest way to add "an agent" to a product is a chat panel wired to an LLM with a few tools. It demos well. It leaves the hard questions open: what the agent may change, where its finished work shows up, how a manager checks it, and what happens when it gets something wrong. A chat transcript is a poor record of work. It is linear, visible to one user and hard to audit. We covered the architecture side of this in AI-native vs AI bolted on. The six decisions below are the product side.

1. Which job does the agent own?

Start from one job, written as a sentence with a finish line. "Reconcile last month's card transactions against receipts and flag the ones with no match" is a job. "Help with finance" is a category. A good first job has four properties:

• A clear done state. The user can tell in seconds whether the result is right.
• Frequency. It recurs weekly or daily, so the time saved adds up.
• Bounded inputs. The data it needs already lives in the product, or behind one integration.
• Reversible outputs. A wrong result can be corrected before it reaches a customer, a bank or a regulator.

Jobs that fail the fourth test (moving money, deleting records, emailing a customer's own clients) can become agent jobs later. They start at a lower autonomy level, which is the next decision.

2. How much autonomy does it get?

Autonomy is a design choice, separate from what the model can do. Researchers at the University of Washington make this case in "Levels of Autonomy for AI Agents" (Feng, McDonald and Zhang, 2025), which defines five levels by the role the user plays: operator, collaborator, consultant, approver and observer. At the operator level the user directs and the agent executes. At the observer level the agent works alone and the user monitors.

We set the level for each action type, so one agent can sit at three levels at once. The same reconciliation agent matches transactions on its own (observer), proposes categories that a person accepts in batch (approver), and never posts a journal entry without an explicit click (operator). In the interface this becomes a small, visible setting per action type, with the cautious level as the default. Teams raise it once they trust the results, and the product records who raised it and when.

3. Whose permissions does it act with?

An embedded agent should never be able to do more than the person it works for. The safest pattern is delegated, scoped access: the agent acts on behalf of a named user, inherits that user's role, and gets a narrower scope on top for the job it owns. An agent that reconciles transactions reads the ledger and writes draft matches. It has no reason to touch billing settings or user management.

Two consequences show up in the data model. Every write carries two identities, the agent and the user it acted for, so the audit log reads "matched by the reconciliation agent for Maria Rossi". And revoking a user's access revokes their agents in the same step. The same authorization questions come back when other companies' agents call yours, which we cover in our guide to the A2A protocol.

4. Where do people review its work?

Chat output scrolls away. Agent work needs a place in the product where it waits: a review queue, an inbox of proposed changes, or a status column on the records it touched. Most of this is classic product design, and the guidance predates LLMs. Microsoft Research's 18 Guidelines for Human-AI Interaction (Amershi et al., CHI 2019) still map well onto agents. Four of them speak directly to this decision:

• Make clear what the system can do. The agent's job and limits fit in one sentence, shown where the agent is switched on.
• Support efficient correction. Approving or fixing twenty proposals takes one screen, with batch actions and keyboard shortcuts.
• Make clear why the system did what it did. Each proposal shows the evidence it used: the receipt it matched, the rule it applied.
• Scope services when in doubt. When confidence is low, the agent asks, or leaves the item for a person, rather than guessing.

Disclosure belongs here too. Article 50 of the EU AI Act, which has applied since 2 August 2026, requires providers to design AI systems that interact directly with people so that those people know they are dealing with an AI, unless that is obvious from context. How it applies to a given product is a question for legal counsel. The product answer is cheap either way: label agent-made changes as such, everywhere they appear.

5. How is an action undone?

Every action the agent takes needs a defined way back, decided before it ships. Three patterns cover most cases:

• Draft first. The agent writes a draft (an email, a journal entry, a ticket reply) and a person sends it. Undo means deleting the draft.
• Soft writes. The agent's changes are stored as a change set the user can revert in one click, with the previous values kept.
• Delayed execution. Irreversible actions wait in a short, visible window where they can be cancelled, the same pattern as undo-send in email clients.

Next to undo, keep a run log: for each run, what triggered it, which inputs it read, which actions it took and how they ended. Support reads it when a customer asks why something changed, and engineers read it when an evaluation fails. It is also the raw material for showing a buyer that the agent saves time, which answers Gartner's "unclear business value" with data from the product itself.

6. What does it cost to run, and who pays?

An assistant costs money when a user types. An agent costs money on every run, scheduled or triggered, whether anyone looks at the result or not. A nightly job across every account multiplies model calls by the size of the customer base. These are the "escalating costs" in Gartner's cancellation forecast, and they are a pricing decision as much as an engineering one.

Decide early how runs are metered (per run, per item processed, or inside a plan's allowance), set a cap per account, and show usage in the product before the invoice does. On the engineering side, keep each run's context small: the agent receives only the records the job needs. A cheaper model handles routine steps, and the expensive one is kept for the step that needs judgment.

What this looks like in practice

Take a hypothetical B2B invoicing product that wants an agent to chase overdue invoices. The six decisions become:

1. Job: every morning, find invoices more than 14 days overdue and prepare a reminder for each, in the customer's language, with the invoice attached.
2. Autonomy: approver level for the first reminder, observer level for the second once a team turns it on.
3. Permissions: read invoices and contacts, create email drafts, no access to payment settings or credit notes.
4. Review: a "Reminders to send" queue on the invoices page, one row per invoice, with the draft visible and a send-all button.
5. Undo: drafts until approved; approved emails wait ten minutes in an outbox before they leave.
6. Cost: one run per account per day, a small model for drafting, usage counted against the plan's monthly allowance.

None of this is exotic. Most of the build is queues, permissions, logs and settings, the parts of a SaaS product that already exist, and the model call is a small share of the work. That is why agent features fit best in products whose data model and roles are already clean: the agent inherits everything the product gets right, and everything it gets wrong.

Sources

• Gartner: 40% of enterprise apps will feature task-specific AI agents by 2026 (August 2025)
• Gartner: over 40% of agentic AI projects will be canceled by end of 2027 (June 2025)
• Feng, McDonald, Zhang: Levels of Autonomy for AI Agents (arXiv, 2025)
• Amershi et al.: Guidelines for Human-AI Interaction (Microsoft Research, CHI 2019)
• EU AI Act, Article 50: transparency obligations
• Cooley: EU AI Act transparency obligations take effect 2 August 2026