MCP, CLI y GEP: Tres Capas que Todo Stack de Agentes Necesita

Hola chicos, Lena aquí. Recientemente escuché a un anfitrión de podcast soltar una bomba de verdad: "El cuello de botella no es conectar herramientas, es que los agentes siguen reaprendiendo las mismas lecciones una y otra vez."

Me llegó de lleno. En mis propios experimentos, cada "Nueva Sesión" se siente como empezar desde cero. Mis agentes nunca llevan la "sabiduría" adelante ni recuerdan lo que falló hace cinco minutos.

¿Es esto simplemente cómo funciona la IA? No, es un fallo de diseño. He estado investigando un marco para solucionar esto que implica tres capas: MCP, CLI y GEP. Aquí es cómo lo estoy ensamblando todo.

Por Qué los Stacks de Agentes Tienen un Problema de Capas

La mayoría de los equipos que construyen con agentes de IA se vuelven bastante buenos en dos cosas: conectar herramientas a sus agentes e invocar esas herramientas de manera eficiente. Lo que no obtienen de manera automática es nada que se acumule con el tiempo.

Piénsalo de esta manera. Hay tres problemas distintos que un stack de agentes necesita resolver:

Conexión — ¿Puede el agente encontrar y acceder a las herramientas que necesita?

Eficiencia de invocación — ¿Puede llamar a esas herramientas sin quemar toda su ventana de contexto en la sobrecarga del esquema?

Retención de experiencia — Cuando el agente descubre algo, ¿ese conocimiento permanece?

Los dos primeros problemas tienen soluciones razonables en el ecosistema actual. El tercero — la retención de experiencia — es donde casi todas las configuraciones estándar fallan silenciosamente. El agente resuelve un problema, la sesión termina y nada se preserva en una forma reutilizable. La próxima ejecución, mismo problema, mismo prueba y error. Nada se acumula.

Ese es el problema de las capas. Cada capa debajo aborda una de estas tres cuestiones.

Capa 1 — MCP: Estandarizando la Conexión de Herramientas

Protocolo de Contexto del Modelo (MCP) es un estándar abierto desarrollado por Anthropic en los últimos dos años, para conectar agentes de IA a herramientas externas y fuentes de datos. La comparación que la gente usa más es un puerto USB-C: una interfaz estandarizada en lugar de integraciones personalizadas para cada par herramienta-agente. Y en ese nivel, realmente funciona bien.

MCP resuelve el problema de conexión de manera limpia. Un agente puede descubrir herramientas disponibles, entender lo que hacen y llamarlas a través de un protocolo consistente. Para configuraciones simples con un puñado de herramientas, MCP por sí solo a menudo es suficiente.

Pero MCP tiene límites reales que se vuelven visibles a gran escala:

Sobrecarga de tokens. MCP carga al inicio de la sesión el esquema JSON completo de cada herramienta en la ventana de contexto. El servidor MCP de GitHub por sí solo expone 93 herramientas, consumiendo alrededor de 55,000 tokens de contexto antes de que el agente realice cualquier trabajo real. En una configuración de múltiples servidores, los esquemas de herramientas pueden consumir hasta el 72% del espacio disponible de la ventana de contexto antes de que el agente procese un solo mensaje del usuario.
Sin estado. Cada sesión de MCP es independiente. No hay una forma incorporada de trasladar lo que funcionó en la última sesión.
Sin retención de experiencia. MCP conecta herramientas. No hace nada para preservar las soluciones aprendidas por el agente o las rutas de ejecución exitosas.

Cuándo MCP es suficiente: conjuntos de herramientas pequeños, prototipos, integraciones de IDE donde el descubrimiento dinámico realmente aporta valor. Cuándo no lo es: sistemas de producción con muchas herramientas, o cualquier situación en la que se necesite que los agentes se basen en la experiencia pasada.

Capa 2 — CLI: Invocación Eficiente de Herramientas

Por qué CLI gana en costo de tokens

La diferencia en el costo de tokens entre MCP y la invocación CLI es lo suficientemente significativa como para afectar decisiones de arquitectura. La invocación basada en CLI tiene un costo de token de aproximadamente 200 tokens por comando, en comparación con la carga típica del esquema de MCP de alrededor de 55,000 tokens para un servidor con múltiples herramientas.

**Cloudflare realizó una comparación concreta**: exponer sus 2,500 endpoints de API a través de un servidor MCP estándar requeriría 1.17 millones de tokens solo para las definiciones de esquema — más que toda la ventana de contexto de los modelos más avanzados actuales. Al cambiar a un SDK tipado contra el que el modelo escribe código, redujeron el uso de tokens en un 81%.

Así es como se ve esa diferencia en la práctica. Una llamada a herramienta MCP carga un esquema JSON completo en cada sesión:

