Pi Coding Agent

O bloco Pi Coding Agent executa o harness de código Pi contra um repositório real. Você dá a ele uma tarefa e um modelo; ele cria ou atualiza um pull request, publica uma revisão de PR ou altera seus arquivos no lugar. Os modos Create PR e Update PR podem, opcionalmente, acompanhar o pull request. Create PR, Update PR e Local Dev podem reutilizar suas skills e a memória multi-turno. O Review Code, de propósito, não carrega nenhuma das duas.

Ele tem quatro modos, que definem onde ele executa e como o trabalho é entregue:

• Create PR — cria um sandbox isolado, edita o repositório e abre um pull request. Seu Babysit Mode opcional solicita revisões de bots e trabalha o feedback e as checagens confiáveis em rodadas limitadas.
• Update PR — faz checkout de uma branch existente em um sandbox isolado, edita, envia um novo commit de volta para essa branch e então cria ou atualiza o pull request dela. Seu Babysit Mode opcional dá continuidade a esse PR.
• Review Code — faz checkout de um PR existente em um sandbox, analisa com acesso somente leitura limitado ao repositório e publica uma revisão no GitHub (resumo + comentários inline opcionais).
• Local Dev — conecta-se à sua própria máquina por SSH e edita os arquivos diretamente ali.

Modos

Escolha o modo no dropdown Mode. Os campos abaixo dele mudam de acordo.

Create PR

O Create PR executa inteiramente dentro de um sandbox descartável, então nunca toca a sua máquina. Ele clona o repositório, deixa o agente trabalhar com acesso completo de leitura/shell/edição/git, envia uma branch e abre um PR para você revisar e fazer merge.

• Exige que a execução em sandbox esteja habilitada.
• Exige sua própria chave de API do provedor (BYOK) — a chave do modelo é entregue ao sandbox.
• Precisa de um GitHub token com permissão para clonar, fazer push e abrir um PR (veja Configuração inicial).
• A entrega é um pull request — nada é commitado diretamente na sua branch padrão.

Babysit Mode

Quando habilitado, os dois modos garantem que a branch tenha um PR pronto para revisão antes de publicar cada Reviewer Mention exigida como um comentário de issue próprio e iniciar um segundo sandbox, mais estrito, contra esse PR. O Update PR usa exatamente o PR aberto do mesmo repositório cujo head é a branch de destino, ou o cria quando não existe. Eles repetem este ciclo de vida limitado e controlado pelo host:

1. Ler todas as threads de revisão e o rollup completo de checagens do SHA fixado.
2. Dar ao Pi instruções confiáveis do block, além de dados de thread/checagem não confiáveis e claramente delimitados, e diagnósticos limitados.
3. Deixar o Pi editar o checkout e escrever um arquivo estrito de decisão por thread.
4. Recusar refs desanexados/divergentes, múltiplos commits, violações de limites cumulativos ou mudanças em .github/; depois enviar um único commit não forçado exatamente para o head ref fixado.
5. Publicar primeiro as respostas bem-sucedidas, revalidar o PR e resolver somente as threads cuja resposta funcionou.
6. Publicar novamente cada comentário de revisor configurado e então aguardar atividade posterior de revisão dos bots e as checagens que aquele commit disparou novamente. O Babysit nunca reexecuta o CI por conta própria — é o push que inicia uma nova execução.

O polling de checagens/revisões em modo de espera não consome Maximum Rounds. O sandbox permanece ativo — e é cobrado — durante essas esperas.

Apenas threads completas são acionáveis. Todo comentário em uma thread precisa vir de um owner, member, collaborator ou bot de GitHub App; caso contrário, a thread inteira é ignorada e threadsClean continua false. Bots que operam por contas de usuário comuns são ignorados, a menos que a associação seja confiável. Falhas em checagens opcionais são incluídas quando o Pi executa uma rodada de correção, mas não bloqueiam checksGreen; falhas obrigatórias, contextos obrigatórios pendentes/esperados, contextos ausentes após o push, leituras incompletas e estados desconhecidos falham de forma conservadora.

A continuação não dá ao Pi nenhuma credencial do GitHub, nenhuma ferramenta do GitHub nem integração do Studio. As operações da API do GitHub usam as coordenadas configuradas no block, no host, e não são filtradas pelas denylists de ferramentas do workspace. O modelo e as chaves opcionais de busca entram, sim, no sandbox de edição. O GitHub token entra apenas nos comandos de clone e de push com credencial. Isso é redução de risco, não isolamento de credenciais: o push ainda é executado dentro de um sandbox root que estava sob controle do agente.

