31 términos de agentes de IA para el código que deberías conocer, organizados en cinco pilares

Cada semana aparece un término nuevo en mi feed. Context engineering. Harness engineering. RLM. Progressive disclosure. Uso agentes de IA para programar a diario, y el vocabulario crecía más rápido que mi comprensión del mismo.

Así que paré y organicé los 31 términos que había recopilado en grupos. Surgieron cinco pilares, y una vez que los vi, toda la arquitectura de herramientas como Claude Code y Codex cobró sentido de una forma que antes no tenía.

Los cinco pilares siguen una secuencia lógica: diseñas lo que el agente ve, divides el trabajo entre agentes, controlas cómo ejecutan, les ayudas a recordar entre sesiones y los conectas con el mundo exterior.

Diseñar. Dividir. Controlar. Recordar. Conectar.

Diseñar lo que el agente ve

Un modelo de IA procesa exactamente una cosa: su context window. Cada system prompt, instrucción del usuario, archivo adjunto, entrada del historial de conversación, bloque de memoria y skill cargado se concatenan en un único flujo de tokens. Ese flujo es el universo completo del modelo. AGENTS.md, el archivo que muchos equipos usan para configurar el comportamiento del agente, no es más que otra pieza de ese flujo.

Prompt es la instrucción directa que le das al modelo. Prompt engineering es la práctica de diseñar esas instrucciones, incluyendo ejemplos y formatos de salida, para obtener resultados consistentes. Estos dos términos están bien asentados, pero solo cubren una fracción de lo que realmente entra al modelo.

Context es todo aquello a lo que el modelo puede hacer referencia: system prompts, historial de conversación, archivos adjuntos, memoria, skills y salidas de herramientas combinados. Context engineering es la disciplina de decidir qué entra, qué se queda fuera y en qué orden. La diferencia importa. He visto prompts idénticos producir resultados muy distintos dependiendo de si un archivo de 2.000 líneas se colocaba antes o después de la instrucción. El orden no es cosmético.

Intent es el objetivo real del usuario, que puede diferir de lo que escribe literalmente. Cuando escribes “arregla los tests”, el intent podría ser “que CI se ponga en verde” o “refactoriza el suite de tests para que encaje con la nueva API”. El enrutamiento de agentes empieza aquí, y equivocarse con el intent se propaga por todo lo que viene después.

Skill es un paquete reutilizable de instrucciones especializadas que se carga en el contexto cuando se invoca. Piensa en ello como una función para prompts. En lugar de pegar las mismas 200 líneas de instrucción cada vez que quieres un comportamiento concreto, llamas a /refactor-clean y el contenido del skill entra en la context window bajo demanda.

Progressive disclosure es el patrón de diseño por el que no cargas todos los skills en el contexto de golpe. En cambio, el agente carga únicamente el skill que necesita en ese momento. Anthropic publicó este enfoque en su post sobre skills. Importa porque el espacio de la context window es finito. Cargar 40 skills al inicio consume tokens antes de que el modelo empiece a trabajar. Progressive disclosure mantiene la ventana ligera y el modelo centrado.

El fallo en el que caí repetidamente al principio: meter demasiado en el contexto y preguntarme por qué degradaba la calidad de la salida del modelo. Los 200K de context window son un máximo teórico. En la práctica, una vez que cuentas los system prompts, las definiciones de servidores MCP y el historial de conversación, el espacio útil puede caer a 70K o menos. Context engineering consiste en respetar esa restricción.

Dividir el trabajo entre agentes

Un solo agente manejando todo parece sencillo hasta que la context window se llena y la calidad de la salida cae. Por eso existen las arquitecturas multi-agente.

Un subagent es un proceso hijo al que un agente principal delega trabajo. El agente principal mantiene limpio su propio contexto externalizando tareas especializadas. En Claude Code, cuando lanzas una tarea de investigación en segundo plano, eso es un subagent que opera en su propia context window y devuelve solo el resultado.

Un swarm es un patrón en el que varios agentes trabajan en paralelo sobre distintas partes del mismo problema. Si necesitas analizar cinco archivos simultáneamente, un swarm permite que cinco agentes se encarguen de uno cada uno en lugar de que un solo agente los procese secuencialmente.

