Storage Without Databases: How Agents Persist Data Without Being DBAs

Most developers are used to being DBAs. You create tables, write migrations, manage connection strings, and tune indexes. When you add an agent, you give it a database and hope it doesn't break your schema.

We wanted something different: agents say what kind of data they need; the platform figures out where it lives. No agent-owned connection strings. No "which database?" in the code. Just "I read and write core.meeting.notes"—and policies and connectors do the rest.

The Problem: Agents as Accidental DBAs

If every agent talks to a database directly, you get:

• Connection strings and credentials in config (or worse, in code).
• Schema drift: one agent adds a column, another breaks.
• No clear story for "this data stays in the vault" vs "this data goes to Salesforce."
• Migrations and backups that every team invents again.

Agents are good at reasoning and workflow. They're bad at being database administrators. So we moved the "where does this data live?" question out of the agent and into the platform.

Resource Policies: Rules for Where Data Lives

Resource policies are rules that say: "For this org (or this human), resources of this kind go to this store." For example:

• "For org Acme, core.email.* goes to the Gmail connector."
• "For this human, core.health.* goes to the vault."

The agent never sees "Gmail" or "vault" in its business logic. It just says "save this as core.email.message" or "load resources of kind core.meeting.transcript." The platform matches the kind to a policy, resolves the store and connector, and routes the read or write. The agent stays kind-based; operators change policy or swap connectors without touching agent code.

Connectors: The Bridge to the Real World

A connector is the component that actually talks to a storage backend: vault, Salesforce, a data warehouse, your own API. Each connector declares which kinds it supports (e.g. core.email.*) and a logical store name. When a resource policy says "use store X for kind Y," the platform finds a connector that supports that store and those kinds and routes the request there.

So agents don't persist "to a database." They persist "as this kind." Connectors implement the kind; policies decide which connector is used for which org and kind. One interface for the agent; many possible backends.

Vault, SaaS, and Self-Hosted

Three common patterns:

• Vault: User- or org-controlled storage where keys never leave the device (or a designated enclave). Default for sensitive, sovereign data. The vault connector implements read/write for the kinds you assign to it via policy.

• SaaS connectors: Salesforce, Gmail, Notion, etc. Policy says "for this org, core.crm.lead goes to Salesforce." The Salesforce connector handles the API; the agent still only sees kinds.

• Self-hosted: Your own datacenter or cloud. You run connectors that point to your systems. Same kind-based model: policies point to your store names, your connectors implement the kinds. The agent code is unchanged.

So "storage without databases" doesn't mean no databases—it means the agent doesn't choose or manage them. The platform does, via policies and connectors. You get persistence, schema validation, and the right storage for the right data, without every agent becoming a DBA.