[PITCH] Se trocar Claude por Codex faz seu agente esquecer tudo, você realmente possui esse agente?

Tenho pensado em uma pergunta que parece filosófica, mas na prática virou um problema de arquitetura:

O que exatamente significa possuir um agente de IA?

Não estou falando de possuir acesso ao modelo, uma assinatura, um prompt de sistema gigantesco salvo em algum arquivo.

Possuir o agente.

Porque existe uma situação estranha na forma como estamos construindo agentes hoje.

Você passa semanas acumulando contexto sobre um projeto.

O agente aprende que determinada pasta não deve ser tocada. Aprende por que uma decisão arquitetural foi tomada seis meses atrás. Aprende como seu time nomeia serviços, quais abordagens já falharam, quais ferramentas funcionam melhor, como um cliente específico prefere ser atendido.

Depois você troca o runtime (talvez porque o Claude Code esteja funcionando melhor para uma tarefa. O codex esteja melhor em outra. Apareceu um modelo novo que custa metade. Talvez você precise mover determinada operação para um modelo local porque os dados não podem sair da máquina. Talvez algum provider altere limites, quotas, comportamento, disponibilidade de modelos ou política de contexto e sua arquitetura precise reagir como experienciamos constantemente…).

Essa necessidade de troca não é uma exceção. Ela deveria ser esperada.

Só que muitas vezes trocar o modelo significa trocar muito mais do que computação, significa reconstruir contexto, reimportar instruções, reensinar decisões, reconectar ferramentas, reconstruir memória, em alguns casos, começar praticamente do zero.

E foi aí que a pergunta começou a incomodar:

Se eu troco o modelo e o agente deixa de ser o mesmo agente, quem era dono daquele agente?

Talvez estejamos colocando coisas demais dentro do modelo

Não acho que providers estejam fazendo algo errado ao funcionar dessa maneira, o modelo é compute alugado e tá tudo ok, compute alugado é ótimo inclusive.

Como usuários não queremos ter que treinar um frontier model, operar milhares de GPUs, que todo mundo rode exatamente a mesma stack.Na verdade, queremos o contrário…

Poder escolher o claude para uma tarefa, codex para outra, um modelo local para dados sensíveis, um endpoint OpenAI-compatible interno e talvez amanhã outro modelo que ainda nem existe.

O problema aparece quando começamos a tratar a entidade que gera os próximos tokens como se ela fosse também a entidade que possui a identidade do agente. São duas coisas diferentes. A forma mais simples que encontrei para pensar nisso foi esta:

modelo != agente

O modelo deveria ser um runtime, algo que recebe uma tarefa, executa raciocínio e devolve um resultado.O agente é outra coisa, algo mais próximo disto:

agente =
identidade
+ memória
+ skills
+ estado operacional
+ permissões
+ conexões
+ experiência acumulada

O runtime pode mudar. Essas coisas não deveriam desaparecer junto com ele.

Um teste simples

Imagine que você tenha um agente trabalhando há três meses em um repositório e ele já conhece:

• decisões arquiteturais importantes;
• padrões que seu time usa;
• erros que já aconteceram;
• procedimentos que funcionaram;
• procedimentos que falharam;
• ferramentas disponíveis;
• permissões;
• pessoas e sistemas com os quais pode falar.

Hoje ele roda com o Claude Code, amanhã você aponta esse mesmo agente para Codex e se pergunta, quanto dele sobreviveu?

Se a resposta for “praticamente tudo, porque Claude só era o runtime”, você tem uma separação bastante saudável. Agora see a resposta for “vou ter reconstruir o contexto que fazia aquele agente ser aquele agente”, então talvez o estado esteja no lugar errado.

Esse acabou virando um dos testes centrais de uma coisa que estamos construindo.

O modelo deveria ser um inquilino

Foi dessa ideia que nasceu a Agentis, a forma mais curta de descrevê-la hoje é: **Agentis é um sistema operacional local-first para agentes de longa duração.
**
Mas essa frase sozinha não explica muito, a parte realmente importante é a fronteira:
ALUGADO / SUBSTITUÍVEL

