Una guía práctica para las 3 capas que la gente sigue confundiendo
La mayoría de la gente habla de los agentes de IA como si fueran una sola cosa.
No lo son.
Cuando un agente va más allá de una demo de juguete y comienza a tocar archivos, APIs, documentos, clientes o código en producción, ya no estás simplemente "haciendo prompting a un modelo".
Estás diseñando un sistema.
Y en ese sistema, tres ideas se siguen mezclando:
- Ingeniería del harness (entorno de operación)
- Ingeniería del bucle (loop)
- Ingeniería del grafo
Todas giran en torno al mismo modelo.
Todas afectan la fiabilidad.
Y sí, todas pueden contener bucles.
Pero resuelven problemas diferentes.
Si las mezclas, terminas debuggeando la capa equivocada.
La respuesta en 30 segundos
Aquí está la versión clara:
- Ingeniería del harness construye el entorno alrededor del modelo
- Ingeniería del bucle diseña el ciclo repetido de trabajo y retroalimentación
- Ingeniería del grafo hace explícita la topología del flujo de trabajo
Un buen modelo mental es:
Entorno → Retroalimentación → Flujo
- El harness le da al modelo herramientas, memoria, control y un espacio de trabajo
- El bucle decide cómo se reintenta, verifica y mejora el trabajo
- El grafo define qué paso puede ocurrir a continuación
Esa es la diferencia.
Por qué estos términos importan ahora
Un modelo en bruto no puede hacer trabajo real por sí mismo.
No puede:
- mantener el estado del proyecto entre sesiones
- llamar a herramientas de forma segura
- inspeccionar un navegador
- imponer permisos
- reintentar trabajos fallidos
- validar la calidad del resultado
- enrutar tareas entre especialistas
- detenerse en el momento adecuado
Todo eso proviene del sistema que lo rodea.
A medida que el software de agentes madura, está surgiendo una pila práctica:
- El harness le da al modelo las condiciones de operación
- Los bucles hacen que el trabajo sea repetible y verificable
- El grafo hace que los flujos de trabajo complejos sean explícitos y controlables
Una vez que ves estas como capas separadas, gran parte de la confusión sobre la arquitectura de IA desaparece.
Lo que suele incluir un harness serio
- Inyección de contexto
Lo que el modelo ve antes de actuar:
- instrucciones
- conocimiento recuperado
- estado de la conversación
- memoria
- políticas
- reglas específicas de la tarea
- Superficies de acción
Lo que el modelo puede hacer:
- llamadas a APIs
- acciones en el navegador
- comandos de shell
- ejecución de código
- herramientas MCP
- bases de datos
- funciones personalizadas
- Persistencia
Lo que sobrevive a través del tiempo:
- archivos
- puntos de control (checkpoints)
- estado de la sesión
- registros de progreso
- historial de git
- memoria a largo plazo
- Control de ejecución
Cómo se gestiona la ejecución:
- reintentos
- tiempos de espera (timeouts)
- presupuestos
- selección de modelo
- creación de subagentes
- compuertas de aprobación
- Seguridad y gobernanza
Lo que mantiene el sistema seguro:
- permisos de mínimo privilegio
- aislamiento
- listas blancas
- manejo de secretos
- aprobación humana
- Observabilidad
Lo que te permite depurarlo:
- trazas
- entradas y salidas de herramientas
- transiciones de estado
- latencia
- coste
- resultados de evaluación
Por qué importa la ingeniería del harness
Dos equipos pueden usar el mismo modelo y obtener resultados completamente diferentes.
¿Por qué?
Porque un equipo le da al modelo:
- herramientas limpias
- estado estable
- memoria estructurada
- permisos claros
- ejecución observable
Y el otro le da:
- un prompt vago
- herramientas desordenadas
- contexto ruidoso
- sin memoria
- sin verificación
El modelo puede ser el mismo.
Las condiciones de trabajo no lo son.
La ingeniería del harness importa siempre que el agente:
- no pueda acceder a la capacidad correcta
- pierda contexto entre sesiones
- actúe de forma inconsistente entre entornos
- no pueda ser auditado
- tenga demasiados permisos
- no pueda recuperarse limpiamente tras una interrupción
Si el modelo no puede operar de forma fiable, el primer lugar donde mirar es el harness.
2. Ingeniería del bucle (loop)
Qué es
Todo agente que usa herramientas ya tiene un pequeño bucle incorporado:
- llamar al modelo
- observar el resultado
- ejecutar herramientas
- retroalimentar las observaciones
- repetir hasta terminar
La ingeniería del bucle comienza cuando diseñas intencionalmente ciclos adicionales alrededor de ese comportamiento.
No solo "preguntar de nuevo".
No solo "reintentar".
Sino un verdadero sistema de trabajo y retroalimentación.
Anatomía de un buen bucle
Desencadenante (Trigger)
¿Qué inicia un nuevo ciclo?
- solicitud del usuario
- prueba fallida
- nuevo documento
- ejecución programada
- webhook
- retroalimentación de un evaluador
Objetivo (Goal)
¿Qué condición específica estamos tratando de alcanzar?
No "seguir mejorando".
Un objetivo real.
Estado (State)
¿Qué necesita saber el siguiente ciclo?
- borrador actual
- intento anterior
- resultados de herramientas
- errores
- estado del progreso
Política de acción (Action Policy)
¿Qué se le permite hacer al agente?
- editar
- delegar
- llamar a herramientas
- gastar tokens
- escribir archivos
- abrir PRs
Evidencia (Evidence)
¿Cómo sabemos si funcionó?
- pruebas
- validación de esquemas
- citas
- diferencias (diffs)
- métricas
- aprobación del revisor
Retroalimentación (Feedback)
¿Qué falló exactamente?
La retroalimentación debe ser compacta y procesable.
Regla de parada (Stop Rule)
¿Cuándo termina?
- éxito
- tiempo de espera agotado
- presupuesto agotado
- máximo de reintentos alcanzado
- fallo irrecuperable
- escalado a un humano
El principio más importante en la ingeniería del bucle
**No bucles sobre la confianza.
Bucles sobre la evidencia.**
"El agente dice que está listo" no es una condición de parada.
Una condición de parada real se parece más a:
- las pruebas pasan
- el esquema valida
- las citas se resuelven
- el revisor aprueba
- la verificación de políticas está limpia
Eso es ingeniería del bucle.
Por qué la ingeniería del bucle no es solo ingeniería de prompts
Un prompt le dice al modelo qué hacer durante una llamada.
Un bucle define qué hace el sistema después de la llamada.
Eso incluye:
- cómo verifica los resultados
- cómo reacciona ante el fallo
- cómo persiste el progreso
- cómo decide continuar
- cómo termina
El prompting mejora una respuesta.
Un bucle mejora un proceso.
Eso es un problema de ingeniería muy diferente.
3. Ingeniería del grafo
Qué es
La ingeniería del grafo hace explícita la estructura del flujo de trabajo.
Responde a una pregunta diferente:
No solo "¿qué debería hacer el agente?" Sino "¿qué se permite que ocurra a continuación?"
En la ingeniería del grafo:
- los pasos son nodos
- las transiciones son aristas
- la ramificación es explícita
- el trabajo paralelo es explícito
- las uniones son explícitas
- los reintentos son explícitos
- las interrupciones humanas son explícitas
El grafo se convierte en el mapa de control del sistema.
Lo que los ingenieros de grafos realmente diseñan
Límites de los nodos
¿Qué pertenece a:
- una función determinista
- una llamada LLM
- un agente especialista
- un paso de revisión humana?
Esquema de estado
Qué puede leer o escribir cada nodo.
Condiciones de enrutamiento
Qué evidencia mueve el trabajo:
- hacia adelante
- hacia atrás
- hacia los lados
- hacia escalado
Concurrencia
Qué puede ejecutarse en paralelo y qué debe esperar.
Ciclos y salidas
Dónde se permiten reintentos, cuántos se permiten y cómo se detienen.
Durabilidad
Dónde ocurren los puntos de control y cómo se reanuda el flujo de trabajo tras una interrupción.
Cuándo valen la pena los grafos
Los grafos son valiosos cuando el proceso incluye:
- ramificaciones significativas
- aprobaciones
- traspasos entre especialistas
- trabajo paralelo
- rutas de recuperación
- flujos de trabajo de varios pasos con puntos de control explícitos
Son menos útiles cuando el trabajo es simplemente:
"Dale a un agente unas pocas herramientas y déjalo trabajar."
En ese caso, un harness sólido más unos pocos bucles pueden ser suficientes.
Un grafo añade claridad, pero también añade estructura.
Demasiada estructura demasiado pronto puede hacer que el sistema sea frágil.
Cómo funcionan juntas las 3 capas
Supongamos que estás construyendo un agente de investigación y publicación.
Tiene que:
- definir el alcance de un tema
- recopilar fuentes
- filtrar citas
- redactar un informe
- pasar una revisión legal
- publicar solo después de la aprobación
Así es como se asignan las capas:
Harness
Proporciona:
- acceso al navegador
- herramientas de búsqueda
- espacio de trabajo de archivos
- memoria
- citas
- aprobaciones
- trazas
- enrutamiento de modelos
Bucle
Maneja:
- reintentar la recuperación de fuentes cuando la evidencia es débil
- corregir fallos de citas
- ejecutar comprobaciones de calificación
- refrescar el trabajo cuando el mercado cambia
Grafo
Controla la ruta:
- definición de alcance
- investigación
- filtrado
- síntesis
- redacción
- revisión
- publicación
Con una compuerta humana antes del lanzamiento.
Por eso las 3 capas no son intercambiables.
Trabajan juntas, pero no son lo mismo.
Diagnostica el fallo antes de elegir la solución
Aquí está la regla práctica:
Si el agente no puede operar, arregla el harness
Ejemplos:
- falta de acceso a herramientas
- estado obsoleto
- memoria débil
- permisos incorrectos
- falta de observabilidad
Si el agente casi funciona pero no es fiable, arregla el bucle
Ejemplos:
- el primer borrador se acerca pero es débil
- el éxito es inconsistente
- los reintentos no están controlados
- no hay prueba de finalización
Si el proceso en sí es complejo, arregla el grafo
Ejemplos:
- muchos especialistas
- aprobaciones
- lógica de ramificación
- rutas paralelas
- traspasos estructurados
Errores comunes
1. Construir el grafo demasiado pronto
Los equipos a menudo diagraman un flujo de trabajo enorme antes de ver cómo se comporta realmente el trabajo.
Mejor enfoque:
- empezar con un harness más simple
- recopilar trazas
- encontrar los patrones estables
- formalizar solo lo que merece control
2. Dejar que el mismo modelo escriba y evalúe sin salvaguardas
La autoevaluación puede ayudar, pero comparte los mismos puntos ciegos.
Es preferible:
- comprobaciones deterministas cuando sea posible
- contexto de revisor separado
- evaluadores externos
- aprobación humana para acciones de alto impacto
3. Usar "sigue intentando" como bucle
Eso no es un diseño de bucle.
Eso es una fuga de costes no controlada.
Cada bucle necesita:
- un objetivo medible
- evidencia real
- límites de reintento
- reglas de escalado
4. Tratar el harness como un cajón de sastre
Más herramientas no significan automáticamente mejores agentes.
Demasiadas herramientas crean:
- errores de selección
- contexto ruidoso
- fiabilidad débil
- una superficie de riesgo más amplia
Un buen harness no está abarrotado.
Es preciso.
5. Culpar al modelo por fallos de orquestación
Un modelo no puede compensar por:
- APIs rotas
- estado obsoleto
- condiciones de salida faltantes
- esquemas de herramientas vagos
- modos de fallo invisibles
Arregla la capa que posee el fallo.
Una lista de verificación simple para producción
Harness
- ¿Las herramientas son específicas y están documentadas?
- ¿El estado es duradero?
- ¿Los permisos son de mínimo privilegio?
- ¿Los operadores pueden pausar, inspeccionar y reanudar?
- ¿Las trazas son visibles?
Bucle
- ¿Qué evidencia prueba el éxito?
- ¿Qué retroalimentación se devuelve en caso de fallo?
- ¿Cuántos reintentos están permitidos?
- ¿Cuál es la regla de parada?
- ¿Qué ocurre cuando se agota el presupuesto?
Grafo
- ¿Qué rutas deben ser deterministas?
- ¿Qué puede ejecutarse en paralelo?
- ¿Dónde están las compuertas humanas?
- ¿Qué estado se comparte?
- ¿Dónde comienzan las rutas de recuperación?
Evaluación
- ¿Puedes reproducir trazas reales?
- ¿Puedes comparar versiones?
- ¿Puedes atribuir la mejora a un cambio real?
Operaciones
- ¿Estás rastreando el coste?
- ¿la latencia?
- ¿la tasa de fallos?
- ¿la tasa de intervención?
- ¿el éxito de la tarea en producción?
La forma más simple de recordar la diferencia
Si solo recuerdas una cosa, recuerda esto:
- La ingeniería del harness hace operativo al modelo
- La ingeniería del bucle hace que el trabajo sea iterativo y verificable
- La ingeniería del grafo hace que la ruta de ejecución sea explícita y controlable
Ninguna reemplaza a las otras.
Un grafo perfecto no salvará un harness débil.
Un harness fuerte seguirá desperdiciando dinero sin buenos bucles.
Y los bucles limpios se vuelven difíciles de gestionar cuando la ramificación y las aprobaciones permanecen ocultas en código ad hoc.
Los sistemas de agentes fiables aparecen cuando las 3 capas se diseñan intencionalmente.
Esa es la pila de arquitectura real.
Conclusión final
La gente sigue hablando de los agentes de IA como si el gran avance fuera el modelo.
En producción, ese rara vez es el verdadero diferenciador.
El diferenciador es el sistema alrededor del modelo:
- el harness que le permite trabajar
- los bucles que le permiten mejorar
- el grafo que le permite operar bajo control
Así es como los agentes de juguete se convierten en sistemas reales.
Si has llegado hasta aquí:
- GUARDA ESTO.
- Sigue a @LunarResearcher
- Sigue mi Substack
- Sigue mi Canal Privado de Telegram
