Nos últimos dias eu comecei a explorar o Pi Durable, uma extensão da ideia do Pi para agentes que precisam continuar trabalhando por bastante tempo.

A motivação foi simples: eu já estava usando agentes de IA no desenvolvimento, mas ainda pensava neles como conversas que começam e terminam. Abro o terminal, faço uma pergunta, acompanho algumas ferramentas e, quando a sessão acaba, o trabalho volta a depender da minha memória.

O Durable propõe uma mudança de perspectiva. Em vez de pensar apenas no agente que responde a uma pergunta, podemos pensar em uma pequena infraestrutura que mantém conversas, tarefas e estado de trabalho ao longo do tempo.

O que significa “durável”

O Pi Coding Agent é muito bom para uma pessoa dirigir um agente no terminal. Eu entro em uma pasta, faço uma solicitação e acompanho o que ele está fazendo. Se alguma coisa dá errado, olho o resultado e peço para continuar.

O Pi Durable tenta resolver outro problema. Ele foi criado para aplicações agênticas que precisam:

• continuar depois que o processo cai;
• sobreviver ao computador dormir ou ao container ser reiniciado;
• executar tarefas demoradas;
• manter várias conversas ao mesmo tempo;
• permitir que mais de uma interface acompanhe o trabalho;
• guardar o estado da aplicação junto com a conversa.

A palavra importante aqui é harness. O Durable não é um modelo de linguagem e também não é apenas um chatbot. Ele fornece o armazenamento e a máquina de execução que colocam o modelo para trabalhar.

Cada chamada ao modelo, cada chamada de ferramenta e cada etapa de uma tarefa pode ter um checkpoint. Se o processo morrer no meio do caminho, outro processo pode abrir o mesmo armazenamento e continuar de onde parou.

Isso parece parecido com uma fila de jobs, mas há uma diferença interessante: a conversa com o agente também faz parte do estado. O agente pode saber o que já tentou, o que falhou e qual era o próximo passo.

O agente não precisa morar no produto

Uma ideia do vídeo IA como veículo de expressão, mais do que ferramenta, do Henrique Bastos com o Alison, ficou na minha cabeça: talvez a IA seja mais do que uma ferramenta. Ela pode ser um novo veículo de expressão.

Isso também muda a forma de pensar nos produtos de IA. Em vez de aceitar um aplicativo fechado e tentar viver dentro dele, podemos montar um ambiente que se encaixa no nosso jeito de trabalhar.

No meu caso, esse ambiente já tinha algumas peças:

• o Pi como harness de desenvolvimento;
• o caxola como vault de decisões e descobertas;
• Engram como memória operacional;
• diferentes modelos para implementação, busca e revisão;
• regras em AGENTS.md para separar workspace-A e workspace-B;
• ferramentas de QA, testes e automação.

O Pi Durable entrou como uma camada para conectar essas peças no tempo. Ele pode manter uma conversa de coordenação, iniciar tarefas filhas e guardar o estado do que foi descoberto.

Meu primeiro caso de uso

Meu trabalho fica dividido principalmente entre dois contextos:

workspace-A/
workspace-B/

Seria tentador apontar um agente para a pasta pai e deixar que ele enxergasse tudo. Mas isso seria uma má ideia. O workspace-A e o workspace-B têm regras, modelos e níveis de confidencialidade diferentes.

Por isso, montei uma arquitetura simples:

Coordenador
├── agente workspace-A
└── agente workspace-B

O coordenador recebe os relatórios. Cada agente filho trabalha no seu próprio contexto, com seu próprio diretório e seu próprio modelo.

Para o workspace-A, uso o provider e os modelos configurados para esse ambiente. Para o workspace-B, uso o GitHub Copilot e mantenho o acesso somente para leitura. O agente não recebe um caminho arbitrário; ele escolhe um workspace autorizado, e o programa resolve o diretório internamente.

Também excluí explicitamente do relatório um repositório sensível que não fazia sentido aparecer no briefing diário. Esse tipo de detalhe parece pequeno, mas é exatamente o tipo de coisa que precisa estar no código, não apenas na intenção do prompt.

O primeiro briefing

A primeira ferramenta que criei foi um snapshot do workspace. Ela consulta apenas informações simples:

• repositórios disponíveis;
• branch atual;
• estado da working tree;
• quantidade de arquivos alterados;
• alguns commits recentes.

Depois, o coordenador transforma os dois relatórios em um briefing com:

• prioridades;
• riscos;
• mudanças desde o último relatório;
• próximos passos.

O estado anterior fica salvo em um documento Durable no SQLite. Assim, o agente não precisa apenas olhar para o estado atual. Ele pode comparar a execução de hoje com a anterior e dizer que nada mudou — o que é bem melhor do que gerar um relatório enorme repetindo as mesmas informações.

Uma pequena surpresa no caminho

Na primeira execução, recebi algo assim no terminal:

{
  "name": "read",
  "arguments": {
    "path": "/home/fabiano/work",
    "content_type": "directory_contents"
  }
}

Não era o briefing. Era uma chamada de ferramenta que vazou para a saída.