Claude Codex Cursor Local
\ | | /
execution runtimes

---

       swap seam

---

          SEU:
   Identidade do agente
          Brain
         Skills
        Conexões
      Orquestração
     Estado durável

O que está em cima da linha pode mudar, o que está embaixo continua pertencendo ao agente.

Na V1, estamos tentando fazer essa separação existir de verdade, e não apenas como uma abstração bonita em um diagrama.

O primeiro problema foi memória

Memória de agente virou uma palavra meio desgastada, muita coisa chamada de “memory” hoje é basicamente histórico de conversa, um resumo periódico ou uma vector database anexada ao lado. Nós queríamos uma coisa diferente. Se um agente vai durar meses ou anos, memória não pode simplesmente significar, guarde tudo que apareceu, porque isso cria outro problema. Depois de algum tempo você não tem memória, você tem um depósito.

Então construímos o primeiro conceito de Brain na agentis. Ele é separado do runtime, o objetivo é que conhecimento acumulado pertença ao agente, não ao modelo que estava rodando no momento em que aquele conhecimento apareceu.

A memória então passa por formação, reconciliação, deduplicação, classificação e recuperação.Uma observação temporária não deveria necessariamente virar uma verdade etern, uma decisão importante deveria sobreviver, uma falha recorrente pode virar aprendizado, uma skill pode evoluir. E algo interessante é que a recuperação precisa conseguir dizer, não sei, em vez de fabricar uma lembrança porque semanticamente alguma coisa parecia parecida.

O Brain também roda localmente. Depois do download inicial do modelo de embedding, a recuperação semântica pode funcionar offline. Isso era importante para nós por dois motivos, privacidade é um deles e o outro é mais fundamental:

A memória de um agente não deveria parar de funcionar porque o provider de inferência está indisponível.

Depois descobrimos que memória sozinha não resolvia

Mesmo com memória persistente, ainda existe outro estado extremamente importante, o trabalho em andamento.

Imagine em workflows assíncronos — como aguardar um webhook de um ticket por dias, e não segundos —, que seguem o seguinte pipeline:

1. I/O para fetch de registros;
2. Dispatch de requisição (API/RPC) para contato externo;
3. Await passivo aguardando o callback;
4. Processamento do payload de retorno;
5. Integração downstream com outro serviço;
6. Bloqueio por aprovação externa (Human-in-the-loop);
7. Retomada da rotina.

Se o processo reinicia entre os passos 3 e 4, esse trabalho não pode simplesmente evaporar. Também não faz sentido, por exemplo, manter uma thread aberta, queimando recurso, enquanto esperamos terça-feira chegar.

Por isso o Agentis acabou ganhando uma camada de estado durável.

Entidades têm inbox, relógio de wake-up, estado persistente e identidade independente de uma execução específica.

Implementamos um padrão similar ao Actor Model: as entidades possuem filas de mensagens (inboxes), agendadores assíncronos (wake-up timers), estado persistido (via checkpoints ou event sourcing) e uma identidade cujo ciclo de vida é totalmente desacoplado do runtime.

E existe um problema ainda pior: agentes que dizem que fizeram algo

Esse talvez seja um dos problemas que mais me incomoda em automações com LLM. O workflow executa e o agente responde:

“Done.”

E todo mundo comemora… mas o email foi enviado? O registro foi alterado? O arquivo existe? A mensagem chegou ao provider? O pagamento foi criado? O objetivo de negócio aconteceu?

“O agente terminou” e “o trabalho foi realizado” são fatos diferentes.

No workflow engine da Agentis, tentamos separar isso explicitamente.

Um run pode estar completed = true, e ainda assim accomplished = false.

Porque finalizar o grafo não prova que o resultado declarado existe. Parece um detalhe pequeno mas não é.

A partir do momento que agentes começam a tocar sistemas reais, “parece que deu certo” deixa de ser uma política aceitável de execução.

Isso também mudou nossa visão sobre workflows

Inicialmente é tentador pensar em automação de agentes como:

prompt
↓
tool
↓
prompt
↓
tool

