How to add an AI agent to your SaaS product

An in-app AI agent lets your customers ask for what they want in plain language and have it done inside your product. Build it on your own API, give it exactly the access of the signed-in user, require approval before it changes data, and log every action. Expose the same capabilities as an MCP server so customers can also use them from Claude, ChatGPT and other assistants.

What is the difference between an AI chatbot and an in-app agent?

A chatbot answers questions about your product. An in-app agent uses your product: it creates records, updates fields, builds the report, sets up the automation. That is far more useful and far riskier, which is why permissions and approvals are the core of the design, not an afterthought.

How should an in-app agent get its permissions?

From the user who is asking. The agent calls your API with that user's session or token, so it can do exactly what that user could do in the interface, and nothing more. Our team builds in-app agents this way: every action is scoped to the signed-in user, with the same access as that user's own API calls, and writes are gated by human approval.

Should you build an MCP server?

Probably, and soon. The Model Context Protocol is the open standard assistants like Claude and ChatGPT use to connect to tools. An MCP server lets your customers use your product from the assistant they already work in, with their own login. Your in-app agent and your MCP server can share the same set of tools, so you build the capability once. Our team has built MCP servers both for internal use and for customers to connect to.

What should the agent do first?

Pick jobs that are tedious in your interface and easy to verify:

• Bulk changes ("move all overdue tasks for Acme to next week").
• Setup work ("create a project like last quarter's, with these people").
• Finding things ("which customers haven't logged in for 30 days?").
• Drafting content from data already in the product.

Avoid destructive actions (deleting, sending to customers, billing changes) until the approval flow is proven.

How do approvals work inside a product?

Show the proposed change as a preview: what will be created or changed, on which records, with a clear Approve or Cancel. For larger jobs, show a queue of proposed actions the user can approve one by one or all at once. Our team has built customer-facing approval flows where customers approved, denied or requested changes on everything an agent produced before it went live. More in human in the loop AI agents.

What breaks in production?

• Too many tools. An agent with 80 loosely described tools picks the wrong one. Fewer, well-named tools with clear descriptions work better.
• Rules in the prompt. Long lists of instructions stop being followed reliably. Put limits and permissions in code.
• No evaluation set. Without a few hundred real requests to test against, every change is a guess.
• Cost surprises. Long conversations that re-read large records get expensive. Plan for context limits and caching.

How long does it take?

A first version on a few well-chosen tools, with user-scoped permissions and approvals, can be in front of early-access customers in weeks. A broad agent across the whole product is a roadmap, built tool by tool based on what customers actually ask for.

Common questions

Should we build our own agent or embed a vendor's?

Build when the agent's value is acting inside your product with your rules. Vendor widgets suit help-center answers, not actions.

Which model should we use?

Choose by testing a few on your own evaluation set. Keep the model swappable; it will change.

Do customers trust agents that change their data?

They do when they can preview changes, approve them and undo them. Trust grows with a visible log.