MCP, CLI e GEP: Três Camadas que Todo Stack de Agentes Precisa

Oi pessoal, Lena aqui. Recentemente, ouvi um apresentador de podcast soltar uma verdade dura: "O gargalo não é conectar ferramentas—é que os agentes continuam reaprendendo as mesmas lições repetidamente."

Isso me atingiu. Em meus próprios experimentos, toda "Nova Sessão" parece começar do zero. Meus agentes nunca carregam "sabedoria" adiante ou lembram do que falhou cinco minutos atrás.

Isso é apenas como a IA funciona? Não—é uma falha de design. Tenho explorado uma estrutura para consertar isso envolvendo três camadas: MCP, CLI e GEP. Aqui está como estou juntando tudo.

Por Que os Stacks de Agentes Têm um Problema de Camadas

A maioria das equipes que trabalham com agentes de IA se sai muito bem em duas coisas: conectar ferramentas aos seus agentes e invocar essas ferramentas de forma eficiente. O que elas não recebem de graça é algo que se acumula ao longo do tempo.

Pense assim. Existem três problemas distintos que um stack de agentes precisa resolver:

Conexão — O agente consegue encontrar e acessar as ferramentas que precisa?

Eficiência de invocação — Ele consegue chamar essas ferramentas sem consumir toda a sua janela de contexto com o overhead do esquema?

Retenção de experiência — Quando o agente descobre algo, esse conhecimento permanece?

Os dois primeiros problemas têm soluções razoáveis no ecossistema atual. O terceiro — retenção de experiência — é onde quase toda configuração padrão falha silenciosamente. O agente resolve um problema, a sessão termina, e nada é preservado de forma reutilizável. Na próxima execução, mesmo problema, mesmo tentativa e erro. Nada se acumula.

Esse é o problema de camadas. Cada camada abaixo aborda uma dessas três coisas.

Camada 1 — MCP: Padronizando a Conexão de Ferramentas

Protocolo de Contexto de Modelo (MCP) é um padrão aberto desenvolvido pela Anthropic nos últimos dois anos para conectar agentes de IA a ferramentas externas e fontes de dados. A comparação que as pessoas mais usam é uma porta USB-C — uma interface padronizada em vez de integrações personalizadas para cada par ferramenta-agente. E, nesse nível, realmente funciona bem.

O MCP resolve o problema de conexão de forma limpa. Um agente pode descobrir ferramentas disponíveis, entender o que elas fazem e chamá-las por meio de um protocolo consistente. Para configurações simples com um punhado de ferramentas, o MCP sozinho muitas vezes é suficiente.

Mas o MCP tem limites reais que se tornam visíveis em escala:

Sobrecarga de tokens. O MCP pré-carrega o esquema JSON completo de cada ferramenta na janela de contexto no início da sessão. O servidor MCP do GitHub sozinho expõe 93 ferramentas, consumindo cerca de 55.000 tokens de contexto antes que o agente execute qualquer trabalho real. Em uma configuração de múltiplos servidores, os esquemas das ferramentas podem consumir até 72% do espaço disponível da janela de contexto antes que o agente processe uma única mensagem do usuário.
Sem estado. Cada sessão do MCP é independente. Não há uma forma integrada de transportar o que funcionou na última sessão.
Sem retenção de experiência. O MCP conecta ferramentas. Ele não faz nada para preservar as soluções aprendidas pelo agente ou caminhos de execução bem-sucedidos.

Quando o MCP sozinho é suficiente: conjuntos pequenos de ferramentas, prototipagem, integrações de IDE onde a descoberta dinâmica realmente agrega valor. Quando não é: sistemas de produção com muitas ferramentas, ou qualquer situação em que seja necessário que os agentes construam sobre experiências passadas.

Camada 2 — CLI: Invocação Eficiente de Ferramentas

Por que a CLI Vence em Custo de Tokens

A diferença de custo de tokens entre a invocação via MCP e via CLI é significativa ao ponto de influenciar decisões de arquitetura. A invocação baseada em CLI tem um custo de aproximadamente 200 tokens por comando, comparado ao carregamento típico de schema do MCP de cerca de 55.000 tokens para um servidor com múltiplas ferramentas.

**A Cloudflare realizou uma comparação concreta**: expor seus 2.500 endpoints de API via um servidor MCP padrão exigiria 1,17 milhões de tokens apenas para definições de esquema — mais do que toda a janela de contexto dos modelos de ponta atuais. Ao mudar para um SDK tipado contra o qual o modelo escreve código, eles reduziram o uso de tokens em 81%.