Só que o mundo real é inconveniente, APIs falham, dados vêm incompletos, um runtime perde uma capacidade, permissões mudam, uma pessoa responde algo inesperado, uma integração entrega um formato diferente, o agente escolhe uma estratégia ruim. Por isso a engine acabou ficando muito mais próxima de um sistema de execução durável do que de uma simples sequência de prompts.

Ela tem snapshots, replay parcial, checkpoints, loops, recuperação e diferentes níveis de self-healing.

E existe uma regra importante:

se não conseguimos recuperar de forma defensável, falhamos de forma explícita.

Prefiro um workflow dizendo “não consegui provar que fiz” do que um agente dizendo, “você tem razão, a migration não foi concluída”.

Se o agente é seu, as capacidades também precisam poder ser suas

Outro problema aparece quando começamos a depender demais das ferramentas que um determinado harness decidiu oferecer. Claude Code tem determinadas capacidades, codex tem outras, cursor tem características próprias, um runtime local talvez não tenha nenhuma delas. Por isso criamos uma camada de abstração de runtime, hoje a Agentis consegue trabalhar com diferentes harnesses e endpoints através de um contrato comum.

Isso não significa fingir que todos são iguais, um runtime pode ter browser e outro não, um pode conseguir escrever no filesystem, outro pode estar em modo read-only. Então uma tarefa pode declarar que precisa de determinadas capacidades, e o sistema verifica isso antes de enviá-la ao runtime.

A abstração serve para reduzir o acoplamento. Não para apagar a realidade.

Foi aí que Agentic Apps começaram a fazer sentido

Essa parte é provavelmente a mais experimental da ideia toda.

Se um agente:

• tem identidade durável;
• possui memória própria;
• consegue executar workflows;
• consegue conversar com sistemas e pessoas;
• aprende com outcomes;
• sobrevive à troca do modelo;

então ele começa a poder participar de algo maior do que uma conversa.

Começa a ser possível construir software onde agentes não são uma feature adicionada no canto direito da tela, eles fazem parte da própria operação do produto.

Estamos chamando isso de Agentic Apps.

Hoje pensamos neles através de quatro partes:

1. Data
2. Interface
3. Orchestration
4. Brain

Dados reais, uma interface real, workflows reais, e agentes naquela execução acumulando conhecimento sobre os resultados daquele sistema de forma compartilhada.

Por exemplo, um app pode ter um goal, pode testar duas estratégias diferentes, medir os resultados das duas, depositar esses resultados na Brain, e com evidência suficiente, sugerir uma estratégia seguinte. Não porque o modelo “sentiu” que A parecia melhor que B, mas porque outcomes foram registrados e comparados.

Ainda estamos no começo dessa ideia.Mas, para mim, é onde a separação entre modelo e agente começa a produzir consequências muito mais interessantes.

Então o que existe de fato na V1?

Hoje a Agentis já junta, em uma única instalação:

• agentes persistentes;
• Brain local e durável;
• múltiplos runtimes;
• workflows duráveis;
• self-healing;
• replay;
• approvals;
• budgets;
• integrações e canais;
• MCP;
• A2A;
• Agentic Apps;
• extensions (operações tipadas, testáveis e com permissões explícitas.);
• interfaces geradas;
• experimentos;
• auditoria;
• uma SDK tipada agentis.*.

Tudo é open source sob Apache 2.0, e o estado principal fica local.

Para rodar:

npm install -g @agentis-labs/cli
agentis up

O dashboard sobe junto com a API e o runtime local. Não precisa preencher formulário para baixar. Não tem “request access”. O código está aberto porque essa tese fica muito menos interessante se ninguém puder verificar a implementação.

O que ainda não resolvemos

É claro,

V1 significa V1.

Ela já é utilizável, mas não vou fingir que estamos entregando uma infraestrutura completamente madura para qualquer escala e qualquer ambiente. Algumas limitações atuais:

Escala distribuída

O caminho principal hoje usa SQLite.

Isso funciona muito bem para local-first, equipes pequenas e cargas controladas.

Não estamos prometendo hoje escrita horizontal, HA ou ambientes multi-tenant gigantes.

Integrações

