AI agents and SaaS: what a system of record has to add

AI agents will not replace the SaaS products that hold a company's records. They will replace much of the clicking: moving between screens, keying in data that exists elsewhere, sorting routine requests. The products that hold up are the ones an agent cannot route around, because they hold the truth, enforce the rules and show a person what changed and who changed it. Products that are mostly screens over someone else's data are the ones at risk.

So the useful question for a product team is not whether agents kill SaaS. It is what your product has to add so that agents work through it rather than around it. Our answer is five things: actions exposed with clear scopes, permissions that cover agents, an audit trail that tells an agent from a person, approvals at the point of consequence, and state that people and agents read the same way. Below are the argument, the evidence behind it and a self-check your team can run.

What the analysts are arguing

The "SaaSpocalypse" case says agents will soon do the tasks SaaS applications do, so the applications lose their reason to exist. Two research firms have published more careful views this year. Read them as views, not settled facts.

• IDC, 23 September 2026. In SaaSpocalypse: Catchy Title, Flawed Premise, Eric Newmark argues that enterprise SaaS applications "are not primarily task executors" but systems of record, workflow orchestrators and data governance frameworks. His summary: "AI is augmenting the system of record, not circumventing it." He also warns vendors that "if an agent cannot find your capability, your capability does not exist", and reports that 24.7% of companies in IDC's 2026 SaaS & Agent Path study plan to switch vendors outright if the next release fails to ship adequate agentic features.
• Forrester, 11 February 2026. SaaS As We Know It Is Dead takes the harder line in its title and a subtler one underneath. The enterprise core stays, while "horizontal point-solution SaaS vendors will be challenged". It gives vertical vendors that own unique or proprietary data a better chance, and notes that agentic control planes, orchestration layers and semantic data layers increasingly sit above the suites.
• Forrester, 19 August 2026. The Forrester AI Disruption Model, by Craig Le Clair and Ted Schadler, starts from the point that AI's effects will not be spread evenly, and places providers of infrastructure, data, model, integration and trust capabilities among the markets AI accelerates.

The firms arrive from different directions at a similar place. The record survives. What is in play is whether your product is where agents act, or a screen they skip. Both firms also expect seat pricing to give way to consumption and outcome pricing; that is a separate decision, and our piece on AI feature billing and usage UX covers how it shows up in the product.

What stays with the product, and what moves to agents

Split the jobs a SaaS product does into two kinds. Some are about the interface. Some are about the record.

The left column is why IDC can call the record durable. The right column is why Forrester can say agents will erode the remit of current enterprise applications. Both hold at once, and a product plan has to serve both.

A quick test for any feature: if an agent did this job through an action instead of the screen, would the business lose anything except the screen? If not, the feature is clicking, and agents will take it. If the answer is "we would lose the rule, the record or the trail", that feature is the product, and it is where to invest.

Which products are exposed, and which hold up

This is our reading, combining the analysts' views with what we see in B2B workflow products.

More exposed:

• Thin task tools whose value is a better screen over data held somewhere else. An agent can go to the source.
• Horizontal point tools with shallow workflows and low switching costs, the group Forrester names.
• Products whose main job is moving information between two other systems. An agent with access to both ends can do the move.

Holding up better:

• Products that are the authoritative record for something that matters: money, people, contracts, regulated cases.
• Products that enforce rules a business must be able to prove it followed.
• Vertical products with proprietary data and domain workflows, which Forrester expects to fare better.
• Products where several people and teams coordinate around shared state.

Timing will differ by market. IDC's framework names contact centre, HCM and supply chain among its "Agentic Leaders" and puts ERP among its "Structural Laggards".

Holding the record is necessary, but it is not enough. A system of record that agents cannot discover, or cannot act through safely, will watch work move to whatever layer sits above it. That is the design problem the rest of this page addresses.

How agents reach your product now

Agents reach a product in two ways: by operating its screens as a person would, or by calling actions the product exposes. Screen operation works, but it is fragile. We tested it in what we saw when an AI agent operated a SaaS admin screen, and most of the fixes turned out to be accessibility work. Exposed actions are sturdier, and the Model Context Protocol (MCP) has become a common way to offer them.

With MCP, your product runs a server that offers tools (functions the model can call), resources (data for context) and prompts. The points in the current specification, version 2026-07-28, that matter most for a product team:

• The model chooses when to call a tool. The specification says there SHOULD always be a human in the loop with the ability to deny tool invocations, but that interface belongs to the host application, which is not yours.
• Descriptive hints are not a control. Clients must treat tool annotations as untrusted unless they come from a trusted server, so a label saying an action is safe protects nothing on its own.
• Access is scoped. The authorisation section builds on OAuth 2.1. Servers should state the scopes an operation needs, following the principle of least privilege, and can answer with an insufficient_scope error that prompts the client to request more (step-up authorisation). Servers must check that a token was issued for them and must not accept or pass on any other token.
• What a caller sees can depend on its rights. The tool list a server returns may vary by the authorisation presented, so a caller with read scopes need not see write tools at all.
• The server carries the safety duties. Servers must validate every tool input, implement access controls and rate-limit invocations. Clients should log tool usage for audit, which leaves your own record of who did what as the one you control.

The consequence for design: the assistant may or may not ask a person before it acts. Your product is the only party in the chain that can guarantee its own rules hold. The OWASP GenAI Security Project names this complete mediation in its entry on Excessive Agency: implement authorisation in downstream systems rather than relying on a language model to decide whether an action is allowed.