A causa foi interessante: a conversa coordenadora já existia no SQLite com uma configuração antiga, que incluía as ferramentas de leitura do Pi. Quando o programa foi aberto novamente, passar uma nova configuração para root() não substituiu automaticamente tudo o que estava persistido.

Foi preciso reconfigurar explicitamente a conversa e remover as ferramentas que o coordenador não deveria ter. Também apareceu uma incompatibilidade com o nível de thinking do modelo, que foi corrigida configurando o nível de forma explícita.

Essa foi uma boa demonstração do motivo pelo qual a durabilidade exige cuidado. Persistir estado não significa apenas guardar mensagens. A configuração persistida também precisa ser tratada como parte do sistema.

Por enquanto, somente leitura

Eu decidi começar sem permitir que o agente altere qualquer coisa.

O Durable pode consultar os repositórios e produzir relatórios, mas não pode:

• editar arquivos;
• criar commits;
• fazer push;
• alterar o vault;
• atualizar Jira ou GitHub;
• fazer deploy;
• executar mudanças em produção.

Essa escolha deixa o experimento bem mais tranquilo. Posso observar a utilidade do sistema sem me preocupar com uma automação tomando uma decisão que eu não queria.

A regra ficou simples:

leitura automática
análise automática
alteração somente depois de aprovação

Talvez algumas tarefas nunca precisem passar da primeira etapa. Um relatório que me ajuda a começar o dia já pode ser bastante útil.

Tirando o briefing do terminal

Depois de testar o comando manualmente, o passo seguinte foi automatizar a rotina.

Configurei dois timers de usuário do systemd:

• 09:00: briefing matinal;
• 17:00: fechamento do dia.

Eles não mantêm um processo rodando o tempo todo. O timer inicia o programa, o Durable abre o SQLite, faz o trabalho, salva o resultado e encerra o processo.

O briefing matinal responde, na prática:

• o que mudou desde a última execução?
• quais são as prioridades de hoje?
• existe algum bloqueio?
• há algum risco que merece atenção?

O fechamento do dia olha para outra direção:

• o que foi concluído?
• o que ficou pendente?
• o que deve ser retomado amanhã?

Os relatórios ficam em uma pasta local:

pi-durable-lab/reports/

Também foi configurada uma notificação desktop com o caminho para abrir o arquivo. Recebi a primeira notificação, cliquei no link e consegui abrir o relatório. Essa foi uma pequena coisa, mas mudou bastante a sensação do sistema: ele deixou de ser um comando que eu precisava lembrar e passou a aparecer no meu fluxo de trabalho.

O que estou tentando descobrir

Ainda não sei se esse briefing será realmente útil depois que passar a novidade inicial. Quero observar algumas coisas:

• ele me ajuda a escolher o que fazer primeiro?
• traz informações que eu não teria visto sozinho?
• repete demais o estado dos repositórios?
• os horários fazem sentido?
• o fechamento do dia ajuda a recomeçar no dia seguinte?
• deveria consultar também as decisões do vault?
• quais informações são ruído?

Essa fase é importante. É muito fácil criar uma automação tecnicamente interessante que não melhora a vida de ninguém.

Por isso, ainda não estou tentando integrar Slack, Jira, GitHub ou o vault. Primeiro quero entender se o relatório simples, baseado no estado dos repositórios, já resolve algum problema real.

O que pode vir depois

Se o uso diário provar que o briefing vale a pena, o próximo passo pode ser adicionar contexto com cuidado:

• decisões recentes do caxola;
• issues relacionadas às branches atuais;
• pull requests aguardando revisão;
• resultados de testes;
• pendências registradas no último fechamento.

Depois podemos pensar em ações, sempre com aprovação explícita:

• criar uma tarefa;
• preparar um plano de implementação;
• gerar um rascunho de decisão;
• sugerir uma atualização no vault;
• abrir um trabalho para um agente especializado.

Eu não quero que o sistema saia escrevendo em todo lugar só porque agora ele consegue. A durabilidade deve tornar o trabalho mais contínuo, não mais difícil de controlar.

O que aprendi até aqui

A principal descoberta foi que um agente durável não é apenas um agente que fica ligado por mais tempo.

Ele precisa de:

• estado persistente;
• tarefas com checkpoints;
• regras claras de ownership;
• ferramentas com política de replay;
• separação entre workspaces;
• contexto que possa ser reconstruído;
• uma maneira de comparar o estado atual com o anterior;
• interfaces para acompanhar o trabalho.

Também ficou claro que o agente precisa desaparecer um pouco. O objetivo não é abrir mais uma tela para acompanhar um robô. O objetivo é receber uma informação útil no momento certo e continuar trabalhando.

Por enquanto, o Pi Durable está fazendo uma coisa pequena: observa dois workspaces, compara o estado atual com o anterior e me entrega um resumo pela manhã e no fim do dia.

Pode parecer pouco. Mas é exatamente assim que prefiro começar: uma automação simples, persistente, observável e somente de leitura. Se ela provar seu valor, aí sim ganha mais contexto e, talvez, autorização para agir.