No Ivy Tendril, uma issue do GitHub transforma-se em pull request através de uma sequência rigorosa de etapas: a issue chega à Inbox por webhook, um agente redige um rascunho de plano, um desenvolvedor revisa e aprova o plano, um agente o executa em um git worktree isolado, a validação automática é executada, o desenvolvedor avalia o diff e um agente abre o pull request. A intervenção humana ocorre em exatamente dois pontos: no plano e no diff. Todo o restante é conduzido de forma autônoma por agentes, e múltiplos tickets avançam por esse fluxo ao mesmo tempo. Este artigo acompanha um ticket em cada etapa do processo.
O ciclo de vida em resumo
A Ivy denomina esse fluxo de trabalho de «fábrica de software»: uma sequência estruturada de fases na qual os agentes realizam o trabalho e os engenheiros inspecionam as entregas em pontos de controle pré-definidos. As fases, quem atua e a condição que encerra cada etapa estão resumidas na tabela abaixo. O guia completo está na documentação do ciclo de vida.
| Fase | Quem atua | Condição de conclusão |
|---|---|---|
| Inbox | Agente (webhook) | A issue é armazenada com título, corpo, etiquetas e link |
| Draft plan | Agente (CreatePlan) | Existe um rascunho com objetivo, escopo, arquivos afetados e passos de verificação |
| Plan review, ponto de controle 1 | Humano | O desenvolvedor aprova o plano, após eventuais anotações e ajustes |
| Execute | Agente (ExecutePlan) | O agente relata a conclusão do plano dentro do seu worktree |
| Verify | Agente | Testes e lint foram executados e o diff está pronto para revisão (portões de verificação) |
| Diff review, ponto de controle 2 | Humano | O desenvolvedor aprova o diff |
| Pull request | Agente (CreatePr) | Um pull request é aberto no GitHub para a branch do plano via API REST de pull requests |
| Merge e limpeza | Humano faz merge, agente limpa | O worktree é removido e os aprendizados são consolidados na memória |
Da issue ao plano aprovado
Chegada da issue
Um usuário abre a issue #418 no repositório: "Export to CSV drops rows with commas in the description field." A integração com o GitHub encaminha o chamado para a Inbox do Tendril via webhook. Nenhum código é executado de imediato. A Inbox é uma fila de triagem onde o desenvolvedor decide quais itens serão convertidos em planos de trabalho. Relatórios de erro do jam.dev chegam exatamente da mesma forma.
CreatePlan redige o plano
O desenvolvedor seleciona a issue e clica em Create plan. O promptware CreatePlan analisa a issue, consulta sua memória contextual do repositório e o código-fonte pertinente, gerando uma minuta estruturada. Um rascunho típico especifica o objetivo, os arquivos com alteração prevista (src/export/csv.ts e o arquivo de teste correspondente), a abordagem de implementação (envolver com aspas campos com delimitador conforme o padrão RFC 4180) e as etapas de validação (adicionar teste com vírgula no campo de descrição, rodar os testes de exportação existentes). A minuta é disponibilizada em Drafts.
Ponto de controle 1: O desenvolvedor revisa o plano
Este é o primeiro dos dois pontos de controle humanos. O desenvolvedor analisa a proposta e identifica uma lacuna: o plano prevê o tratamento de aspas apenas no campo de descrição, porém a mesma falha atinge qualquer coluna de texto livre. Em vez de reescrever o plano manualmente, o desenvolvedor seleciona o parágrafo correspondente e inclui uma anotação: "Apply the quoting to all string columns, not just description." O promptware UpdatePlan regera o plano incorporando a diretriz, e a versão corrigida é reapresentada para aprovação.
Se o esboço carecer de detalhes, o desenvolvedor pode acionar o ExpandPlan. Se os apontamentos revelarem que o ticket na realidade contempla duas entregas distintas — por exemplo, a correção do bug e uma migração separada do módulo de exportação para uma biblioteca CSV compartilhada —, o SplitPlan divide a demanda em dois planos independentes. Quando o desenvolvedor estiver satisfeito, ele formaliza a aprovação. O plano passa a ser o contrato técnico estrito para a execução, sem que o agente precise reinterpretar o texto inicial da issue.
Execução e verificação
ExecutePlan roda em um worktree isolado
Após o aval humano, o Tendril inicializa um git worktree exclusivo para o plano em sua própria branch e inicializa o agente escolhido dentro dele. O desenvolvedor define o agente por plano: Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode ou outro agente de linha de comando. A metodologia de orquestração permanece rigorosamente a mesma qualquer que seja o agente.
O isolamento em worktrees é mandatório porque múltiplos planos rodam em paralelo. Cada qual conta com diretório e branch próprios; alterações em andamento de um plano nunca interferem em outro, e a branch principal fica protegida e intocada até a aprovação. Os pilares dessa arquitetura estão explicados em git worktrees para agentes paralelos de IA.
Enquanto o agente trabalha, a tela Jobs exibe em tempo real o fluxo de logs e chamadas de ferramentas: arquivos acessados, comandos executados no shell, baterias de teste e o consumo acumulado de tokens e custos. O desenvolvedor pode acompanhar a execução ou partir para a revisão de outro plano. Com um Cloudflare Quick Tunnel ativo, essa mesma telemetria fica acessível no smartphone.
Verificação em ação
Quando o agente declara o plano concluído, a verificação dispara automaticamente no worktree: a suíte de testes e o linter são executados, consolidando o diff final para auditoria. Os resultados são organizados na interface Review sob três abas: tests, lint e diff. Falhas de teste ou alertas de lint são expostos imediatamente, antes que qualquer pessoa despenda tempo lendo código. Os planos Pro e Enterprise permitem inclusive puxar dados de verificação da esteira de CI. A importância de tratar a verificação como um portão obrigatório de qualidade é analisada em portões de verificação para código gerado por IA.
Revisão, pull request e limpeza
Ponto de controle 2: O desenvolvedor revisa o diff
Chega-se ao segundo ponto de controle humano. Na tela Review, o desenvolvedor audita o diff em paralelo com o plano e os relatórios de validação. Para a issue #418, o diff altera src/export/csv.ts, introduz uma função auxiliar de escape e estende o arquivo de testes com três cenários de teste: vírgula, aspas e quebra de linha interna em um campo. Todos os testes passam e o linter não aponta desvios. O desenvolvedor aprova o diff.
Se o diff não atender aos requisitos, o desenvolvedor retém o aval, enriquece o plano com os critérios faltantes e comanda uma nova rodada de execução. Nenhum código sobe para o GitHub sem esse consentimento explícito.
CreatePr abre o pull request
O promptware CreatePr abre o pull request a partir da branch do plano. A partir dessa etapa, segue-se o fluxo rotineiro de code review e merge adotado pela equipe no GitHub. A interface Pull Requests do Tendril acompanha o ciclo de cada PR gerado nessa dinâmica.
Pós-merge
Com a incorporação (merge) do PR, o Tendril remove o respectivo worktree. O promptware ExecutePlan então salva as descobertas obtidas na base de memória. No caso deste ticket, um registro como "The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export" é catalogado, orientando automaticamente os próximos planos que envolverem o módulo de exportação.
A esteira completa, para uma intervenção desse porte, consome minutos de processamento de agente e duas análises humanas pontuais. A equipe da própria Ivy registrou um salto de cerca de 10 para mais de 100 pull requests por dia após adotar essa prática de trabalho, mantendo inegociáveis ambos os pontos de controle.
Como começar
Instale o Tendril, conecte a integração com o GitHub para receber issues na Inbox e teste o ciclo com um único agente em uma demanda antes de escalar para execuções paralelas.
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
No Windows, execute irm https://cdn.ivy.app/install-tendril.ps1 | iex. A versão gratuita, com código aberto sob a Functional Source License, contempla o ciclo de vida completo. Pro e Enterprise adicionam gestão colaborativa para times, importação de status da CI e hospedagem on-premise.
Perguntas frequentes
O agente pode pular um ponto de controle caso a alteração seja pequena?
Não. As duas checagens humanas valem para absolutamente todos os planos. Um ajuste de apenas uma linha é submetido à aprovação de plano e de diff como qualquer outro. Planos menores apenas demandam menos tempo de inspeção.
O que acontece se dois planos simultâneos alterarem o mesmo arquivo?
Como cada plano se desenvolve em um worktree e em uma branch dedicada, não há conflitos durante a execução. O eventual atrito se manifestará no momento em que o segundo pull request for rebaseado ou mergeado, sendo resolvido segundo as regras normais do Git. Modularizar os planos em escopos bem delineados reduz consideravelmente essa ocorrência.
A issue precisa vir obrigatoriamente do GitHub?
Não. Planos podem nascer a partir de uma ideia digitada, um reporte de bug no jam.dev, pela CLI, via API REST ou pelo servidor MCP. O webhook do GitHub é apenas uma das portas de entrada disponíveis para alimentar a Inbox.
Primeiros passos com o Ivy Tendril
Pronto para a orquestração paralela de agentes em nível de engenharia?
- Explore o código: Confira o Ivy Tendril no GitHub (Código aberto).
- Consulte a documentação: Encontre guias de integração em tendril.ivy.app.
- Agende uma sessão técnica: Entre em contato pelo e-mail renco@ivy.app para uma consultoria de arquitetura de 30 minutos.