• Exige pelo menos uma Reviewer Mention, como @greptile ou @cursor review.
• Precisa de acesso de leitura a Contents, Pull requests, Issues, Actions e commit status/checks, conforme descrito em Configuração do Create PR e Configuração do Update PR.
• Não dá suporte a PRs de fork, force-push/reescrita de histórico, resolução de conflitos de merge nem edições em .github/. Um conflito na base é relatado, mas não impede pushes de correção de revisão.
• Uma rodada que publica respostas mas perde o pin antes de resolver pode responder novamente à mesma thread não resolvida em uma execução posterior. Responder é intencionalmente mais seguro do que resolver feedback desatualizado.

Update PR

O Update PR usa o mesmo sandbox descartável de autoria e as mesmas operações de PR controladas pelo host que o Create PR, mas faz checkout de uma branch que já existe e envia as alterações de volta para ela.

• Exige execução em sandbox e sua própria chave de API do provedor (BYOK).
• Precisa das mesmas permissões de GitHub token que o Create PR: permissão para clonar, fazer push e criar ou atualizar um pull request.
• Nunca cria, faz rebase, merge ou force-push na branch. Se outro commit chegar à branch enquanto o Pi trabalha, o push falha em vez de sobrescrevê-lo.
• Encontra exatamente o PR aberto do mesmo repositório cujo head é a branch de destino e verifica de novo após a autoria. Uma correspondência é atualizada; nenhuma correspondência aberta — inclusive quando um PR anterior ou de preflight foi fechado — resulta em um novo PR; várias correspondências abertas falham por ambiguidade.
• Quando definidos explicitamente, Base Branch, PR Title, PR Body e PR State atualizam o PR existente. Metadados em branco preservam o que já existe. Um PR recém-criado usa metadados gerados e a base padrão do repositório quando esses campos estão em branco.
• Uma passagem de autoria sem alterações ainda cria ou atualiza o PR. Um push inicial rejeitado interrompe a execução antes de qualquer mutação de PR ou continuação do Babysit.
• A entrega é a branch atualizada e o PR dela — leia prUrl, branch, changedFiles e diff.

Review Code

O Review Code usa um sandbox descartável para o repositório, mas o harness Pi e a credencial do modelo permanecem no Studio. Ele fixa os commits de base e de head do PR, dá ao agente apenas ferramentas limitadas de leitura/busca e valida as coordenadas inline contra exatamente aquele diff local. O Studio então envia uma única revisão no GitHub, com um corpo de resumo e comentários inline opcionais por linha.

• Exige execução em sandbox. A chave do provedor permanece no Studio, então chaves hospedadas e BYOK são ambas suportadas.
• Precisa de um GitHub token que consiga clonar o repositório e enviar revisões (veja Configuração inicial).
• Precisa do Pull Request Number a ser revisado.
• Não carrega skills nem memória, e nunca expõe ferramentas de shell, escrita ou edição ao revisor. Seu único acesso de rede é o Internet Search, e apenas quando você seleciona um provedor.
• Verifica o PR novamente imediatamente antes do envio e fixa a revisão exatamente no commit de head que foi feito checkout.
• A entrega é uma revisão enviada — leia reviewUrl e commentsPosted.

Local Dev

O Local Dev executa o agente contra um repositório em uma máquina que você controla, acessada por SSH. As alterações são escritas no lugar — não há PR; você as revisa como alterações git normais naquela máquina.

• A máquina precisa ser acessível em um hostname público — localhost e endereços de LAN/privados são bloqueados. Exponha-a com um túnel (veja Configuração inicial).
• As ferramentas de arquivo e shell do agente ficam confinadas ao Repository Path que você configurar.
• Você também pode expor ferramentas do Studio (Gmail, Slack, Exa, …) ao agente, para que ele atue além do repositório enquanto trabalha.

Configuração

Task

O que o agente deve fazer, em linguagem simples — por exemplo "Adicione validação de entrada ao formulário de cadastro e um teste para isso." ou "Revise este PR em busca de problemas de segurança e correção." Insira uma connection tag para passar uma saída anterior, como <start.input>.

