AI Agent for SaaS: The Five Things It Has to Get Right

An AI agent for SaaS is an agent that works inside a software product for that product's customers: it knows who the user is, acts with that user's permissions, calls the product's own tools, and keeps working on the customer's job after the conversation ends. If it cannot do those four things, it is a help widget with a better writing style.

Most of what ranks for this topic is a list of use cases (support, onboarding, churn, expansion) or a roundup of platforms. Those lists are useful, and the better ones already say the agent should take actions rather than only answer. What they treat as a checklist line, "scope data to the correct user", is the actual design problem. Identity and permissions decide what the agent is allowed to do, and that decides whether it can do the work at all.

The second thing the lists miss is time. Your customers do not want a good answer. They want the work done, and most real work on top of a product is not one conversation. It is a job that stays open for weeks: keep every location compliant, get every new hire through onboarding. An agent that forgets the customer when the chat window closes cannot own that. So here are the five requirements, written so a product team can judge any approach against them, including ours.

Start from what the customer is buying

Foundation Capital put the shift plainly in its piece on service as software: with a tool, "customers are still responsible for using that tool to achieve the desired outcome." With a service, "responsibility for achieving the desired outcome sits with the company selling the service."

That sentence is the whole brief for an AI agent in a SaaS product. The customer bought your software to get something done. Today they do the doing: they learn the settings page, run the import, chase the colleague who never finished setup. An agent is worth building when it moves that responsibility back to you, the vendor, because you own the product, the data, and the relationship.

Every requirement below follows from that. If the agent is going to take on the customer's work, it has to be allowed to, it has to be able to, and it has to still be there tomorrow.

1. It knows who the user is

An agent inside a product is never acting for "the company". It is acting for Maya, the operations lead at one customer, with access to the Dallas and Denver locations and nothing else.

The Model Context Protocol, which many teams now use to expose product tools to agents, builds this in at the protocol level. Its authorization specification describes a protected MCP server as an OAuth 2.1 resource server and the MCP client as a client "making protected resource requests on behalf of a resource owner." The resource owner is the user. The agent borrows their identity; it does not have one of its own that outranks them.

In practice that means:

• The agent signs in as the user, through the product's normal auth, not through a shared admin key.
• Every tool call carries that user's identity, so the product's own rules apply.
• The agent can tell an admin setting up a team from a solo user and behave differently for each.

If an approach cannot tell you whose account an action ran in, it fails this test before you get to features.

2. It acts with that user's permissions, and no more

Knowing who the user is only helps if the agent is then held to what that user may do. This is where most of the risk sits.

OWASP lists Excessive Agency among its top risks for LLM applications and traces it to three root causes: excessive functionality, excessive permissions, and excessive autonomy. Its mitigation is direct: track user authorization so that actions taken on behalf of a user are executed on downstream systems in that user's context, with the least privilege needed.

The MCP security best practices make the same point from the protocol side. "Token passthrough", where a server forwards a token it was never issued, is explicitly forbidden, partly because it breaks the audit trail: logs end up showing requests from the wrong identity. The same document warns against omnibus scopes like admin:* and recommends starting with minimal scopes and elevating only when a privileged operation is actually attempted.

The standards do not finish the job for you. As Cerbos notes in its review of MCP authorization, these standards "cover authentication and token handling. They do not define fine-grained authorization," and "there is no standard slot in an OAuth token for 'this agent is acting on behalf of this user.'" Per-call decisions, like whether this user may change this location's settings, are left to whoever builds the agent.

That is an argument for the vendor building it. You already enforce those rules in your product. An agent that calls your product as the user inherits them. An agent that sits outside your product with a broad key has to reinvent them, and usually does not.

3. It uses your product's own tools, described well

An agent that can only read your help center can tell a customer how to do something. An agent that can call your product can do it.

The tools matter more than the model. Anthropic's guide to building effective agents tells teams to "carefully craft your agent-computer interface (ACI) through thorough tool documentation and testing," and adds that tool definitions deserve "just as much prompt engineering attention as your overall prompts." The same guide says agents should "gain 'ground truth' from the environment at each step", meaning they check the result of each tool call instead of assuming it worked.

