When you set out to add AI agents to a mature SaaS product, the obvious move is to build a feature: a smart button that does one impressive thing. This is the wrong instinct. The better bet is to treat agentic AI as a platform layer rather than a feature, and the discipline that makes that layer work is restraint. The hard part of a multi-agent system is rarely the agents themselves. It is the architecture around them.
That conviction shaped how we approached our first agentic capability. Instead of wiring a model call into an existing screen, we drew the system as a set of layers, each with a single job: an interface for input, an authenticated gateway, an orchestration service that choreographs the work, an agentic layer where reasoning happens, a foundation that routes requests to whichever model fits, an integration layer to the existing product, and observability running alongside all of it. The first feature is simply the first tenant of that platform. The next one reuses the layers instead of rebuilding them.
A platform earns its cost over time
A single capability does not need this much structure, and that is exactly the point of building it anyway. The roadmap behind the first feature is full of work that shares the same shape: take messy real-world input, reason over it, check it against company policy and live data, and produce an action a human can approve. If every one of those is a bespoke integration, you pay for authentication, model routing, and monitoring again and again. Build them once as platform layers and the tenth capability is far cheaper than the first. The expensive agent is the one that comes with no foundation underneath it.
We are already seeing that dividend in three ways.
The first is cost. We had been paying a specialized third-party service to pull data out of documents, and once we pointed our own multimodal agents at the same task, the cost of that workload fell by more than tenfold. We now own the pipeline instead of renting it.
The second is time. Entering the details from a quote by hand used to take about 30 minutes of careful copying. An agent now does it in roughly a minute and hands back a draft that is ready to submit.
The third, and the one that matters most for a platform, is leverage. Once the layers were in place, building the next feature and embedding these agents into other parts of the product became dramatically faster, because each one inherits the orchestration, model routing, permissions, and real-time plumbing that already exist. Every hour not spent rebuilding that foundation is an hour returned to the people using the product and the people extending it.
Restraint is a design principle
The word "multi-agent" invites a sprawl of agents handing work to one another, and that sprawl is usually a mistake. Every handoff between agents is another model round trip, more latency, and another chance for the system to drift.
We saw this clearly while building our conversational intake flow, the one that turns a request into a ready-to-submit draft order. That conversation moves through several stages: confirming who and where the request is for, gathering the item details, reviewing matching products, and assembling the order. The tempting design is to give each stage its own agent and let them pass control down the line.
We deliberately did not. Instead, a single orchestrator owns the entire conversation, and the specialized agents for policy, catalog, cart, and order are capabilities it calls rather than peers it negotiates with. They do their work, return a structured result, and never speak to the user. One voice stays in control, the behavior stays predictable, and there is one place to reason about what the product is doing.
Restraint also buys reuse. The same policy agent can badge a product during search, recheck a budget when the cart changes, and run a final compliance pass, instead of being rebuilt three times. Adding orchestration where a single well-instructed component would do is the most common way these systems become slow and hard to debug. Knowing when not to add an agent is as important as knowing how to build one.
The architecture lives in the seams
The genuinely difficult decisions in agentic SaaS are not about prompts. They are about the boundaries between parts of the system.
The first boundary is time. Putting a model in the middle of a request means you no longer know how long the work will take, so the synchronous request and response shape breaks down. The answer is to respond immediately and let the heavy work run in the background, reporting progress through real-time events so the interface stays alive while the system thinks.
State needs the same care. What the user chose should be persisted; what the organization currently is, such as budgets and policies, should reflect the latest reality so the system doesn't act on outdated information.
The existing product is the last boundary. With its permissions and business rules already enforced, it should stay the gateway to its own data rather than being bypassed for convenience.
These choices are quiet, but they are the difference between a demo and something a customer can trust.
What's next
Adding intelligence to a product is tempting to treat as a race to the most capable model. Our experience points the other way: the model is becoming a commodity you can route to and swap out, while the durable value sits in the platform around it.
That platform changes the question we get to ask. Instead of "can an agent do this one task," it becomes "what can we compose from the capabilities we already have."
The next step is more flexible, personalized workflows that adapt to how each organization operates. Over time, these workflows can become increasingly streamlined and proactive, helping teams move from submitting requests to getting things done.