# Durable Harness e Pi Durable: agentes à prova de falhas

> Entenda como o durable-harness da Vercel e o Pi Durable transformam agentes de codificação em máquinas de estado que sobrevivem a quedas e rodam por meses.

Source: https://agentify.ia.br/blog/durable-harness-pi-durable/

**TL;DR:** O `durable-harness` da Vercel e o Pi Durable da Earendil transformam agentes de codificação (como Pi, OpenCode, Claude Code, Codex e fx) em máquinas de estado resilientes. Em vez de perderem o progresso quando o terminal fecha ou a função serverless dá timeout, eles gravam cada chamada de modelo e ferramenta em um log de eventos append-only (“World”), permitindo retomar a execução no meio do turno sem duplicar efeitos colaterais.

Você dispara uma refatoração grande no seu agente de codificação antes do almoço. O agente lê vinte arquivos, roda a suíte de testes, aplica metade das correções, abre um branch — e aí o seu notebook suspende, a conexão cai ou a função serverless estoura o timeout de cinco minutos.

Quando você volta, sobrou apenas um processo morto e um repositório pela metade.

Em julho, expliquei aqui que o modelo é o motor e o [harness é o chassi](/blog/harness-e-loop-arquitetura-agentes). Há poucos dias, vimos como o [Harness² otimiza o próprio chassi sozinho](/blog/harness2-recursive-harnessing) por meio de auto-melhoria recursiva. Mas faltava resolver uma falha estrutural muito mais básica: **quase todo harness nasceu efêmero**, preso à memória RAM de uma aba de terminal ou de um container temporário.

