Los 3 Sistemas de Agentes de IA que Todo Constructor Debe Entender
Fallos de los agentes
La mayoría de los sistemas de agentes no fallan porque el modelo sea demasiado débil
Fracasan porque el sistema alrededor del modelo nunca fue diseñado como un sistema
Las herramientas no son confiables
El estado desaparece entre ejecuciones
El agente reintenta sin aprender nada
Los flujos de trabajo se ramifican de maneras que nadie puede inspeccionar
Entonces cada fallo se le atribuye al modelo
Ese es el diagnóstico equivocado
Hay tres capas distintas de ingeniería detrás de un agente serio:
- el entorno de ejecución le da al modelo un lugar para trabajar
- el bucle le da al trabajo un ciclo de retroalimentación
- el grafo le da al proceso una ruta explícita
Se superponen
Pueden contenerse entre sí
Pero resuelven problemas diferentes
Un modelo decide. Un entorno de ejecución le permite actuar. Un bucle lo obliga a probar el resultado. Un grafo controla lo que puede suceder a continuación.
La versión en 30 segundos
Ingeniería del entorno de ejecución: construye el entorno operativo alrededor del modelo
Herramientas, memoria, archivos, permisos, entornos aislados, enrutamiento, puntos de control, trazas y aprobaciones humanas viven aquí
Ingeniería de bucles: diseña trabajo repetido y retroalimentación
El agente produce algo, lo verifica contra evidencia, recibe una señal de fallo útil y lo intenta de nuevo bajo una regla acotada
Ingeniería de grafos: hace explícito el flujo de control
Define los nodos, ramificaciones, uniones, trabajo paralelo, ciclos permitidos, transiciones de estado y rutas de salida
La forma más fácil de recordar la diferencia es:
1ENTORNO DE EJECUCIÓN = AMBIENTE2BUCLE = RETROALIMENTACIÓN3GRAFO = FLUJO
Esta distinción importa en cuanto un agente sale de una demo y comienza a tocar archivos reales, APIs, clientes, dinero o código de producción
Por qué la gente sigue mezclándolos
Las tres capas se sitúan alrededor del mismo modelo
Las tres afectan la confiabilidad
Las tres pueden incluir algo que parece un bucle
Y en un prototipo pequeño, las tres suelen estar enterradas dentro de un solo script
Eso hace que parezcan intercambiables
No lo son
Considera un agente básico que usa herramientas
1preguntar al modelo2recibir llamada a herramienta3ejecutar herramienta4devolver observación5preguntar al modelo de nuevo6detenerse cuando termine
Ese pequeño ciclo es parte del tiempo de ejecución
Pero las definiciones de herramientas, el sistema de archivos y el almacén de estado pertenecen al entorno de ejecución
La política de prueba y reintento es una decisión de diseño del bucle
La elección entre investigador, revisor y publicador es una decisión de diseño del grafo
Un solo software puede contener las tres capas a la vez
La arquitectura más limpia comienza nombrándolas por separado
Capa 1: Ingeniería del Entorno de Ejecución
Un modelo en bruto puede transformar entrada en salida
No puede mantener independientemente el estado del proyecto, ejecutar un conjunto de pruebas, inspeccionar un navegador, escribir archivos de forma segura, aplicar permisos o retomar mañana donde lo dejó hoy
El entorno de ejecución proporciona esas capacidades
La definición más simple es:
El modelo es la inteligencia. El entorno de ejecución es la maquinaria que hace que esa inteligencia sea útil.
Elimina el modelo de tu diagrama de arquitectura
Todo lo que aún sea visible probablemente es parte del entorno de ejecución
Este es el cambio hacia producción que Boris Cherny señala constantemente a través de Claude Code: hooks, ejecuciones programadas, árboles de trabajo aislados, agentes personalizados y ejecución en paralelo no son trucos de prompts
Son primitivas del entorno de ejecución
https://x.com/bcherny/status/2038454336355999749
Qué pertenece a un entorno de ejecución serio
Contexto
- instrucciones del sistema
- conocimiento recuperado
- estado de la conversación
- políticas de tareas
- habilidades y procedimientos operativos
Superficies de acción
- APIs
- control del navegador
- shell y ejecución de código
- bases de datos
- herramientas MCP
- agentes especialistas
Persistencia
- archivos
- puntos de control
- estado de sesión
- registros de progreso
- historial de git
- memoria a largo plazo
Control de ejecución
- tiempos de espera
- límites de reintento
- presupuestos de tokens y costos
- enrutamiento de modelos
- transferencias
- puertas de aprobación
Seguridad
- entornos aislados
- permisos de mínimo privilegio
- listas permitidas
- manejo de secretos
- autorización humana
Observabilidad
- trazas
- entradas y salidas de herramientas
- transiciones de estado
- costo y latencia
- resultados de evaluación
Dónde la ingeniería del entorno de ejecución demuestra su valor
El trabajo del entorno de ejecución se vuelve crítico cuando las tareas duran más de una ventana de contexto
Un agente de codificación que trabaja durante horas no puede depender solo del historial del chat
Necesita artefactos duraderos que otra sesión pueda entender
Una configuración útil podría incluir:
- un inicializador que inspecciona el espacio de trabajo
- un archivo de progreso que explica qué está hecho y qué falta
- commits de git que preservan estados de trabajo
- puntos de control antes de acciones riesgosas
- herramientas de verificación que producen evidencia clara
Esto no es un mejor prompt
Es un mejor entorno de trabajo
Comienza con ingeniería del entorno de ejecución cuando el agente:
- no puede acceder a la capacidad correcta
- pierde progreso entre sesiones
- tiene permisos demasiado amplios
- se comporta de manera diferente entre entornos
- no puede ser pausado, inspeccionado o reanudado
- produce fallos que nadie puede reconstruir
Capa 2: Ingeniería de Bucles
Todo agente que usa herramientas ya tiene un pequeño bucle interno
1modelo -> acción -> observación -> modelo
La ingeniería de bucles comienza cuando diseñas intencionalmente los ciclos alrededor de ese comportamiento
El objetivo no es hacer que el agente se repita para siempre
El objetivo es convertir un intento único en un proceso gestionado
El bucle de verificación
El bucle externo más útil es simple
1CONSTRUIR2 ↓3VERIFICAR CONTRA EVIDENCIA4 ↓5¿PASA? ── sí ──> DETENER6 │7 no8 ↓9DEVOLVER RETROALIMENTACIÓN ESPECÍFICA10 ↓11REINTENTAR CON UN LÍMITE
La verificación puede ser determinista:
- las pruebas pasan
- el esquema valida
- los enlaces resuelven
- los números concilian
- los archivos compilan
O puede requerir un revisor:
- el argumento está completo
- el tono coincide con la audiencia
- la evidencia respalda la conclusión
- el cambio está correctamente delimitado
La regla es la misma
No bucles sobre confianza
Bucles sobre evidencia
"El agente dice que está terminado" no es una prueba
"Las pruebas pasan, las fuentes resuelven y el revisor aprobó el diff" es una prueba
El apalancamiento proviene de construir el ciclo una vez y dejar que el sistema lo ejecute por ti
Las tareas programadas de Claude son la versión visible del producto de este mismo cambio: define trabajo recurrente una vez y deja que el sistema lo retome sin otro prompt manual
La programación es solo el desencadenante
Las verificaciones, la retroalimentación y la condición de salida son lo que convierte la tarea recurrente en un bucle diseñado
https://x.com/claudeai/status/2026720870631354429
La anatomía de un bucle útil
Todo bucle de producción necesita siete cosas
1. Desencadenante
Lo que inicia otro ciclo: una solicitud, programación, webhook, prueba fallida, nuevo documento o resultado de evaluador
2. Objetivo
Un estado medible a alcanzar, no "seguir mejorando"
3. Estado
Lo que el siguiente intento debe saber sin reproducir todo el historial
4. Política de acción
Lo que el agente puede cambiar, llamar, delegar o gastar
5. Evidencia
Pruebas, citas, diffs, métricas, esquemas o revisión humana
6. Retroalimentación
Una explicación compacta de qué falló y qué debe cambiar
7. Regla de detención
Éxito, intentos máximos, agotamiento del presupuesto, tiempo de espera, error grave o escalación humana
Los bucles pueden apilarse
El bucle del agente realiza el trabajo
El bucle de verificación verifica el trabajo
Un bucle de eventos despierta al sistema cuando llega nuevo trabajo
Un bucle de mejora estudia las trazas de producción y cambia el entorno de ejecución mismo
1BUCLE DE EVENTOS2└── BUCLE DE VERIFICACIÓN3 └── BUCLE DEL AGENTE45BUCLE DE MEJORA POR TRAZAS6└── actualiza prompts, herramientas, políticas y evaluadores
Por eso la ingeniería de bucles es más grande que la ingeniería de prompts
Un prompt define lo que debería suceder durante una llamada al modelo
Un bucle define lo que el sistema hace después de esa llamada
El costo es obvio
Cada reintento, evaluador y revisor añade latencia y gasto
Añade un bucle cuando el costo esperado del fallo sea mayor que el costo de la verificación
Capa 3: Ingeniería de Grafos
La ingeniería de grafos hace una pregunta diferente
No "cómo debería trabajar el agente"
Sino "qué puede ejecutarse a continuación"
El trabajo se convierte en nodos
Las transiciones permitidas se convierten en aristas
El estado se mueve a través del grafo
Esa estructura puede representar:
- secuencias fijas
- ramificaciones condicionales
- expansión en paralelo
- uniones
- ciclos acotados
- rutas de recuperación
- interrupciones humanas
Qué deciden realmente los ingenieros de grafos
Límites de nodos
Qué trabajo pertenece a código normal, una llamada LLM, un agente especialista o un paso de revisión humana
Esquema de estado
Qué puede leer o actualizar cada nodo y cómo se fusionan los resultados paralelos
Condiciones de enrutamiento
Qué evidencia mueve el trabajo hacia adelante, hacia atrás, lateralmente o hacia escalación
Concurrencia
Qué puede ejecutarse en paralelo y qué debe esperar una unión
Ciclos y salidas
Dónde son legales los reintentos, cuántos intentos están permitidos y qué hace seguro al ciclo
Durabilidad
Dónde se checkpointea la ejecución y cómo se reanuda después de una interrupción
Cuándo vale la pena la ceremonia de un grafo
Usa un grafo cuando el proceso contenga ramificaciones significativas, especialistas en paralelo, aprobaciones, rutas de recuperación o transferencias con estado
No empieces con un grafo solo porque el flujo de trabajo tenga múltiples pasos
Si un agente capaz con tres herramientas puede resolver la tarea, un grafo puede añadir estructura sin añadir valor
Hay otro modo de fallo
Los equipos formalizan el flujo de trabajo antes de entender el trabajo
El resultado es un diagrama hermoso que codifica las suposiciones equivocadas
Comienza con un entorno de ejecución simple
Estudia trazas reales
Formaliza los caminos que se mantienen estables
El siguiente paso después de los bucles es hacer explícita la topología de ejecución
OpenAI empaquetó la misma idea en Agent Builder: un lienzo de flujo de trabajo visible para ejecución multiagente con barreras de seguridad y evaluaciones alrededor del grafo
https://x.com/OpenAIDevs/status/1975269388195631492
Cómo funcionan las tres capas juntas en un sistema real
Imagina un agente de investigación y publicación que produce un informe informativo de la industria
El entorno de ejecución proporciona:
- herramientas de navegador y búsqueda
- almacenamiento de fuentes
- un espacio de trabajo de redacción
- verificación de citas
- permisos y reglas de aprobación
- puntos de control y trazas
El grafo controla la ruta:
1INVESTIGAR2 ↓3BORRADOR4 ↓5VERIFICAR HECHOS ── fallo ──> INVESTIGAR6 │7 éxito8 ↓9REVISIÓN EDITORIAL ── fallo ──> BORRADOR10 │11 éxito12 ↓13APROBACIÓN HUMANA14 ↓15PUBLICAR
Los bucles viven dentro de esa ruta
El nodo de investigación puede buscar hasta que la cobertura de fuentes sea suficiente
El nodo de redacción puede revisar hasta que el evaluador de estilo pase
El nodo de verificación de hechos puede devolver afirmaciones no respaldadas exactas en lugar de un rechazo vago
El anidamiento es la parte importante
El grafo se ejecuta dentro del entorno de ejecución
Los bucles se ejecutan dentro de partes del grafo
El entorno de ejecución proporciona las herramientas, el estado y la evidencia que esos bucles necesitan
Las capas se superponen porque las capas de software real se superponen
Aún te dan tres palancas diferentes cuando el sistema falla
Diagnostica el fallo antes de cambiar la arquitectura
Síntoma
Empieza con
Solución probable
El agente no puede acceder a los datos correctos de forma segura
Entorno de ejecución
Mejor contrato de herramientas, permisos, entorno aislado e inyección de contexto
El agente olvida el progreso entre sesiones
Entorno de ejecución
Estado duradero, puntos de control, artefactos de progreso y compactación
El primer intento es cercano pero poco confiable
Bucle
Evaluador externo, pruebas deterministas, retroalimentación procesable y reintento acotado
El agente continúa después del éxito o se detiene antes de la prueba
Bucle
Estados terminales basados en evidencia y reglas de detención con presupuesto
Los especialistas deben ejecutarse en un orden controlado
Grafo
Nodos, aristas, condiciones de enrutamiento y uniones explícitas
Un fallo de múltiples pasos es imposible de localizar
Grafo + entorno de ejecución
Trazas con estado alineadas con nodos y transiciones
El proceso cambia demasiado rápido para un diagrama fijo
Entorno de ejecución más simple
Mantén la planificación impulsada por el modelo y retrasa la formalización del grafo
Esta tabla es más útil que discutir sobre terminología
Encuentra la capa propietaria del fallo
Arregla esa capa primero
Los errores costosos detrás de sistemas de agentes débiles
Construir el grafo demasiado pronto
No conviertas un proceso de negocio imaginado en cuarenta nodos antes de ver a un agente fuerte realizar el trabajo
Traza primero
Formaliza después
Dejar que el creador se evalúe a sí mismo
La autoevaluación es útil pero comparte los mismos puntos ciegos que el intento original
Prefiere verificaciones deterministas cuando sea posible
Usa un contexto de revisor aislado para evaluaciones subjetivas
Requiere aprobación humana para acciones de alto impacto
Definir el bucle como "seguir intentando"
Un reintento sin límite no es confiabilidad
Es una fuga de costos
Cada ciclo necesita evidencia fresca, un número máximo de intentos y una ruta de escalación nombrada
Convertir el entorno de ejecución en un almacén
Más herramientas no crean automáticamente un mejor agente
Un conjunto de herramientas abarrotado aumenta los errores de selección
Un contexto ruidoso aumenta la confusión
Permisos amplios aumentan el riesgo
Dale al agente el entorno más pequeño que pueda completar el trabajo
Culpar al modelo por fallos de orquestación
Un modelo más fuerte no puede reparar de forma confiable estado obsoleto, APIs rotas, esquemas de herramientas ambiguos o condiciones de salida faltantes
No actualices el modelo antes de probar que el modelo es el problema
Una lista de verificación para producción
Entorno de ejecución
- ¿las herramientas son limitadas, documentadas y observables?
- ¿el estado es duradero entre sesiones?
- ¿los permisos son de mínimo privilegio?
- ¿puede un operador pausar, inspeccionar y reanudar la ejecución?
- ¿cada acción importante puede reconstruirse a partir de trazas?
Bucle
- ¿qué evidencia prueba el éxito?
- ¿qué retroalimentación se devuelve después del fallo?
- ¿cuántos reintentos están permitidos?
- ¿qué sucede cuando se agota el presupuesto?
- ¿dónde se requiere juicio humano?
Grafo
- ¿qué caminos deben ser deterministas?
- ¿dónde puede ejecutarse trabajo en paralelo?
- ¿qué estado se comparte?
- ¿dónde están las uniones, aprobaciones y rutas de recuperación?
- ¿qué ciclos son legales y cómo terminan?
Evaluación
- ¿puede el equipo reproducir trazas reales?
- ¿pueden compararse versiones contra las mismas tareas?
- ¿puede atribuirse una mejora a un cambio específico?
Operaciones
- ¿se monitorean el costo y la latencia?
- ¿la tasa de fallos es visible por nodo y herramienta?
- ¿se mide la intervención humana?
- ¿el éxito a nivel de tarea se mide en producción?
La forma más simple de recordar la diferencia
La ingeniería del entorno de ejecución hace operativo al modelo
La ingeniería de bucles hace que el trabajo sea iterativo y verificable
La ingeniería de grafos hace que la ejecución compleja sea explícita y controlable
Ninguna reemplaza a las otras
Un grafo perfecto no puede salvar a un agente que pierde su estado
Un entorno de ejecución perfecto aún desperdicia dinero si el bucle no tiene evidencia ni regla de detención
Un bucle fuerte se vuelve difícil de operar cuando las ramificaciones, el paralelismo y las aprobaciones están escondidos dentro de código ad hoc
Los agentes confiables aparecen cuando las tres capas se diseñan juntas
Y cuando cada capa tiene un trabajo claro
1AMBIENTE -> ENTORNO DE EJECUCIÓN2RETROALIMENTACIÓN -> BUCLE3FLUJO -> GRAFO
Ese es el marco completo
Fuentes y lecturas adicionales
- Tareas programadas de Claude
- OpenAI AgentKit
- OpenAI Agents SDK
- AutoGen GraphFlow
- Construyendo Agentes de IA Efectivos
Si llegaste hasta aquí
Guarda el artículo y sigue a @0xwhrrari para más ingeniería práctica de agentes
También puedes leer otros artículos:
- Cómo configuré Obsidian + Claude como mi segundo cerebro
- Cómo configuré a Claude para que realmente haga trabajo
- Cómo configuré proyectos de Claude para que realmente funcionen
- 30 prompts de sistema de Claude que realmente uso
- Ingeniería de Bucles: La habilidad de IA que todo constructor necesita en 2026
- 30 configuraciones, atajos y flujos de trabajo de Claude Code que la mayoría de usuarios pasa por alto
- Cómo uso Claude Cowork para operar como una empresa unipersonal