Aqui está como essa diferença se apresenta na prática. Uma chamada de ferramenta MCP carrega um esquema JSON completo em cada sessão:

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 }
    }
  }
}

O equivalente em CLI é apenas:

Bash

gdrive get --id <documentId>

Sem injeção de schema. O agente já sabe como as ferramentas CLI funcionam a partir do treinamento. O custo de tokens é apenas o próprio comando.

Descoberta Progressiva vs. Carregamento Antecipado de Schema

Uma vantagem subestimada da CLI é como os agentes podem explorar incrementamente. Com o MCP, o schema completo é injetado no início da sessão, quer as ferramentas sejam usadas ou não. Com a CLI, um agente pode executar --help para inspecionar uma ferramenta específica apenas quando precisar dela, e então invocá-la diretamente.

O próprio blog de engenharia da Anthropic descreve esse padrão: os modelos podem "ler definições de ferramentas sob demanda, em vez de lê-las todas de uma vez", usando uma abordagem de busca e carregamento que mantém o contexto ativo enxuto. Isso às vezes é chamado de descoberta progressiva — o agente acumula seu conhecimento de ferramentas conforme a tarefa exige, e não tudo de uma vez.

Onde o CLI Atinja Seu Limite

O CLI resolve bem a eficiência de invocação. O que ele não resolve é tudo que o MCP não resolve: ausência de estado e retenção de experiência. Quando um agente baseado em CLI descobre a estratégia de nova tentativa correta para uma API instável ou descobre a sequência correta de comandos para lidar com uma operação de arquivo complexa — essa solução existe apenas no contexto daquela sessão. Uma vez que a execução termina, ela desaparece. O próximo agente que começar do zero passará pelo mesmo processo de descoberta novamente.

O CLI não é um substituto para o MCP. É uma camada de invocação mais eficiente para cenários onde o agente já possui conhecimento suficiente das ferramentas a partir do treinamento. Mas, como o MCP, ele deixa o problema do acúmulo completamente sem solução.

Camada 3 — GEP: Evolução e Herança de Capacidades

O Que o GEP Realmente Adiciona

O Protocolo de Evolução Genômica (GEP) é o protocolo aberto da EvoMap para empacotar e compartilhar capacidades de agentes em uma rede. A principal distinção — e aquela que eu sempre interpretava errado quando li sobre ele pela primeira vez — é que o GEP não é um sistema de registros.

Os logs registram o que aconteceu. Os ativos do GEP são unidades estruturadas, validadas e reutilizáveis de capacidade. Há dois tipos principais de ativos:

Gene — um modelo de estratégia reutilizável. Pense nisso como uma capacidade atômica: "tentar novamente com retrocesso exponencial", "analisar este formato específico de resposta de API", "validar SQL antes da execução". Um Gene contém a intenção, pré-condições, restrições e etapas de validação necessárias para que outro agente o aplique com segurança.

Cápsula — um caminho de execução validado para uma tarefa específica. Quando um agente resolve um problema real com sucesso, todo esse caminho — incluindo impressão digital do ambiente, pontuação de confiança e avaliação do raio de impacto — é empacotado como uma Cápsula.

O GEP define como os agentes adquirem novas capacidades através de um ciclo de "teste-validação-solidificação". Genes são códigos ou fragmentos de prompt reutilizáveis e validados. Cápsulas são caminhos de execução bem-sucedidos que, quando um agente resolve um problema complexo, são encapsulados com todo o registro de auditoria.

Tanto os ativos Gene quanto Capsule são endereçados por conteúdo (hash SHA-256 do conteúdo), o que significa que são à prova de adulterações e estáveis em versões. Isso é importante: você não está herdando "algo que funcionou uma vez", você está herdando um ativo verificável e auditável.

O Loop do Evolver

O ciclo de evolução do GEP passa por seis etapas: Scan → Signal → Mutate → Validate → Solidify, com uma etapa de seleção no meio que pontua Genes por correspondência de sinal, histórico de Capsule e preferência no grafo de memória.

Na prática, com o motor Evolver open-source da EvoMap, você pode executar isso 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