Em outubro de 2026, duas peças complementares mudaram esse jogo: o lançamento do **Pi Durable** (`@earendil-works/pi-durable`), criado por Mario Zechner e Armin Ronacher na Earendil, e o anúncio do **`durable-harness`** pela [Vercel](https://vercel.com/blog/making-every-harness-durable), assinado por Pranay Prakash e Eric Dodds.

A proposta é direta: **tirar o agente de codificação da aba do terminal e transformá-lo em um sistema durável**, capaz de sobreviver a crashes, reiniciar no meio de um turno e rodar por horas, dias ou meses.

## O que é um Durable Harness (e onde entra o Pi Durable)?

Um **Durable Harness** é um harness de execução de agentes que desacopla o loop de raciocínio e ação da vida útil do processo em memória, persistindo não apenas o histórico de mensagens, mas o **estado exato de execução em voo** (*turn-in-flight*).

Pense na diferença entre escrever um documento no Bloco de Notas sem salvar e editar uma transação em um banco de dados com *Write-Ahead Logging* (WAL). No Bloco de Notas, se a energia acabar no meio de uma frase, tudo o que estava na memória RAM desaparece. Em um banco de dados moderno, cada intenção e cada confirmação são gravadas em um log sequencial antes e depois de acontecerem: quando a máquina religa, o sistema lê o log, descobre exatamente o que ficou pela metade e retoma do ponto exato.

Um agente tradicional funciona como o Bloco de Notas. Mesmo quando salva o histórico do chat em disco ao final de cada resposta, ele perde tudo o que estava acontecendo *dentro* do turno se o processo cair no meio de cinco chamadas de ferramentas.

Já um Durable Harness funciona como o banco de dados transacional.

### Duas camadas do mesmo movimento: Pi Durable e `durable-harness`

Como os dois nomes apareceram quase juntos em outubro de 2026 e se integram diretamente, vale separar quem é quem:

- **[Pi Durable](https://earendil.com/posts/pi-durable/) (`@earendil-works/pi-durable`)**: lançado em 1º de outubro de 2026 pela Earendil junto ao marco do Pi 1.0/2.0, é o bloco de construção oficial de persistência e recuperação de falhas do ecossistema [Pi](/blog/pi). Ele permite rodar múltiplas conversas concorrentes, fazer *fork* de estado com histórico de ancestralidade e retomar trabalho inacabado sobre SQLite, PostgreSQL ou IndexedDB no navegador.

- **[`durable-harness`](https://github.com/vercel-labs/durable-harness)**: lançado pela Vercel em 19 de outubro de 2026 (atualmente na série `0.0.1-beta`), é um kit open-source e agnóstico de runtime que mapeia múltiplos harnesses do mercado — incluindo o próprio Pi (`durable-harness/pi`), o Pi Durable (`durable-harness/pi-durable`), [OpenCode](/blog/opencode), [Claude Code](/blog/claude-code), [Codex](/blog/codex-cli), `eve` e `fx` — sobre a camada de armazenamento do [Vercel Workflow SDK](https://github.com/vercel/workflow).

Ou seja: se você usa o Pi puro ou o Pi Durable, o pacote da Vercel fornece o adaptador pronto para que cada sessão do agente vire uma execução durável de workflow — seja na infraestrutura da Vercel (com Queues e Sandboxes), localmente em disco ou self-hosted no seu próprio PostgreSQL.

### O que um Durable Harness não é

Para manter o vocabulário afiado e não misturar conceitos:

- **Não é apenas persistência de histórico de chat.** Salvar o JSON da conversa no banco no fim da resposta é trivial. A durabilidade real rastreia o estado da execução *durante* o turno, chamada por chamada.

- **Não é um novo agente de codificação de terminal.** Como destacou o canal da Hugging Face em sua análise técnica de outubro de 2026, o Pi Durable é um bloco de construção para aplicações agênticas *always-on*, não um substituto de CLI interativa.

- **Não é um [Meta-Harness](/blog/meta-harness-nextjs-agentes-ia) nem o [Harness²](/blog/harness2-recursive-harnessing).** Enquanto o Meta-Harness governa frotas multi-repositório e o Harness² otimiza prompts e [skills](/blog/o-que-sao-skills-e-como-especializar-agentes) recursivamente, o Durable Harness resolve a **confiabilidade de sistemas distribuídos** (tolerância a falhas, retomada e idempotência).

No `r/PiCodingAgent`, o desenvolvedor `u/fingerthief` resumiu a diferença prática em duas frases que viralizaram na comunidade: o Pi base já salva suas sessões e o histórico de ferramentas, mas o Pi Durable também rastreia o estado de execução — então, após um crash ou reinicialização, ele retoma automaticamente o trabalho inacabado.

## Como funciona a execução durável na prática?

A mágica do `durable-harness` está em transformar o [loop ReAct](/blog/harness-e-loop-arquitetura-agentes) (raciocinar → agir → observar) em um log de eventos determinístico apoiado por uma abstração de armazenamento chamada **World** (do Vercel Workflow SDK).

Quando você inicia ou envia uma mensagem para uma sessão de agente, o fluxo segue quatro passos rigorosos:

- **Mapeamento Sessão → Workflow Run.** Cada sessão do agente é vinculada a uma execução de workflow única. Em vez de depender de uma conexão HTTP aberta por horas, o estado vive no **World** (que pode ser gerenciado pela Vercel ou apontado para um banco PostgreSQL seu).

- **Gravação antes e depois de cada passo.** Durante um turno, o agente pode chamar o LLM três vezes e invocar dez [ferramentas (tools)](/blog/ferramentas-tools-e-mcp-servers). O harness intercepta cada passo e grava um evento no log *antes* de iniciar a operação e outro *depois* que ela termina com o respectivo resultado.

- **Redelivery automático em caso de queda.** Se a função serverless sofrer timeout, o container cair por falta de memória ou a API do provedor de LLM oscilar, o sistema de filas (como o Vercel Queues) reentrega o turno para uma nova instância limpa.

- **Replay instantâneo até a fronteira da falha.** A nova instância lê o log de eventos desde o início do turno. As chamadas de modelo e de ferramentas que já tinham registro de conclusão **não são re-executadas** — seus outputs são lidos diretamente do log em milissegundos, até que o agente chegue exatamente na operação que estava em voo no momento do crash.

Na prática, você pode matar o processo do servidor no meio de uma geração de código e, quando a nova instância assume, o agente continua exatamente do passo em que parou.

### O problema difícil: o que acontece quando uma tool cai no meio?

Retomar chamadas de leitura é fácil. Mas como levantou o desenvolvedor `@mohammadvazin` no X logo após o anúncio da Vercel: *“Retomar é a metade fácil. A parte difícil é o passo que caiu no meio da chamada da ferramenta: se o agente já enviou o e-mail ou fez o push do commit, repetir o passo faz isso duas vezes.”*

É aqui que entra o detalhe de engenharia mais elogiado do `durable-harness`: **as políticas explícitas de replay por ferramenta (`safe` vs `never`)**.

Toda ferramenta entregue ao harness recebe uma classificação de idempotência que dita como o motor de recuperação age quando encontra uma chamada iniciada, mas sem registro de conclusão no log:

 Política de Replay
 Quando usar
 Comportamento após crash no meio da execução

 safe (Idempotente)
 Leituras de arquivo ( read ), buscas ( grep ), consultas HTTP GET , inspeção de estado
 O harness re-executa automaticamente a ferramenta na nova instância e segue o turno normalmente

 never (Com efeito colateral)
 Pagamentos, envio de e-mail, git push , deleção de recursos, mutações em APIs externas
 O harness não re-executa a ferramenta; ele devolve ao LLM o status de “possivelmente executada” ( possibly run )

Repare na inteligência da política `never`: em vez de tomar uma decisão cega (abortar tudo ou duplicar um reembolso no Stripe), o harness devolve o controle cognitivo ao modelo com a informação exata do que houve. O LLM então usa uma ferramenta de leitura (`safe`) para checar se o commit já está no remoto ou se o e-mail já consta como enviado antes de decidir o próximo passo.

### Harnesses embutíveis vs. isolados: por que Pi e fx levam vantagem?

No anúncio oficial no X, Guillermo Rauch (`@rauchg`), CEO da Vercel, destacou um ponto arquitetural que passou despercebido por muita gente: embora o `durable-harness` torne até o Claude Code e o Codex duráveis e observáveis, **nem todo harness nasceu para ser embutido**.

Hoje existem duas categorias claras de integração dentro do `durable-harness`:

 Característica
 Harnesses Embutíveis (Pi, Pi Durable, OpenCode, fx, eve)
 Harnesses Isolados em Sandbox (Claude Code, Codex)

 Arquitetura original
 Biblioteca TypeScript/Go modular, projetada para rodar em memória
 CLI standalone acoplada ao sistema operacional local

 Integração com durable-harness
 Nativa no mesmo processo/função ( durable-harness/pi e pi-durable )
 Experimental, exigindo um ambiente isolado (Vercel Sandbox)

 Overhead de recursos
 Baixíssimo (inicialização instantânea, sem container pesado)
 Mais alto (precisa provisionar e manter o sandbox anexado)

 Portabilidade
 Roda em serverless, edge, browser (IndexedDB), mobile ou Postgres local
 Depende de infraestrutura de sandboxing compatível

Isso explica por que o **Pi** (`badlogic/pi-mono` / `earendil-works/pi`, que já ultrapassou 117 mil estrelas somadas nos snapshots do ecossistema) se tornou a estrela do post da Vercel.

Quando analisamos a diferença entre [IDE vs CLI](/blog/ide-vs-cli-dois-modelos-de-agente) e o [guia definitivo do Pi](/blog/pi), vimos que a filosofia minimalista de Mario Zechner — entregar apenas 4 ferramentas base (`read`, `write`, `edit`, `bash`) e um prompt enxuto — parecia espartana demais para quem vinha do Claude Code. Mas na hora de transformar o agente em uma biblioteca durável rodando na nuvem, **menos bagagem acoplada significa portabilidade total**.

Além disso, na transição do Pi original para o Pi 2.0 com Pi Durable e *Codemode* (onde o LLM escreve pequenos programas JavaScript para executar ferramentas em paralelo), a Earendil tomou uma decisão cirúrgica comentada no Hacker News: substituiu árvores complexas de ramificação livre por **forks de conversação com informação de ancestralidade**. Isso permite que um único processo durável hospede múltiplas conversas isoladas, crie sub-rotinas por *fork* e recupere qualquer fio de execução sem corromper o estado.

### Como fica o código na prática?

A beleza do design da Vercel é que você não precisa reescrever o loop do seu agente do zero. Expondo um handler de rota (como `chatRoute`) no Next.js ou invocando o adaptador do Pi Durable sobre um **World** do Workflow SDK, o código se resume a declarar o harness e as políticas das ferramentas:

```
import { createDurablePi } from "durable-harness/pi-durable";
import { postgresWorld } from "@vercel/workflow/postgres";
import { z } from "zod";

// 1. Define o backend de persistência (Vercel, disco local ou Postgres próprio)
const world = postgresWorld({
 connectionString: process.env.DATABASE_URL!,
});

// 2. Inicializa o harness durável com políticas de replay por ferramenta
export const agentHarness = createDurablePi({
 world,
 model: "anthropic/claude-sonnet-5-5",
 tools: {
 checkDeploymentStatus: {
 description: "Consulta o status atual do deploy na Vercel",
 parameters: z.object({ deploymentId: z.string() }),
 replayPolicy: "safe", // Pode rodar novamente sem risco após um crash
 execute: async ({ deploymentId }) => {
 return await fetchStatus(deploymentId);
 },
 },
 triggerProductionRollback: {
 description: "Executa rollback imediato em produção",
 parameters: z.object({ deploymentId: z.string() }),
 replayPolicy: "never", // Efeito colateral crítico: nunca repetir às cegas
 execute: async ({ deploymentId }) => {
 return await performRollback(deploymentId);
 },
 },
 },
});
```

Se a função cair exatamente enquanto `triggerProductionRollback` está aguardando resposta da rede, a próxima instância não vai disparar dois rollbacks seguidos: ela vai avisar o modelo que a chamada foi iniciada antes da queda e pedir que ele consulte `checkDeploymentStatus` (`safe`) primeiro.

## Por que isso importa para você?

Se você constrói ou opera agentes em produção, a chegada dos harnesses duráveis resolve três dores que faziam muita gente desistir no meio do caminho — um dos motivos clássicos de [por que agentes de IA morrem no piloto](/blog/por-que-agentes-ia-morrem-no-piloto).

### 1. Você apaga milhares de linhas de “código de encanamento”

Qualquer equipe que já tentou colocar um agente para rodar tarefas de 30 minutos em background acabou construindo a mesma gambiarra: filas no Redis, tabelas de lock no banco, workers com retry manual, webhooks que quebram de madrugada e scripts para descobrir onde a sessão morreu.

No episódio do podcast **Syntax** dedicado ao Pi Durable (que passou de 90 mil visualizações no YouTube em poucos dias), o apresentador resumiu o impacto de adotar um harness durável pronto: *“Quando a biblioteca saiu, eu fiz a migração, consegui deletar cerca de 8.000 linhas de código customizado e basicamente ganhei um sistema melhor de graça.”*

### 2. O salto real dos agentes “preguiçosos” para agentes proativos (*out-of-the-loop*)

A maior parte dos agentes que usamos hoje é passiva: eles ficam parados em uma janela esperando você digitar um prompt. Como provoca o engenheiro Dan (`IndyDevDan`), **o futuro pertence aos agentes proativos** — agentes que trabalham para você em background e depois aguardam sua decisão.

Com Pi Durable e `durable-harness`, a comunidade já está colocando de pé casos de uso que eram inviáveis em terminais efêmeros:

- **Agentes de plantão (on-call) e curadoria contínua:** agentes que acordam via webhook quando um alerta dispara, investigam logs por vinte minutos, preparam o PR e pausam aguardando aprovação humana no Slack sem consumir CPU enquanto esperam.

- **Sistemas de inteligência de dados contínua:** como relatou `@MicahBerkley` no X, usando um harness Pi Durable para varrer sites governamentais e monitorar projetos de infraestrutura energética nos EUA, atualizando e verificando o banco de dados de forma autônoma por semanas.

- **Agentes pessoais multi-dispositivo:** desenvolvedores rodando o mesmo harness persistente (como o projeto comunitário *Pi Pocket* ou o agente pessoal *Pip* demonstrado por André Prado) acessível simultaneamente pelo Mac e pelo celular, inclusive rodando modelos locais via `llama.cpp` ou até inteiramente no browser com IndexedDB.

### 3. Human-in-the-loop sem queimar computação

Em um runtime tradicional, se o agente precisa pedir aprovação humana para rodar uma migração de banco de dados, o processo precisa ficar vivo esperando — ou você precisa serializar tudo manualmente.

Em um Durable Harness sobre o Vercel Workflow SDK, pausar para aprovação humana significa apenas gravar o checkpoint no **World** e encerrar a função serverless. O custo de computação cai a **zero** enquanto você dorme. Se você aprovar o passo três dias depois pelo celular, uma nova função sobe, hidrata o estado a partir do log e conclui o turno em segundos.

## Onde está o gargalo agora: limites e cuidados

Como toda tecnologia que acabou de sair do forno (o `durable-harness` está na versão `0.0.1-beta.6` e as APIs do Pi Durable seguem evoluindo rápido), vale separar o entusiasmo da realidade de produção:

- **A pergunta da reimplantação (redeploy):** como apontou `@TSC` na discussão técnica do lançamento, recuperar uma função que caiu usando o mesmo código é problema resolvido; o próximo desafio de todo harness hospedado é garantir determinismo quando você faz um *redeploy* da aplicação e muda o código do agente enquanto uma sessão de três semanas ainda está em andamento (o clássico problema de versionamento do Temporal.io).

- **Idempotência continua sendo responsabilidade sua:** o `durable-harness` oferece as primitivas `safe` e `never`, mas se você marcar acidentalmente uma ferramenta de cobrança ou de escrita como `safe`, o replay automático vai duplicar a ação. Projetar boas ferramentas e [servidores MCP](/blog/ferramentas-tools-e-mcp-servers) com chaves de idempotência continua obrigatório.

- **Fadiga de velocidade no ecossistema:** com Pi 1.0, Pi 2.0 + Codemode, OpenCode 2 (que também passou a rodar como biblioteca em servidores ou Cloudflare Durable Objects) e `durable-harness` saindo na mesma janela de semanas, a sensação de vertigem é real — como brincou o comentário mais curtido no vídeo do Syntax (`@asmc0403`, 117 likes): *“Quão atrasado você está? Eu: sim.”*

## Próximos passos

Se você quer experimentar harnesses duráveis hoje sem se perder no hype, aqui está o roteiro prático:

- **Leia o anúncio técnico original e a documentação** — o post [Making every harness durable](https://vercel.com/blog/making-every-harness-durable) no blog da Vercel e a [documentação oficial de Agent Harnesses](https://vercel.com/docs/agent-harnesses/pi) explicam em detalhes o modelo de *Worlds*, sandboxes e regras de segurança de tools.

- **Explore os repositórios open-source** — inspecione o código de [`vercel-labs/durable-harness`](https://github.com/vercel-labs/durable-harness), o SDK base [`vercel/workflow`](https://github.com/vercel/workflow) e o post de arquitetura do [Pi Durable da Earendil](https://earendil.com/posts/pi-durable/).

- **Comece pelo Pi se quiser leveza** — se você ainda não conhece o agente minimalista que virou a base preferida para esses experimentos, leia nosso [guia definitivo do Pi](/blog/pi) e compare com o [OpenCode](/blog/opencode) e o [Claude Code](/blog/claude-code).

- **Conecte as pontas da arquitetura de harnesses** — revise a base em [Harness e Loop: a arquitetura de 2 camadas](/blog/harness-e-loop-arquitetura-agentes), veja como escalar frotas em [Meta-Harness: o Next.js dos agentes](/blog/meta-harness-nextjs-agentes-ia) e entenda a otimização automática no artigo sobre o [Harness²](/blog/harness2-recursive-harnessing).

Se a sua equipe quer sair de protótipos frágeis no terminal e colocar agentes duráveis em produção — com políticas de replay, self-hosting em PostgreSQL e governança ponta a ponta —, fale comigo na [ft.ia.br](https://ft.ia.br). E para encontrar ou publicar [skills](/blog/o-que-sao-skills-e-como-especializar-agentes) prontas para especializar o loop dos seus agentes, acesse o [skilldev.pro](https://skilldev.pro).

**Um agente que morre quando a aba fecha é um assistente de luxo. Um agente que sobrevive à queda e termina o trabalho enquanto você dorme é infraestrutura.**

-->