Fleet es la vista operativa de tus agentes en ejecución. Es un término de gestión, no de arquitectura. Cuando tienes tres subagents y dos background agents activos, esa colección es tu fleet.

Handoff es la transferencia de trabajo de un agente (o persona) a otro. En flujos de trabajo secuenciales, el Agente A completa su fase y hace un handoff al Agente B. El detalle importante es qué se transfiere: solo la salida, o el contexto completo. La mayoría de los handoffs transfieren un resumen, lo que significa que la pérdida de información es posible y hay que tenerla en cuenta.

Un background agent se ejecuta de forma asíncrona sin interacción del usuario. Tanto GitHub Copilot Workspace como Claude Code de Anthropic soportan este patrón. Describes una tarea, cierras el portátil y el agente trabaja de forma independiente. Los resultados aparecen cuando vuelves.

La trampa en la que caí: dividir el trabajo entre demasiados agentes demasiado pronto. Un solo agente con un contexto bien diseñado maneja el 80% de las tareas mejor que una arquitectura multi-agente mal coordinada. Divide solo cuando tengas evidencia de que un solo agente está llegando a los límites de contexto o sufriendo degradación de calidad.

Controlar cómo ejecutan los agentes

Un agente que genera código correcto no sirve de nada si además llama silenciosamente a herramientas peligrosas o modifica archivos que no debería tocar. El control es el tercer pilar, y es el que la mayoría de equipos trabaja menos.

Harness es el marco operativo que envuelve la ejecución, verificación y ciclo de vida de un agente. Incluye todo: desde comprobaciones de permisos hasta validación de salidas y lógica de reintentos. Harness engineering es diseñar las restricciones y los bucles de retroalimentación dentro de ese marco. OpenAI puso este término en circulación cuando publicó cómo Codex generó más de un millón de líneas de código con patrones de harness estructurados.

Trace es el log de ejecución de cada paso y decisión que tomó un agente. Empecé a tomar los traces en serio cuando descubrí que un agente llamaba a una herramienta de búsqueda web 14 veces por tarea cuando solo necesitaba la información una vez. Sin el trace, habría asumido que el agente funcionaba con eficiencia. Los traces son lo más parecido al debugging para agentes de IA.

Diff es la comparación del código antes y después de los cambios de un agente. Junto con los traces, los diffs forman la columna vertebral de la verificación. No puedes revisar lo que no puedes ver, y los diffs hacen que los cambios del agente sean revisables de la misma manera que las pull requests hacen revisables los cambios humanos.

Guardrails son reglas y comprobaciones de validación que evitan salidas peligrosas. Pueden ser tan simples como “nunca ejecutes comandos de shell que contengan rm -rf” o tan sofisticadas como clasificadores de contenido que impiden que datos sensibles aparezcan en las salidas.

Un sandbox es un entorno de ejecución aislado con permisos restringidos. Codex se ejecuta dentro de un sandbox de Docker donde el agente puede escribir código y ejecutar tests, pero no puede acceder a la red ni modificar el sistema anfitrión. Esta es la diferencia entre “el agente cometió un error” y “el agente cometió un error que afectó a producción”.

CLI (command-line interface) está viviendo un renacimiento en la era de los agentes. Ejecutar herramientas a través del terminal resulta ser más eficiente en tokens que enrutar a través de capas de protocolo. Cuando cada token cuesta dinero y consume espacio de contexto, la directness del CLI importa.

REPL (read-eval-print loop) es un entorno interactivo para ejecutar código de forma inmediata. Los agentes usan REPLs para probar hipótesis, validar resultados intermedios e iterar sobre soluciones sin escribir archivos en disco primero.

Recordar entre sesiones

Los modelos de lenguaje tienen un límite claro: la context window. Cuando se llena, el contenido más antiguo se expulsa. Para tareas que se extienden durante horas o días, esto genera un problema real.

Memory es cualquier sistema que almacena el historial de conversación y el estado de la tarea más allá de una sola context window. Memory hierarchy organiza estos almacenes en capas, típicamente a corto plazo (conversación actual), a medio plazo (sesiones recientes) y a largo plazo (conocimiento persistente). El diseño es paralelo a las jerarquías de caché de CPU por la misma razón: distintos patrones de acceso necesitan distintas estrategias de almacenamiento.

