Why We Bet on Bundled Identity Instead of Point Solutions

The default architectural advice for building an AI agent platform in 2026 looks like this. Pick the best email API for agents. Pick the best voice API for agents. Pick the best vault. Pick the best MCP server. Stitch them together. Call the stitching layer "your platform."

We started Anima this way. We changed our minds. This post is the long version of why.

What the point-solution stack actually looks like#

Let's walk through what an honest founder building an agent product in 2026 has to assemble if they go the point-solution route.

Email for agents. AgentMail is the obvious pick. Working API, decent inbound parsing, sub-100ms latency. Per-agent identities that don't reuse the same SES account. Around $0.30 per 1,000 sends after the free tier. For pure email workflows, this is a fine choice. We have nothing bad to say about the email API itself.

Voice for agents. AgentPhone, Bland, Vapi, Retell. Mostly Twilio under the hood, with various opinions on latency, voice quality, and price. If you're calling existing customers (transactional purpose, opt-in already on file), any of them work. If you're calling cold leads, none of them ship server-side TCPA gates (they pass it to your code), none of them ship RND checks by default (you pay for Twilio Lookup yourself), and none of them ship time-of-day windows derived from the destination area code (you write that). The compliance burden lives in your application layer.

Vault for credentials. This is where Composio and similar players sit. They broker OAuth flows, store refresh tokens, mint short-lived access tokens for your agent. Solid product, real engineering behind it. Per-credential audit log lives in their dashboard. If you want server-side masking of sensitive fields before the token reaches your agent, that is a feature you wire up yourself.

MCP server. You write your own, or you self-host one of the open-source frameworks, or you bolt on a hosted MCP from one of the above providers (most of them now have one).

Total integration count: four vendors, four auth schemes, four audit logs, four billing relationships, four different opinions about identity. Total time to get a working multi-channel agent shipped: somewhere between four and twelve months, depending on how much of the compliance and observability glue you build vs. defer.

The hidden cost: who owns the identity graph?#

The bill of materials is real but not the deepest problem. The deepest problem is: across the four vendors above, nobody owns the agent's identity.

AgentMail knows the agent has an inbox at <slug>@agents.agentmail.to. AgentPhone knows the agent owns phone number +14155550142. Composio knows the agent has stored credentials for Gmail, Slack, and GitHub. Each of these vendors has a partial view. None of them have the whole picture.

The "agent identity" in this stack lives in your application database. It is a row in a table you wrote that says "agent_id 8x1 has email at AgentMail, phone at AgentPhone, vault entry at Composio." That row is the identity graph. You wrote it. You maintain it. You audit it. You scrub it when an agent is decommissioned. You hope nobody on your team forgot to write the cleanup hook.

When something goes wrong (a prompt injection, a runaway loop, a compromised key), you have to ask the question "what did this agent do today" and answer it by querying multiple vendors' APIs separately, joining their results in your code, and trusting that the timestamps line up.

When a procurement team at a Fortune 500 asks "show me the audit trail for agent X," your answer is a stitched-together CSV that took your team a half-day to generate.

When a regulator asks "demonstrate that this agent's actions are bound to a single accountable person," the path from "API key" to "human" goes through multiple different vendors' notions of org membership, and you cannot draw a clean diagram.

This is the structural cost of the point-solution stack: the identity graph is yours to maintain, but you do not have first-class primitives for it, because every vendor in your stack treats identity as their own internal concept, scoped to their channel.

What changes when one platform owns the boundary#

We took the opposite bet. One platform, one identity primitive, one audit event table, one billing relationship, one set of compliance gates.

What this looks like in practice:

One identity surface. The agent has an agent_id that lives in the Anima org. It owns an email inbox, optionally a phone number, and any vault entries the operator has provisioned for it. The mapping is in our database, not yours. When you ask "what does agent 8x1 have access to?", the answer is one query against one table, with a clean schema we maintain.

One audit log. Every cross-channel action emits a row to audit_events with a correlation ID that threads the workflow. Email sends, voice calls, vault reads, and phone provisioning all show up in the same chain. Your team queries one table. Procurement queries one table. The regulator queries one table. The chain is the identity story.

