AI applications in enterprise SaaS: why most can't reach their own products

An AI application is software that uses a foundation model to reason, plan, and act on behalf of a user. In enterprise SaaS, that last word — act — is where the trouble starts. Reasoning is cheap now. Acting on the product the customer actually pays for is the part nobody has solved at scale.

Most AI applications shipped by established SaaS vendors today are reasoning wrappers. They summarise, draft, and answer. The moment a user asks one to do something — update the pipeline stage, reconcile the invoice, reassign the ticket, push the deploy — the application hits a wall. Not a model wall. An access wall. The product can do the thing through its UI. The API can't.

This piece argues that the defining technical question for enterprise AI applications in 2026 is no longer "which model?" but "can the application reach the product?" We'll look at what an AI application actually has to do in production, why the integration layer breaks first, what agent-ready applications look like in practice, and the three paths SaaS companies are taking to get there.

The shape of an AI application has changed

For roughly two years, "AI application" mostly meant a chat surface bolted onto a SaaS product. Sidebar, modal, command palette. The user typed; the model answered. Useful, sometimes. But the application's job ended at the response.

That's not what enterprise buyers want any more. The current generation of AI applications is expected to take action: complete the task, file the record, run the workflow. The model is the easy part. The hard part is the application's ability to invoke the right operation, with the right permissions, against the product the customer is paying for.

This shift changes what the application is. It's no longer a UI feature. It's an autonomous (or semi-autonomous) operator that needs the same surface area a power user has — and ideally more, because the point of automation is to do things at machine scale. A pipeline-management AI application that can read opportunities but can't update them is, commercially, a demo.

The gap between read and write is where most enterprise AI applications are stuck. Reading usually works because reporting APIs were built years ago for analytics and BI tools. Writing — the actions a user takes through the UI dozens of times a day — frequently has no programmatic equivalent. We covered the structural reason for this in APIs expose 2% of what your product can do: products were built UI-first, the API caught up with the obvious bits, and the rest never made it.

What an AI application actually has to do in production

Strip away the chat interface and an AI application in production has four jobs:

1. Understand intent. Map a user request to one or more concrete operations. The foundation model handles this — Anthropic, OpenAI, and others have made this part roughly solved for most enterprise tasks.
2. Find the right tool. Locate, among the operations the application has access to, the one that matches the intent. This is a catalogue and discovery problem.
3. Invoke it as the user. Run the operation with the authenticated user's permissions, against their data, with the right audit trail.
4. Handle what comes back. Parse the response, recover from failure, retry sensibly, surface errors that mean something to the user.

