El problema
Los flujos empresariales no pueden darle a un LLM una conexión a base de datos y confiar en que todo salga bien. Airlock Agents es una plataforma multiagente que responde preguntas sobre documentación interna, consulta una base de datos analítica real y propone acciones — con permisos por rol, puertas de aprobación humana y un registro de auditoría completo entre cada agente y los sistemas que toca.
Enfoque y decisiones
Un agente supervisor en LangGraph enruta cada petición a un especialista —
docs_qa, analyst o actions — pero el especialista solo existe con las
herramientas que concede el rol de quien pregunta. Cada sistema externo
(documentación, base de datos, tickets) vive detrás de su propio servidor
MCP a medida, así que los agentes nunca tienen credenciales directamente:
- Defensa en profundidad, no ingeniería de prompts. Los permisos rol→ herramienta deciden con qué se construye el agente; el servidor MCP revalida en cada llamada; el servidor SQL se conecta con un rol de base de datos de solo lectura. Tres capas independientes.
- La aprobación como estado durable. Una llamada a una herramienta
criticalinterrumpe el run de LangGraph víainterrupt(); el grafo se guarda en Postgres y puede reanudarse horas después desde una cola de aprobación — no un callback que muere con el proceso. - Servicio de modelos totalmente local. Ollama detecta la VRAM/RAM del
host al arrancar y elige un nivel de modelo (
qwen3:32bhastaqwen3:4ben CPU) — ningún prompt, documento o consulta sale de la máquina. - Un único trace ID de principio a fin, que enlaza la petición HTTP, los pasos del agente, las llamadas MCP, la traza LLM de Langfuse y las filas del registro de auditoría — así una mala respuesta es depurable, no solo registrable.
- Preparado para desplegarse, no solo para una demo. Docker Compose para local y manifiestos kustomize para Kubernetes: despliegues de la API y de los servidores MCP, autoescalado y un job de migraciones.
Los datasets son reales, no sintéticos: 8 páginas del GitLab Handbook público
para docs_qa, y 541.909 transacciones reales de comercio minorista del Reino
Unido (UCI Online Retail, con cancelaciones y compras sin registro incluidas)
para analyst. Los ground truths de evaluación se calculan por SQL contra los
datos cargados, no se escriben a mano.
Resultados
Puerta de evaluación offline sobre qwen3:8b (RTX 2070 8 GB) — superada:
| Suite | Métrica | Puntuación | Umbral |
|---|---|---|---|
docs_qa | fuente citada correcta | 0,86 | ≥ 0,80 |
docs_qa | fidelidad (juez LLM) | 0,94 | ≥ 0,75 |
analyst | cifra coincide con el ground truth SQL sobre 541k filas | 1,00 | ≥ 0,70 |
routing | el supervisor eligió el especialista correcto | 0,92 | ≥ 0,85 |
actions | herramienta crítica interrumpida para aprobación | 1,00 | = 1,00 |
En la misma GPU, una respuesta de documentación tarda unos 6 s (~2,1k tokens) y una ejecución de analyst entre 8 y 20 s de SQL en varios pasos sobre las 541k filas.
La puerta no es decorativa — detectó que el traspaso supervisor→subagente alucinaba confirmaciones de tickets en un modelo pequeño, y un run de analyst respondiendo una pregunta de 2024 con cifras acumuladas de todo el histórico.
Qué matizaría
Los conjuntos de evaluación son pequeños (4–14 casos por agente) y los juzga un modelo local de la misma familia, así que las puntuaciones son una puerta de regresión, no una afirmación de benchmark. El siguiente paso real es una ruta de servicio con vLLM probada bajo carga para despliegue multi-GPU — Ollama vale para un modelo residente, no para carga concurrente.