Why Consolidate Agent Infra on One Governed Identity

TL;DR

›A production agent touches identity, money, comms, secrets, and third-party apps — stitching a separate vendor for each creates disconnected accounts, duplicated OAuth, and policy that lives in prompts.
›Consolidating on one governed identity means one tenant user owns the card, inbox, vault entry, connection grant, and verification record — with one Account Kit enforcing caps, approvals, audit, and revoke.
›Migration is incremental: swap one capability at a time using the docs migration guides; the tenant user stays constant.
›The consolidation win is accountability — one activity log answers who acted, for which end-user, under which policy.
›Naïve is not 'rip and replace everything day one'; it is one identity layer that absorbs point solutions as you migrate them.
›Start with the highest-risk stitch (secrets or payments), then connections, then comms.

Agents that only chat are easy to stitch together. Agents that act — spend, send, sign up, verify, connect apps — accumulate infrastructure whether you plan for it or not. The default pattern is a separate vendor account for each capability: one stack for secrets, another for email, another for cards, another for OAuth tools, another for identity checks. Each works in isolation. None share a policy boundary.

Naïve consolidates those capabilities onto one governed identity per tenant user — one record that owns the card, the inbox, the vault entry, the connection grant, and the verification status, with one Account Kit deciding what the agent may do at execution time. This post is the thesis behind the docs migration guides; the guides hold the step-by-step swaps.

What breaks in a stitched stack?

Symptom	Why it happens
"Who let this agent spend?"	Card audit lives in one dashboard; agent identity in another
Cross-tenant leak risk	OAuth tokens stored in app code, not scoped by platform
Policy in prompts	"Don't spend more than $50" is not enforced by the card issuer
Revoke is a project	Rotating one vendor key does not cut off the others
Billing surprises	Each vendor bills independently; runaway agents hit multiple caps

The governed agent profile model fixes this by routing regulated actions through one governance gateway — caps, approvals, audit, and revoke apply across the whole bundle, not per vendor.

Stitched stack vs one governed identity

Concern	Stitched point solutions	One governed identity (Naïve)
Unit of isolation	Per-vendor account or API key	Tenant user — every primitive attaches to it
Policy	Scattered config + prompt instructions	Account Kit — enforced server-side on every call
Secrets	External secrets manager + app code	Vault — per-user, envelope-encrypted
Tool auth	Separate OAuth for each integration vendor	Connections — 1,000+ apps, per user (per published docs)
Spend	Card API + separate LLM billing	Cards + credits under one budget ceiling
Audit	Multiple vendor logs	One activity log per user
Revoke	Revoke each integration manually	`agentProfile.revoke()` or kill MCP session — gateway denies all further calls

How do migrations work in practice?

You do not rewrite the agent loop on day one. You re-anchor one capability at a time onto the tenant user you already created for each customer:

Create the tenant user — naive.users.create() on signup; scope with naive.forUser(id) (multi-tenant playbook).
Assign an Account Kit — encode tier policy once (what is an Account Kit?).
Migrate the highest-risk surface — pick the matching guide from the migration index:
- Secrets → vault guide
- Outbound email → email guide
- Tool OAuth → connections guide
- Card spend → cards guide
- LLM routing → LLM guide
- Browser automation → browser guide
- …and the rest of the index
Leave the agent framework in place — orchestration stays in LangGraph, Vercel AI SDK, or your loop; only the tool endpoints change (Naïve inside your framework).

Each guide follows the same shape: concept map, smallest working swap, consolidation gains, honest gaps. Vendor names appear in the docs guides for search and migration intent; the blog describes the pattern.

What is the consolidation win?

Three outcomes compound once more than one primitive lives on the same identity:

Accountability. "What did this agent do for customer X?" is one query on the activity log — card spend, email sends, connection grants, and renders in one timeline.

Policy that travels. Disable cards on a kit and the same agent code that issues email cannot issue a card — forbidden at execution time, not a new if in your app.