Jobs 1 and 4 are well-served by the agent framework layer (LangChain, CrewAI, the OpenAI Agents SDK, Anthropic's tool-use APIs). Lots of good options. Job 2 is partly solved by the Model Context Protocol (MCP) and similar discovery mechanisms.

Job 3 is where AI applications die. Invoking an operation as the authenticated user — with their permissions, their tenant, their audit trail — requires that the operation exist as a callable thing in the first place. For enterprise SaaS products with twenty years of UI-first development behind them, most of what users do isn't callable. It's clickable.

This is why a lot of enterprise AI application demos use service accounts. A service account has god-mode access; it can do anything. But shipping a production AI application on a service account is a security posture nobody's compliance team will sign. Permissions get flattened, audit trails get muddled, and one prompt-injection incident ends the project.

Why integration is the bottleneck, not the model

There's a popular framing that says: AI applications are limited by model capability. Better models, better applications. It's wrong, or at least it's been wrong for the past year.

Frontier models are now substantially more capable than the integration layer they sit on top of. Claude and GPT-class models can reason about multi-step workflows, decompose ambiguous requests, and self-correct when a tool call fails. What they can't do is invent an operation that doesn't exist. If the underlying SaaS product can't expose "reassign ticket and notify previous owner" as a callable operation, no amount of model improvement helps.

This is the substance behind the 2025 MuleSoft Connectivity Benchmark figure that 95% of organisations face challenges integrating AI into existing processes, with data integration cited by 80% of respondents as a top blocker. The model isn't the constraint. The plumbing is.

For SaaS companies building AI applications on top of their own products, the problem is doubly acute. The internal API surface was built for the product team's own roadmap, not for an autonomous operator that needs to do everything a user can do. So the application team — often a sibling team or an AI-focused squad — ends up filing tickets to platform teams asking for endpoints. The platform team has its own roadmap. Months pass. The agent project stalls at the same point most agent projects stall: not at the model, at the surface.

The two responses that don't work at scale

When a SaaS company hits this wall, two responses are common. Both fail at portfolio scale.

Rewrite the API layer. Build a comprehensive, agent-friendly API for the entire product. Two to five years, depending on product complexity. By the time it ships, the AI application market has moved twice. No CFO funds this voluntarily.

Build bespoke connectors per product. Hand-write tool definitions for each SaaS product in the portfolio, wrapping whatever APIs do exist and filling gaps with brittle workarounds. This works for one product. It compounds badly across five. We mapped the full cost in the hidden cost of bespoke agent connectors — the short version is that maintenance grows faster than the value any individual connector delivers.

A third response — wait for the foundation model providers to solve it — is a real strategy some teams are taking. It's a bet that Anthropic, OpenAI, or Google will ship a universal connector layer that makes the access problem disappear. Possible. Not something to plan a 2026 product roadmap around.

What agent-ready AI applications look like

An AI application is agent-ready when it can take action on the product it serves with the same fidelity a human user would, under the user's own identity. Concretely, that means four properties:

Coverage. The application can invoke the operations users actually perform — not just the subset that happens to have a documented endpoint. If the UI can do it, the application can do it.

Identity preservation. Operations execute as the authenticated user, not a shared service account. Permissions, data scoping, and audit trails are honoured. This matters for compliance and for the simple reason that an AI application that can do more than the user invoking it is a security incident waiting to happen.

Maintenance under change. When the underlying product ships a new version of an operation — new field, renamed parameter, deprecated endpoint — the application doesn't silently break. The tool layer is part of the SDLC: tested in CI, observed in production, updated alongside the code that backs it.

Composability. Operations can be combined into higher-level actions when that's what the application needs, with human-in-the-loop oversight for sensitive combinations. "Close the deal" is a sequence of underlying operations; the application should be able to express it as one.

Real AI applications hit these properties unevenly. Most do well on identity and coverage for the operations they explicitly built for, and badly on maintenance — the failure mode is a tool that worked in QA, broke after a routine product release, and nobody noticed for two weeks. We dug into the technical pattern in why AI agents fail in production.

A note on what "agent-ready" doesn't mean

It doesn't mean MCP-compliant. MCP is a useful protocol; it's not a substitute for having tools in the first place. An MCP server that exposes a thin set of underlying APIs gives you a thin AI application with a fashionable wrapper.

It doesn't mean having a chat sidebar. The chat sidebar is a UI choice. Plenty of agent-ready AI applications have no conversational interface at all — they're triggered by events, scheduled jobs, or other applications.

It doesn't mean using the latest foundation model. Model capability is necessary but not sufficient. A GPT-5-class model with a 2% tool surface is still a 2% AI application.

Three paths SaaS companies are taking

In conversations with engineering and product leaders at established SaaS companies over the past year, three patterns emerge for how they're getting AI applications past the integration wall.

Path 1: Vertical investment in one product. Pick the flagship product, fund a multi-year API rebuild, ship a flagship AI application on top of it. This works when the company has one dominant product line and the strategic clarity to bet on it. Doesn't work for portfolio companies with five or fifty products, where the same investment would take a decade.

Path 2: Bespoke connectors with a tooling team. Stand up a small team — usually three to six engineers — whose job is to build and maintain agent connectors for the company's own products. Reasonable for the first eighteen months. After that, the team is so consumed by maintenance that new connector work slows to a crawl, and any change to an underlying product creates a ticket queue.

Path 3: Tools-as-a-Service. Use a platform that generates tool definitions from the product's existing codebase, runs those tools as the authenticated user, and keeps them current as the product evolves. This is the category Pontil sits in. It works against the APIs and code that already exist, so it doesn't require an API rewrite, and it amortises maintenance across the platform rather than across each product team. We've written more about this approach in API modernisation for agents: build, buy, or wait.

None of these paths is purely better. Path 1 produces a deeper integration than path 3 for the one product that gets the investment. Path 2 gives the team complete control over the tool definitions, which matters for products with unusual semantics. Path 3 trades some of that control for the ability to cover a portfolio without a rewrite. The right answer depends on portfolio shape, timeline, and how much rebuild appetite the company has.

What doesn't depend on the path: the requirement that AI applications eventually need to act, not just answer. Every SaaS company will hit this wall. The variance is in when, and in how prepared they are when they do.

How Pontil fits

Pontil is a Tools-as-a-Service platform. We make SaaS products accessible to AI agents by generating tool definitions from the codebase that already runs the product, executing those tools as the authenticated user, and keeping them current as the product changes. That's path 3 above — and it's the path designed for companies whose AI applications have to reach across multiple products without funding a multi-year API rewrite for each one.

The access problem this article describes is the one Pontil exists to close. If the question on your roadmap is "how do we get our AI applications past the demo and into production?" we'd find a conversation useful, even if Pontil ends up not being the right fit. The shape of the problem is consistent across the companies we talk to; the right answer isn't always the same.

Where does this go in the next eighteen months?

The interesting question isn't whether enterprise SaaS will solve the AI application access problem — it has to, the commercial pressure is too high. The question is how the solution distributes.

One scenario: foundation model providers absorb the integration layer. Anthropic or OpenAI ships a universal connector platform, every SaaS product publishes to it, and the access problem becomes a protocol problem. Possible. The track record of large platform plays from foundation model providers in adjacent layers is mixed.

Another scenario: the tools layer becomes its own category, the way the API gateway category emerged in the 2010s. SaaS companies pick a Tools-as-a-Service platform the same way they currently pick a database or an observability vendor. The platforms compete on coverage, maintenance automation, identity handling, and ecosystem fit.

A third scenario: nothing converges, and every SaaS company ends up running its own bespoke tooling team in perpetuity. MuleSoft's 2025 Connectivity Benchmark put the cost of integration challenges in the millions of dollars per organisation per year in lost productivity and delayed projects — which suggests this is what enterprises already tolerate for traditional integration, so a continuation of the pattern isn't far-fetched. It's also expensive enough that it creates the demand for the second scenario.

Whichever scenario plays out, the underlying truth doesn't change: an AI application is only as capable as the surface it can reach. The companies that figure out how to expose their products to agents — fully, safely, and under the user's identity — will ship AI applications that do real work. The ones that don't will keep shipping reasoning wrappers and watching their competitors win the deals where the buyer asks what the agent can actually do.