¿Qué es una capa de contexto?

Una capa de contexto es el registro aprobado de cómo funcionan los datos y el negocio de una organización: las definiciones, las reglas y los documentos que un agente de IA consulta antes de actuar. Se sitúa entre tu stack de datos y tus agentes. No es otro agente. Le dice a cualquiera de ellos qué significa «ingresos» aquí, cuál de las tablas parecidas es la oficial y qué excepción se aplica desde 2025.

Una persona lo aprende en unos seis meses de onboarding. Un agente no lo aprende nunca, porque nadie lo ha escrito donde él pueda leerlo. Está en YAML que nadie mantiene, hilos de Slack, PDFs y unas cuantas personas. La capa de contexto lo escribe, el equipo lo aprueba y los agentes lo reciben al responder.

La formulación más clara es «Your Data Agents Need Context» (Jason Cui y Jennifer Li, a16z, marzo de 2026). Su diagnóstico: los agentes de datos se equivocan en producción por razones que poco tienen que ver con el modelo: flujos frágiles, falta de aprendizaje contextual, un desajuste con la operativa real del negocio. Al conocimiento que les falta lo llaman tribal knowledge, y existe en todas las empresas. Simplemente nunca está donde el agente mira.

Su propuesta es una capa de contexto: un corpus donde el código convive con el lenguaje natural, se mantiene al día, lo refinan personas y se expone a los agentes en tiempo real. La descomponen en cinco componentes. El vocabulario de la categoría (conocimiento tribal, abstención, cita tipada, procedencia) está definido en el glosario.

Para el ingeniero, la capa de contexto es lo que hace que su agente acierte. Para legal, seguridad y el CDO es otra cosa: trazabilidad. Cada respuesta lleva citas tipadas (qué entrada o documento exacto, qué versión, quién la aprobó y cuándo se verificó por última vez), de modo que cualquier afirmación de un agente se puede defender ante un auditor sin abrir un ticket. Cuando el contexto falta, ha caducado o está en conflicto, la respuesta lo reconoce en lugar de rellenar el hueco. En un entorno regulado, decir que no se puede responder vale más que una cifra inventada.

No es una capa semántica. Las capas semánticas (Cube, dbt Semantic Layer) modelan métricas sobre tablas, y lo hacen bien. Lo que no cabe en su YAML es la parte condicional («para CRM, los clientes nuevos están en Salesforce desde 2025») y los documentos donde vive la política de la empresa. La capa de contexto lee tu dbt. No lo sustituye. Nadie tira nada para adoptarla.

No es un catálogo de datos. Los catálogos como Atlan son productos de gobernanza para personas: lineage, calidad, workflows de stewardship. La capa de contexto la consultan agentes en el momento de responder, y su unidad de valor es la definición aprobada, no el inventario.

No es RAG sobre la wiki. La recuperación encuentra el texto más parecido. Cuando un agente pregunta qué significa «ingresos», necesita la respuesta aprobada (una entrada, una versión, un aprobador) o un «no lo sé» si el contexto falta o está en conflicto. Ese contrato es una decisión de arquitectura, no un prompt. La documentación lo compara en detalle frente a las plataformas RAG gestionadas.

Renbase sirve contexto; tu agente actúa. No ejecuta ni genera SQL contra tu warehouse, y las credenciales nunca salen de tu lado. La introspección de esquemas corre como un CLI en tu máquina que solo envía borradores. La dirección de producto es que la capa también verifique el SQL aprobado contra sus fuentes en cada resincronización, y más adelante componga consultas a partir de definiciones aprobadas. Es dirección, no una fecha. Ejecutar consultas sobre definiciones que nadie ha verificado es el agente que describe a16z fallando.

Tampoco es lineage, calidad de datos ni stewardship. Si necesitas eso, necesitas además un catálogo. Ambos conviven sin problema.