Pizza Bot: Como Funciona um Inbox para Agentes de IA em Background

Se você já teve um agente rodando e fechou o navegador sem querer, sabe o problema. O Pizza Bot resolve isso reorganizando o modelo mental: em vez de chat, um inbox.

O que foi lançado e por quem

A AWS apresentou o Pizza Bot, um inbox open source para agentes de IA que continuam trabalhando em background depois que o chat termina, construído com DeepAgents e LangGraph, projetado para mostrar o progresso das tarefas e os pontos em que uma pessoa precisa responder. O repositório está em github.com/pizza-bot-app/pizza-bot sob licença Apache 2.0. O projeto é um esforço comunitário e não um serviço da AWS, então os usuários são responsáveis por hospedar, backups, atualizações e suporte.

A ideia central é simples de descrever e não trivial de implementar: você dispara uma tarefa, fecha a tela, e volta depois. Trabalho concluído cai em Unread e execuções que esperam sua decisão caem em Action. Os agentes continuam trabalhando quando você navega para outro lugar ou desconecta; o processo api-server precisa continuar rodando.

Como funciona por baixo do capô

Antes de olhar o Pizza Bot em si, precisamos dos dois blocos que ele empilha: LangGraph e DeepAgents. São peças independentes, com responsabilidades diferentes.

LangGraph: o runtime que salva o estado a cada passo

LangGraph modela a execução do agente como um grafo de nós, onde cada nó é uma função (chamar o modelo, chamar uma ferramenta, decidir o próximo passo) e o estado global é uma estrutura compartilhada que atravessa esses nós. Esse estado global é uma memória compartilhada que persiste durante toda a execução do workflow, mantendo progresso, resultados intermediários, parâmetros de configuração e dados contextuais acessíveis a todos os nós.

A parte que importa aqui é o checkpoint. A cada transição entre nós, o LangGraph serializa o estado e grava em disco. Isso permite três coisas que um loop em memória não permite: pausar para pedir aprovação humana, sobreviver à queda do cliente, e retomar do ponto exato onde parou.

Uma analogia rápida. Pense num jogo com save automático depois de cada sala. Se o console reinicia, você não volta ao menu inicial, volta pra última sala. Onde a analogia quebra: no jogo o save é opcional, aqui o checkpoint é a mecânica que define o que é um passo. Sem checkpoint, não há estado durante para reaproveitar.

DeepAgents: a camada opinativa em cima do LangGraph

DeepAgents é um harness, um conjunto de padrões prontos, que monta um grafo LangGraph já com ferramentas embutidas para planejamento, sub-agentes e um filesystem virtual. LangGraph é o runtime do grafo. O create_agent do LangChain é um harness mínimo em cima dele. Deep Agents é um harness mais opinativo em cima do create_agent, mesmos blocos, mas com filesystem, sub-agentes, gerenciamento de contexto e skills embutidos.

Dois padrões de DeepAgents fazem diferença no Pizza Bot:

• Planejamento como ferramenta. Ao forçar o modelo a chamar uma ferramenta de todo, DeepAgents mantém uma lista de tarefas explícita e visível. Esse simples plano no-op melhora dramaticamente a coerência de longo prazo. Na prática, o agente escreve a própria lista, marca itens como feitos, e isso vira estado inspecionável.
• Sub-agentes com contexto isolado. Delegar subtarefas complexas a agentes especializados. Isso põe o contexto em quarentena: o agente principal só vê os resultados finais, não cada busca ou passo intermediário. No Pizza Bot isso aparece como skills.

Como o Pizza Bot conecta isso a um inbox

O runtime fica isolado num pacote próprio. A aplicação usa DeepAgents e LangGraph para execução stateful. Um servidor de API Hono é dono da execução do runtime e do armazenamento. Clientes Electron e browser compartilham a mesma interface React, enquanto todos os clientes se comunicam com o servidor via HTTP e server-sent events. Checkpoints do LangGraph retêm o estado da thread e as pausas de aprovação; stores SQLite separados guardam memória cross-thread e metadados da aplicação.

O fluxo de uma tarefa, passo a passo:

1. Você dispara a tarefa. O gatilho pode ser manual, mas também pode vir de cron ou webhook. O servidor é dono do agendamento. Depois de um downtime, intervalos de cron perdidos produzem um único catch-up run em vez de reproduzir cada intervalo perdido. Ocorrências de trigger são gravadas durablemente.
2. O api-server abre uma thread, cria o grafo DeepAgents e começa a executar. Cada passo do grafo grava checkpoint em SQLite.
3. Quando o agente chama uma ferramenta marcada como sensível, o grafo interrompe. Deep Agents integra com interrupts do LangGraph para pausar em aprovações de chamadas de ferramentas sensíveis. Ativa esse comportamento com o parâmetro interrupt_on em create_deep_agent. interrupt_on aceita um mapeamento de nomes de ferramentas para configurações de interrupt. Por exemplo, interrupt_on={“edit_file”: True} pausa antes de cada edição, permitindo aprovar a chamada, adicionar orientação ou modificar os inputs antes da execução.
4. Essa thread pausada aparece na fila Action. Enquanto isso, outras threads que terminaram sozinhas caem em Unread.
5. Você responde à aprovação ou lê o resultado. O grafo retoma do checkpoint, não do início.

O ponto técnico que sustenta tudo: o cliente não segura estado. O Pizza Bot separa o runtime do agente dos clientes usados para inspecioná-lo. O servidor de API é dono das execuções ativas, estado e persistência. Clientes Electron, browser e terminal se comunicam com esse servidor via HTTP/SSE. Fechar a janela não mata a execução. Só mata a execução se você derrubar o api-server.