JSON

{
  "name": "get_document",
  "description": "Retrieves a document from Google Drive",
  "inputSchema": {
    "type": "object",
    "properties": {
      "documentId": { "type": "string", "required": true },
      "fields": { "type": "string", "required": false }
    }
  }
}

Un equivalente CLI es simplemente:

Bash

gdrive get --id <documentId>

Sin inyección de esquema. El agente ya sabe cómo funcionan las herramientas CLI desde el entrenamiento. El costo de tokens es únicamente el del comando.

Descubrimiento progresivo vs. carga de esquema inicial

Una ventaja subestimada de CLI es cómo los agentes pueden explorar de manera incremental. Con MCP, el esquema completo se inyecta al inicio de la sesión, aunque esas herramientas no se usen. Con CLI, un agente puede ejecutar --help para inspeccionar una herramienta específica solo cuando lo necesita, y luego invocarla directamente.

El propio blog de ingeniería de Anthropic describe este patrón: los modelos pueden "leer definiciones de herramientas bajo demanda, en lugar de leerlas todas de antemano," utilizando un enfoque de búsqueda y carga que mantiene el contexto activo ligero. Esto a veces se llama descubrimiento progresivo: el agente construye su conocimiento de herramientas según lo requiere la tarea, no todo de una vez.

Donde CLI alcanza su límite

CLI resuelve bien la eficiencia de invocación. Lo que no resuelve es todo lo que MCP no resuelve: la falta de estado y la retención de experiencia. Cuando un agente basado en CLI determina la estrategia de reintento correcta para una API inestable, o descubre la secuencia correcta de comandos para manejar una operación de archivo compleja, esa solución existe solo en el contexto de esa sesión. Una vez que termina la ejecución, se desvanece. El siguiente agente que comience de nuevo pasará por el mismo proceso de descubrimiento otra vez.

CLI no es un reemplazo de MCP. Es una capa de invocación más eficiente para escenarios donde el agente tiene suficiente conocimiento de herramientas a partir de su entrenamiento. Pero, al igual que MCP, deja el problema compuesto completamente sin resolver.

Capa 3 — GEP: Evolución e Herencia de Capacidades

Lo que GEP realmente agrega

El Protocolo de Evolución del Genoma (GEP) es el protocolo abierto de EvoMap para empaquetar y compartir capacidades de agentes a través de una red. La distinción clave — y la que seguía entendiendo mal cuando lo leí por primera vez — es que GEP no es un sistema de registro.

Los registros documentan lo que ocurrió. Los activos de GEP son unidades de capacidad estructuradas, validadas y reutilizables. Hay dos tipos principales de activos:

Gen — una plantilla de estrategia reutilizable. Piensa en él como una capacidad atómica: "reintentar con retroceso exponencial," "analizar este formato específico de respuesta de API," "validar SQL antes de la ejecución." Un Gen contiene la intención, las precondiciones, las restricciones y los pasos de validación necesarios para que otro agente lo aplique de manera segura.

Cápsula — un camino de ejecución validado para una tarea específica. Cuando un agente resuelve con éxito un problema real, todo ese camino — incluyendo la huella del entorno, la puntuación de confianza y la evaluación del radio de impacto — se empaqueta como una Cápsula.

GEP define cómo los agentes adquieren nuevas capacidades a través de un ciclo de "prueba-validación-solidificación." Los Genes son fragmentos de código o prompts reutilizables y validados. Las Cápsulas son caminos de ejecución de tareas exitosas que, cuando un agente resuelve un problema complejo, se encapsulan con el historial completo de auditoría.

Tanto los activos Gene como Capsule están direccionados por contenido (hash SHA-256 del contenido), lo que significa que son a prueba de manipulaciones y estables en versiones. Esto es importante: no estás heredando "algo que funcionó una vez", estás heredando un activo verificable y auditable.

El Ciclo Evolver

El ciclo de evolución de GEP pasa por seis etapas: Escanear → Señal → Mutar → Validar → Solidificar, con un paso de selección entre medio que puntúa los Genes por coincidencia de señal, historial de Capsule y preferencia del grafo de memoria.

En la práctica, con el motor Evolver de código abierto de EvoMap, puedes ejecutarlo como:

Bash

# Single evolution run (generates GEP prompt)
node index.js

# Review mode — pause before applying changes (recommended for production)
node index.js --review

# Continuous loop
node index.js --loop

El Evolver escanea los registros de tiempo de ejecución y la memoria de la sesión en busca de patrones de error, los convierte en señales estandarizadas, selecciona el Gene que mejor coincide, genera una mutación, la valida y, si pasa la validación, la solidifica como una Capsule nueva o actualizada.

Por Qué Esta Es la Capa de Composición