Existe um catálogo grande de conectores, mas “existe no catálogo” não significa que todos possuem uma integração específica e igualmente profunda. Parte utiliza templates HTTP ou configuração manual.

Há diferença entre:

consigo chamar esta API

e:

todos os fluxos específicos desse produto estão tratados.

Paridade entre runtimes

Ter uma interface comum não torna Claude Code, Codex, Cursor, Hermes ou um endpoint local iguais. Permissões, browser, filesystem, MCP, sessões e capacidades continuam variando, a Agentis verifica essas diferenças, não consegue fazê-las deixar de existir.

Ergonomia

Hoje a plataforma é, em vários pontos, mais poderosa do que simples.

Existe CLI, dashboard, API e a superfície agentis.*, mas configurar runtimes, OAuth, permissões e ambientes mais complexos ainda exige conhecimento operacional.

Tem bastante coisa para melhorar aqui.

Segurança de extensions

Sobre as extensions, node:vm não é uma fronteira suficiente contra código malicioso.

Código não confiável precisa de isolamento real.

Performance

Ainda não publiquei uma matriz séria de throughput e latência por cenário. A prioridade inicial foi correção, durabilidade e rastreabilidade. Benchmarking de carga e caracterização de limites ainda precisam amadurecer.

APIs

A superfície ainda está evoluindo. Existem aliases de compatibilidade e partes que ainda podem mudar então quem construir algo grande em cima da V1 deve acompanhar migrações.

Por que lançar agora, então?

Porque acho que existe valor em discutir a arquitetura antes de ela ficar completamente congelada. Principalmente porque não estou convencido de que nossa definição de ownership seja necessariamente a definição final.

Talvez estejamos errados em algum ponto importante, talvez exista uma divisão melhor entre identidade, memória e runtime, talvez parte do que colocamos no Brain devesse estar em outro lugar, talvez Agentic Apps precisem de outra abstração.

Esse é um dos motivos para abrir o projeto agora. A V1 não é a declaração de que resolvemos agentes. É a primeira versão em que conseguimos colocar uma linha concreta no sistema e dizer:

isso aqui pertence ao runtime.

isso aqui pertence ao agente.

E fazer a maior parte da plataforma respeitar essa linha.

E o harness?

Esse é um dos próximos passos que mais nos interessa por motivos pessoais, do que acredito que os harnesses criaram hoje que não é tão saudável, mas isso é um assunto pra outra hora.

Hoje a Agentis consegue trabalhar com vários harnesses existentes, isso é útil porque ninguém precisa abandonar a ferramenta que já usa. Mas também significa que parte da experiência continua limitada pelo formato, pelas permissões e pelas decisões desses runtimes.

O caminho natural é continuar reduzindo essa distância. Não queremos construir um mundo onde Agentis exige um único modelo assim como também não queremos um mundo onde possuir o agente significa continuar dependendo completamente da semântica interna de um harness externo.

A ideia é continuar empurrando a fronteira:

modelos cada vez mais intercambiáveis; agentes cada vez mais duráveis.

A pergunta que eu gostaria de jogar para vocês

Esquece a Agentis por um minuto.

Pensa no melhor agente que você usa hoje, pode ser Claude Code, Codex, Cursor, alguma stack própria, LangGraph, CrewAI, qualquer coisa.

Agora troca o runtime.

O que sobrevive?

• Memória?
• Skills?
• Histórico de decisões?
• Estado de workflows?
• Permissões?
• Conhecimento do repositório?
• Falhas anteriores?
• Capacidades?

Ou você está criando um agente novo e tentando fazer ele parecer com o antigo?

Essa é a discussão que acho interessante agora:

Qual é o conjunto mínimo de estado que precisa sobreviver à troca de modelo para você dizer que realmente possui aquele agente?

Se a resposta de vocês for diferente da nossa, melhor ainda. É justamente esse tipo de coisa que queremos descobrir enquanto a arquitetura ainda pode mudar.

Github: https://useagentis.com/
NPM: https://www.npmjs.com/package/@agentis-labs/cli
Documentação: https://docs.useagentis.com/
Website: https://useagentis.com/