Graph Engineering

Definition

Graph engineering é um padrão de orquestração em que uma tarefa maior é dividida entre vários agentes especializados, conectados por fluxos de informação e critérios de sucesso. Cada agente executa uma versão menor de um loop: recebe um gatilho, realiza uma tarefa e verifica se o resultado atende ao critério definido.

O conceito é apresentado como uma evolução de vibe-coding e de loop engineering, não como substituto obrigatório para um loop simples.

Key Points

• Um agente de pesquisa pode coletar dados, enquanto agentes separados analisam YouTube, redes sociais ou e-mail.
• Agentes de síntese consolidam os resultados; um agente de revisão verifica a qualidade e decide se o fluxo deve continuar ou ser repetido.
• Dividir o trabalho reduz a sobrecarga de contexto de cada agente e facilita localizar falhas específicas.
• Tarefas independentes podem ser executadas em paralelo, reduzindo o tempo total.
• Critérios de sucesso devem ser definidos por etapa, e não apenas para o resultado final.

Quando usar

Para um founder ou PM, graph engineering merece consideração quando pelo menos uma destas condições aparece:

• o loop acumula tanto contexto que a qualidade começa a cair;
• o resultado exige uma revisão independente, especialmente em trabalho de maior risco;
• várias fontes ou tarefas independentes precisam ser processadas rapidamente.

Se a tarefa é pequena, sequencial e de baixo risco, um único agente em um loop simples tende a ser suficiente. O grafo adiciona coordenação, infraestrutura e pontos de falha, portanto deve ser tratado como uma decisão de produto e operação, não como sinal de sofisticação.

Decision Rules

• Comece com um loop simples e divida apenas a etapa que está causando lentidão, contexto excessivo ou revisão insuficiente.
• Dê a cada agente uma tarefa atômica e um critério observável de sucesso.
• Mantenha uma etapa de revisão quando o agente que produziu o resultado não for uma autoridade adequada para avaliá-lo sozinho.
• Registre qual agente falhou e em qual etapa, para que a correção não exija reexecutar tudo sem necessidade.

Related Concepts

• vibe-coding — contexto de construção de produto com agentes de IA.
• pm — papel responsável por decidir escopo, critérios de sucesso e trade-offs.
• non-technical-founder — perfil que precisa entender o desenho do fluxo sem necessariamente implementar o código.
• system-design — vocabulário para avaliar componentes, dependências, escala e limites do sistema.
• plan-first-com-agentes-de-ia — prática complementar para planejar o trabalho antes da execução dos agentes.
• pstack — exemplo empacotado de orquestração com critérios por etapa: um roteador (/poteto-mode) casa o pedido a um playbook verbatim, delega por papel de modelo e exige evidência antes de reportar sucesso.

Implications

Graph engineering transforma a pergunta “qual prompt devo usar?” em “como devo dividir, conectar e avaliar o trabalho?”. Para um founder/PM, o ganho principal é obter um fluxo mais observável e controlável; o custo é administrar mais componentes, contratos entre etapas e possíveis falhas de coordenação.

Open Questions

• Quais métricas comprovam que a divisão em agentes melhora o resultado o suficiente para pagar sua complexidade?
• Em que ponto um agente de revisão realmente é independente, em vez de repetir o mesmo erro do agente original?
• Como definir critérios de sucesso confiáveis para tarefas subjetivas, como síntese e priorização?

External Links

• A deep dive into pstack — Flavio Copes

Sources

^[raw/vibecoding/transcripts/youtube-Joqh7Tui9B8.md]