Introducción
Las empresas que hoy despliegan agentes de IA en producción enfrentan un problema crítico: la falta de un estándar unificado para gestionar contextos, permisos y estados entre múltiples modelos y herramientas. Mientras los modelos de frontera mejoran su rendimiento, la utilidad real de un agente depende de su capacidad para interactuar con datos empresariales en tiempo real, aplicar políticas de seguridad dinámicas y mantener sesiones persistentes. Databricks, en su reciente Data + AI Summit 2026, presentó tres iniciativas clave —Omnigent, LTAP y Lakebase— que apuntan a resolver estos desafíos mediante código abierto, arquitecturas unificadas y un enfoque radical en las bases de datos como capa crítica.
El mensaje central es claro: el futuro de la computación basada en agentes no se trata solo de modelos más potentes, sino de sistemas que se integren profundamente con los datos operativos de la empresa. Esto implica repensar desde las bases de datos hasta las políticas de seguridad, pasando por protocolos comunes para agentes. La pregunta clave es: ¿cómo construir una infraestructura lo suficientemente flexible para soportar agentes personalizados, sesiones compartidas y controles de gasto en entornos empresariales?
Qué ocurrió
En el Data + AI Summit 2026, los cofundadores de Databricks, Matei Zaharia y Reynold Xin, detallaron cómo la empresa está evolucionando desde su modelo tradicional de lakehouse hacia una plataforma de operaciones para agentes de IA. Tres anuncios destacan por su impacto técnico:
- Omnigent: Un meta-harness de código abierto que actúa como capa de abstracción sobre agentes existentes (Claude Code, Codex, Cursor, etc.) y herramientas internas. Su objetivo es unificar la gestión de sesiones, permisos, historial y costos, resolviendo el problema de portabilidad y colaboración entre agentes heterogéneos. Databricks ya lo usa internamente para sus flujos de desarrollo, donde más de 50–60 millones de máquinas virtuales procesan exabytes de datos diariamente.
- LTAP (Live Transactional Analytics Platform): Una propuesta para reemplazar el paradigma tradicional de ETL/ELT con un almacenamiento unificado que combine transacciones y analítica en tiempo real. A diferencia de los sistemas HTAP (Hybrid Transactional/Analytical Processing), LTAP no intenta colapsar los motores de consulta, sino reescribir la capa de almacenamiento para que los datos transaccionales se escriban directamente en formatos columnares como Parquet. Esto evita los problemas de CDC (Change Data Capture), que Databricks describe como «corrupción de datos continua» por su fragilidad en pipelines nocturnos.
- Lakebase: Una capa de abstracción que expone datos operativos a los agentes en tiempo real, eliminando la necesidad de replicar información en sistemas separados. Su enfoque se basa en consultas directas sobre el estado operativo (transacciones, logs, permisos), en lugar de telemetría histórica. Según Xin, esto responde a una necesidad crítica: «los agentes no necesitan datos del pasado; necesitan el estado correcto en el momento exacto en que actúan».
Además, Databricks reafirmó su postura sobre la obsolescencia de las bases de datos vectoriales como categoría separada, argumentando que LTAP ya soporta búsquedas semánticas mediante índices integrados. También criticó el enfoque de Snowflake, señalando que su arquitectura no está preparada para el Agent Cloud, donde los modelos requieren acceso contextualizado a datos vivos y no solo a consultas SQL estáticas.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
DevOps y Cloud
- Omnigent introduce un cambio paradigmático: hasta ahora, cada herramienta de agentes (Cursor, Pi, etc.) tenía su propio harness y API. Omnigent estandariza sesiones persistentes, cancelación de tareas, flujos de herramientas y control de costos, reduciendo la complejidad operativa. Para equipos de DevOps, esto significa menos integraciones ad-hoc y más consistencia en entornos híbridos (nube + on-premise).
- LTAP redefine el rol de las bases de datos en arquitecturas basadas en agentes. Tradicionalmente, los sistemas HTAP (como Apache Cassandra + Spark) intentaban combinar OLTP y OLAP en un mismo motor, lo que generaba cuellos de botella. LTAP propone unificar el almacenamiento (usando formatos como Parquet) y delegar el procesamiento a motores especializados, algo que Databricks ya implementa en su lakehouse con Delta Lake.
- Lakebase elimina la réplica de datos para agentes. Hoy, muchas empresas mantienen data lakes separados para analítica y bases de datos transaccionales. Con Lakebase, los agentes acceden directamente al estado operativo, reduciendo latencia y evitando inconsistencias. Esto es crítico para flujos como CI/CD automatizados, donde un agente podría necesitar leer logs de despliegues en tiempo real.
Seguridad
- Agentes con acceso a datos confidenciales: Un riesgo documentado es que un agente mal configurado lea documentos internos, instale paquetes npm comprometidos y filtre datos. Databricks propone políticas de seguridad contextuales y basadas en estado, donde los permisos no sean estáticos (ej.: «este usuario puede leer la tabla X»), sino dinámicos (ej.: «este agente puede leer la tabla X solo si está en el contexto de esta tarea Y, y con un límite de gasto de $500″).
- Control de gasto en agentes: Un agente con acceso a logs puede consumir $500 en minutos si no hay límites configurados. Omnigent incluye métricas integradas para rastrear:
– Número de llamadas a APIs externas.
– Bytes transferidos en sesiones.
- Formato abierto: Al open-sourcear Omnigent, Databricks evita el vendor lock-in en la capa de agentes, permitiendo a las empresas auditar el código y adaptarlo a sus necesidades sin depender de un solo proveedor.
Infraestructura
- Escala de Databricks: La empresa procesa exabytes de datos diariamente con 50–60 millones de VMs en su nube. Esto le da una ventaja única para prototipar sistemas como LTAP, donde millones de transacciones deben ser analizadas en tiempo real.
- Cultura de prototipado rápido: Databricks implementa cambios en su infraestructura sin procesos burocráticos. Por ejemplo, LTAP se desarrolló a partir de una década de trazas y cuatrillones de puntos de datos, permitiendo optimizar consultas antes de llegar a producción.
Detalles técnicos
Omnigent: La capa de infraestructura para agentes
Omnigent es un framework de código abierto escrito en Rust y Python que actúa como puente entre agentes y sistemas empresariales. Su arquitectura incluye:
- API unificada para sesiones: Todos los agentes (Claude Code, Codex, etc.) implementan la misma interfaz para:
– Acceder a archivos (scratchpads).
– Llamar a herramientas externas (ej.: APIs de AWS).
– Gestionar permisos mediante políticas basadas en contexto (ej.: «este agente solo puede usar la herramienta aws:ec2:describe-instances si el usuario tiene rol devops«).
- Sandboxes en la nube: Omnigent lanza entornos efímeros (usando Kubernetes + Firecracker) para ejecutar código de agentes sin afectar sistemas críticos. Esto ya lo usa Databricks internamente para pruebas de modelos, donde cada agente tiene un espacio aislado con acceso controlado a recursos.
- Métricas de gasto: La versión actual de Omnigent (v0.9.0) incluye un dashboard integrado que registra:
{
"agent_id": "genie-123",
"session_duration_ms": 45000,
"cpu_seconds": 12.4,
"external_api_calls": 8,
"cost_usd": 0.32,
"data_transfer_bytes": 1048576
}
LTAP: HTAP hecho bien
LTAP aborda un problema conocido en bases de datos: la fragilidad de CDC. Según Reynold Xin:
> «CDC es tan frágil que bromeamos con que significa ‘corrupción de datos continua’. Los pipelines se rompen a las 3 a.m. porque alguien cambió un esquema en producción.»
La propuesta de LTAP se basa en:
- Escritura directa en formatos columnares: En lugar de usar CDC para replicar transacciones a un data warehouse, LTAP escribe los datos transaccionales directamente en Parquet (usando Delta Lake 3.0). Esto permite:
– Transacciones con aislamiento serializable (gracias a Delta Lake’s optimistic concurrency control).
– Retrocompatibilidad: Los motores de consulta existentes (Spark, Trino) siguen funcionando sin cambios.
- Separación de responsabilidades:
– Analítica: Motor OLAP (ej.: Spark) leyendo directamente del almacenamiento unificado.
- Soporte para búsquedas semánticas: LTAP incluye un índice integrado que permite consultas vectoriales sin necesidad de un vector database separado. Por ejemplo:
SELECT * FROM orders
WHERE embedding_match(
'SELECT product_embedding FROM catalog',
'buscar productos similares a X'
) > 0.8;
- Delta Lake: ≥ 3.0 (requiere Apache Spark 3.5+).
- PostgreSQL con plugin LTAP: ≥ 16.0 (versión experimental).
Lakebase: Datos vivos para agentes
Lakebase expone una API de estado en tiempo real para agentes, evitando réplicas de datos. Su diseño incluye:
- Consultas sobre el estado operativo: En lugar de usar data lakes o warehouses, los agentes consultan directamente:
– Logs de despliegues (para CI/CD).
– Permisos dinámicos (ej.: «este agente puede leer el repo dev-team solo si está en la tarea deploy-prod«).
- Integración con Omnigent: Cuando un agente inicia una sesión, Lakebase le provee el contexto necesario (ej.: «el usuario
aliceejecutó un modelo hace 2 minutos con los datosdataset-42«). Esto se implementa mediante:
– Streaming (usando Apache Kafka o Pulsar) para actualizaciones en tiempo real.
Qué deberían hacer los administradores y equipos técnicos
1. Evaluar Omnigent para estandarizar agentes
Si su organización usa múltiples herramientas de agentes (Cursor, Claude Code, etc.), implemente Omnigent v0.9.0+ para:
- Unificar APIs: Migre agentes existentes a la interfaz de Omnigent. Ejemplo con Python:
from omnigent import AgentHarness
harness = AgentHarness(
agent_type="claude-code",
sandbox="k8s-firecracker",
spend_limit_usd=5.0 # Límite por sesión
)
- Habilitar sandboxes: Configure entornos aislados para agentes no confiables (ej.: código de terceros). Use:
helm install omnigent-sandbox ./omnigent/charts/sandbox \
--set resources.limits.cpu=2 \
--set resources.limits.memory="4Gi"
- Monitorear gasto: Active el dashboard de métricas y configure alertas para agentes que superen umbrales. Ejemplo con Prometheus:
- alert: AgentHighSpend
expr: rate(omnigent_agent_cost_usd[5m]) > 10
for: 5m
labels:
severity: warning
annotations:
summary: "Agente con alto gasto ({{ $value }} USD)"
2. Planificar la migración a LTAP
Si su organización depende de ETL/ELT, evalúe LTAP para:
- Reemplazar CDC: Elimine pipelines de replicación y escriba datos transaccionales directamente en Parquet. Ejemplo con Delta Lake:
from delta.tables import DeltaTable
DeltaTable.merge(
source="postgres://orders",
target="dbfs:/mnt/data/orders",
condition="source.id = target.id",
update={
"target.quantity": "source.quantity",
"target.last_updated": "current_timestamp()"
}
)
- Optimizar consultas: Aproveche Delta Lake 3.0 para consultas analíticas sin réplica. Ejemplo:
-- Consulta en tiempo real sobre transacciones
SELECT
customer_id,
SUM(amount) as total_spent
FROM delta.`/mnt/data/orders`
WHERE _commit_timestamp > now() - INTERVAL 1 HOUR
GROUP BY customer_id;
- Probar el plugin LTAP para PostgreSQL: Instale la versión 16.0+ con soporte experimental para LTAP:
sudo apt install postgresql-16-ltap-plugin
psql -c "CREATE EXTENSION ltap;"
3. Implementar Lakebase para agentes
Para exponer datos operativos a agentes:
- Configure webhooks para eventos críticos: Ejemplo con AWS Lambda:
import boto3
from lakebase import WebhookClient
client = WebhookClient(
endpoint="https://lambda.us-east-1.amazonaws.com/2024-01-01/functions/agent-context/invocations"
)
# Dispara cuando un modelo complete una tarea
client.trigger(
event_type="model_completion",
payload={
"task_id": "genie-42",
"data_ref": "s3://datasets/prod/dataset-42",
"user": "alice"
}
)
- Use streaming para actualizaciones: Integre Lakebase con Kafka para datos en tiempo real:
lakebase:
kafka:
bootstrap_servers: "kafka-cluster:9092"
topics:
- "agent-events"
- "deployment-logs"
4. Seguridad: políticas contextuales y auditoría
- Aplique políticas basadas en estado: Use Omnigent para definir reglas como:
policies:
- id: "restrict-internal-docs"
condition:
resource_type: "document"
contains: "confidential/"
action: "deny"
context:
task: "code-review"
user_role: "developer"
- Limite gastos por agente: Configure umbrales en Omnigent:
kubectl patch deployment omnigent-controller \
--type='json' \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/env/-",
"value": {"name": "AGENT_SPEND_LIMIT_USD", "value": "10"}}]'
- Audite sesiones: Exporte logs de Omnigent a un SIEM (ej.: Splunk):
{
"timestamp": "2026-05-20T14:30:00Z",
"agent_id": "genie-123",
"user": "alice",
"actions": [
{"tool": "aws:ec2:describe-instances", "cost_usd": 0.05},
{"tool": "github:list-repos", "cost_usd": 0.01}
],
"session_status": "completed"
}
Conclusión
El anuncio de Databricks en el Data + AI Summit 2026 no se trata solo de nuevas herramientas, sino de una visión radicalmente distinta de cómo interactúan los agentes de IA con los sistemas empresariales. Omnigent, LTAP y Lakebase representan un cambio de paradigma:
- De modelos aislados a sistemas integrados: Los agentes ya no son scripts sueltos, sino componentes críticos con sesiones persistentes, permisos dinámicos y métricas de gasto.
- De bases de datos especializadas a almacenamiento unificado: LTAP elimina la necesidad de CDC y vector databases, mientras que Lakebase expone datos en tiempo real sin réplicas.
- De seguridad estática a contexto dinámico: Las políticas deben adaptarse al estado operativo, no a roles fijos.
Para equipos de DevOps e infraestructura, esto significa repensar arquitecturas:
- Adopten Omnigent para estandarizar agentes y reducir complejidad.
- Migrén a LTAP si aún dependen de ETL/ELT, aprovechando Delta Lake 3.0+.
- Implementen Lakebase para dar a los agentes acceso directo al estado operativo.
- Refuercen la seguridad con políticas contextuales y control de gasto.
La pregunta ya no es «¿Cómo desplegamos un agente?», sino «¿Cómo construimos una infraestructura que permita a los agentes actuar con contexto, seguridad y escalabilidad?». Databricks está apostando fuerte por la respuesta: ecosistemas abiertos, datos unificados y sistemas preparados para la era de los agentes.