Llevamos dos años diciendo "AI para datos". Creo que nos equivocamos de framing.
Todo lo que se lanzó bajo ese paraguas — text-to-SQL, chatbots sobre dashboards, agentes notebook-first — parte de la misma suposición: la capa analítica está terminada, solo hay que pegarle un LLM encima. Y está mal.
La capa analítica moderna se diseñó para humanos leyendo dashboards. No para agentes autónomos operando sobre datos. Y la diferencia no es cosmética.
Una Data Agent Platform es infraestructura para desplegar, equipar, gobernar y escalar agentes autónomos que interactúan con datos para ejecutar tareas analíticas, operativas y de toma de decisiones. No es "IA + datos" — es un paradigma donde los agentes son la unidad principal de ejecución. Eso implica que la plataforma tiene que poder crear agentes, conectarlos a fuentes de datos, equiparlos con herramientas, gestionar su estado y memoria, orquestar varios colaborando, gobernar sus acciones, y medir su costo.
Un humano abre un dashboard, interpreta una cifra ambigua, pregunta a un analista por Slack, lee un doc de confluence, aplica criterio. Un agente no puede hacer nada de eso. Un agente necesita un tool schema explícito, guardrails duros que no dependan de disciplina humana, memoria procedural que acumule correcciones, y contabilidad de costo por invocación. Ninguna plataforma tradicional le da eso de raíz. Tienen que sumarlo. Y lo suman como feature bolt-on.
Por eso estamos construyendo Calliope Data como la primera Data Agent First Platform — una categoría que creemos que define la próxima década de infraestructura analítica. Las capas fundacionales ya funcionan. Las capas superiores son hacia donde vamos.
Cómo llegamos hasta aquí
No empezamos diciendo "vamos a crear una categoría". Empezamos construyendo un producto.
Durante un año desarrollamos Calliope Marketing — una especialización vertical de Calliope Data para equipos de marketing. Un agente que podía responder preguntas de atribución, CAC, LTV, conversión, usando datos reales de la empresa, con ontología semántica, reglas de negocio y contabilidad de costo. Un agente real, en producción, sobre datos reales.
En ese proceso descubrimos algo: si el vertical era extremademente valioso. El potencial de la plataforma en la que se apoyaba era excepcional. La ontología, el pipeline, las reglas, la contabilidad — todo lo que construimos para que un agente de marketing operara con rigor era reutilizable para cualquier agente operando sobre cualquier dato. Finanzas, operaciones, producto, soporte — mismo substrato, mismas garantías, distinto dominio.
Ese fue el momento de inflexión. Calliope Marketing validó la tesis; ahora la plataforma la generaliza.
Y hay un principio de diseño que surgió de esa experiencia: independencia. Calliope Data es agnóstico a modelos de IA y a proveedores cloud.
No estás atado a OpenAI, a Anthropic, ni a ningún hyperscaler.
Si mañana sale un modelo mejor o más barato, simplemente lo cambiás.
Si tu empresa no puede enviar datos a un cloud específico, no tiene que hacerlo. La independencia no es un feature — es un principio de arquitectura que protege al cliente de la obsolescencia en un mercado que cambia cada seis meses.
Qué queremos decir con "Data Agent First"
Una Data Agent First Platform no es una base de datos con un chatbot pegado encima. Es infraestructura donde los agentes son la unidad principal de ejecución y cada pieza de la plataforma existe para soportar su ciclo de vida:
Conectar: la ingestión produce un substrato estable — snapshots versionados sobre los que el agente opera sin race conditions.
Equipar: la capa semántica genera un tool schema que el agente consulta antes de cada decisión.
Gestionar: los validated examples y el estado de conversación son la memoria procedural del agente.
Gobernar: las reglas de negocio son guardrails duros que viajan con cada query — el agente no puede violarlos.
Medir: la observabilidad descompone costo por agente, no solo por modelo o por usuario.
Crear y Orquestar: la capacidad de definir agentes custom y coordinar múltiples agentes especializados — hacia donde estamos construyendo.
Cada una de las capas fundacionales existe también en un stack analítico tradicional — pero están diseñadas para un consumidor equivocado. El semantic layer de dbt está pensado para BI tools. El catálogo de datos está pensado para data stewards. El dashboard de cost está pensado para FinOps. Ninguno tiene al agente como ciudadano de primera clase, porque todos se construyeron antes de que los agentes fueran una pregunta legítima de arquitectura.
Calliope se construyó después. Por eso el framing cambia.
Las cuatro capas, vistas desde el agente
1. Substrato: un mundo estable para leer
Los agentes necesitan leer datos que no se muevan bajo sus pies durante una conversación. En Calliope, el pipeline tiene cinco fases explícitas:
Las primeras tres fases son ingestión clásica. Lo interesante son las dos últimas: generar la ontología y los ejemplos. En la mayoría de los stacks, el pipeline termina en "datos cargados" y la capa semántica es un proyecto paralelo que alguien mantiene a mano. En Calliope, la capa semántica es parte del pipeline. Cada vez que llegan datos nuevos, el contexto del agente se refresca automáticamente — y las ediciones manuales que los humanos hicieron se preservan.
2. Semántica: la ontología como tool schema
Un LLM genérico no sabe que en tu empresa customer_revenue excluye devoluciones. No puede inferirlo del nombre de la columna. No puede inferirlo del tipo de dato. Necesita que alguien se lo diga explícitamente.
En Calliope, la ontología es exactamente eso: descripciones semánticas de tablas y columnas, generadas con IA pero editables por humanos. Y acá está la decisión de diseño que importa: cuando la ontología se regenera, las ediciones humanas se preservan. El LLM refresca lo que el LLM escribió; los humanos mantienen lo que los humanos saben. Hay un paréntesis de producto que sale literal del UI: "Regenerates the semantic description of tables and fields using AI. Useful when data sources have been modified."
Eso es el tool schema del agente. Antes de generar cualquier query, el agente lee qué significa cada columna, qué joins son válidos, qué tablas son canónicas. Las alucinaciones caen al suelo.
3. Gobernanza: reglas como guardrails
En la mayoría de los stacks analíticos, las reglas de negocio viven en un wiki, en un doc de Notion, o en la cabeza de un analista senior que se va a cambiar de trabajo en 18 meses. Se aplican por disciplina humana. Cuando un agente aparece, esa disciplina es el primer lugar donde se rompe.
En Calliope, las business rules son objetos versionados, activables, categorizados, con descripciones en markdown. Se aplican a toda query que el agente ejecuta — no a dashboards específicos. El subtítulo del hero del producto lo dice verbatim: "Query {tables} tables with {rules} business rules applied". La regla no es opcional. El agente no puede saltearla aunque quiera.
Ese es el guardrail. Gobernanza que no depende de disciplina.
4. Economía del agente: cost accounting nativo
El costo LLM es el primer recurso que vas a tener que justificar cuando pongas agentes a escala frente a datos empresariales. Pero el framing convencional — "cost por request" o "cost por modelo" — no sirve. Lo que importa es cost por agente por respuesta útil.
Calliope tiene un dashboard de uso LLM que descompone costo por modelo, por usuario y por agente. No es una pestaña de observability bolt-on; es un requisito de producto. La razón: cuando dentro de 18 meses tengas 15 agentes custom corriendo sobre tus datos — uno para finanzas, uno para marketing, uno para ops — la pregunta no va a ser "¿cuánto me costó Claude este mes?". Va a ser "¿el agente de finanzas tiene ROI positivo o está quemando tokens explorando cosas que nadie usa?".
Esa métrica — cost por agente — va a ser la unit economics de esta categoría. La gente que la mida primero va a ganar.
Dónde estamos y hacia dónde vamos
Una Data Agent Platform completa cubre siete capacidades: crear agentes, conectarlos a datos, equiparlos con herramientas, gestionar su estado, orquestar varios colaborando, gobernar sus acciones, y medir su costo. Un manifesto honesto dice cuáles ya funcionan y cuáles son la dirección.
Lo que ya funciona (capas fundacionales): conexión de datos vía pipeline de 5 fases, ontología como tool schema, validated examples como memoria procedural, business rules como guardrails en query-time, y cost accounting por agente. Estas capas están en producción.
Lo que viene (capas superiores):
MCP server y API de tool calling para que cualquier agente — Claude, Cursor, un agente custom — use la ontología, las reglas y los ejemplos de Calliope como herramientas. Hoy el assistant es la superficie principal. Mañana, cualquier agente puede operar con las mismas garantías.
Agentes custom por organización: "el agente de finanzas de ACME tiene este prompt de sistema, estos ejemplos fijos, estas reglas extra". Crear agentes especializados desde la plataforma.
Orquestación multi-agente: un agente planificador que invoca especializados y consolida. Hoy es una sola conversación lineal.
Audit trail agent-centric con intención capturada: qué pregunta, qué SQL generó, qué reglas aplicó, qué ejemplo usó, cuánto costó — todo en una sola vista.
No los tratamos como debilidades. Los tratamos como la dirección explícita del producto. La arquitectura ya está diseñada para recibirlos sin reescrituras.
Por qué esto importa ahora
Hay una ventana. Durante los próximos 12 meses, cada stack analítico grande va a sacar su versión de "AI agent". Snowflake va a sacar Cortex Analyst. Databricks va a expandir Genie. ThoughtSpot, Mode, Hex — todos van a tener la suya. Y todas van a compartir el mismo defecto: van a ser features bolt-on sobre arquitecturas diseñadas antes de que los agentes fueran una pregunta real.
Creemos que la oportunidad es la opuesta: construir desde el día uno pensando en el agente, y dejar que el resto de la plataforma salga de ahí. Si tenemos razón, el término "Data Agent First" va a empezar a aparecer en pitches ajenos en seis meses. Si tenemos razón, en 18 meses va a ser una categoría de Gartner.
Si no tenemos razón, por lo menos vamos a haber construido algo que hace mucho más fácil que un analista no técnico le pregunte a sus datos sin abrir un ticket.
Qué sigue
Este es el primero de seis artículos. En las próximas semanas vamos a ir capa por capa:
Este artículo — el manifesto.
El substrato que los agentes necesitan — cómo los datos llegan a un estado estable, leíble por agentes.
Tu ontología es el tool schema del agente — por qué el text-to-SQL ingenuo falla y cómo lo resolvemos.
Reglas de negocio como guardrails — gobernanza que no depende de disciplina humana.
La memoria del agente — validated examples y streaming como feedback loop.
Contabilidad de agentes — cost LLM como problema de producto, no de FinOps.
Si la tesis te pega, ponte en contacto con nosotros, te podremos enseñar mucho más
Llevamos dos años diciendo "AI para datos". Creo que nos equivocamos de framing.
Todo lo que se lanzó bajo ese paraguas — text-to-SQL, chatbots sobre dashboards, agentes notebook-first — parte de la misma suposición: la capa analítica está terminada, solo hay que pegarle un LLM encima. Y está mal.
La capa analítica moderna se diseñó para humanos leyendo dashboards. No para agentes autónomos operando sobre datos. Y la diferencia no es cosmética.
Una Data Agent Platform es infraestructura para desplegar, equipar, gobernar y escalar agentes autónomos que interactúan con datos para ejecutar tareas analíticas, operativas y de toma de decisiones. No es "IA + datos" — es un paradigma donde los agentes son la unidad principal de ejecución. Eso implica que la plataforma tiene que poder crear agentes, conectarlos a fuentes de datos, equiparlos con herramientas, gestionar su estado y memoria, orquestar varios colaborando, gobernar sus acciones, y medir su costo.
Un humano abre un dashboard, interpreta una cifra ambigua, pregunta a un analista por Slack, lee un doc de confluence, aplica criterio. Un agente no puede hacer nada de eso. Un agente necesita un tool schema explícito, guardrails duros que no dependan de disciplina humana, memoria procedural que acumule correcciones, y contabilidad de costo por invocación. Ninguna plataforma tradicional le da eso de raíz. Tienen que sumarlo. Y lo suman como feature bolt-on.
Por eso estamos construyendo Calliope Data como la primera Data Agent First Platform — una categoría que creemos que define la próxima década de infraestructura analítica. Las capas fundacionales ya funcionan. Las capas superiores son hacia donde vamos.
Cómo llegamos hasta aquí
No empezamos diciendo "vamos a crear una categoría". Empezamos construyendo un producto.
Durante un año desarrollamos Calliope Marketing — una especialización vertical de Calliope Data para equipos de marketing. Un agente que podía responder preguntas de atribución, CAC, LTV, conversión, usando datos reales de la empresa, con ontología semántica, reglas de negocio y contabilidad de costo. Un agente real, en producción, sobre datos reales.
En ese proceso descubrimos algo: si el vertical era extremademente valioso. El potencial de la plataforma en la que se apoyaba era excepcional. La ontología, el pipeline, las reglas, la contabilidad — todo lo que construimos para que un agente de marketing operara con rigor era reutilizable para cualquier agente operando sobre cualquier dato. Finanzas, operaciones, producto, soporte — mismo substrato, mismas garantías, distinto dominio.
Ese fue el momento de inflexión. Calliope Marketing validó la tesis; ahora la plataforma la generaliza.
Y hay un principio de diseño que surgió de esa experiencia: independencia. Calliope Data es agnóstico a modelos de IA y a proveedores cloud.
No estás atado a OpenAI, a Anthropic, ni a ningún hyperscaler.
Si mañana sale un modelo mejor o más barato, simplemente lo cambiás.
Si tu empresa no puede enviar datos a un cloud específico, no tiene que hacerlo. La independencia no es un feature — es un principio de arquitectura que protege al cliente de la obsolescencia en un mercado que cambia cada seis meses.
Qué queremos decir con "Data Agent First"
Una Data Agent First Platform no es una base de datos con un chatbot pegado encima. Es infraestructura donde los agentes son la unidad principal de ejecución y cada pieza de la plataforma existe para soportar su ciclo de vida:
Conectar: la ingestión produce un substrato estable — snapshots versionados sobre los que el agente opera sin race conditions.
Equipar: la capa semántica genera un tool schema que el agente consulta antes de cada decisión.
Gestionar: los validated examples y el estado de conversación son la memoria procedural del agente.
Gobernar: las reglas de negocio son guardrails duros que viajan con cada query — el agente no puede violarlos.
Medir: la observabilidad descompone costo por agente, no solo por modelo o por usuario.
Crear y Orquestar: la capacidad de definir agentes custom y coordinar múltiples agentes especializados — hacia donde estamos construyendo.
Cada una de las capas fundacionales existe también en un stack analítico tradicional — pero están diseñadas para un consumidor equivocado. El semantic layer de dbt está pensado para BI tools. El catálogo de datos está pensado para data stewards. El dashboard de cost está pensado para FinOps. Ninguno tiene al agente como ciudadano de primera clase, porque todos se construyeron antes de que los agentes fueran una pregunta legítima de arquitectura.
Calliope se construyó después. Por eso el framing cambia.
Las cuatro capas, vistas desde el agente
1. Substrato: un mundo estable para leer
Los agentes necesitan leer datos que no se muevan bajo sus pies durante una conversación. En Calliope, el pipeline tiene cinco fases explícitas:
Las primeras tres fases son ingestión clásica. Lo interesante son las dos últimas: generar la ontología y los ejemplos. En la mayoría de los stacks, el pipeline termina en "datos cargados" y la capa semántica es un proyecto paralelo que alguien mantiene a mano. En Calliope, la capa semántica es parte del pipeline. Cada vez que llegan datos nuevos, el contexto del agente se refresca automáticamente — y las ediciones manuales que los humanos hicieron se preservan.
2. Semántica: la ontología como tool schema
Un LLM genérico no sabe que en tu empresa customer_revenue excluye devoluciones. No puede inferirlo del nombre de la columna. No puede inferirlo del tipo de dato. Necesita que alguien se lo diga explícitamente.
En Calliope, la ontología es exactamente eso: descripciones semánticas de tablas y columnas, generadas con IA pero editables por humanos. Y acá está la decisión de diseño que importa: cuando la ontología se regenera, las ediciones humanas se preservan. El LLM refresca lo que el LLM escribió; los humanos mantienen lo que los humanos saben. Hay un paréntesis de producto que sale literal del UI: "Regenerates the semantic description of tables and fields using AI. Useful when data sources have been modified."
Eso es el tool schema del agente. Antes de generar cualquier query, el agente lee qué significa cada columna, qué joins son válidos, qué tablas son canónicas. Las alucinaciones caen al suelo.
3. Gobernanza: reglas como guardrails
En la mayoría de los stacks analíticos, las reglas de negocio viven en un wiki, en un doc de Notion, o en la cabeza de un analista senior que se va a cambiar de trabajo en 18 meses. Se aplican por disciplina humana. Cuando un agente aparece, esa disciplina es el primer lugar donde se rompe.
En Calliope, las business rules son objetos versionados, activables, categorizados, con descripciones en markdown. Se aplican a toda query que el agente ejecuta — no a dashboards específicos. El subtítulo del hero del producto lo dice verbatim: "Query {tables} tables with {rules} business rules applied". La regla no es opcional. El agente no puede saltearla aunque quiera.
Ese es el guardrail. Gobernanza que no depende de disciplina.
4. Economía del agente: cost accounting nativo
El costo LLM es el primer recurso que vas a tener que justificar cuando pongas agentes a escala frente a datos empresariales. Pero el framing convencional — "cost por request" o "cost por modelo" — no sirve. Lo que importa es cost por agente por respuesta útil.
Calliope tiene un dashboard de uso LLM que descompone costo por modelo, por usuario y por agente. No es una pestaña de observability bolt-on; es un requisito de producto. La razón: cuando dentro de 18 meses tengas 15 agentes custom corriendo sobre tus datos — uno para finanzas, uno para marketing, uno para ops — la pregunta no va a ser "¿cuánto me costó Claude este mes?". Va a ser "¿el agente de finanzas tiene ROI positivo o está quemando tokens explorando cosas que nadie usa?".
Esa métrica — cost por agente — va a ser la unit economics de esta categoría. La gente que la mida primero va a ganar.
Dónde estamos y hacia dónde vamos
Una Data Agent Platform completa cubre siete capacidades: crear agentes, conectarlos a datos, equiparlos con herramientas, gestionar su estado, orquestar varios colaborando, gobernar sus acciones, y medir su costo. Un manifesto honesto dice cuáles ya funcionan y cuáles son la dirección.
Lo que ya funciona (capas fundacionales): conexión de datos vía pipeline de 5 fases, ontología como tool schema, validated examples como memoria procedural, business rules como guardrails en query-time, y cost accounting por agente. Estas capas están en producción.
Lo que viene (capas superiores):
MCP server y API de tool calling para que cualquier agente — Claude, Cursor, un agente custom — use la ontología, las reglas y los ejemplos de Calliope como herramientas. Hoy el assistant es la superficie principal. Mañana, cualquier agente puede operar con las mismas garantías.
Agentes custom por organización: "el agente de finanzas de ACME tiene este prompt de sistema, estos ejemplos fijos, estas reglas extra". Crear agentes especializados desde la plataforma.
Orquestación multi-agente: un agente planificador que invoca especializados y consolida. Hoy es una sola conversación lineal.
Audit trail agent-centric con intención capturada: qué pregunta, qué SQL generó, qué reglas aplicó, qué ejemplo usó, cuánto costó — todo en una sola vista.
No los tratamos como debilidades. Los tratamos como la dirección explícita del producto. La arquitectura ya está diseñada para recibirlos sin reescrituras.
Por qué esto importa ahora
Hay una ventana. Durante los próximos 12 meses, cada stack analítico grande va a sacar su versión de "AI agent". Snowflake va a sacar Cortex Analyst. Databricks va a expandir Genie. ThoughtSpot, Mode, Hex — todos van a tener la suya. Y todas van a compartir el mismo defecto: van a ser features bolt-on sobre arquitecturas diseñadas antes de que los agentes fueran una pregunta real.
Creemos que la oportunidad es la opuesta: construir desde el día uno pensando en el agente, y dejar que el resto de la plataforma salga de ahí. Si tenemos razón, el término "Data Agent First" va a empezar a aparecer en pitches ajenos en seis meses. Si tenemos razón, en 18 meses va a ser una categoría de Gartner.
Si no tenemos razón, por lo menos vamos a haber construido algo que hace mucho más fácil que un analista no técnico le pregunte a sus datos sin abrir un ticket.
Qué sigue
Este es el primero de seis artículos. En las próximas semanas vamos a ir capa por capa:
Este artículo — el manifesto.
El substrato que los agentes necesitan — cómo los datos llegan a un estado estable, leíble por agentes.
Tu ontología es el tool schema del agente — por qué el text-to-SQL ingenuo falla y cómo lo resolvemos.
Reglas de negocio como guardrails — gobernanza que no depende de disciplina humana.
La memoria del agente — validated examples y streaming como feedback loop.
Contabilidad de agentes — cost LLM como problema de producto, no de FinOps.
Si la tesis te pega, ponte en contacto con nosotros, te podremos enseñar mucho más
