Agente persistente não é memória: é um ambiente com contrato
Um agente trabalhou durante a noite. Pela manh, h arquivos novos no workspace, um log comprido e uma mensagem dizendo que a tarefa pode continuar de onde parou.
Mas em qual branch ele estava? Qual hiptese guiou a mudança? Quais permisses foram usadas? Quanto do orçamento j foi consumido? E o que exatamente significa "continuar" quando o projeto recebeu commits enquanto o agente estava parado?
Dizer que o agente tem memria uma descriço confortvel, mas curta demais para um processo que pode alterar cdigo. Quando a execuço atravessa sesses, o que precisa persistir no apenas o texto da conversa. Precisam persistir o estado operacional, os limites e um caminho para conferir o trabalho.
Persistncia no significa compreenso
Um workspace persistente guarda arquivos, histrico, resultados intermedirios e instruçes. Isso reduz trabalho repetido. Tambm pode guardar uma hiptese errada.
Se a primeira sesso concluiu que um bug vinha do cache, mas a evidncia apontava para uma condiço de corrida, a segunda sesso pode retomar o mesmo diagnstico com bastante confiança. O erro no desaparece s porque o estado foi preservado.
Antes de retomar, o agente precisa confirmar pelo menos:
- o objetivo ainda o mesmo;
-
- a branch e o commit inicial continuam vlidos;
-
- os arquivos do workspace no foram alterados por outra pessoa;
-
- a hiptese anterior tem evidncia suficiente;
-
- o orçamento restante permite uma nova tentativa.
Histrico ajuda a reconstruir o caminho. No prova que o caminho estava certo.
O ambiente vem antes da autonomia
A pergunta mais importante no quantos passos o agente consegue executar sem intervenço. quais passos ele pode executar sem causar um estrago desproporcional.
Para uma tarefa de frontend, por exemplo, o contrato do runtime pode começar assim:
escopo:
arquivos_permitidos:
- app/components/CheckoutForm.tsx
- app/components/CheckoutForm.test.tsx
comandos_permitidos:
- pnpm test -- CheckoutForm
- pnpm lint
permissoes:
rede: somente_desenvolvimento
secrets: nenhum
deploy: proibido
operacoes_destrutivas: exigir_aprovacao
orcamento:
minutos: 30
tentativas_de_teste: 2
```
O formato no o ponto. O ponto transformar uma intenço vaga em uma superfcie de aço que algum consegue revisar.
Permisses para rede, secrets, deploy e operaçes destrutivas merecem tratamento diferente. Um agente pode precisar consultar uma API de desenvolvimento, mas isso no significa que deve acessar credenciais de produço. Pode editar um componente, mas isso no autoriza trocar dependncias do projeto inteiro.
Um sandbox mais estreito cria pausas e pode exigir aprovaço humana. Esse um custo real. Ainda assim, a pausa mais barata do que descobrir depois que uma investigaço de bug publicou uma configuraço, removeu dados ou alterou arquivos fora do escopo.
## Parar tambm parte do contrato
Um runtime que s conhece "sucesso" e "erro" força o agente a esconder situaçes importantes. A execuço deveria conseguir terminar como `concludo`, `bloqueado`, `timeout` ou, quando fizer sentido, `budget_reached`.
Esses estados no so enfeite de dashboard. Eles mudam o handoff.
- `concludo` significa que os critrios de aceite foram verificados.
- `bloqueado` significa que falta uma permisso, uma deciso ou uma informaço.
- `timeout` significa que o tempo acabou antes de a tarefa ser validada.
- `budget_reached` significa que o limite configurado foi atingido, no que o agente encontrou a soluço.
H runtimes gerenciados que j adotam limites rgidos de gasto por sesso e interrompem novas requisiçes ao atingir o orçamento. Essa ideia til mesmo quando voc no usa esse runtime: custo e tempo precisam ser sinais de parada visveis, no detalhes que ficam escondidos na implementaço.
A pior sada encerrar uma investigaço incompleta com a mesma aparncia de uma tarefa validada. "O agente parou" e "o agente terminou" so eventos diferentes.
## Skills versionadas ficam perto do cdigo
Se o agente precisa seguir o jeito do projeto, essa regra deve viver perto do projeto.
Uma skill curta pode registrar convençes, arquivos que no devem ser tocados, comandos de teste e critrios de aceite. Como ela est no repositrio, entra no histrico e pode ser revisada junto com o cdigo. Alguns ambientes j carregam esse tipo de instruço a partir de diretrios de skills quando montam o repositrio.
Isso no transforma a skill em uma enciclopdia. Pelo contrrio. Quanto mais ela tenta explicar tudo, maior a chance de ficar velha e ser ignorada.
Para uma correço pequena, bastaria algo prximo de:
```md
## Correço de estado do checkout
- Altere apenas os componentes do checkout e os testes relacionados.
- No troque dependncias neste fluxo.
- Rode `pnpm test -- CheckoutForm` antes de abrir o handoff.
- Se a hiptese sobre a API no puder ser confirmada, marque a tarefa como bloqueada.
```
A documentaço externa continua sendo consultada quando muda. A skill local guarda o que especfico do repositrio. Misturar as duas coisas em um nico prompt torna difcil saber se uma regra uma deciso da equipe ou um detalhe temporrio de uma API.
## Checkpoint melhor que promessa de retomada
Um checkpoint bom no precisa registrar cada pensamento do agente. Precisa registrar o que outra pessoa usaria para continuar sem adivinhaço.
Eu incluiria:
```md
## Checkpoint — 2026-08-13 02:10
- objetivo: corrigir o estado do formulrio aps erro de API
- branch: fix/checkout-error-state
- commit inicial: a1b2c3d
- hiptese: o estado de carregamento no limpo no caminho de erro
- arquivos alterados: nenhum
- comandos executados: pnpm test -- CheckoutForm
- resultado: 1 cenrio ainda falha
- pendncia: reproduzir com resposta 500 e verificar o estado visual
- encerramento: budget_reached
```
Na retomada, o agente revalida o commit, confere o diff e roda o teste afetado antes de aplicar outra mudança. Se algum mexeu no mesmo componente, o checkpoint no manda continuar cegamente; ele revela que o contexto mudou.
O custo de escrever esse registro pequeno. O ganho aparece quando a tarefa d errado. Um diff menor facilita reviso e rollback. Uma hiptese explcita pode ser descartada sem que o prximo agente precise inferi-la de dezenas de mensagens.
Persistncia reduz repetiço, mas tambm preserva lixo. Vale definir uma poltica de limpeza: o que checkpoint ativo, o que artefato temporrio e o que deve ser removido quando a tarefa termina. Guardar tudo para sempre no observabilidade. acumular contexto sem dono.
## Trace no substitui evidncia do produto
Traces mostram quais ferramentas foram chamadas e em que ordem. Isso ajuda a responder "o que o agente tentou fazer?". No responde sozinho "o produto ficou correto?".
Em uma correço frontend, o handoff deveria juntar a execuço do agente com sinais do comportamento real:
- teste afetado executado e resultado;
- diff revisado;
- fluxo reproduzido no navegador;
- estado final observado;
- console e rede inspecionados quando forem relevantes;
- captura de tela ou vdeo apenas quando ajudar a provar uma mudança visual.
Ferramentas estruturadas para a web, como as propostas pelo WebMCP, apontam para um futuro em que agentes podero interagir com funçes e formulrios expostos pela aplicaço, em vez de depender apenas de cliques. Isso pode tornar a automaço mais previsvel, mas o recurso ainda experimental e no substitui autenticaço, permisses, testes nem aprovaço.
A regra simples: o trace explica o caminho; o teste e a evidncia do produto sustentam a concluso.
## Um fluxo pequeno para começar
Escolha uma tarefa que atravesse duas sesses, mas que tenha um risco controlvel. Uma correço de estado em um formulrio melhor para esse experimento do que um pedido vago para "melhorar o frontend".
1. Defina no repositrio os arquivos permitidos, o comando de teste e o critrio de aceite.
2. Monte um workspace isolado e registre branch, commit inicial e orçamento.
3. Antes de parar, salve a hiptese, os arquivos tocados, os comandos executados e o que ficou pendente.
4. Na retomada, confirme que o objetivo e o estado do cdigo continuam vlidos.
5. S marque como concludo depois de revisar o diff e observar o comportamento esperado.
O fluxo pode parecer burocrtico na primeira semana. Depois de uma retomada confusa, ele começa a parecer uma economia de tempo.
Um agente persistente til no o que nunca interrompe. o que trabalha dentro de limites, sabe declarar que est bloqueado e deixa um handoff que outra pessoa consegue conferir sem confiar na memria da mquina.
## Fontes
- [Claude Platform — release notes](https://platform.claude.com/docs/en/release-notes/overview)
- [What’s new in Microsoft Foundry — Build Edition](https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-build-2026/)
- [Chrome at Google I/O 2026](https://developer.chrome.com/blog/chrome-at-io26?hl=pt_br)