Carbon como Agentic Data Cloud — el norte

1 · La definición

Una Agentic Data Cloud es una plataforma que transforma datos dispersos en conocimiento de negocio gobernado, contextualizado y accionable, optimizado para que agentes de IA razonen, colaboren y ejecuten procesos de forma autónoma con trazabilidad y calidad garantizadas.

El valor crudo de Carbon, dicho en una frase:

No «consultable». Consumible: el agente no explora, no descubre, no compone SQL. Pide un objeto de negocio y lo recibe hidratado y gobernado.

2 · Lo que dice la frontera (y lo que no)

Tres fuentes leídas para calibrar el encuadre. Coinciden en el diagnóstico y difieren en dónde ponen la solución — y esa diferencia es exactamente nuestra oportunidad.

Google — «System of Record → System of Action» (enlace). Nombra cuatro capas: agentic workforce, context and memory (el «Knowledge Flywheel» + Knowledge Catalog), orquestación vía MCP, y motores activos. Su diagnóstico central es el trust gap: «un catálogo es una lista de inventario», y un inventario no basta — un agente necesita entender relaciones y distinciones semánticas (su ejemplo: «revenue» vs «projected revenue»). Y lo que dicen que un agente no debe ver: datos crudos sin comprensión de negocio, metadata técnica sin contextualizar, y semántica no verificada.

Snowflake — el Data Cloud y la plataforma de agentes (Data Cloud · plataforma de agentes). Aporta lo operativo que a Google se le queda en abstracto: multi-tenancy con aislamiento estricto (row access policies, un agente sirviendo a varios tenants), ejecución de código en sandbox dentro del perímetro, MCP como estándar de integración, presupuestos de recursos por agente y evaluaciones (precisión en la selección de herramienta, corrección de la respuesta, consistencia lógica). Nótese lo que no hay en su argumento de plataforma de agentes: una capa semántica. Su apuesta es acceso directo gobernado por políticas.

Salesforce Agentforce — la página devolvió 403, no la he leído. No la cito.

La lectura: todos aceptan que el cuello de botella es el contexto y la confianza, no el cómputo. Google pone la solución en enriquecer el catálogo; Snowflake, en gobernar el acceso directo. Nosotros ponemos la solución un nivel por encima de ambos: en un objeto de negocio que el agente pide por su nombre.

3 · El primitivo: Business Capability (Pod)

Un Pod es un objeto empresarial que vive en un grafo y representa una imagen completamente gobernada e hidratada de un sistema de producción o de sandbox.

No es una tabla. No es una vista. No es un término de glosario. Un Pod tiene cuatro mitades, y ninguna sobra:

Un catálogo enriquecido te da la primera mitad. Un lakehouse gobernado te da la segunda. El Pod es el único sitio donde las cuatro se encuentran, y por eso es el producto.

El ciclo del agente

   Pregunta
      ↓
   Solicitar el Pod «Customer»          ← nunca «SELECT … FROM …»
      ↓
   Razonar sobre el objeto hidratado
      ↓
   Actuar  (dentro y fuera de la plataforma)

La invariante dura

Es una invariante, no una preferencia: es lo que hace que la trazabilidad, la política y la calidad sean garantizables en vez de esperables. Si el agente puede caer al SQL crudo, todo lo que prometemos encima es opcional.

Y tiene un precio que hay que decir en voz alta: toda pregunta que un agente pueda responder debe ser expresable contra Pods. Cuando llega una que no lo es, hay exactamente dos salidas honestas — el Pod crece, o la respuesta no existe. Lo que no puede haber es una tercera puerta al SQL «solo para este caso», porque esa puerta convierte la invariante en un adorno. La cobertura del catálogo de Pods es, por tanto, la métrica de producto que hay que vigilar desde el día uno.

Esto es la misma jugada que ya hicimos con el Warehouse: allí la cintura estrecha es el catálogo/formato y los motores son plurales detrás de ella (warehouse-as-narrow-waist.md). Aquí la cintura estrecha es el Pod, y detrás de ella son plurales los datos, los motores y las fuentes. Misma disciplina, un piso más arriba.