Embeddings convierten texto en vectores numéricos que capturan el significado semántico. Son la base de RAG (retrieval-augmented generation), donde un agente busca en una base de datos vectorial para traer información relevante a su context window. Cuando tu agente “recuerda” algo de una sesión anterior, normalmente está realizando una búsqueda de similitud basada en embeddings.

Un long-running agent mantiene el estado a través de múltiples context windows, trabajando en tareas que duran más que una sola sesión. Esto requiere gestión de estado externa porque el modelo en sí no tiene memoria persistente.

El Ralph Loop, creado por Geoffrey Huntley, es un bucle de programación autónomo que resuelve el problema de la memoria de forma pragmática. Cada iteración arranca una instancia fresca del agente, pero el progreso se persiste mediante commits de git y archivos de progreso. La nueva instancia lee el historial de git y las notas de progreso para entender qué se ha hecho y continúa desde ahí. Maximiza el test-time scaling iterando repetidamente, y cada bucle se beneficia del contexto acumulado en el propio repositorio.

RLM (Recursive Language Model) adopta un enfoque fundamentalmente diferente. En lugar de introducir una entrada larga directamente en el modelo (donde excedería la context window), RLM almacena los datos originales en variables del REPL y deja que el modelo escriba código para explorarlos. El modelo lanza consultas dirigidas contra los datos almacenados mediante llamadas recursivas a funciones. Como los datos originales nunca entran en la context window, la información nunca se pierde por truncado. Los autores afirman que este enfoque gestiona entradas equivalentes a 100 veces la context window normal.

Ambos enfoques reconocen la misma restricción pero la resuelven de forma distinta. El Ralph Loop trabaja con las limitaciones de la context window usando persistencia externa. RLM trabaja al margen de la context window completamente, manteniendo los datos fuera de ella. Ninguno es universalmente mejor; la elección correcta depende de si tu cuello de botella es la continuidad de la tarea (Ralph Loop) o el tamaño de la entrada (RLM).

Conectar agentes con el mundo exterior

Un agente que no puede acceder a herramientas externas, APIs o servicios se limita a generar texto. Los protocolos resuelven el problema de la integración.

MCP (Model Context Protocol) estandariza cómo los modelos se conectan a herramientas externas. Sin MCP, integrar N modelos con M herramientas requiere N x M implementaciones personalizadas. Con MCP, cada modelo y cada herramienta implementan el protocolo una sola vez, reduciendo el coste de integración a N + M. Es el mismo principio que hizo que USB tuviera éxito: acordar una única interfaz, y todo se conecta.

ACP (Agent Communication Protocol) estandariza la comunicación entre editores y agentes de código. Zed y JetBrains están liderando su desarrollo. El problema que resuelve es similar al de MCP pero en una capa distinta: en lugar de modelo a herramienta, es editor a agente.

LSP (Language Server Protocol) es el estándar establecido para la comunicación entre editor y servidor de análisis de código. Es la prueba original de que la estandarización de protocolos funciona en herramientas de desarrollo. Una búsqueda de referencias que tardaba 30 segundos con grep se completa en 50ms a través de LSP. El uso de tokens cae de más de 2.000 a unos 500 porque LSP devuelve resultados estructurados y precisos en lugar del contenido en bruto de los archivos. LSP es también el modelo de referencia para el diseño de ACP, lo cual tiene sentido: la forma del problema es casi idéntica.

Estos tres protocolos operan en capas distintas pero comparten la misma idea arquitectónica. Las integraciones personalizadas punto a punto no escalan. Las interfaces estándar sí.

El mapa, no el territorio

La mayoría de estos términos no existían hace seis meses. Si te resultan desconocidos, es lo esperado. El vocabulario crece porque el campo crece, y los conceptos nuevos necesitan nombres.

El valor de estos cinco pilares no está en memorizar definiciones. Está en tener un marco mental que te dice dónde encaja un término nuevo en el momento en que lo encuentras. Cuando alguien menciona “agent memory”, sabes que pertenece al cuarto pilar. Cuando sale un nuevo protocolo, sabes que va en el quinto. El marco absorbe vocabulario nuevo sin romperse.

Yo sigo consultando términos con regularidad. La diferencia es que ahora sé en qué estante van.