One compliance posture. TCPA gates run server-side on every voice call. Rate limits run server-side on every channel. PII masking runs server-side on vault reads. Hard caps run per-org with custom thresholds. Your application code does not have to remember to run any of these checks, because the platform runs them at the credential boundary. The agent cannot opt out, because there is no opt-out flag.

One billing relationship. One invoice, one usage meter per channel, one tier (Free / Starter / Growth / Scale / Enterprise) that gates capability across email + voice + vault + phone in a coherent way. Not multiple separate Stripe subscriptions to reconcile.

One MCP surface. All 190+ tools across email, phone, voice, vault, and platform live behind one MCP URL: https://mcp.useanima.sh/mcp. The agent registers once. Updates ship to all tools. There is no "the email MCP is on v2 but the phone MCP is still on v1" version skew.

What we give up#

Bundling is not free. We are direct about the tradeoffs.

We lose vendor optionality. If a customer wants to use a specific email vendor we do not support, they cannot. They use ours, or they do not use us. This is a real restriction. We bet that the integrated experience is worth the loss of optionality, but for some customers (the team that is already deeply invested in AgentMail's email API and just wants the rest of the stack), the bet is wrong, and they will pick the point-solution route.

We have to be the best at every channel, or at least good enough. A team that picks AgentMail for email gets the best-in-class email API. We have to be good enough at email that they do not regret picking us instead. Same for voice, vault, phone, MCP. This is a higher product bar than a point solution faces. We accept it.

The identity graph is our table, which means we are responsible for it. A point-solution stack means the customer's identity table is their problem. Our bundled stack means the identity table is ours. When something goes wrong with the identity layer, the customer calls us, not their internal team. That is the right tradeoff for the customer; it is more work for us.

Why bundling is the right bet for agents specifically#

Bundling has a long history of being wrong. Salesforce started bundled, the market unbundled around best-of-breed CRM, marketing automation, and customer service. Microsoft bundled Office, and various best-of-breed tools (Notion, Figma, Linear) carved out specific surfaces. The default lesson from this history is: bundles are a temporary advantage; specialists win the long game.

We think agents are different. Here is the structural argument.

Bundled wins when the integrations between the components are the value, and the components themselves are mostly commodity. Office wins because the value of "spreadsheet talks to slide deck talks to email" is higher than the value of any individual app being best-in-class.

The agent stack is the same shape. The value of "email triggers voice call triggers vault read" with one identity, one correlation chain, and one audit log is dramatically higher than the value of any of those channels being marginally better in isolation. The integrations are not "nice to have." They are the product.

Specifically: the per-agent identity primitive we ship requires bundling. You cannot have a unified identity graph if every channel lives at a different vendor. You cannot have one compliance posture if every channel enforces compliance differently. You cannot have one billing meter if every channel bills separately. The bundling is not a marketing position; it is a structural requirement of the primitive we are selling.

The unbundling argument applies when the integrations between channels are weak (CRM and marketing automation can talk to each other through APIs without losing much). The unbundling argument fails when the integrations are the primitive (you cannot have "one identity across email and voice" by stitching two vendors' identity systems together; you have to own both).

This is the bet we are making. We could be wrong. If we are right, the next two years of agent infrastructure consolidate around bundled platforms, and the point-solution wave we just lived through becomes a transitional phase. If we are wrong, we still have the best email-and-voice-and-vault-and-phone-with-one-identity-and-one-audit-log product on the market, which is enough.

What this means for you#

If you are choosing infrastructure for an AI agent product right now, you have two paths.

Path A: stitch. AgentMail + AgentPhone + Composio + your own MCP. Maximum optionality, maximum ownership of the identity graph (which means: your team writes the glue), four-to-twelve months of integration work, multiple vendors to manage, multiple compliance pictures to reconcile.

Path B: bundle. Anima. Ship a working agent with email + voice + vault and a real identity graph in 60 seconds with npx @anima-labs/cli init. Lose the optionality. Gain the integrated audit chain, server-side compliance, and one billing relationship.

For most teams shipping their first agent product in 2026, Path B is the right call. For teams that have already built half of Path A and just need the missing 30%, Path A makes sense. We are not pretending the answer is obvious. We are saying which side of the bet we took, and why.

The platform we wish had existed when we started building agents is the platform we built. If you want to skip the stitching, run am init. The thing the agent needs (a real identity, server-side gates, an audit chain it cannot route around) is in the box, on day one.

That is the bundle.