Agent infrastructure
Platform integration
Simplified AI sounds friendly, but most framings hide real complexity. Where it actually lives in enterprise SaaS agent projects.
The phrase "simplified AI" gets used to sell a lot of things. Drag-and-drop builders. No-code agent canvases. One-click model swaps. Most of it solves the easy half of the problem — the part where a model talks to a chat window — and leaves the hard half untouched. The hard half is the layer where an agent has to act on a real product, with real permissions, against real APIs that were never designed for it.
Pontil's view: simplifying AI for established B2B SaaS doesn't mean hiding complexity behind a friendlier UI. It means removing the structural work that's actually stalling agent projects — generating the tools agents need against the APIs that already exist, running them under the right user, and keeping them current as products change.
This piece walks through five things. What "simplified AI" tends to mean in the market today. Why that framing misses the real complexity in established SaaS. Where the complexity actually lives. What a genuinely simpler architecture looks like. And how to tell the difference between a tool that simplifies and one that just defers the cost.
Walk through any vendor landing page using the phrase and you'll see a pattern. Simplified AI tends to mean one of four things.
The first is a visual builder. A canvas where you drag nodes representing prompts, retrieval steps, and tool calls. n8n, Zapier, and a wave of newer agent canvases sit here. These are useful for prototyping and for workflows that string together pre-built integrations. They're not useful when the integration you need doesn't exist yet.
The second is a model-routing abstraction. LiteLLM and similar tools let you swap between Anthropic, OpenAI, and Google with one config change. Real engineering value, but it simplifies the wrong layer. Choosing a model is rarely what's blocking an enterprise agent project.
The third is an agent framework with batteries included. LangChain, CrewAI, and LlamaIndex bundle memory, planning, retrieval, and tool-calling into something you can pip install and run a demo with in an afternoon. The demo always works. The production deployment is where most of these projects discover that orchestration was never the bottleneck.
The fourth is a vertical AI product — a customer-support agent, a sales-research agent, a coding agent — sold as a finished thing. Simple to buy. Simple to evaluate. Not relevant if your job is to build agents on your own platform.
None of these are bad. They're all real products solving real problems. But for an established B2B SaaS company with multiple products and APIs that were built for the UI, none of them simplify the part of the project that actually stalls. We've written before about why orchestrator-first thinking keeps producing dead ends — the same pattern shows up under the "simplified AI" label.
The complexity in an enterprise SaaS agent project doesn't live in the model, the canvas, or the framework. It lives in the gap between what the product can do and what its API exposes.
Most mature SaaS products were built for the UI first. Years of features shipped through web forms, modals, and bulk actions. APIs kept up with some of it — usually the parts that customers explicitly asked for as integration points. The rest stayed inside the application. Based on what we've seen across customer engagements, the gap is large — often only a small fraction of product capability is reachable through the public API. We've argued the point at length — the exact number isn't the point, the structural shape is.
This is what makes "simplified AI" framings frustrating for the teams who actually need help. A drag-and-drop canvas doesn't help when the node you need to drag — "reassign a workspace owner across these 14 conditions" — doesn't exist as an API. A model-routing layer doesn't help when the model can't reach the action either way. An agent framework doesn't help when the framework's tools=[] array stays empty because nobody on the team has time to hand-write 200 tool wrappers.
The complexity is structural, not surface-level. Hiding it under a friendlier interface doesn't reduce it — it just moves who pays the cost. The vendor's canvas looks simple; the customer's engineering team still spends a year-plus writing connectors.
If you want to simplify AI in a way that matters for established SaaS, you have to be specific about which complexity you're attacking. There are five distinct layers, and they're not interchangeable.
The tools layer is where the multi-year work hides. Not because tool-calling as a protocol is hard — Model Context Protocol (MCP) and the Responses API both provide standard ways to expose tools to models — but because generating, running, and maintaining the tools themselves is the work nobody else does for you.
Generating a tool means turning a capability that exists somewhere in your product into a callable surface an agent can use. If the API exposes it, that's a thin wrapper. If the API doesn't, that's a real engineering project — and most of your product is in the second bucket. Running a tool means executing it reliably, under the right user, with the right rate limits, error handling, and audit trail. Maintaining a tool means catching it when the underlying product changes — a renamed field, a deprecated endpoint, a new required parameter — before the agent silently fails in production.
This is the complexity that needs simplifying. Everything else is downstream of it.
The simpler architecture isn't a prettier canvas. It's removing the work that was making the project unfundable.
Three things have to change.
First, tool generation has to operate on the codebase, not on the API alone. If you're limited to what your OpenAPI spec describes, you're limited to the public surface. Generation has to read the source of truth — the actual application code — and produce callable tools for the capabilities that live there. This is the difference between an SDK generator (works from a spec) and a tools platform (works from the system).
Second, tools have to run as the authenticated user. Service-account architectures are the default for traditional integrations, and they're the wrong default for agents. An agent acting as a shared service account sees everything any user can see, takes actions no audit log can attribute, and breaks every permission boundary your product has spent years getting right. The runtime needs to honour the real identity end to end.
Third, maintenance has to be automated and aligned with your SDLC. Tools that drift silently when the product changes are worse than no tools — they produce confident wrong answers. The maintenance loop needs to live in CI, run on every change to the relevant code paths, and catch regressions before the agent does.
This is what we mean by Tools-as-a-Service. Not a canvas. Not a model wrapper. A layer that generates the tools agents need against your existing systems, runs them under the right user, and keeps them current. The reader's experience is simpler because the structural work has been removed — not because it's been hidden behind a graphic.
There's a useful comparison in our piece on agent project stalls — the projects that get unblocked aren't the ones that picked a friendlier orchestrator. They're the ones that stopped trying to solve the tools-layer problem by hand.
The market is full of "simplified AI" claims. Most of them defer cost rather than remove it. Here's how to tell which is which.
Ask where the integration work actually goes. If the answer is "your team writes a connector for each product, just in our nicer SDK," the cost hasn't been simplified — it's been re-skinned. The compounding maintenance burden, which we've mapped out in detail, is still entirely on you.
Ask what happens when the underlying product changes. If the tools have to be manually updated, you've bought a momentary simplification that will get more expensive every quarter. If the platform detects the change and updates the tool, the simplification compounds.
Ask how the agent authenticates against the underlying product. If the runtime uses a shared service account or a pooled credential, you've inherited a permissions and audit problem that will surface in security review. If the runtime executes as the user who triggered the agent, the simplification is real — the existing permission model does the work it was built for.
Ask what the proof of concept costs to scale. A POC that took two weeks but takes a year-plus to roll out across the product portfolio isn't simplified. It's a deferred bill. The honest question is whether the architecture lets the second, third, and tenth product onboard at a fraction of the cost of the first — or whether each one is roughly the same lift.
These four questions cut through most of the "simplified AI" claims in the market. The ones that survive them are doing something structural. The ones that don't are selling a friendlier interface to the same long project.
Pontil is the Tools-as-a-Service layer for established B2B SaaS companies whose APIs were built for the UI and now can't keep up with what their agents need to do. We generate tools from your existing codebase — not from a spec, and not by hand — run them as the authenticated user, and keep them current as the product changes.
The practical effect is that the part of the project most teams think of as the multi-year blocker stops being one. The complexity hasn't been hidden. It's been removed. Engineering time goes back to the things that genuinely need engineering judgement.
If you're sizing up the work and want to see how the generation and runtime behave against a real product surface, the demo walks through both.
It's worth asking what "simple" looks like on the other side of this. When generating, running, and maintaining tools stops being the part that consumes the project, the rest of the agent stack gets to do what it was designed for. The orchestrator can orchestrate. The model can reason. The product team can ship the capability instead of arguing about which 12 features make the API-rewrite cut.
The harder thing to predict is what happens next. Once an agent can actually reach the full surface of your product, the questions shift from "can we build this?" to "which workflows are worth automating, and which ones are we comfortable letting an agent run end-to-end?" Those are good problems. They're the ones the product team should have been solving all along.
Simplified AI, in the sense that matters for established SaaS, isn't a smoother surface over the same long project. It's removing the work that was making the project unfundable — and getting back to the part of the job that was always the point.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