For a SaaS team, that turns into a few concrete questions:

• Does the agent act through your API or MCP, so the result is real, or does it describe steps for the user to follow?
• Are the tools named and described for the jobs customers actually have, or are they a raw dump of every endpoint?
• Does it check what happened after each call, so a failed import is caught by the agent and not by the customer a week later?

How much of your product to expose, and to whom, is its own decision. We went through it in what to expose to your customers' AI agents, including why the vendor's own agent can safely do more than an assistant reaching in from outside.

4. It owns the job after the conversation ends

This is the requirement the use-case lists skip, and it is the one that separates an agent from a smarter help widget.

Take a training company running an LMS. The customer's job is not "answer my question about compliance". It is "keep every location compliant". That job has a state you can check (say, 11 of 12 locations compliant) and it slips on its own: someone new is hired, a certificate lapses, a manager ignores a reminder. The work is noticing, acting with the product's tools, looping in the right person, and doing it again next week.

An agent that only exists inside a chat session cannot do that. It has no memory of the customer's state, no reason to wake up, and no one to report to. So the fourth requirement is that the agent can take on a job per customer and keep working it:

• It holds the state of the job for each customer, not just a transcript.
• It acts when that state slips, without waiting to be asked.
• It brings people in through the systems they already use, like Slack, email or the CRM, when a decision needs a human.

We call that unit a service: a job the AI owns for each customer and keeps working. It is not a report or a scheduled run; reports and reminders are things the AI does in service of the job. The longer version is in outcome as a service.

5. Everything it does is visible and bounded

An agent that does real work in customer accounts has to be inspectable, and it has to stop.

Anthropic's guide recommends "stopping conditions (such as a maximum number of iterations) to maintain control." The MCP security guidance ties correct identity handling to accountability: if you cannot tell which client made a call as which user, incident investigation and auditing get harder. Put together, the bar for a product team is:

• Every action is attributed to a customer, a user, and a tool call.
• You can see what the agent saw, what it called, and what it delivered.
• Spend is capped per customer and per job, so a stuck loop costs a bounded amount.
• There is a clear line between what it may do alone and what needs a person to approve.

None of this is exotic. It is what you would ask of a contractor working in your customers' accounts. The agent should meet the same standard.

Judging the common approaches

Here is how the usual options score against the five requirements. This is our reading, and the honest answer for some cells is "it depends on how you build it".

Two concessions. A docs widget is fine when the question really is a question; plenty are. And an external assistant reaching your product through MCP is good for customers who want to drive the work themselves. You should support it. But it works for the customer, not for you, so it will not take on a job and keep it.

Where Aimdoc fits

Aimdoc connects securely to your product through MCP or API and to your systems (CRM, Slack, email), and delivers the work your customers need: metered, monitored and cost controlled. The agent your customers talk to, in the app, by email, or through their own AI agents, is the entry point. The services are the jobs it owns for each customer.

You pay Aimdoc in prepaid credits for the AI's work, with spend caps. What you charge your own customers for a job is yours to set, through your own Stripe account, usually as a subscription for the job. See selling services for how that works.

FAQ

What is an AI agent for SaaS?

An agent that works inside a software product on behalf of each customer. It signs in as the user, acts within that user's permissions, calls the product's own tools, and can keep working on a customer's ongoing job, not just answer one question.

How is it different from a chatbot on the help center?

A help-center bot answers from documentation and leaves the doing to the user. An agent in the product does the work through the product's API or MCP, and checks the result.

Is MCP enough to build one?

MCP gives you a standard way to expose tools and to authorize a client on behalf of a user. It does not decide fine-grained permissions or give the agent a job to own over time. Those are still yours to design.

Who should build it, the vendor or the customer?

Both will exist. Customers will bring their own assistants, and you should let them in with scoped access. The work that needs your product's full context, your permissions model, and follow-through over weeks is best done by the vendor's own agent.

Your customers want the work done, not another screen to learn. See how services let your product own that work for each customer, or start free.