Products that hold records are already moving this way. Two examples, cited as examples and not endorsements:

• Atlassian's Rovo MCP server lets MCP clients act in Jira, Confluence and Compass with the user's existing permissions, connected through an OAuth 2.1 consent screen. Admins control which tools can connect, and Atlassian's guidance is to use least privilege and review high-impact changes before confirming.
• Workday announced an Agent System of Record in February 2025, to onboard AI agents, define their roles and responsibilities, track their impact and cost, and manage agents from Workday and third parties alike, with access controls and policy enforcement.

Both treat agents as participants the record has to know about, not as a new kind of screen. If you are also deciding how much of your interface to bring into the assistant itself, our piece on MCP apps for SaaS covers that boundary.

Five things a system of record has to add

1. Expose business actions, not screens

Design actions around the verbs of the work: approve an invoice, reassign a case, attach a listing to a deal. A generic update call that accepts any field hands the agent your whole data model and none of your rules. Give each action a clear name, an input schema, a plain description of what it changes and the scope it needs.

Split reading from writing, and reversible writes from irreversible ones, so that customers can grant them separately. Offer a search action alongside every create action, because agents, like people, make duplicates when the only path is to create. Return structured results, and return errors that name the business rule that blocked the action, such as an amount above the approver's limit. MCP separates tool execution errors, which a model can use to correct itself, from protocol errors, and the first kind is where your rules should speak.

2. Extend the permission model to agents

The standards already draw the line that matters. RFC 8693, the OAuth token exchange standard, separates impersonation, where the acting party is indistinguishable from the person, from delegation, where it keeps its own identity and acts on that person's behalf. For agents, delegation is the safer default.

In product terms, that means agents become a kind of principal in your role model, not a shared login. An agent's grant can be narrower than its user's role: fewer actions, fewer records, value limits, rate limits and an expiry date. A customer must be able to revoke one agent without touching the person it works for, and see which agents hold which grants. Expect your customers' IT administrators to review this side closely; the controls they look for are set out in a checklist of admin console controls for AI agents.

3. Record who acted, for whom, and on what instruction

Every change should record the person, the agent if there was one, the delegation that let it act, the action it called and when. Where you can store it, keep the instruction or task the agent was working on. RFC 8693's act (actor) claim is one standard way to carry "this agent, acting for this person" in a token, so the record does not have to guess.

Then show it in the product, not only in a log export. A history view where agent changes look the same as human ones fails the people who have to trust the record. We designed this distinction for Omny, an AI platform for Amazon brands and agencies: each line of a listing showed who wrote it, in one colour for the AI's work and another for a person's, and no AI text entered the listing until someone picked it. The same principle carries over to a record that agents act on.

4. Put approvals where the consequence is

Decide approval by consequence, not by actor. Moving money, deleting data, sending a message outside the company, changing a permission and any other step that cannot be undone are candidates. OWASP's guidance on Excessive Agency is to require a human to approve high-impact actions before they are taken.

Make the approval a state in your record, not a dialogue in someone else's assistant. The agent proposes; the record holds a pending change; a named person approves it with the change in front of them. MCP leaves confirmation prompts to the host, and a host may not show one, so the hold has to live where the rule lives. Design the approval view so a reviewer can decide in one look: what will change, which agent proposed it, on whose behalf, and which rule triggered the hold. Allow grouped approval for low-risk bulk changes, or reviewers will start approving without reading.

5. Keep one state that people and agents read the same way

People read your product through screens. Agents read it through actions and resources. If status logic lives only in the interface, such as an "overdue" badge computed in the front end, the agent sees a different product from the one your users see.

Put status, ownership, due dates and locks in the domain model, and expose the same values through your actions. Show pending agent proposals in the screens people use, so nobody is surprised by a change already queued. Guard against an agent and a person editing the same record at once, with version checks or locks, so that neither overwrites the other silently. MCP's guidance on stateful tools makes a matching point: when a server hands out a handle to state, it should check the caller's authorisation against that handle on every call.

A self-check for your product team

Answer yes or no. Each no marks a place where agents are likely to work around your product, or where a customer's security review is likely to stop.

1. Can you list the business actions an agent can take in your product, each with its scope?
2. Can an agent search for a record before it creates one?
3. Do your errors name the rule that blocked an action?
4. Does an agent have its own identity in your permission model, separate from its user?
5. Can a customer grant an agent narrower rights than the person it works for, and revoke them on their own?
6. Does every change record whether a person or an agent made it, and on whose behalf?
7. Can a person see agent changes in the product's own history view, not only in an export?
8. Are approval rules set by consequence and enforced by your product, not by the assistant?
9. Does an agent see the same status, owner and history a person sees on screen?
10. Can an agent find your capabilities at all, through a documented set of actions?

Where to start

We would sequence the work by risk. Start with read actions and the audit trail: they carry little risk, and they show customers that agent activity will be visible. Next, extend the permission model so that agents are principals with their own grants. Then expose write actions, beginning with reversible ones, with approvals in place for anything that is not. Widen from there as you see how customers use it.

Start with the hand-offs your record already coordinates, because that is where agents will first try to act. This is the core of our work on B2B SaaS workflow software, and the agent side of it is what we design in AI copilots and agents. If your team is earlier in the journey, adding AI features before opening the product to agents, our guide on how to add AI to an existing SaaS product covers what to fix first.