Model

O modelo que conduz o agente. O padrão é claude-sonnet-4-6. O dropdown contém a interseção entre os modelos disponíveis no Studio e as entradas exatas, relativas ao provedor, do catálogo Pi instalado. O Studio nunca inventa metadados de modelo como fallback.

API Key

Sua chave para o provedor escolhido. No Studio hospedado ela é opcional para execuções de Local Dev e Review Code (uma chave hospedada é usada e medida contra o seu workspace). Create PR e Update PR exigem sua própria chave, porque o cliente de modelo deles executa dentro do sandbox, inclusive durante uma continuação do Babysit. Quando o provedor suporta BYOK de workspace, você pode guardar a chave em Settings → BYOK em vez de informá-la no block.

Internet Search

Desligado por padrão. Escolha um provedor — Exa, Serper, Parallel AI ou Firecrawl — e o agente ganha uma única ferramenta web_search, que retorna um punhado de resultados, cada um com título, URL, trecho e (quando o provedor informa) data de publicação. Funciona igual nos quatro modos, e é o único acesso de rede do agente no Review Code. A ferramenta aceita no máximo 20 chamadas por execução do block, o que limita loops acidentais de ferramenta. Um block Pi dentro de um Loop ou Parallel recebe essa cota de novo em cada iteração, então limite também a contagem de iterações se você se preocupa com o quanto uma única execução de workflow pode gastar.

A busca sempre usa sua própria chave do provedor selecionado, informada no campo Search API Key do block. Esse campo é a única fonte: não há fallback de BYOK de workspace e o Studio nunca fornece uma chave de busca hospedada, então, diferente da chave do modelo, esse campo aparece em toda implantação. Deixe-o vazio e a execução falha com um erro de configuração antes de qualquer sandbox ser criado. Trocar o provedor no editor limpa o campo, então informe novamente a chave que pertence ao provedor escolhido — um workflow que você importa, faz fork ou atualiza pela API mantém qualquer chave que estava salva, então confira lá.

Resultados são dados de terceiros. O agente é instruído a tratá-los como evidência citada e a nunca seguir instruções encontradas neles — a mesma postura que o Pi adota em relação ao conteúdo do repositório.

O tráfego vai nas duas direções: o agente escreve as próprias consultas depois de ler o repositório, então deixe a busca em None no Review Code quando o pull request vem de um fork não confiável de um repositório privado. Instruções injetadas em um diff poderiam, de outro modo, colocar texto do repositório em uma consulta enviada ao provedor.

Repository (Create PR / Update PR / Review Code)

• Repository Owner / Repository Name — o repositório no GitHub (por exemplo your-org / your-repo).
• GitHub Token — um personal access token usado para acessar o GitHub. As permissões variam por modo; veja Configuração do Create PR, Configuração do Update PR ou Configuração do Review Code.

Campos do Create PR

• Base Branch — a branch contra a qual o PR é aberto e da qual o clone é feito. O padrão é a branch padrão do repositório.
• Babysit Mode — cria um PR pronto para revisão, solicita revisões de bots e monitora feedback confiável e checagens obrigatórias.
• Reviewer Mentions — obrigatório quando o Babysit Mode está habilitado. Uma lista limitada, separada por vírgulas, de comandos de comentário de issue; cada entrada é publicada imediatamente e após cada correção enviada.
• Maximum Rounds (avançado) — rodadas de correção que invocam o Pi, de 1 a 10; o padrão é 3. O polling em modo de espera não consome essa contagem.
• Branch Name (avançado) — a branch a enviar. Gerada automaticamente quando em branco.
• Open as Draft PR (avançado) — abre o PR como rascunho. Ligado por padrão e oculto quando o Babysit Mode está habilitado, porque esses PRs estão sempre prontos para revisão.
• PR Title / PR Body (avançado) — gerados a partir da execução quando em branco.

Campos do Update PR

