Una base de datos por agente de IA: la arquitectura que propone Turso
Darle a cada agente de IA su propia base de datos limita el daño de sus errores y abarata la escala. Repasamos la guía de Jeff Olson en el blog de Turso: los cuatro patrones, el modelo de costos, el caso CTO.new y cuándo no conviene.
8 min de lectura Investigado y publicado con Claude
En este artículo
- Por qué este tema importa ahora
- La idea central: el radio de daño de un agente es su propia base
- Los cuatro patrones de la guía
- Cómo se crea una base para cada agente
- El modelo de costos: pagás por lo que se usa
- El caso CTO.new
- Cuando el agente rompe algo
- Cuándo no conviene
- Qué significa para tu proyecto
- Preguntas frecuentes
- Fuentes
La arquitectura de "una base de datos por agente" consiste en darle a cada agente de IA su propia base, en lugar de que todos escriban en una base compartida. Turso la explica en una guía de Jeff Olson publicada en julio de 2026, con un argumento central: si la base es un archivo liviano, barato de crear y fácil de borrar, el daño que puede causar un agente queda encerrado en su propia base. Funciona muy bien para muchos agentes independientes y no conviene cuando varios agentes necesitan transacciones estrictas entre sí.
En el primer post de la serie contamos qué es Turso; acá vamos a cómo se diseña un sistema de agentes con esta idea.
Por qué este tema importa ahora#
La compra de Turso por parte de Supabase se explicó justamente con este escenario. En su anuncio, Supabase dice que los agentes ya crean millones de bases para prototipos, dashboards y apps, y plantea que un agente debería poder crear una base tan fácil como un archivo, y con la misma poca preocupación por el costo. Lo repasamos en nuestra nota sobre Supabase Select 2026 y la compra de Turso.
La idea central: el radio de daño de un agente es su propia base#
Un agente de IA ejecuta acciones que no siempre podés prever. Si veinte agentes comparten una base, un error de uno puede afectar los datos de todos.
La guía de Jeff Olson lo formula como "blast radius", el radio de daño: con una base por agente, ese radio es la base del propio agente. Si algo sale mal, borrás o restaurás esa base y el resto sigue funcionando.
La página de soluciones para agentes suma tres ventajas:
- Memoria y estado en un solo lugar: la búsqueda vectorial nativa vive en la misma base que el estado del agente.
- Experimentar sin miedo: el branching, que crea una copia de la base, se describe allí como una operación que solo toca metadatos.
- Costo de las bases quietas: una base inactiva solo paga almacenamiento.
Los cuatro patrones de la guía#
La guía de Jeff Olson describe cuatro formas de implementar la idea. Este es nuestro resumen:
| Patrón | Dónde vive la base | Encaja cuando... |
|---|---|---|
| 1. Una base en la nube por agente | Turso Cloud | Los agentes corren en servidores y querés administrarlos de forma centralizada |
| 2. Agente embebido con SQLite local | En el mismo proceso del agente | El agente corre en un dispositivo o en un entorno aislado y no necesita compartir datos |
| 3. Agente local conectado a la nube con sync | Archivo local que se sincroniza con Turso Cloud | Necesitás lecturas locales rápidas, pero también un respaldo y una vista central |
| 4. Hub-and-spoke | Una base por agente más una capa de coordinación compartida | Los agentes trabajan en equipo y necesitan un punto común para coordinarse |
Los nombres son los de la guía; la columna "encaja cuando" es nuestra lectura.
En el cuarto patrón cada agente conserva su aislamiento, pero hay un lugar compartido para lo que tienen que saber todos, por ejemplo el estado de una tarea.
Cómo se crea una base para cada agente#
La documentación de Turso tiene una guía específica para bases de agentes. El ejemplo usa el cliente de la Platform API (la API para administrar bases por código), @tursodatabase/api, y crea una base llamada agent- más el identificador del agente:
import { createClient } from "@tursodatabase/api";
const turso = createClient({
token: process.env.TURSO_PLATFORM_API_TOKEN,
org: process.env.TURSO_ORG_NAME,
});
// Crea una base nueva para el agente dentro del grupo "default"
async function provisionAgentDatabase(agentId) {
const database = await turso.databases.create(`agent-${agentId}`, {
group: "default",
});
console.log(`Database created for agent ${agentId}: ${database.Name}`);
return database;
}
La guía resume los beneficios en aislamiento, escalado independiente, seguridad y limpieza sencilla. Un detalle de la referencia de la API: el nombre de la base solo admite letras minúsculas, números y guiones, con un máximo de 64 caracteres. Si tus identificadores de agente tienen otro formato, normalizalos antes.
El modelo de costos: pagás por lo que se usa#
Lo que hace viable esta arquitectura es cómo se cobra. La guía lo explica con un ejemplo: si tenés 1.000 bases de agentes y solo 100 trabajaron este mes, pagás el almacenamiento de 1.000 archivos chicos más exactamente las consultas que hicieron esas 100.
Como cada base es un archivo y no un servidor encendido, crear una nueva deja de ser una decisión financiera.
Ojo: según la página de precios, el plan gratuito permite hasta 100 bases; los pagos, ilimitadas.
El caso CTO.new#
El ejemplo más citado es CTO.new, de Engine Labs, contado por Glauber Costa en el blog de Turso. La plataforma le da a cada proyecto, donde trabaja un equipo de agentes de IA, su propia base de Turso como capa de coordinación. Según ese caso de estudio:
- Manejan decenas de miles de bases y unos 50.000 usuarios.
- El gasto de infraestructura ronda los USD 500 por mes.
- En el pico hay unas 2.000 bases activas al mismo tiempo.
- El costo por usuario bajó alrededor de 95%, de unos USD 20 a cerca de USD 1.
La página de soluciones para agentes agrega que Engine Labs pasó de gastar entre USD 3.000 y 5.000 por mes en Postgres administrado a unos pocos cientos con Turso. Simon Spurrier, su fundador, lo resume así: cuando el costo marginal de una base tiende a cero, ya no pensás cuánto podés meter en una sola; simplemente creás otra. Son cifras publicadas por Turso, no una medición independiente.
Cuando el agente rompe algo#
Un agente con autonomía alguna vez va a borrar lo que no debía. Turso tiene dos piezas para eso, que veremos más adelante en la serie:
- Accident Protection: en planes pagos, las bases borradas se pueden restaurar hasta 5 días después, sin costo extra. El anuncio de Pedro Muniz y Nikita Sivukhin lo resume en una frase: los agentes borran cosas, ahora las podés recuperar.
- AgentID: un post invitado de Haakam Aujla presenta un proveedor OpenID Connect para que los agentes tengan cuentas propias de Turso, con su propia identidad.
A eso sumale los permisos finos de los tokens, que permiten limitar por tabla qué puede hacer cada credencial (leer, agregar, actualizar, borrar o cambiar el esquema).
Cuándo no conviene#
La guía es clara en esto: si varios agentes necesitan garantías ACID fuertes entre ellos al mismo tiempo, es decir, que una operación que toca los datos de varios agentes se complete entera o no se haga, separar las bases te complica. En ese caso una base compartida, o el patrón hub-and-spoke con la parte crítica en la capa común, es más razonable.
Qué significa para tu proyecto#
Si estás construyendo agentes para tu empresa, como un asistente de atención o automatizaciones con n8n que guardan contexto, esta arquitectura te obliga a pensar tres decisiones:
- Qué es "un agente" en tu sistema. ¿Un agente por cliente, por conversación, por proyecto? CTO.new eligió una base por proyecto, no por agente individual.
- Qué datos tienen que ser compartidos. Si hay información que todos necesitan, diseñá desde el inicio la capa de coordinación.
- Cómo se limpia. Definí cuándo se borra la base de un agente que ya no se usa y cómo la recuperás si fue un error.
Para un proyecto chico con un solo asistente, probablemente alcance con una base. El patrón rinde cuando la cantidad de agentes crece.
Preguntas frecuentes#
¿Cuánto cuesta tener miles de bases de agentes que casi no se usan?#
Según Turso, una base inactiva solo paga su almacenamiento, porque no hay un proceso corriendo cuando nadie la consulta. El costo real lo marcan las bases que sí trabajan ese mes.
¿Cómo comparten información los agentes si cada uno tiene su propia base?#
Con el patrón hub-and-spoke de la guía: cada agente mantiene su base y además existe una capa de coordinación compartida donde se registra lo que el equipo necesita saber.
¿Cada agente necesita su propio servidor de base de datos?#
No. En Turso cada base es un archivo administrado por la plataforma, no un proceso dedicado. Por eso Supabase destaca que un solo servidor de Turso puede administrar millones de bases.
¿Qué pasa si un agente borra su base por error?#
En planes pagos podés restaurarla durante 5 días con Accident Protection. En el plan gratuito no está incluida, así que conviene tener backups propios.
Si estás pensando en sumar agentes de IA a tu negocio y querés diseñar bien dónde guardan su memoria y su estado, en Mark-Co Digital desarrollamos agentes a medida y te ayudamos a evaluar la arquitectura de datos, incluidas opciones como Turso y Supabase. También podés ver cómo trabajamos con agentes de IA.
Fuentes#
- Building AI Agent Databases: A Complete Guide to Database-per-Agent Architecture, de Jeff Olson
- Turso para agentes de IA
- Guía de bases por agente (documentación)
- Platform API: crear una base
- CTO.new Coordinates Tens of Thousands of AI Agents, de Glauber Costa
- Let your agents run free with Turso Accident Protection, de Pedro Muniz y Nikita Sivukhin
- Giving Agents Their Own Turso Accounts with AgentID, de Haakam Aujla
- Permisos finos de tokens (documentación)
- Precios de Turso
- Supabase is acquiring Turso, de Paul Copplestone
- Supabase Select 2026 y la compra de Turso (Mark-Co Digital)