4 · La arquitectura

                    Agentes  (sandboxed · prod)
                         │  pregunta → pide Pod → razona → actúa
                         │  (MCP)
   ┌─────────────────────┴──────────────────────────────┐
   │  POD LAYER — la cintura estrecha de los agentes    │  ← Carbon
   │  Customer · Order · Contract · Shipment …          │
   │  semántica + hidratación + acción + política       │
   └───────┬────────────────────────────────┬───────────┘
           │ significado                    │ dato
   ┌───────┴─────────────────┐   ┌──────────┴────────────────┐
   │  OpenMetadata           │   │  Carbon Data (Junction)   │
   │  SoT de METADATA        │   │  SoT de DATO              │
   │  ingesta · lineage      │   │  Iceberg · Lakekeeper · R2│
   │  calidad · glosario     │   │  DuckDB · Karma · pyiceberg│
   │  clasificación · perfil │   │                           │
   └───────┬─────────────────┘   └──────────┬────────────────┘
           │ conectores de ingesta          │
   ┌───────┴────────────────────────────────┴────────────────┐
   │  El ecosistema empresarial: BBDD, SaaS, BI, pipelines,  │
   │  ficheros, colas, modelos…                              │
   └──────────────────────────────────────────────────────────┘

El reparto, sin solapes

• OpenMetadata = fuente de verdad de la METADATA. Se adopta desde la ingesta: sus conectores recorren el ecosistema y construyen el grafo técnico (esquemas, lineage columna a columna, calidad, perfilado, clasificación, glosario). Es más maduro que el Index para esto y está diseñado exactamente para esto.
• Carbon Data = fuente de verdad del DATO. El Warehouse ya cerrado: Iceberg sobre Lakekeeper y R2, con Junction como puerta única y motores plurales detrás.
• Carbon Pod Layer = el producto. Compone las dos y añade lo que ninguna de las dos tiene: acción y política de agente.

5 · Qué pasa con el Index

El Index deja de aspirar a ser el catálogo. Ése es el cambio de rumbo real, y es una corrección, no una ampliación: OpenMetadata hace mejor y con más madurez lo que el Index estaba empezando a hacer a mano (glosario, clasificación, lineage, calidad).

Lo que el Index conserva es lo que sigue siendo verdad de su invariante original —«guarda lo que el catálogo no puede saber»— más lo nuevo que nace aquí:

• La definición de los Pods (contrato, mapa de hidratación, acciones, políticas).
• La tenencia por workspace, que OM no modela como nosotros.
• La procedencia, los contratos de vista y las versiones de esquema que ya guardaba.

Lo que el Index no debe volver a intentar: ser el glosario, el lineage o el registro de calidad. Eso vive en OM y se lee de OM.

6 · Sandbox y producción

Un Pod es una imagen gobernada de un sistema, y el sistema puede ser de producción o de sandbox. Eso obliga a que el entorno sea parte de la identidad del Pod, no un flag de despliegue: el mismo Customer hidratado contra sandbox y contra prod son dos objetos distintos con políticas distintas, y un agente entrenado o probado contra uno no queda autorizado sobre el otro.

Snowflake es explícito en esto y conviene copiarles la disciplina: aislamiento estricto por tenant y ejecución en sandbox dentro del perímetro, no fuera. Un agente que ejecuta código para razonar sobre un Pod debe hacerlo donde las políticas siguen aplicando.

7 · Lo que un agente consume: contexto, capacidades y feedback

Un agente no consume «datos». Consume tres cosas, y el Pod es rico precisamente porque las sirve juntas:

El feedback es la mitad que nadie modela y la que cierra el bucle. Si el Pod registra qué atributos se consultaron realmente, qué acciones fallaron y —sobre todo— qué preguntas no supo responder, entonces la métrica de cobertura de §3 deja de ser una estimación y pasa a ser una medición: el propio uso te dice dónde tiene que crecer el catálogo. Ese bucle es el que convierte el Pod Layer en algo que mejora solo, en vez de en un modelo que alguien tiene que mantener a mano para siempre.