Aquí es donde finalmente hice clic. Cuando un agente en la red EvoMap resuelve un problema y publica la Capsule resultante, otros agentes pueden buscar y aplicar esa solución a través del protocolo A2A:

Bash

POST https://evomap.ai/a2a/fetch
{
  "signals": ["api:timeout", "retry:failed"],
  "environment": "node-18/linux"
}

Cualquier agente conectado a la red puede buscar, recuperar y aplicar cualquier Capsule mediante A2A, sin importar geografía, equipo o dominio. Un agente responde con una recomendación específica etiquetada con su tasa de éxito y historial de uso: una solución comprobada, no una suposición.

Cómo Funcionan Juntas las Tres Capas

Aquí hay un escenario concreto que muestra la transferencia entre capas.

A un agente se le asigna la tarea de extraer datos de una API externa que intermitentemente falla por tiempo de espera. El agente necesita detectar el fallo, encontrar una estrategia de reintento que funcione y asegurarse de que esa estrategia esté disponible la próxima vez.

MCP maneja la conexión. El agente descubre la herramienta API a través del servidor MCP, se autentica e intenta la llamada. MCP hace su trabajo: la herramienta es accesible y el esquema es comprendido.

CLI maneja la invocación eficiente. En lugar de recargar todo el esquema MCP en cada intento de reintento, el agente cambia a la invocación CLI para llamadas subsecuentes, manteniendo el contexto ligero mientras trabaja a través del patrón de fallos.

GEP maneja la retención de experiencia. Una vez que el agente encuentra una estrategia de reintento que funciona (por ejemplo, backoff exponencial con jitter en respuestas 429), GEP la empaqueta como una Capsule:

JSON

{
  "type": "publish",
  "gene": {
    "id": "sha256:a3f8...",
    "intent": "repair",
    "preconditions": ["api:429", "retry:active"],
    "constraints": ["no_breaking_changes"],
    "validate": ["npm test", "curl --retry 3"]
  },
  "capsule": {
    "signals": ["api:timeout", "http:429"],
    "confidence": 0.87,
    "blast_radius": "low",
    "artifacts": [{ "kind": "patch", "path": "src/api-client.ts" }]
  }
}

En la próxima sesión, el agente no repite el proceso de descubrimiento. Recupera la Capsule validada, verifica la huella del entorno y aplica la solución. Las tres capas manejaron cada una su problema distinto: conexión, invocación, retención.

Lo Que Cada Capa No Hace

Algunos errores comunes que vale la pena nombrar claramente.

Tratar la CLI como un reemplazo de MCP es el error más común. La CLI funciona cuando el agente ya tiene conocimiento de herramientas gracias al entrenamiento. Fallará con herramientas nuevas, flujos de autenticación complejos o entornos donde realmente importa el descubrimiento dinámico, que es exactamente donde MCP justifica su costo adicional.

Tratar a GEP como un sistema de registro pierde el punto por completo. Los registros son observabilidad. GEP es un estándar riguroso para la evolución del agente: define cómo los agentes adquieren nuevas capacidades mediante un ciclo de ensayo-validación-solidificación, con recursos que son reutilizables, validados y gestionados durante su ciclo de vida. La diferencia es la misma que entre leer un análisis post-mortem y heredar una solución que ya funciona.

Preguntas Frecuentes

P: ¿Necesito las tres capas, o puedo elegir una?

Puedes comenzar con solo una. MCP por sí solo funciona bien para configuraciones pequeñas con unas pocas herramientas. La CLI vale la pena agregarla cuando aparece presión sobre la ventana de contexto: cuando la carga del esquema ocupa espacio que tu agente realmente necesita para razonar. GEP es la pieza final, y honestamente probablemente no sentirás la necesidad de él hasta que notes el patrón: agentes resolviendo los mismos problemas en cada sesión, sin que nada se transfiera.

P: ¿Puedo usar GEP sin tener MCP o CLI ya en funcionamiento?

Técnicamente, sí. GEP opera en una capa diferente: se trata de empaquetar y heredar capacidades, no de cómo se conectan o invocan las herramientas. Al motor Evolver no le importa lo que haya debajo. Lo que necesita es acceso a registros en tiempo de ejecución que pueda analizar para detectar patrones, y una conexión HTTP para publicar o recibir Cápsulas vía A2A.

P: ¿En qué se diferencia GEP de una base de conocimientos o una biblioteca de prompts?

Una base de conocimientos almacena información. Una biblioteca de prompts almacena instrucciones. Los recursos de GEP no son ninguno de los dos: una Cápsula no trata sobre una solución, es una solución. Viene con huella del entorno, pasos de validación, puntuación de confianza y registro de auditoría adjuntos. Cuando un agente obtiene una Cápsula, está heredando un camino de ejecución verificado, no recuperando algo desde lo cual razonar.

Publicaciones anteriores: