Embedded AI assistants for SaaS: what they are and how to choose one

What is an embedded AI assistant?

An embedded AI assistant is an AI agent that runs inside a software product's own screens, knows how that product works, and can act for the signed-in user. The test of one is whether a user can say what they want done and watch it happen in the product they already have open.

The pattern it replaces is the help widget in the corner. Ask a billing tool how to issue a partial refund and you get a tidy list of seven steps, which you then perform yourself, in order, by hand. An assistant that can act reads the page, fills in the form, calls your API as the user, and stops for a yes before anything risky.

The cost it removes has a name. We call it the interface tax: the distance between deciding and done, paid in clicks. This guide skips the case for paying less of it and goes straight to the buying decision, which is where the vocabulary gets slippery.

What is copilot-as-a-service?

Copilot-as-a-service means buying the assistant as a managed product instead of building it from parts. The vendor supplies the chat interface, the agent runtime, the permission controls and the knowledge layer; you supply your product, your API and the decisions about what the assistant may do.

The label is a category nickname with no standard behind it. Nobody certifies what is inside, and vendors apply it to anything from a React chat component to a managed agent platform. That looseness is the reason this guide exists. Treat the phrase as a question to put to a vendor: which of the layers below do I still own?

How an embedded assistant works inside a SaaS product

Every embedded assistant, whatever it is sold as, is five layers stacked in the same order.

1. UI surface

   Where the conversation appears: a corner widget, a sidebar, a command palette, a full page, or an interface you build yourself on a headless API.

2. Runtime

   Runs the agent loop. It calls the model, runs tools, streams the reply, pauses for approvals and keeps the conversation state.

3. Knowledge

   What the agent knows about your product: docs, the page in front of the user, live data from your API. This is the layer that goes stale.

4. Actions

   The operations it can perform: API calls, form fills, navigation. Each one has a schema that limits what the model can ask for.

5. Identity and permissions

   Who the assistant acts as, what it may attempt, and who has to say yes first.

Read in order, it doubles as a build list, because every product on the market covers one stretch of it and leaves you the rest. Component kits usually cover the first layer. Toolkits reach into the second. Support agents cover knowledge and a few actions, inside a channel they own. No demo lingers on the last layer, identity and permissions, and that is where most of the real risk lives.

That layer deserves a name, because the rest of this guide leans on it. Call it the keys question: when the assistant acts, whose keys is it holding? A service account with broad access, a token your backend mints, or the signed-in user's own session. The answer decides how much of your authorization logic the assistant can route around by accident.

The five kinds of product sold as embedded AI assistants

The five kinds are UI component kits, agent toolkits, hosted bot builders with web widgets, support agents and full-stack embedded agents. These are tendencies, and individual products cross the lines. The useful column is the third one: what you still build.

A team with an agent backend and a design system should read the first row as the right answer. A team that has neither should notice how much of the third column is the unglamorous part: identity, approvals and state that survives a restart.

How to choose: eight questions to ask every vendor

Ask every candidate eight questions: can it act, whose identity it acts as, who approves risky actions, whether a conversation survives a closed tab or a deploy, how knowledge stays current, whether you can switch models, who pays for inference, and what UI ships. Put them to every candidate, including us. Questions two and three are the ones whose wrong answers you tend to find out about in production, so weight them accordingly.

Judge each candidate by what you would still have to build. A product that answers four of these questions with "you build that" can still be the right call, as the next section explains, provided you chose it on purpose.

Embedded AI assistant options in the market, by type

The list is unranked and alphabetical within each type. Each line comes from the vendor's own site or documentation, and where a line says what something is built for, that is the vendor's positioning. The last group has a single entry because Teaflask is the example of that kind that we know best, and we make it. Read that row as an illustration of the category, not a ranking within it.

Questions buyers ask

Where to go next

If Teaflask is on your shortlist, start with these four. The two docs pages carry the detail behind every Teaflask answer in the checklist above.

• How Teaflask works

  Where the agent runs, and what goes into your frontend.

• Grounding and verification

  How docs and actions are drafted from your repo and re-checked as code changes.

• Architecture and durable turns

  Where each part runs, how a turn survives a deploy, and the trust model.

• Pricing

  The free plan is the full platform; the only bill is the model.