Por qué el Pod puede ser esto y una ontología no

No es una cuestión de modelado más listo. Es de control del plano de datos.

Una capa semántica que vive encima del almacén de otro (Snowflake, Databricks, BigQuery) sólo puede describir y pedir. No puede materializar, no controla la frescura, no gobierna la escritura y su política vive en una API que se puede rodear.

Carbon posee el plano entero — Iceberg sobre Lakekeeper y R2, con Junction como puerta única y motores plurales detrás. Eso permite cuatro cosas que una capa semántica prestada no puede hacer:

1. Hidratar a la granularidad que haga falta, sin pedir permiso a nadie.
2. Materializar un Pod caliente (precomputarlo) cuando el patrón de uso lo justifique — una decisión de plano de datos, tomada desde el conocimiento del uso.
3. Garantizar frescura y linaje, porque controlamos también el camino de escritura.
4. Aplicar la política en el plano de datos, no sólo en la API — que es la diferencia entre una política y una sugerencia.

8 · La granularidad del Pod: la pregunta abierta

Ésta es la indagación viva del diseño, y se deja abierta a propósito: cerrarla antes de tener un Pod real funcionando sería adivinar.

La pregunta ingenua era «¿un Pod por entidad (Customer) o por capacidad (Customer Churn Management)?». La respuesta que se perfila es que la granularidad no es del modelo, es de cada Pod — y por tanto evoluciona:

• Un Pod puede ser entidad-forma (Customer): mucho contexto, capacidades genéricas.
• Un Pod puede ser capacidad-forma (Gestión de Churn): compone varios Pods entidad, y sus capacidades son las del proceso, no las del registro.
• Un Pod capacidad-forma que se usa mucho puede querer materializarse; uno entidad-forma que casi nadie pide, no.

Si eso se sostiene, el modelo necesita que un Pod pueda componer otros Pods desde el primer día — no como extensión futura, porque retrofitear composición en un modelo plano es caro. Es la única consecuencia estructural que este apartado impone sobre P2.

Lo que queda genuinamente por resolver:

• ¿Un Pod capacidad-forma compone Pods entidad, o los proyecta (vista propia)? Componer preserva una sola verdad; proyectar da libertad y duplica.
• ¿Puede un Pod nacer del feedback — es decir, que el uso sugiera un Pod que no existe? Es la versión ambiciosa del bucle de §7 y probablemente la más valiosa.
• ¿Cuál es la unidad de política: el Pod, el atributo, o la capacidad? Los tres son defendibles y llevan a modelos de autorización muy distintos.
• ¿Qué pasa con el versionado? Un agente en producción razonando contra Customer v3 mientras alguien publica v4 es un problema real, no teórico.

9 · Decisiones

Cerradas

• La ontología legacy queda FUERA, también para las acciones. action_types y su maquinaria (versionado, contratos, gating de submission) no se levantan al Pod Layer. Las capacidades del Pod se construyen limpias. Se paga en tiempo y se cobra en no arrastrar el acoplamiento que llevamos un programa entero dejando atrás.

Abiertas

1. Superficie de consumo: MCP de OM, MCP nuestro, o los dos. OpenMetadata ya envía un servidor MCP sobre su grafo. Pero un agente que habla con el MCP de OM ve metadata, no Pods — y eso rompe la invariante de §3. Lo más probable es que el MCP que sirve Pods tenga que ser nuestro, con el de OM apagado o restringido a uso interno. Hay que verificarlo antes de comprometerse.
2. Granularidad y composición — §8 entero.
3. Presupuesto y evaluación de agentes. Snowflake los trata como primitivos de plataforma. Nosotros no los tenemos y hoy no hacen falta — pero conviene no diseñar el Pod Layer de forma que luego no quepan.

10 · Qué invalida esto de lo ya escrito

Honestidad de estado, para que nadie construya sobre un plano viejo:

Nada de lo invalidado está aplicado ni desplegado: la migración no se ha corrido y las rutas no se han commiteado. El coste del giro es de horas, no de semanas.