ETCLOVG: La taxonomía de siete capas para el entorno de agentes, adaptada a un entorno de ejecución en producción

La fiabilidad de un agente es una propiedad tanto del modelo como del sistema que lo rodea. Un estudio de 2026 realizado por investigadores de Carnegie Mellon, Yale, Amazon y otras instituciones propone ETCLOVG (Ejecución, Herramientas, Contexto, Ciclo de vida, Observabilidad, Verificación y Gobernanza) como taxonomía para ese sistema circundante, o entorno de agentes.

Los autores clasifican más de 170 proyectos de código abierto en estas siete capas e identifican tanto áreas maduras como lagunas operativas. Este artículo resume la taxonomía y la aplica al entorno de agentes de TrueFoundry, separando las capacidades nativas del entorno de ejecución de los patrones e integraciones adyacentes.

Priyanka, jefa de plataforma, tenía un problema de fiabilidad que no sabía cómo definir. Sus equipos gestionaban cinco agentes en producción y, cuando uno fallaba, los análisis post-mortem nunca llegaban a un acuerdo sobre qué corregir. Uno culpaba al modelo y pedía una actualización. Otro reescribía el prompt. Otro añadía un reintento. Otro quería un entorno aislado (sandbox). Cada solución era plausible, cada una abordaba una capa distinta y ninguna compartía un vocabulario común para identificar qué capa había fallado realmente, por lo que las reuniones no llegaban a ninguna parte. Lo que Priyanka necesitaba no era un modelo mejor ni una opinión más firme; era un mapa: una forma de señalar a un agente y decir "este fallo reside en el ciclo de vida, no en el modelo" o "no tenemos ninguna capa de verificación". ETCLOVG es ese mapa, y este artículo es el recorrido por él: primero la taxonomía tal como la definieron sus autores, y luego cada capa frente a un entorno de ejecución en producción, distinguiendo las capacidades nativas de los flujos de trabajo e integraciones adyacentes, independientemente de si los llama por estos nombres o no.

1. Por qué existe una taxonomía para el entorno de agentes

La tesis central del estudio es deflacionaria respecto a los modelos e inflacionaria respecto a la infraestructura: el rápido despliegue de agentes basados en LLM reveló que la fiabilidad de la ejecución depende menos del modelo base que del entorno que lo envuelve. La evidencia es, en parte, histórica. La era ReAct de 2022-23 envolvía un bucle de modelo único en un bucle "while", una plantilla de prompt y una pequeña tabla de despacho de herramientas; AutoGPT y BabyAGI expusieron entonces los modos de fallo de ese envoltorio ligero (ejecución descontrolada, desbordamiento de contexto, pérdida de estado, efectos secundarios no supervisados) como problemas de infraestructura y no de prompts. Los años transcurridos desde entonces han servido para que el sector construya lentamente la infraestructura que faltaba y, solo recientemente, para ponerle nombre.

Esa denominación es el marco de tres fases del estudio, que sitúa la ingeniería del entorno de agentes con precisión. Ingeniería de prompts (2022-24): la palanca es el texto de entrada, optimizado para una única llamada. Ingeniería de contexto (2025): la pregunta cambia a "¿qué debería ver el modelo en cada paso?" (recuperación, compactación, clasificación de resultados de herramientas, saturación de ventana). Ingeniería del entorno (2026-): a medida que los modelos se vuelven lo suficientemente capaces para tareas de larga duración, el enfoque se expande a todo el envoltorio de infraestructura. Cada fase subsume a la anterior (el entorno incluye el contexto, que incluye el prompt) y se solapan en lugar de reemplazarse. ETCLOVG proporciona a esa tercera fase los límites arquitectónicos que las dos primeras nunca necesitaron.

2. ETCLOVG, capa por capa

La taxonomía se divide en un núcleo estructural y un plano de control. E, T, C y L son los pilares estructurales: hacen que un agente funcione. O, V y G son el plano de control: hacen que un agente en ejecución sea observable, evaluable y seguro. El movimiento notable del estudio es promover la observabilidad y la gobernanza a capas independientes en lugar de integrarlas en los ganchos del ciclo de vida, bajo el argumento de que, en producción, cada una tiene su propio ecosistema de herramientas y es responsabilidad de un equipo diferente. Aquí están las siete, parafraseadas a partir de las definiciones del estudio.

E — Entorno de ejecución. Donde el código y las acciones del agente se ejecutan realmente, y lo que los limita: sandboxes gestionados, microVMs, entornos de ejecución especializados en código, entornos de uso de ordenador y navegador, modelos de permisos a nivel de sistema operativo. Esta es la capa de radio de explosión: lo que un agente puede tocar cuando ejecuta un comando.

T — Interfaz y protocolo de herramientas. Cómo se describen, descubren e invocan las capacidades externas: estándares de protocolo (MCP, A2A), descripción y selección de herramientas, entrenamiento aumentado por herramientas, gestión de sesiones. El modelo solo conoce las herramientas a través de esta capa.

C — Gestión de contexto y memoria. Lo que el modelo puede ver a corto plazo, durante la sesión y en horizontes persistentes: técnicas de contexto a largo plazo y mitigaciones para la deriva del contexto. El tema de la fase de ingeniería anterior, ahora uno de los cuatro pilares.

L — Ciclo de vida y orquestación. El flujo de control que lee y escribe el estado, desde el bucle interno de un solo agente hasta los patrones multiagente y los flujos de trabajo completos de resolución de incidencias a solicitudes de extracción. El bucle en sí reside aquí.

O — Observabilidad y operaciones. Trazas, costes, fallos, señales de fiabilidad: plataformas de rastreo, herramientas de operaciones específicas para agentes, seguimiento de costes y observabilidad unificada. El mapa de código abierto del estudio revela que esta capa es comparativamente escasa en el código público.

V — Verificación y evaluación. Convertir tareas y trazas en evaluación, atribución de fallos y retroalimentación de regresión: fundamentación de pruebas comparativas, ejecución controlada, juicio multinivel y bucles de evaluación en tiempo de despliegue. La diferencia entre "se ejecutó" y "fue correcto".

G — Gobernanza y seguridad. Restricciones en las subcapas del modelo, el sistema y la organización: modelos de permisos, ganchos de ciclo de vida, refuerzo de componentes, constituciones declarativas e infraestructura de auditoría. El estudio señala que también es escasa en el código abierto y que "suele residir dentro de plataformas comerciales".

‍

‍