Agentic AI Architecture for Enterprise SaaS

Key facts, with sources

• Gartner predicts over 40 percent of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. (Gartner)
• Gartner predicts 33 percent of enterprise software applications will include agentic AI by 2028, up from less than 1 percent in 2024. (Gartner)
• Gartner estimates only about 130 of the thousands of vendors claiming to sell agentic AI are real, with the rest engaged in agent washing of existing chatbots and RPA products. (MarTech)
• McKinsey's State of AI 2025 found 23 percent of organizations are scaling an agentic AI system somewhere in the enterprise and another 39 percent have begun experimenting with agents. (McKinsey)
• Gartner forecasts 40 percent of enterprise applications will embed task-specific AI agents by the end of 2026, up from under 5 percent in 2025. (Joget)

Put the agent behind your service layer, not beside it

The biggest architectural mistake I see in audits is giving the agent its own privileged data path — a service account with broad database access "so the model can be flexible." That one decision undoes years of authorization work. The pattern that survives security review is boring: the agent is a client of your existing service layer. Every tool it can call maps to a service method that already enforces row-level security, rate limits, and validation for your web and mobile clients.

Practically, I deploy the agent loop as its own stateless service that holds a session token, calls internal APIs with that token, and streams progress back over a websocket or SSE. Nothing about your data model changes. If a tool needs a capability your API does not expose, that is a signal to build the endpoint properly — with authorization — rather than to hand the model a database connection.

Tenant isolation: bind tools to the session, not the prompt

Never let the model supply identifiers that control data scope. If a tool signature accepts tenant_id as a model-filled parameter, a prompt injection hidden in one tenant's documents can request another tenant's records, and the model will comply because it has no concept of your isolation boundary. The fix is structural: build the tool functions as closures over the authenticated session, so tenant and role are baked in before the model ever sees the tool.

In code reviews I check every tool schema for scope-bearing parameters. Customer email, invoice number, date range — fine, those are inputs. Tenant ID, workspace ID, role, permission flags — never. Those come from the session your backend already authenticated.

def build_tools(session):
    """Tool handlers close over the authenticated session --
    the model never supplies tenant or role identifiers."""

    def list_open_invoices(customer_email: str) -> str:
        rows = invoice_service.list_open(
            tenant_id=session.tenant_id,  # from auth, never from the model
            actor_role=session.role,      # RBAC enforced in the service layer
            customer_email=customer_email,
        )
        return to_json(rows)

    # Only the closure is exposed; scope is fixed before the model sees it
    return {"list_open_invoices": list_open_invoices}

Tier tools by reversibility, not by feature

Enterprise agent design is mostly deciding what happens without a human. I use three tiers. Read-only tools — search, fetch, summarize — run freely; the worst case is a wasted call. Reversible writes — draft a reply, create a ticket, stage a config change — run automatically but land in a pending state a human can discard. Irreversible actions — send, delete, refund, deploy — always stop the loop and wait for explicit approval with the full proposed action rendered for review.

The useful property of this scheme is that it is legible to buyers. "The agent can read and stage, humans release" fits in one sentence of a security questionnaire. It also gives you a natural expansion path: as trust accumulates in production logs, individual actions can be promoted a tier with a config change instead of a redesign.

Audit logging is a feature, not an afterthought

Every tool call needs an immutable record: who started the session, which model and prompt version ran, the exact tool inputs and outputs, latency, token usage, and — for gated actions — who approved and when. I write these as structured events to the same audit pipeline the rest of the product uses, keyed by a run ID so an entire agent session can be replayed step by step.

This is not compliance theater. The audit trail is your debugging tool when the agent does something strange, your evidence when a customer disputes an action, and your dataset when you want to measure which tools fail most and where the loop wastes tokens. Teams that treat logging as an afterthought end up rebuilding it under pressure after the first incident; teams that build it first ship faster because every regression is diagnosable.

Roll out in three rings

I roll agentic features out in three rings. Ring one is internal operations — your own support or ops team uses the agent on real data with real stakes, and every complaint is a free bug report. Ring two is customer-facing but read-only: the agent answers questions and drafts artifacts, humans do all the acting. Ring three enables gated writes for design partners who have explicitly opted in.

Each ring has an exit criterion defined up front — typically an acceptance rate on drafts and a ceiling on incident count, measured from the audit log. The discipline matters because agent failures are long-tail: things look fine for weeks, then a weird document or a hostile input produces behavior you have not seen. Rings keep the blast radius proportional to your confidence.

When to hire senior help

Senior help is most valuable at the architecture stage, deciding what to automate, where approval gates belong, and how business value will be measured, before any code is written. It is also worth bringing in when a stalled pilot needs risk controls and evaluation rigor to pass security and compliance review. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — Agentic AI Systems projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Buying agent-washed products, since Gartner estimates only around 130 of thousands of self-described agentic AI vendors are genuine rather than rebranded chatbots or RPA
• ✕Deploying autonomy before defining risk controls and human-approval gates, one of the three causes Gartner cites for the 40 percent of projects it expects to be canceled
• ✕Measuring activity like tasks attempted instead of business value, leaving the project unable to justify escalating costs at renewal time
• ✕Wrapping agents around existing processes instead of redesigning the workflow, when McKinsey finds workflow redesign is the single biggest driver of EBIT impact from gen AI

Frequently asked questions

Sources

• Gartner
• MarTech
• McKinsey
• Joget