How to add AI to your app: four ways, compared

“Add AI to the app” is on a lot of SaaS roadmaps right now. It can mean very different things, and they cost very different amounts to build. The useful question isn’t which model to use. It’s where your users get stuck today, and what would actually get them unstuck.

Here are the four ways teams usually do it, what each is good at, and where each one stops. Each is the right answer for some products; the trick is matching it to your users.

1. A help chatbot over your docs

You point a chatbot at your help center and docs. A user asks a question, and it answers in plain words, usually with a link to the article it drew from.

Good for: “What does this setting do?”, “Do you support SSO?”, “Where do I find invoices?” Questions with an answer written down somewhere.

Where it stops: it answers, and the user does the steps. For questions, that is exactly what they need. For “set this up for me” requests, the user still follows the guide themselves, and the answers stay as current as the docs behind them.

What it costs you: low. Most help desks offer one, and setup is mostly uploading content.

2. AI features inside your product

You call a model API for specific jobs in your product: summarise this thread, draft this email, suggest tags, turn this text into a table.

Good for: jobs that are naturally about text and happen in one place. Done well, these feel like part of the product, not a bolt-on.

Where it stops: each feature is its own project, with its own prompt, UI, edge cases and evaluation. Each one helps with the job it was built for, so a user who is lost somewhere in your settings needs something else.

What it costs you: engineering time per feature, plus model costs that grow with use.

3. A copilot built on your API

You give a model a set of tools, one per action in your product (create a project, invite a teammate, change a plan), and let it pick which to call from what the user asks. This is what “function calling” or “tool use” means in model APIs.

Good for: products with a clean, complete API and a team that can keep the tool list in step with it. When it works, it’s fast, because it skips the UI entirely.

Where it stops: it can only do what you wrote a tool for. Most products have far more in the UI than in the API, and every new tool needs permissions, input checks and tests. The user sees the result rather than the steps, which is fast, though they don’t learn where the setting lives.

What it costs you: a real ongoing project. The tool list grows with your product, and someone has to own it.

4. An agent that uses your UI

The agent works in the browser, inside your app. It reads the live screen and does the steps the way a user would: opens the right page, fills in the form, changes the setting. The user watches it happen.

Good for: the “how do I…” requests that make up much of a support queue, across the whole product, without an integration per action. Because it reads the screen as it is, a redesign doesn’t break it, and the user sees where things are as it goes.

Where it stops: it’s slower than an API call, because it moves through real pages. And because it can press real buttons, it has to know when not to: anything that sends, spends or deletes should go back to the user to confirm.

What it costs you: usually a script tag and some configuration.

How Stiro does option 4

Stiro is an agent that uses your UI, built for the helper role: your users ask in plain words, typed or spoken, and it does the steps in your app while they watch.

• One script tag, nothing to train. It goes in your app’s main layout, and its key only works on the domains you list. There are no flows to record and no tools to write per action.
• It reads the live screen. When you ship a redesign, it works from what is on the page now.
• It says so when it can’t. If the app has no such feature or the record doesn’t exist, it stops, tells the user why and changes nothing.
• The user keeps the final say. Anything that sends, spends or deletes is set up and handed back for the user to press. Password, card and ID fields it recognises never leave the browser.
• Stuck goes to your team. When it can’t finish, the user can message your team or your help desk from where they are.
• It gets to know your app. It remembers what it learns, so later requests start ahead.

We tested it the hard way: cold, in three open-source apps it had never seen, with every result checked in the app’s own database.

everyday requests passed, cold, in three apps it had never seen

44 of 44

on a repeat run of the same code

43 of 44

median time from request to reply

19.5 s

How we ran that test covers the method and what it doesn’t prove.

How to choose

Start from where your users get stuck, not from the technology:

• They have questions that your docs already answer: a help chatbot.
• They do one text-heavy job over and over: an AI feature for that job.
• Your API covers what they need, and you have the team to maintain it: a copilot on your API.
• They get lost doing things in your app, across many screens: an agent that uses your UI.

1. They have questionsA help chatbot over your docs
2. One text-heavy jobAn AI feature for that job
3. Your API covers itA copilot on your API
4. Lost across screensAn agent that uses your UI

These aren’t exclusive. Plenty of products end up with a chatbot for questions and an agent for doing.

What to check, whichever you pick

• What can it touch? It should only reach what the signed-in user could reach themselves, through your app’s own permissions.
• What does it do when it can’t? “That isn’t possible here” is a good answer. Guessing, or changing the wrong record, is the worst one. Ask any vendor what happens when the request doesn’t match anything in your app.
• What happens when it’s stuck? It should hand the user to your team or help desk with the context, not leave them in a loop.
• How do you know it worked? Check results where they are stored, not in what the AI says it did. A confident “done” is easy to produce.
• What does it cost at your volume? Per seat, per message and per task pricing look very different once real users show up.

For Stiro, the answers are on the security page and the pricing page: it acts through your app’s own screens and permissions, stops and says why when it can’t, hands stuck users to your team, is checked against the database in the benchmark, and is priced per task done.

Try it in your app

If your users get lost doing things in your product, this guide walks through adding Stiro in a few minutes, and the questions teams ask first. The free plan includes 50 runs a month on localhost and a staging address, so you can see how it handles your app before your users do.