Arquitectura de agentes de IA
Arquitectura de agentes de IA
La mayoría de los contenidos sobre "agentes de IA" hablan de cómo hacer que un modelo haga más cosas con el prompt adecuado. Esta página trata de la otra mitad: la arquitectura que mantiene las acciones de un agente seguras, revisables y reversibles una vez que está conectado a infraestructura real — no una demo de chatbot.
El problema de darle a un agente acceso real
Un agente que solo puede responder preguntas es fácil de razonar. Un agente que puede actuar — publicar algo, cambiar infraestructura, resolver un incidente — necesita un sistema alrededor, no solo un mejor prompt. Mi enfoque, cubierto a un nivel más alto en Automatización IA y sistemas de agentes, viene de tratar un pipeline de agentes como trataría un pipeline de datos: versionado, observable y construido para fallar en voz alta en lugar de en silencio.
Los patrones sobre los que construyo
- Filtros de aprobación en cualquier cosa irreversible. Un agente puede proponer o preparar una acción, pero publicar, desplegar o resolver algo marcado como anomalía pasa por un paso explícito de aprobación humana antes de tener efecto.
- Controles de identidad y alcance antes de acciones de escritura. Verificar sobre qué está a punto de actuar realmente el agente — no solo confiar en el plan que generó — antes de cualquier llamada que cambie el estado.
- Artefactos inmutables. Lo que se aprueba queda con un hash, así que lo que se ejecuta es demostrablemente idéntico a lo que una persona aprobó, no una versión regenerada de ello.
- Ejecución de un solo uso, no reintentos silenciosos. Sin ninguna ruta genérica de "forzar" o "bypass" alrededor de un filtro de aprobación, y sin repetición en lote de una acción sensible sin una aprobación nueva.
- Registros de auditoría de solo apéndice. Cada acción de agente que importa queda registrada de una forma que no se puede editar en silencio después, así que "automatizado" nunca se convierte en "sin rendición de cuentas".
- Una superficie de revisión dedicada para desviaciones. Mi propio sistema interno de operaciones de agentes de IA tiene una interfaz de revisión humana específicamente para acciones que un agente toma y que quedan marcadas como desviación de lo esperado — revisadas antes de considerarlas resueltas, no después.
Dónde termina la capa de razonamiento y empieza la orquestación
Mantengo estas como dos capas separadas en lugar de un solo bloque de lógica de agente. Claude / Claude Code se encarga de las partes que necesitan juicio y razonamiento — leer el estado, decidir qué hacer, redactar la acción. n8n se encarga de la lógica determinista alrededor: programación, llamadas de integración, mover datos entre sistemas, y hacer cumplir el propio filtro de aprobación como un paso concreto del flujo en lugar de algo que el agente pudiera evitar hablando. Mantener el filtro fuera de la capa de razonamiento es deliberado — un paso que impone un flujo determinista es un paso que un agente no puede saltarse en silencio.
Un ejemplo concreto: Traffic OS
El pipeline de publicación de Traffic OS es el ejemplo público más claro de esta arquitectura en producción: aislamiento de credenciales por canal, verificación en vivo de la identidad del canal antes de cualquier acción de escritura, un hash inmutable de cada artefacto aprobado, un paso de aprobación creativa, un paso final de aprobación de publicación, controles de publicación canario de un solo uso, y un historial de auditoría de solo apéndice — sin ninguna ruta genérica de bypass alrededor de nada de esto. Ver el resumen para revisores y cumplimiento para el desglose completo.
Cuándo no dejo que el agente publique
Un filtro de aprobación solo vale la pena si puede decir que no. Mi pipeline diario de blog tiene varios: evidencia, hechos, narrativa, privacidad y QA del sitio, más un único intento de reparación acotado. Lo sometí a una prueba de aceptación estricta para publicar sin mí. Necesitaba que las tres ejecuciones fueran elegibles y produjo dos. No aflojé los filtros para llegar a tres, así que producción sigue con aprobación humana. La explicación completa está en mi sistema de IA pasó 2 de 3 pruebas para publicar solo. Dos fallos reales que he documentado: el primer fallo en producción de Traffic OS, y uno más silencioso,un bug silencioso que bloqueó mi pipeline de contenido.
Trabaja conmigo
Si estás diseñando o revisando un sistema de agentes de IA que necesita ejecutar acciones reales de forma segura — no solo responder preguntas — ve Proyectos para más de lo que he construido, o ponte en contacto a través de la página de contacto.