Build vs. buy the AI governance layer — the decision every SaaS adding agents faces
Every SaaS adding agentic features hits the same wall: your customers' compliance teams want approvals, tenant isolation, and an audit trail — none of which is your differentiator. This is a build-vs-buy decision about the governance layer, not the model. Here's a framework for making it, and an honest account of what an embeddable governed engine does and doesn't solve today.
Gartner projects that around a third of enterprise software applications will include agentic AI by 2028, up from under 1% in 2024. If you build software, the pressure to ship an “AI agent” is already here. The trap is assuming the work is the model. It isn’t. The model is the easy, commoditised part. The work — and the risk — is everything around it.
The governance layer is table stakes, not differentiation
The moment your agent can do something — send a message, change a record, move money — your customers’ security and compliance teams show up with a list. It’s the same list every time:
- Human approval for sensitive actions, with a real decision UX (approve, reject, edit-and-approve, escalate) and no self-approval.
- Grounded, access-filtered retrieval — the agent may only see what a given user or tenant is allowed to see, and it must cite its sources.
- Tenant isolation — in a multi-tenant product, one customer’s data, secrets, and actions can never bleed into another’s.
- Tool governance — the agent acts only through allow-listed tools, with schema validation, brokered credentials, and a kill-switch.
- An append-only audit trail — every request, retrieval, approval, and tool call, correlated with your own business audit.
None of that is your product’s differentiator. Your customers won’t pay more because you built an approval inbox. But they will refuse to switch on your AI feature — or fail your SOC 2 review — if it isn’t there.
What it actually costs to build
Teams consistently underestimate this because each piece looks small in isolation. In practice, a signed execution-context contract, mandatory tenant-scoped retrieval, tenant-isolated secrets, approval-state management, an append-only correlated audit, and usage metering is on the order of eight-plus months of specialist work — and then it’s yours to maintain, forever, against a moving regulatory target. That’s eight months your team is not spending on the thing customers actually buy you for.
A decision framework
Build the governance layer yourself if: governance is your product, you have specialist security-engineering capacity to spare, and you want to own that surface as a differentiator.
Buy — or embed — if: agentic features are a capability you need, not your core product; your customers’ compliance bar makes “ungoverned agent” a non-starter; and you’d rather ship in weeks on a maintained engine than spend two or three quarters rebuilding multi-tenancy and audit from scratch.
The honest test is simple: is the governance layer the reason customers choose you? If not, it’s infrastructure — and infrastructure is usually better bought than built.
Being straight about the embeddable option
An embeddable governed engine — one you drop behind your own service boundary while keeping your brand, UX, and customers — is the “buy” path for agentic governance. It supplies the approvals, grounded retrieval, tool governance, and audit as a product, not a DIY assembly.
We’ll be direct about where Zahen is on this. The governed engine runs in production today as a dedicated, single-tenant deployment: grounded retrieval, human approvals, append-only audit, and tool governance are live. The multi-tenant embedding layer — the signed execution-context contract, the SDK, tenant-scoped metering, and the security attestations that go with it — is being productized now through a design-partner program. If you’re weighing this decision for your own roadmap, that’s exactly the conversation to have early: not to buy something finished, but to shape the engine you’ll embed. Talk to us about embedding.