Incremental adoption. Ship vault migration this sprint, connections next sprint, cards the sprint after. The tenant user and kit are stable; each guide is a surgical swap.

What Naïve is not claiming

Consolidation is not "Naïve replaces every SaaS on earth." Each migration guide includes a what does not map yet section — honest gaps before you commit. Some vendor capabilities have no primitive equivalent today; keep that surface on the old vendor until the gap closes or you redesign the flow.

Naïve also does not replace your agent framework. Orchestration stays where it is; only the governed tool layer consolidates.

Where to start

If you have multiple customers, read Building AI Agents Into Your SaaS and create one tenant user per customer.
Open the migration guides index and pick the vendor surface that hurts most today.
Run the smallest swap in the guide against a single tenant user before migrating production traffic.
Wire the agent through Naïve inside your framework so orchestration stays unchanged.

For secrets-first migrations, pair the vault guide with secrets management for AI agents. For the full control lifecycle, continue with The Governed Agent Profile.

Frequently Asked Questions

What does consolidating agent infra mean?+

It means one governed identity — a tenant user under your operator workspace — owns every real-world capability the agent uses: virtual cards, email, phone, encrypted secrets, OAuth connections, verification, and formation. Instead of five vendor dashboards and five API keys, one Account Kit defines what the agent may do and the platform enforces it on every call.

Why is a stitched vendor stack risky for agents?+

Each point solution brings its own account, billing, OAuth tokens, and audit trail. The agent's card lives in one console, its inbox in another, its secrets in a third — and 'may this agent act right now?' is never answered in one place. Prompt instructions cannot connect those boundaries; a compromised or confused agent can still spend on a card whose limit you never tied to the same policy that gates email sends.

Do I have to migrate everything at once?+

No. The docs migration guides are designed for one primitive at a time: move secrets to the vault, move outbound email to the email primitive, move tool auth to connections, move card spend to the cards primitive — each guide maps a vendor's core path to the Naïve equivalent. The tenant user you create on day one stays the anchor; each migration attaches another capability to the same identity.

Where are the step-by-step migration guides?+

The docs migration guides index lists every guide — connections, cards, email, LLM routing, phone, verification, formation, browser automation, compute, domains, trading, search, billing, social, mobile devices, and secrets — each with a concept map, before/after code, consolidation gains, and an honest 'what does not map yet' section. Pick the vendor surface you are replacing first; the pattern is the same in every guide.

How does consolidation interact with multi-tenancy?+

Each of your customers gets their own tenant user; consolidation happens per customer, not once for the whole product. Customer A's card, inbox, vault, and connections are isolated from Customer B's — the same structural boundary described in the multi-tenant playbook. You author a few Account Kits (Starter, Pro, Enterprise) and assign them per tier.

What should I migrate first?+

Start where a leak hurts most: secrets (API keys the model must never see) or money (virtual cards with spend caps and approval gates). Then connections — per-user OAuth for the 1,000+ apps your agent needs (per published docs). Comms and verification follow once the identity anchor exists. Each step uses the matching migration guide; governance from the governed agent profile applies throughout.

Naïve Team

Building the agent-native backend.

Keep reading

Building AI Agents Into Your SaaS: The Multi-Tenant Playbook

Building multi-tenant AI agents into your SaaS means giving each customer an isolated, governed agent. Here's the full architecture and how to ship it.

The Governed Agent Profile: End-to-End Control for AI Agents

A governed agent profile is an AI agent with identity, spend limits, approvals, audit, and instant revoke — enforced on every action. Here's the full lifecycle.

Secrets Your AI Agent Can Use but Never Sees

Secrets management for AI agents means letting an agent use a credential without exposing it to the model. Here's the per-tenant vaulting pattern that fixes it.

Naïve Inside Your Agent Framework (Governed Tools, Any Orchestrator)

Naïve as the governed tool layer under any agent framework — keep your orchestrator; add identity, connections, caps, and approvals via agentTools() or MCP.