O que isso significa na prática

O primeiro caso óbvio é delegar tarefa longa. Um agente que precisa fazer pesquisa em várias fontes, cruzar com dados internos, e chegar num relatório pode levar minutos ou horas. No chat tradicional, você fica olhando cursor piscar. No Pizza Bot, você dispara e vai fazer outra coisa.

O segundo caso é o que muda a arquitetura: aprovação durável. Um agente que faz commit, envia email, ou executa comando no shell pode ser configurado para parar antes da ação. A thread fica em Action com o input proposto. Você aprova, edita ou nega. Essa é uma diferença real em relação a chat, onde “quer que eu faça?” é uma pergunta que você precisa estar olhando pra responder.

No StartAtende, meu agente de suporte no WhatsApp, esse padrão já aparece em versão mais simples: certas ações ficam pendentes de uma decisão humana antes de virarem efeito no sistema. A diferença de arquitetura pra algo como o Pizza Bot é que lá a pausa é um estado de negócio no banco, aqui é um checkpoint do runtime do agente. São camadas diferentes de estado com objetivos parecidos.

Um exemplo mínimo do formato de uma skill, direto da documentação:

---
name: release-check
description: Check release readiness and report blockers.
tools:
 - mcp:release-tools:check_release
---
1. Run the release check.
2. Report blockers.

Pizza Bot é o agente de conversa; cada skill habilitada e pronta vira um worker com escopo de ferramentas que o Pizza Bot pode invocar através do task tool. O nome e a descrição da skill guiam o roteamento, o corpo do SKILL.md fornece as instruções do worker, e suas ferramentas declaradas definem a superfície completa de ferramentas. Skills de usuário ficam em PIZZA_DATA_ROOT/skills/id/SKILL.md. Traduzindo: skill é markdown com frontmatter. O agente principal vê a skill como uma ferramenta chamável, sem enxergar o que acontece dentro dela.

Onde quebra

Alguns limites que ficam claros lendo a documentação com atenção.

Se o api-server cai, tudo pausa. Se o servidor sobe pelo desktop e é parado, o processo atual e as execuções ativas param junto; o estado com checkpoint permite retomar do workflow persistido em vez de perder a thread inteira. Para trabalho agendado confiável, o backend precisa continuar disponível. Retomar não é o mesmo que continuar. Se a execução dependia de uma janela de tempo, ela já passou.

Um data root, um backend por vez. Cada diretório de dados SQLite suporta um processo de backend, um detalhe que importa ao configurar o armazenamento e o runtime da aplicação. Se você quiser rodar duas instâncias, precisa de dois PIZZA_DATA_ROOT.

Plugins e MCP rodam com sua permissão de usuário. Isso significa que uma skill mal escrita, ou um servidor MCP não confiável, tem o mesmo alcance no sistema que você. O README é explícito em avisar isso e limitar acesso a arquivos por default a pastas explicitamente concedidas, mas o custo de segurança fica com quem instala.

DeepAgents é opinativo. Se seu caso não encaixa em planejar-delegar-atualizar, você paga o custo cognitivo do harness sem colher o benefício. Escolha Deep Agents quando quiser construir um agente autônomo para lidar com tarefas complexas, não determinísticas e de longa duração. Escolha LangGraph quando quiser controle de baixo nível para construir workflows e agentes stateful e de longa duração.

Nos livros que escrevi, entre eles a série IA na Prática, um padrão repete: harness resolve 80% dos casos com uma escolha de arquitetura embutida, e cobrar caro nos 20% em que a escolha não serve. DeepAgents não foge disso.

O que não dá para afirmar ainda

O Pizza Bot foi anunciado em setembro de 2026 e a versão pública é recente. Algumas perguntas não ficam respondidas só lendo o README e os posts de anúncio.

• Escala real de threads simultâneas. Não vi número publicado de quantas execuções concorrentes o api-server aguenta antes de o SQLite virar gargalo de escrita.
• Custo por thread longa. Como o estado inteiro é reserializado a cada checkpoint, threads com muitos passos e muito contexto podem inflar o banco. A documentação não publica um perfil de crescimento.
• Comportamento em modelos locais. A lista suporta Ollama, mas o DeepAgents depende de tool calling confiável. Em modelos menores rodando local, isso é onde as coisas costumam falhar em silêncio. Não testei.

Como testar isso você mesmo

Um caminho pequeno para experimentar, na ordem em que a documentação recomenda:

1. Instale Node.js 24 ou superior.
2. Clone o repositório e rode npm install, npm run build, npm run dev. O comando de dev sobe o frontend Vite e o Electron, que por sua vez sobe o api-server local.
3. Em Settings > Providers, configure um provider. Se você já tem chave da Anthropic ou OpenAI, é o caminho mais curto. Se quer testar 100% local, configure Ollama com um modelo que suporte tool calling bem.
4. Dispare uma tarefa que força planejamento, tipo “faça um resumo comparando três artigos sobre X e me pergunte antes de salvar arquivo”. Fecha a janela e reabre em outro momento. Observa se a thread aparece em Action.
5. Escreve uma skill mínima em PIZZA_DATA_ROOT/skills/minha-skill/SKILL.md com o formato do exemplo acima e observa ela aparecer como worker delegável.

Isso é o suficiente para ver o ciclo checkpoint, interrupt e resume acontecendo. Depois disso, a decisão de usar em produção passa por questões que só seu caso responde: segurança de MCP, tolerância a servidor caindo, custo de rodar um backend sempre ligado.