• Target Branch — a branch remota existente a atualizar. A execução falha se ela não existir, estiver protegida contra o token ou mudar antes do push do Pi.
• Base Branch — muda a base de um PR existente quando definida, ou se torna a base de um novo PR. Um novo PR usa por padrão a branch padrão do repositório quando o campo está em branco.
• Babysit Mode / Reviewer Mentions / Maximum Rounds — os mesmos controles do Create PR. O Babysit deixa o PR pronto para revisão e o cria primeiro quando a branch de destino não tem PR aberto.
• PR State (avançado) — preserva o estado de rascunho de um PR existente, converte-o em rascunho ou marca-o como pronto para revisão. Um PR inexistente é aberto como rascunho para Leave unchanged ou Draft, e como pronto para Ready for review. Oculto durante o Babysit, porque o Babysit sempre exige um PR pronto.
• PR Title / PR Body (avançado) — atualizam um PR existente apenas quando definidos. Para um PR inexistente, valores em branco são gerados a partir da tarefa e do resumo da execução.

Campos do Review Code

• Pull Request Number — o PR a revisar (por exemplo 42).
• Review Outcome — a ação de revisão do GitHub a enviar: Comment (padrão) ou Request changes. O Review Code, de propósito, não envia aprovações.

Connection (Local Dev)

• Host — o hostname público ou o túnel da máquina de destino (por exemplo 2.tcp.ngrok.io). Não localhost nem um endereço de LAN.
• Username — o usuário SSH (por exemplo ubuntu, root ou a sua conta do macOS).
• Authentication Method — Password ou Private Key.
• Password / Private Key — a credencial daquele método. Use uma chave quando possível.
• Repository Path — o caminho absoluto do repositório na máquina de destino (por exemplo /home/user/my-repo). As ferramentas do agente ficam confinadas a esse diretório.
• Port (avançado) — a porta SSH. O padrão é 22; ajuste para a porta do seu túnel, se for diferente.
• Passphrase (avançado) — para uma chave privada criptografada.

Tools (Local Dev)

Ferramentas do Studio que o agente pode chamar enquanto trabalha — buscar em uma base de conhecimento, enviar uma mensagem no Slack, chamar qualquer uma das integrações. Elas rodam pelo Studio com as credenciais que você conectou, exatamente como no bloco Agent. MCP e ferramentas customizadas ainda não são suportados aqui (aparecem esmaecidos).

Skills (Create PR / Update PR / Local Dev)

Agent skills que o agente pode usar — pacotes reutilizáveis de instruções, como um padrão de código ou um playbook de revisão. São compartilhados com o bloco Agent. Create PR e Update PR passam para a continuação do Babysit as skills do Studio selecionadas explicitamente, enquanto skills do repositório, extensões do Pi, templates de prompt e confiança de projeto permanecem desabilitados ali.

Thinking Level

Para modelos com raciocínio estendido, quanto o modelo pensa antes de agir. Mais alto é mais minucioso, mas mais lento e custa mais tokens. O padrão é medium.

Memory (Create PR / Update PR / Local Dev)

Memória multi-turno indexada por um ID de conversa, compartilhada com o bloco Agent:

• None. Cada execução é independente.
• Conversation. O histórico completo daquele ID de conversa.
• Sliding window (messages). As N mensagens mais recentes.
• Sliding window (tokens). Mensagens recentes até um orçamento de tokens.

Reutilize o mesmo Conversation ID entre execuções para continuar uma conversa. Cada turno guarda sua tarefa e o resumo inicial de autoria ou de Local Dev, que é incorporado ao prompt da execução seguinte. O Review Code nunca carrega nem salva memória. Uma continuação do Babysit começa com memória vazia, e o relatório derivado da revisão não é salvo na memória.

Limites de contexto

Para Create PR, Update PR e Local Dev, a memória é incorporada ao primeiro prompt do agente, e duas camadas a mantêm dentro da janela de contexto do modelo:

• O Studio corta antes da execução. O tipo de memória selecionado limita o que é injetado: Conversation é automaticamente limitado a uma fração da janela de contexto do modelo (para modelos do catálogo do Studio), Sliding window (messages) mantém as últimas N mensagens e Sliding window (tokens) mantém o histórico até um orçamento explícito de tokens.
• O Pi compacta durante a execução. Conforme o agente trabalha (lendo arquivos, executando comandos), o Pi resume automaticamente os turnos mais antigos para ficar dentro da janela — em todos os modos, ligado por padrão. Você não precisa configurar nada para o crescimento de contexto durante a execução.

O único caso que nenhuma camada resolve é um primeiro prompt que já excede a janela — o Pi só consegue compactar quando há turnos mais antigos para resumir. Isso só é alcançável com memória Conversation mais um modelo digitado manualmente (fora do catálogo do Studio), em que o limite automático não consegue consultar uma janela de contexto. Para históricos longos — e sempre que você usar um modelo informado manualmente — escolha Sliding window (tokens): o orçamento dela se aplica independentemente do modelo, então o primeiro prompt sempre cabe.

Saídas

Configuração inicial

Create PR

O Create PR executa em uma imagem de sandbox com o Pi CLI, Git, Node.js e Bun já embutidos. As dependências do repositório não vêm pré-instaladas; o Pi pode rodar bun install quando um repositório precisar delas.

1. Habilite a execução em sandbox. No Studio auto-hospedado, defina E2B_ENABLED=true, E2B_API_KEY, E2B_PI_TEMPLATE_ID (o id do template do Pi) e NEXT_PUBLIC_E2B_ENABLED=true (isso revela Create PR, Update PR e Review Code na interface). Construa o template com bun run apps/core-api/scripts/build-pi-e2b-template.ts. Esses modos ficam ocultos até NEXT_PUBLIC_E2B_ENABLED ser definido.

   O template solicita 4 vCPU e 8 GB de RAM (dentro do máximo por build de todos os planos do E2B). O dimensionamento é fixado na construção do template — o E2B não tem override por sandbox — então mudá-lo significa reconstruir o template, não reiniciar o Studio. Sandboxes são cobrados por segundo com base nos recursos alocados, não nos que são usados. Os dois números ficam em apps/core-api/scripts/pi-sandbox-packages.ts e são compartilhados com o snapshot do Daytona, para que a imagem de failover não possa divergir da primária.

   O Studio dimensiona cada sandbox do Pi para o tempo restante da própria execução, então uma execução nunca mantém um sandbox por mais tempo do que a plataforma permitiria que ela rodasse. O E2B também impõe um teto de 24 horas de sandbox contínuo no plano Professional, então um sandbox do Pi fica limitado a isso, mesmo quando uma política de workflow Enterprise for mais longa. PI_SANDBOX_LIFETIME_MS pode reduzir esse teto, mas tem um mínimo de 31 minutos; valores menores são elevados ao mínimo. Uma execução que sobrevive ao sandbox perde o trabalho antes do push, e um sandbox órfão — aquele cujo processo do Studio morreu no meio da execução — é cobrado até o tempo de vida expirar, e é por isso que esse tempo de vida acompanha o prazo. O Babysit Mode usa um segundo sandbox sequencial depois que o sandbox de criação foi destruído; ele é cobrado enquanto faz polling de checagens e revisões. O Daytona segue inalterado porque a configuração de auto-stop dele é baseada em inatividade, e não em um tempo de vida absoluto.

2. Traga sua própria chave de modelo. Defina a chave de API do provedor no campo API Key do block, ou guarde-a em Settings → BYOK quando o provedor suportar BYOK de workspace.

3. Crie um GitHub token com permissão para clonar, fazer push e abrir um PR:

   • Fine-grained: selecione o repositório e marque Contents: Read and write + Pull requests: Read and write.
   • Classic: o escopo repo. Para repositórios de organização, autorize o token para SSO.

Quando o Babysit Mode está habilitado em qualquer um dos modos de autoria, use um agendamento assíncrono, webhook ou execução em background quando possível, porque a continuação pode passar vários minutos esperando pelo CI ou pelos bots de revisão. O token precisa, adicionalmente, ler checagens e logs do Actions, responder e resolver threads de revisão, e publicar comentários de issue:

• Fine-grained: adicione Issues: Read and write, Actions: Read e Commit statuses: Read (mais acesso de leitura a check suites, se a sua organização expõe isso separadamente).
• Classic: o escopo repo, autorizado para SSO em repositórios de organização. Um token classic ou uma instalação de GitHub App pode ser necessária onde um token fine-grained não consegue acessar todos os endpoints de checagem.

clean é a única razão de parada que significa que o PR alcançou o estado desejado: nenhuma thread não resolvida acionável ou ignorada, nenhuma checagem obrigatória falhando, pendente ou ausente, e um sinal posterior de revisão de bot após a solicitação de revisão mais recente. Todo outro valor é um sucesso parcial ou uma parada, então compare com clean em vez de supor que um relatório retornado significa que o PR está pronto.

awaiting_checks é um resultado esperado de sucesso parcial após um push: o GitHub pode não concluir o CI dentro do orçamento restante de execução. As outras razões de parada são awaiting_review, no_pr_created, closed_or_merged, fork_pr, skipped_threads, stuck_threads, stuck_checks, check_read_failed, startup_failure, head_moved, push_rejected, pushed_awaiting_confirmation, refused_content, bounds_exceeded, agent_failure e o esgotamento de orçamento/rodadas. Depois que o PR existe, esses resultados preservam prUrl e branch; sempre inspecione os booleanos e contadores explícitos, em vez de tratar um relatório retornado como prova de que o PR está limpo.

O Babysit aplica limites fixos que não são configuráveis, e eles se comportam de formas diferentes conforme qual deles você atinge:

• Rejeitado antes de a execução começar. Reviewer Mentions aceita no máximo 10 entradas, cada uma com no máximo 200 caracteres, e no máximo 2000 caracteres de entrada no total. Cada entrada precisa começar com @. Exceder qualquer um desses limites faz o block falhar com um erro de validação, em vez de um stopReason.
• Cortado em silêncio. No máximo 30 threads de revisão são mostradas ao Pi por rodada. Threads acionáveis extras são levadas para uma rodada posterior, então threadsClean continua false até que sejam tratadas.
• Interrompe a execução com bounds_exceeded. Mais de 20 checagens obrigatórias falhando em uma rodada, ou uma alteração cumulativa ao longo da execução que exceda 50 arquivos ou 200.000 bytes de diff.

Update PR

Habilite a execução em sandbox e o BYOK como no Create PR. O Update PR também usa as mesmas permissões do GitHub, porque sempre cria ou atualiza um pull request depois da autoria:

• Fine-grained: selecione o repositório e conceda Contents: Read and write + Pull requests: Read and write.
• Classic: o escopo repo. Para repositórios de organização, autorize o token para SSO.

A branch de destino já precisa existir. A proteção de branch do GitHub continua sendo a autoridade, e uma branch que avança durante a execução rejeita o push normal, não forçado, do Pi.

O Update PR aceita exatamente um PR aberto do mesmo repositório para a branch de destino, cria um quando nenhum existe e falha se a correspondência é ambígua. Ele não dá suporte a PRs de fork. Com o Babysit Mode, o token também precisa das permissões de Issues, Actions, commit status e checagens listadas acima.

Review Code

Habilite a execução em sandbox como no Create PR. O BYOK é opcional, porque a credencial do modelo permanece no Studio. O GitHub token precisa de acesso suficiente para clonar o repositório e enviar uma revisão — permissão de push não é necessária:

• Fine-grained: selecione o repositório e marque Contents: Read + Pull requests: Read and write.
• Classic: o escopo repo (ou um token mais restrito que consiga ler contents e escrever revisões de pull request). Para repositórios de organização, autorize o token para SSO.

Local Dev

1. Habilite o SSH na máquina de destino (no macOS: System Settings → General → Sharing → Remote Login).
2. Exponha-a em um host público. O Studio bloqueia localhost/LAN, então use um túnel TCP — por exemplo ngrok tcp 22, que fornece um host:port para colocar em Host e Port.
3. Use um modelo que seu provedor suporte (por exemplo, um modelo Claude com uma chave da Anthropic). Defina o método de credencial e o Repository Path, e então execute.

Boas práticas

• Delimite a tarefa. Uma instrução específica ("corrija o teste auth que está falhando e adicione um caso de regressão") produz resultados muito melhores do que uma vaga.
• Combine o modo com a entrega. Create PR para uma nova branch revisável, Update PR para continuar trabalho remoto existente e gerenciar o PR dele, Review Code para dar feedback em um PR, e Local Dev para um repositório que você já tem em checkout.
• Use o Babysit Mode para acompanhamento automatizado de revisões. Execute-o de forma assíncrona e espere sucesso parcial; uma correção enviada seguida de awaiting_checks é normal.
• Prefira autenticação por chave e derrube os túneis. Um túnel SSH público é uma superfície de ataque real — use uma chave privada e encerre o túnel quando terminar.
• Reutilize um Conversation ID para continuações de Create PR, Update PR ou Local Dev. Ele leva a tarefa e o resultado anteriores para a execução seguinte, para que o agente construa sobre o próprio trabalho.