ECC Agent Harness: 4 testes reais antes de confiar (2026)
O problema que me fez abrir o repositório do ECC agent harness não foi a lista de features do README. Foi uma pergunta mais chata: se eu configuro memória, instinto e segurança no Claude Code, essa mesma configuração sobrevive quando troco pra Codex, Opencode ou Cursor? Ou cada ferramenta recebe uma versão própria, remendada à mão, que divergem com o tempo? É esse ponto, portabilidade real entre harnesses, que puxou o resto da investigação.
O repositório é github.com/affaan-m/ECC. Linguagem declarada no GitHub: JavaScript. Licença MIT. Criado em 18 de janeiro de 2026, mantido por uma única pessoa que publica atualizações semanais em sete harnesses diferentes (isso está na própria seção de patrocínio do projeto). Não é crítica, é contexto: quem sustenta sozinho um projeto desse tamanho tem motivo de sobra pra escolher nomes de pasta que vendem bem. A pergunta que interessa é se o nome bate com o código.
O que dá pra confirmar abrindo o pacote, e o que fica só na promessa
A descrição oficial do ECC agent harness no GitHub promete “skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond”. Cada termo tem um equivalente técnico verificável, e foi atrás disso que fui, abrindo os dois pacotes publicados no npm: ecc-universal e ecc-agentshield.
No ecc-universal, o package.json listado no registry do npm não traz nenhuma dependência de embeddings, vetor ou busca semântica (nada de faiss, chromadb, @xenova/transformers ou equivalente). As dependências são de manipulação de arquivo e CLI. Isso não é prova de má-fé, é prova de escolha: a “memória” do ECC é leitura e reescrita de arquivo markdown, não um sistema de recuperação. Dá pra confirmar isso sem baixar o repositório inteiro, só olhando a aba de dependências do pacote no site do npm.
Já no ecc-agentshield, a separação em pacote próprio é um sinal mais forte do que a maioria dos concorrentes oferece (que costumam enfiar tudo num único system prompt). O nome sugere interceptação. Isso eu não consegui confirmar com a mesma segurança que a dependência de embeddings: o código-fonte completo do pacote não está aberto na mesma profundidade que o package.json, então a pergunta “ele intercepta a chamada antes de executar ou só analisa texto depois” fica sem resposta definitiva aqui. Registro essa diferença de confiança entre os dois achados porque é exatamente esse tipo de linha que separa fato de suposição.
Passo 1: memória é busca ou é arquivo que se reescreve sozinho
Dado o que o ecc-universal mostra, a resposta pro ECC está decidida: sem lib de embeddings no manifesto de dependências, a “memória” é contexto persistente em texto, não um sistema de recuperação. Isso tem um efeito prático chato: não existe recuperação seletiva, não existe “esquecer” informação velha, e o arquivo cresce até estourar a janela de contexto do modelo ou virar ruído.
Isso não é exclusividade do ECC. É o padrão mais comum em agent harness open source: chamar de memory uma pasta de .md que o próprio agente sobrescreve a cada sessão. Funciona até certo ponto, mas chamar isso de memória é inflar o nome. O teste que eu aplicaria em qualquer harness antes de confiar: abra o manifesto de dependências e procure por lib de busca ou vetor. Achou, é memória de verdade. Não achou, é acúmulo de texto versionado, o que pode ser até uma escolha legítima pra time pequeno, desde que chamada pelo nome certo.
Passo 2: instinto muda sozinho ou é regra fixa escrita uma vez
“Instinct” é a palavra mais arriscada das cinco porque sugere aprendizado adaptativo, caro de implementar de verdade (fine-tuning, reinforcement learning, ou no mínimo um sistema de scoring que ajusta peso com base em resultado). A maioria dos harnesses não tem nada disso. Tem um conjunto de regras fixas escritas uma vez por um humano, que o agente repete sempre da mesma forma: prompt engineering com nome de neurociência.
O teste que eu aplicaria aqui é concreto: pegue duas sessões separadas, mesma tarefa, resultado ruim registrado na primeira. Na segunda, o comportamento mudou em função daquele resultado, ou o agente repetiu o mesmo texto de instrução porque o arquivo de instinct não foi tocado entre uma sessão e outra? No caso do ECC, o conteúdo interno desses arquivos de instinct não está exposto no npm nem no README de forma que eu consiga rodar esse teste sem instalar o pacote e simular as sessões manualmente. Diferente da memória, aqui não tenho um package.json que resolva a dúvida de longe. Fica registrado como lacuna real, não como suposição disfarçada de conclusão.
Passo 3: segurança intercepta execução ou só avisa o modelo em texto
Segurança de verdade em agente de IA tem camada concreta: container isolado, allowlist de comando, revisão humana obrigatória antes de ação destrutiva, limite de escopo de arquivo. Segurança de mentira é um parágrafo no system prompt pedindo pro modelo “não apague nada sem confirmar”, que depende inteiramente do modelo obedecer, e modelo de linguagem não é determinístico.
O fato de existir um pacote ecc-agentshield separado já é mais do que boa parte da concorrência faz. Isso aponta pra intenção arquitetural de isolar segurança como módulo, o que facilita auditoria futura. Mas intenção não é implementação: sem acesso ao código-fonte completo do shield, não dá pra confirmar se ele intercepta a chamada de ferramenta antes dela rodar ou se só analisa a intenção do modelo depois que a decisão já foi tomada. É a pergunta certa pra fazer antes de rodar isso com permissão de escrita no seu repositório, e é uma pergunta que, por enquanto, só o código completo do pacote responde.
Passo 4: a mesma memória sobrevive trocando de ferramenta, ou são quatro adapters disfarçados de uma coisa só
Aqui mora o problema que puxou este post inteiro. Cada ferramenta (Claude Code, Codex, Opencode, Cursor) tem protocolo de extensão próprio, formato de system prompt próprio, jeito próprio de expor ferramenta pro modelo. “Funcionar nas quatro” quase nunca significa um motor único com quatro portas de entrada. Na prática mais comum, significa quatro adapters escritos à mão, cada um replicando a lógica do outro em sintaxe diferente, e a “mesma memória” vira quatro cópias de arquivo de contexto que alguém precisa sincronizar manualmente ou regenerar via script.
O ECC declara compatibilidade com as quatro, “and beyond”. Um dado que ajuda a situar isso: os badges de linguagem no README mostram Shell, TypeScript, Python, Go, Java e Perl ao lado do JavaScript que o GitHub marca como linguagem principal. Seis linguagens num projeto de harness não costumam ser escolha estética, é sinal de script de integração específico por ambiente, o que bate com a hipótese de adapter por ferramenta em vez de núcleo unificado de fato compartilhado. Não é defeito automático (às vezes é a única forma honesta de cobrir APIs tão diferentes), mas muda a expectativa de manutenção: toda vez que o Cursor ou o Codex mudar o formato de configuração, alguém precisa atualizar aquele adapter específico, e nada garante que isso aconteça no mesmo dia pras quatro ferramentas.
O checklist antes de colocar isso no seu fluxo
Antes de instalar qualquer agent harness que promete memória, instinto e segurança, eu faria estas perguntas direto no package.json, no pacote baixado ou no changelog, não na página de marketing:
- O manifesto de dependências tem lib de busca ou vetor, ou só manipulação de arquivo?
- O arquivo de instinct tem lógica de atualização automática, ou é edição manual?
- O módulo de segurança intercepta a chamada antes de executar, ou só avisa o modelo em texto?
- A compatibilidade multi-ferramenta é testável num motor único, ou cada integração vive num script separado por linguagem?
- O ritmo de atualização do mantenedor (solo, equipe, empresa) combina com a frequência que as quatro integrações vão exigir manutenção?
Nenhuma resposta “ruim” desqualifica um harness sozinha. Um arquivo markdown bem versionado fazendo o trabalho de contexto persistente é opção válida pra time pequeno. O problema real é instalar um adapter achando que comprou um motor universal, e descobrir isso só quando o Cursor muda de versão e a sua “memória” para de sincronizar com o resto.
Fontes consultadas
Este texto se baseia na leitura da página do repositório affaan-m/ECC no GitHub (github.com/affaan-m/ECC): descrição do projeto, tópicos declarados, trecho público do README, licença MIT, data de criação (18/01/2026), e na inspeção do manifesto de dependências (package.json) do pacote ecc-universal e da página do pacote ecc-agentshield, ambos publicados no npm. Onde o código-fonte completo não estava acessível por essa via, deixei a lacuna explícita em vez de preencher com suposição disfarçada de fato. Quem quiser resolver as perguntas que ficaram em aberto aqui (instinct adaptativo, interceptação real do shield) só tem um caminho: instalar o pacote e ler o código linha a linha.