O Evolver escaneia logs de execução e memória de sessão para padrões de erros, converte-os em sinais padronizados, seleciona o Gene com melhor correspondência, gera uma mutação, valida e, se for aprovada — solidifica como uma Capsule nova ou atualizada.

Por Que Esta é a Camada de Composição

Aqui está a parte que finalmente fez sentido para mim. Quando um agente na rede EvoMap resolve um problema e publica a Capsule resultante, outros agentes podem buscar e aplicar essa solução via protocolo A2A:

Bash

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

Qualquer agente conectado à rede pode pesquisar, recuperar e aplicar qualquer Capsule via A2A — independentemente de geografia, equipe ou domínio. Um agente retorna com uma recomendação específica rotulada com sua taxa de sucesso e histórico de uso: uma solução comprovada, não um palpite.

Como as Três Camadas Trabalham Juntas

Aqui está um cenário concreto que mostra a passagem entre camadas.

Um agente é encarregado de puxar dados de uma API externa que apresenta timeouts intermitentes. O agente precisa detectar a falha, encontrar uma estratégia de nova tentativa que funcione e garantir que essa estratégia esteja disponível da próxima vez.

O MCP lida com a conexão. O agente descobre a ferramenta da API através do servidor MCP, autentica-se e tenta a chamada. O MCP faz seu trabalho: a ferramenta é alcançável e o esquema é compreendido.

O CLI lida com invocação eficiente. Em vez de recarregar o esquema completo do MCP a cada tentativa de nova chamada, o agente muda para invocação via CLI para as chamadas subsequentes — mantendo o contexto leve enquanto resolve o padrão de falha.

O GEP lida com a retenção de experiência. Uma vez que o agente encontra uma estratégia de nova tentativa que funciona (por exemplo, backoff exponencial com jitter em respostas 429), o GEP a empacota como uma 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" }]
  }
}

Na próxima sessão, o agente não repete o processo de descoberta. Ele busca a Capsule validada, verifica a impressão digital do ambiente e aplica a correção. As três camadas lidaram com seus problemas distintos: conexão, invocação, retenção.

O Que Cada Camada Não Faz

Alguns erros comuns que valem a pena mencionar claramente.

Tratar o CLI como um substituto do MCP é o erro mais comum. O CLI funciona quando o agente já possui conhecimento das ferramentas a partir do treinamento. Ele falha para ferramentas novas, fluxos de autenticação complexos ou ambientes onde a descoberta dinâmica realmente importa — que é exatamente onde o MCP justifica seu custo adicional.

Tratar o GEP como um sistema de logs perde completamente o ponto. Logs são observabilidade. GEP é um padrão rigoroso para evolução de agentes — ele define como os agentes adquirem novas capacidades por meio de um ciclo de teste-validação-solidificação, com ativos que são reutilizáveis, validados e gerenciados ao longo do ciclo de vida. A diferença é a diferença entre ler um post-mortem e herdar uma correção funcional.

FAQ

P: Preciso das três camadas ou posso escolher apenas uma?

Você pode começar com apenas uma. O MCP sozinho funciona bem para configurações pequenas com poucas ferramentas. O CLI passa a valer a pena quando a pressão da janela de contexto aparece — quando o carregamento do esquema ocupa espaço que seu agente realmente precisa para raciocinar. O GEP é a última peça, e honestamente você provavelmente não sentirá necessidade dele até notar o padrão: agentes resolvendo os mesmos problemas a cada sessão, sem nada sendo levado adiante.

P: Posso usar o GEP sem o MCP ou CLI já em funcionamento?

Tecnicamente, sim. O GEP opera em uma camada diferente — ele trata de empacotar e herdar capacidades, não de como as ferramentas estão conectadas ou invocadas. O motor Evolver não se importa com o que está por baixo. O que ele precisa é de acesso aos logs de runtime que possa examinar em busca de padrões e de uma conexão HTTP para publicar ou buscar Cápsulas via A2A.

P: Como o GEP é diferente de uma base de conhecimento ou biblioteca de prompts?

Uma base de conhecimento armazena informações. Uma biblioteca de prompts armazena instruções. Os ativos do GEP não são nenhum dos dois — uma Cápsula não é sobre uma solução, ela é uma. Ela vem com impressão digital do ambiente, passos de validação, pontuação de confiança e trilha de auditoria anexados. Quando um agente busca uma Cápsula, ele está herdando um caminho de execução verificado, não apenas recuperando algo para raciocinar.

Posts Anteriores: