Este texto compartilha algumas lições importantes para desenvolvedores que pretendem usar OpenClaw para construir agentes com memória e regras próprias.

Comecei a perceber um comportamento errático na Márcia, minha assistente de inteligência artificial. Ela opera sobre o OpenClaw e é responsável, entre outras coisas, por gerar resumos das minhas reuniões a partir das transcrições.

Existe um formato definido para os meus resumos. Um template claro. Sempre o mesmo padrão. Ela começou a ignorá-lo. Importante: quando eu pedia para adotar o template correto, ela refazia o resumo e acertava. Ou seja, o modelo era capaz. Não era limitação cognitiva. Por isso não era catastrófico. Era inconsistência estrutural.

No início, associei o problema a alucinação. Algo próprio do comportamento probabilístico das LLMs. Modelos variam. Oscilam. Nem sempre respondem da mesma forma ao mesmo estímulo.

Mas havia um detalhe que enfraquecia essa hipótese: quando eu reforçava o padrão explicitamente, ela refazia o resumo e acertava. O modelo era capaz. Ficou claro que o erro não estava na inteligência. Estava no contexto. Era engenharia de contexto.

A Márcia se comporta a partir de arquivos-chave no seu workspace. Ali estão suas regras, sua memória e suas diretrizes operacionais.

Optei por manter esse workspace no Git, como código-fonte de uma aplicação. Posso acessar o contexto dela de qualquer lugar, como fazemos com software tradicional. Toda vez que a Márcia altera seus arquivos de memória ou regras, ela faz commit e push para o repositório. Está instruída a operar assim. O contexto dela evolui, mas evolui versionado.

Então fiz o óbvio. Clonei o repositório. Abri o workspace no Cursor. Explorei os arquivos com calma. Fui lendo instrução por instrução. E, aos poucos, o problema apareceu.

Havia instruções conflitantes. Trechos deslocados. Regras sobrepostas. Pequenas incoerências acumuladas ao longo do tempo. Nada dramático isoladamente. Mas suficientes, em conjunto, para gerar comportamento inconsistente.

Não havia nada de misterioso. Havia desorganização estrutural.

O workspace da Márcia sofre do mesmo mal de qualquer código-fonte que evolui sem revisão arquitetural sistemática. As leis de Lehman continuam válidas. Sistemas em evolução tendem a aumentar em complexidade e desordem se não houver esforço deliberado de reestruturação. Agentes não escapam dessas leis.

Eu poderia ter ajustado tudo manualmente, arquivo por arquivo. Não fiz isso.

Escrevi arquivos explícitos de regras que deveriam ser obedecidas pelos agentes no Cursor. Regras persistentes. Porque entendi que esse tipo de desorganização tende a voltar a acontecer. Organização não pode depender de disciplina momentânea. Precisa virar norma formal. Transformei estrutura em contrato.

Depois disso, pedi a um agente no próprio Cursor que analisasse todo o workspace à luz dessas regras, identificasse inconsistências, elaborasse um plano de correção e aplicasse as mudanças. Não corrigi linha por linha. Defini critérios e deixei o agente executar a refatoração. É assim que se programa hoje.

Memórias alinhadas. Contexto limpo. O resumo voltou ao formato correto sem que eu precisasse intervir.

Lições. Trate agentes como software, não como magia. Versione o workspace do seu agente como versiona código-fonte. Formalize regras estruturais antes de corrigir sintomas. Refatore deliberadamente. A complexidade sempre cresce. Teste a hipótese estrutural antes de culpar o modelo. Projete contexto com a mesma disciplina com que projeta código.

Lembre-se: inteligência amplifica estrutura. Se a base está desalinhada, o erro escala.