31 Términos de Agentes de Coding con IA que Deberías Conocer, Ordenados en Cinco Pilares

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

Así que paré y ordenné los 31 términos que había recopilado en grupos. Surgieron cinco pilares, y al verlos, la arquitectura completa de herramientas como Claude Code y Codex cobró sentido de una manera que antes no había tenido.

Los cinco pilares siguen una secuencia lógica: diseñás lo que el agente ve, dividís el trabajo entre agentes, controlás cómo ejecutan, los ayudás a recordar entre sesiones, y los conectás al 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 stream de tokens. Ese stream es el universo completo del modelo. AGENTS.md, el archivo que muchos equipos usan para configurar el comportamiento del agente, es simplemente otra pieza de ese stream.

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 establecidos, pero solo cubren una fracción de lo que realmente entra al modelo.

Context es todo lo que el modelo puede referenciar: system prompts, historial de conversación, archivos adjuntos, memoria, skills y outputs de herramientas combinados. Context engineering es la disciplina de decidir qué entra, qué queda afuera y en qué orden. La diferencia importa. He visto prompts idénticos producir resultados completamente distintos dependiendo de si un archivo de 2,000 líneas estaba 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 literalmente escribe. Cuando alguien escribe “arreglá los tests,” la intent puede ser “hacer que CI pase en verde” o “refactorizar el test suite para que coincida con la nueva API.” El routing de agentes empieza acá, y equivocarse con la intent se propaga por todo lo que viene después.

Skill es un paquete reutilizable de instrucciones expertas que se carga al context cuando se invoca. Pensalo como una función para prompts. En lugar de pegar las mismas 200 líneas de instrucción cada vez que querés un comportamiento específico, llamás /refactor-clean y el contenido del skill entra al context window cuando lo necesitás.

Progressive disclosure es el patrón de diseño donde no cargás todos los skills al context de una vez. En cambio, el agente carga solo el skill que necesita en ese momento. Anthropic publicó este enfoque en su blog post sobre skills. Importa porque el espacio del context window es finito. Cargar 40 skills de entrada quema tokens antes de que el modelo siquiera empiece a trabajar. El progressive disclosure mantiene el window ajustado y el modelo enfocado.

El error que cometí repetidamente al principio: meter demasiado en el context y preguntarme por qué bajaba la calidad del output. El context window de 200K es un máximo teórico. En la práctica, una vez que tomás en cuenta system prompts, definiciones de servidores MCP e historial de conversación, el espacio usable puede caer a 70K o menos. Context engineering es respetar esa restricción.

Dividir el trabajo entre agentes

Un solo agente manejando todo parece simple hasta que el context window se llena y la calidad del output baja. Por eso existen las arquitecturas multi-agente.

Un subagent es un proceso hijo al que un agente principal le delega trabajo. El agente principal mantiene su propio context limpio delegando tareas especializadas. En Claude Code, cuando lanzás una tarea de investigación en background, eso es un subagent que opera en su propio context window y devuelve solo el resultado.

Un swarm es un patrón donde múltiples agentes trabajan en paralelo sobre distintas partes del mismo problema. Si necesitás analizar cinco archivos simultáneamente, un swarm deja que cinco agentes cada uno se encargue de un archivo en lugar de que un solo agente los procese secuencialmente.

Fleet es la vista operacional de tus agentes en ejecución. Es un término de gestión, no de arquitectura. Cuando tenés 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 workflows secuenciales, el Agente A completa su fase y hace handoff al Agente B. El detalle importante es qué se transfiere: solo el output, o el context completo. La mayoría de los handoffs transfieren un resumen, lo que significa que es posible perder información y hay que tenerlo en cuenta.

Un background agent corre de forma asíncrona sin interacción del usuario. GitHub Copilot Workspace y Claude Code de Anthropic soportan este patrón. Describís una tarea, cerrás la laptop, y el agente trabaja de forma independiente. Los resultados aparecen cuando volvés.

La trampa en la que caí: dividir el trabajo entre demasiados agentes demasiado pronto. Un solo agente con un context bien diseñado maneja el 80% de las tareas mejor que una configuración multi-agente mal coordinada. Dividí solo cuando tenés evidencia de que un agente está alcanzando límites de context o degradación de calidad.

Controlar cómo ejecutan los agentes

Un agente que genera código correcto es inútil si también 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 los equipos menos invierte.

Harness es el marco operacional que envuelve la ejecución, verificación y ciclo de vida de un agente. Incluye todo, desde chequeos de permisos hasta validación de outputs y lógica de reintentos. Harness engineering es diseñar las restricciones y los loops de feedback dentro de ese marco. OpenAI puso este término en el mainstream 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 en serio los traces después de descubrir 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, hubiera asumido que el agente trabajaba de forma eficiente. Los traces son lo más parecido que existe 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 el backbone de verificación. No podés revisar lo que no podés ver, y los diffs hacen que los cambios del agente sean revisables de la misma manera que los pull requests hacen revisables los cambios humanos.

Guardrails son reglas y chequeos de validación que previenen outputs peligrosos. Pueden ser tan simples como “nunca ejecutes comandos de shell que contengan rm -rf” o tan sofisticados como clasificadores de contenido que bloquean que datos sensibles aparezcan en los outputs.

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

CLI (command-line interface) está teniendo un resurgimiento en la era de los agentes. Resulta que correr herramientas a través de una terminal es más eficiente en tokens que enrutar por capas de protocolo. Cuando cada token cuesta dinero y consume espacio del context, la directness del CLI importa.

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

Recordar entre sesiones

Los large language models tienen un límite concreto: el context window. Cuando se llena, el contenido más viejo se descarta. Para tareas que duran horas o días, esto crea un problema real.

Memory es cualquier sistema que almacena el historial de conversación y el estado de la tarea más allá de un único context window. Memory hierarchy organiza estos storages en capas, típicamente short-term (conversación actual), medium-term (sesiones recientes) y long-term (conocimiento persistente). El diseño es paralelo a las jerarquías de cache 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 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, generalmente está haciendo una búsqueda de similitud basada en embeddings.

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

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

RLM (Recursive Language Model) toma un enfoque fundamentalmente distinto. En lugar de alimentar un input largo directamente al modelo (donde excedería el context window), RLM almacena los datos originales en variables de REPL y deja que el modelo escriba código para explorarlos. El modelo lanza queries específicos contra los datos almacenados a través de llamadas a funciones recursivas. Como los datos originales nunca entran al context window, la información nunca se pierde por truncamiento. Los autores afirman que este enfoque maneja inputs equivalentes a 100 veces el context window normal.

Ambos enfoques reconocen la misma restricción pero la resuelven de forma distinta. El Ralph Loop trabaja con las limitaciones del context window usando persistencia externa. RLM trabaja alrededor del context window por completo manteniendo los datos fuera de él. 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 del input (RLM).

Conectar agentes al mundo exterior

Un agente que no puede acceder a herramientas externas, APIs o servicios está limitado a la generación de texto. Los protocolos resuelven el problema de 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 implementa el protocolo una vez, reduciendo el costo de integración a N + M. Es el mismo principio que hizo exitoso a USB: acordar una interfaz y todo se conecta.

ACP (Agent Communication Protocol) estandariza la comunicación entre editores y agentes de coding. Zed y JetBrains lideran 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 editores y servidores de análisis de código. Es la prueba original de que la estandarización de protocolos funciona en developer tools. Una búsqueda de referencias que le tomaba 30 segundos a grep se completa en 50ms a través de LSP. El uso de tokens baja de 2,000+ a alrededor de 500 porque LSP devuelve resultados estructurados y precisos en lugar del contenido crudo de los archivos. LSP también es el modelo de referencia para el diseño de ACP, lo cual tiene sentido: las formas del problema son casi idénticas.

Estos tres protocolos operan en capas distintas pero comparten el mismo insight arquitectural. Las integraciones punto a punto personalizadas 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 se sienten poco familiares, 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 framework mental que te dice dónde encaja un término nuevo en el momento en que lo encontrás. Cuando alguien menciona “agent memory,” sabés que pertenece al cuarto pilar. Cuando lanza un protocolo nuevo, sabés que está en el quinto. El framework absorbe vocabulario nuevo sin romperse.

Yo sigo buscando términos regularmente. La diferencia es que ahora sé en qué estante van.