Como se tornar um engenheiro de grafos

Um caminho prático que vai da utilização de ferramentas de IA separadamente à construção de sistemas conectados capazes de executar tarefas reais.

A IA está chegando a um ponto um pouco maluco agora.

Você pode ter o GPT-6 Astra trabalhando em uma tarefa, o Fable 5.1 cuidando de outra, o Kimi sentado em uma enorme pilha de arquivos e um Grok Bot correndo por sites e apps em seu próprio computador.

Cada um deles já é poderoso.

Mas coloque cinco deles no mesmo fluxo de trabalho e um novo problema aparece muito rapidamente: quem faz o quê, quem vai primeiro, o que pode acontecer ao mesmo tempo, o que acontece quando algo falha e quem decide quando o trabalho está realmente terminado?

Acho que essa se tornará uma habilidade de IA muito importante.

Não porque de repente precisamos de mais agentes.

Porque finalmente temos agentes bons o suficiente para que organizá-los esteja se tornando mais difícil do que criá-los.

Essa habilidade agora tem um nome.

Engenharia de grafos.

Os modelos estão ficando melhores. A parte complicada é tudo o que acontece entre eles.

Veja o que aconteceu recentemente.

A nova API de agentes da OpenAI pode manter agentes trabalhando em longas sessões e permitir que subagentes trabalhem em paralelo. O Claude Fable 5.1 foi criado para tarefas de codificação e conhecimento de longa duração em diversas ferramentas e aplicações. O Kimi K3 pode trabalhar com uma janela de contexto de até 1 milhão de tokens. O Grok Bot oferece aos agentes persistentes seus próprios computadores na nuvem e permite que continuem trabalhando depois que você sai.

Estes não são mais apenas chatbots esperando pela próxima pergunta.

Eles estão se tornando trabalhadores.

E, uma vez que você tem vários trabalhadores, a pergunta importante muda.

Não é mais:

“Qual prompt devo escrever?”

Torna-se:

“Como o trabalho deve fluir?”

É aí que a engenharia de grafos começa.

Este guia abaixo tem como objetivo torná-lo genuinamente bom em engenharia de grafos, não apenas familiarizado com o termo: como conectar agentes, modelos, ferramentas e memória, decidir o que é executado onde, manter os custos sob controle, lidar com falhas, criar automações úteis e transformar uma configuração de IA bagunçada em algo que realmente possa funcionar por conta própria.

Esqueça o significado técnico de “grafo”

Para trabalhos com IA, pense em um grafo como um mapa do trabalho.

Isso é o suficiente.

Suponha que você peça a um sistema de IA para avaliar um novo produto antes do lançamento.

A versão preguiçosa parece com isto:

REVIEW PRODUCT
      ↓
ONE BIG AI AGENT
      ↓
FINAL ANSWER

O agente precisa entender o produto, inspecionar o código, verificar a segurança, ler o feedback, testar funcionalidades importantes e decidir o que importa.

Tudo acontece dentro de uma única sessão gigante.

Um grafo divide esse trabalho:

                    → CODE CHECK ───────
                    → SECURITY CHECK ───
REQUEST → PLAN      → PRODUCT TEST ─────→ FINAL REVIEW
                    → USER FEEDBACK ────

Quatro tarefas podem acontecer simultaneamente.

Então seus resultados se encontram novamente.

Essa forma é o gráfico.

Aqui, “gráfico” é diferente de um grafo de conhecimento. Um grafo de conhecimento mapeia informações e relacionamentos. A engenharia de gráficos mapeia trabalho e decisões.

Aprenda estas seis palavras e você já entende metade disso

Você não precisa de muito vocabulário.

Nó

Um nó é uma tarefa.

Exemplos:

Search the web

Read these files

Check the code

Classify the request

Send an email

Verify the answer

Um nó pode ser um agente de IA.

Também pode ser código normal, uma API, uma busca em banco de dados ou uma aprovação humana.

Essa última parte é importante.

Nem toda caixa em um gráfico precisa de IA.

Aresta

Uma aresta simplesmente significa:

depois deste trabalho, para onde o trabalho vai?

Por exemplo:

RESEARCH → WRITE

O escritor precisa da pesquisa, então a conexão faz sentido.

Mas isto:

CHECK WEATHER → REVIEW CODE

não faz sentido.

O revisor de código não precisa do resultado do clima.

Esses trabalhos podem ser executados separadamente.

Isso lhe dá uma das melhores perguntas na engenharia de grafos:

O próximo trabalho realmente precisa do resultado anterior?

Se a resposta for não, você pode ter encontrado um trabalho que pode ser executado ao mesmo tempo.

Roteador

Um roteador escolhe um caminho.

Imagine um sistema de suporte por IA.

                 → BILLING AGENT
MESSAGE → ROUTER → TECH AGENT
                 → SALES AGENT

Um pequeno modelo pode ler a mensagem primeiro.

Então, ele envia o trabalho para o lugar certo.

Isso é muito melhor do que dar a um agente gigante todas as ferramentas, todas as instruções e todas as tarefas possíveis.

Estado

Estado é o que a execução atual precisa lembrar.

Por exemplo:

customer_id
task
current_step
files_found
result
retry_count
approval_status

Você não precisa manter a conversa inteira em todos os lugares.

Mantenha apenas o que a próxima parte do sistema realmente precisa.

Memória

Memória é diferente.

O estado ajuda no trabalho atual.

A memória ajuda em trabalhos futuros.

Por exemplo:

This customer prefers PDF reports.

This project uses Python 3.13.

Never change the production database without approval.

The last successful setup used model X.

Estes são úteis mais tarde.

Uma transcrição de 50.000 tokens normalmente não é.

Portão

Um portão pergunta:

Isso é bom o suficiente para continuar?

Por exemplo:

CODE
 ↓
TEST
 ↓
PASS? ── YES → CONTINUE
  |
  NO
  ↓
FIX

Esse pequeno portão é uma das partes mais úteis de todo o sistema.

O gráfico não é o loop

Essas duas ideias são fáceis de confundir.

Um loop torna uma tarefa melhor.

CREATE
  ↓
CHECK
  ↓
FAIL → FIX → CHECK
  ↓
PASS

Um grafo decide quais trabalhos existem e como eles se conectam.

              → AGENT A →
START → PLAN  → AGENT B → COMBINE → CHECK
              → AGENT C →             ↓
                                  FIX IF NEEDED

Um bom sistema de IA geralmente usa ambos.

O grafo fica do lado de fora.

Pequenos loops vivem dentro dele.

O seu primeiro gráfico deve ter apenas cinco ou seis tarefas

Não comece com 50 agentes.

Escolha uma tarefa real que você já entrega à IA.

Depois, cole isto no Astra, Fable, Kimi, Claude, Grok ou outro modelo robusto:

I want to turn this job into a simple AI graph.

JOB:

[describe the job]

Break it into the smallest useful steps. For every step tell me: – what goes in – what happens – what comes out – which tool or model should handle it – what can run at the same time – what must wait – what should happen if it fails Also show me where I need: – memory – a check – a human approval Keep the system simple. Do not create an AI agent when normal code can do the job reliably.

Então leia o resultado.

Seu trabalho não é aceitar o grafo dele.

Seu trabalho é deletar partes desnecessárias.

Se ele te der 14 nós e o trabalho puder ser feito com seis, use seis.

Grafos simples são mais fáceis de entender, mais baratos de rodar e mais fáceis de reparar.

Existem realmente apenas quatro formas que você precisa no início

A primeira é uma linha reta:

A → B → C

Use-a quando cada etapa realmente precisar da anterior.

A segunda é uma divisão:

        → B1 →
A       → B2 → D
        → B3 →

Use-a quando vários trabalhos puderem ser executados de uma vez.

O terceiro é um roteador:

             → EASY PATH
REQUEST → ROUTER
             → HARD PATH

Use-o quando trabalhos diferentes exigirem níveis diferentes de esforço.

O quarto é um loop:

WORK → CHECK → DONE
         |
        FAIL
         ↓
        FIX
         ↓
       CHECK

Você pode construir sistemas surpreendentemente avançados combinando essas quatro formas.

É aqui que diferentes modelos de IA finalmente fazem sentido juntos

A engenharia de grafos muda a forma como você escolhe modelos.

Em vez de perguntar:

Qual IA é a melhor?

Pergunte:

Qual IA é a melhor para este nó?

Essa é uma pergunta muito melhor.

Você poderia construir algo como:

ROUTING
small cheap model

PLANNING
GPT-6 Astra

HUGE FILE SET
Kimi K3

DIFFICULT CODE OR KNOWLEDGE WORK
Fable 5.1

WORK INSIDE APPS
Grok Bot

EXACT CALCULATION
normal code

FINAL HIGH-RISK CHECK
strong model + real test

Os modelos podem mudar depois.

O gráfico pode ficar.

Essa é uma de suas forças ocultas.

Se um modelo melhor aparecer no próximo mês, você só precisará substituir um nó em vez de reconstruir todo o sistema.

Pare de gastar tokens de IA em trabalhos entediantes

Isso parece óbvio, mas economiza muito dinheiro.

Suponha que cinco agentes retornem 100 URLs.

Você precisa remover as duplicatas.

Não pergunte à Astra.

Use código.

Suponha que você precise:

sort dates
add numbers
remove duplicates
check empty fields
compare IDs
rename files
validate JSON

Use software normal.

Use IA quando o trabalho exigir julgamento.

Is this claim supported?

What is wrong with this code?

Which strategy is stronger?

What information is missing?

What does this customer actually want?

É aí que a inteligência de modelo é útil.

Um grafo se torna muito mais barato quando a IA lida apenas com as partes que precisam de IA.

Dê ao trabalho barato um caminho barato

Este é um dos meus padrões de grafo favoritos.

Antes de fazer um trabalho caro, verifique se o trabalho caro é realmente necessário.

                    → SIMPLE → SMALL MODEL
REQUEST → ROUTER
                    → HARD → STRONG MODEL + TOOLS

Imagine que 100 tarefas cheguem.

Talvez 70 sejam simples.

Por que enviar todas as 100 através da sua configuração mais cara?

Encaminhe primeiro.

Pense depois.

Isso se torna especialmente importante com modelos como GPT-6 Astra e Fable 5.1, que são precificados para trabalhos de nível de fronteira, em vez de pequenos trabalhos de classificação. O Astra lista atualmente preços padrão de API de US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída; o Fable 5.1 lista as mesmas taxas base.

Coloque um limite rígido em cada loop

Esta regra pode te salvar de algumas contas desagradáveis.

Nunca escreva:

Keep trying until it works.

Escreva:

Try once.

If it fails, repair it.

Maximum retries: 2.

If it still fails:
stop and ask for help.

Agentes são muito bons em continuar.

Esse é, às vezes, o problema.

Todo loop deveria ter uma regra de parada.

Toda ramificação cara deveria ter um orçamento.

Toda automação deveria saber quando desistir.

O trabalho em paralelo torna as coisas mais rápidas, não mais baratas

Suponha que você tenha quatro agentes de pesquisa.

Cada um usa 20.000 tokens.

Execute-os um após o outro:

20K + 20K + 20K + 20K

Execute-os juntos:

20K
20K
20K
20K

A segunda versão pode terminar muito mais rápido.

Mas você ainda pagou por aproximadamente 80.000 tokens.

Trabalho em paralelo economiza tempo.

Isso não economiza tokens magicamente.

É por isso que a engenharia de grafos é, em parte, engenharia de custos.

Você decide onde vale a pena pagar por inteligência extra.

Gráficos de longa execução precisam de pontos de verificação

Imagine que seu sistema está funcionando há 40 minutos.

Ele completou sete etapas.

Então, uma API falha.

Um sistema ruim começa novamente a partir do passo um.

Um sistema melhor se lembra:

Step 1 complete
Step 2 complete
Step 3 complete
...
Step 7 complete
Step 8 failed

Então ele retoma a partir do passo oito.

Esse ponto salvo é chamado de checkpoint.

Isso se torna muito importante quando agentes trabalham por minutos ou horas.

Sistemas de fluxo de trabalho modernos, como LangGraph e o Agent Framework da Microsoft, oferecem suporte a estados salvos, pontos de verificação e retomada de fluxos de trabalho de longa duração.

Dê a cada agente apenas as ferramentas de que ele precisa

Imagine que um grafo tenha acesso a:

browser
email
calendar
files
database
payments
code
CRM

Todos os agentes deveriam ter acesso a tudo?

Não.

O nó de pesquisa pode precisar apenas de:

browser
files

O nó de agendamento pode precisar de:

calendar

O nó de cliente pode precisar de:

CRM
email

E o nó de pagamento pode exigir aprovação humana antes de realizar qualquer ação.

Isso torna o sistema mais fácil de controlar.

Isso também reduz o dano que um agente confuso pode causar.

As automações são onde os gráficos se tornam realmente úteis

Imagine que você quer que algo aconteça todas as manhãs.

Uma automação básica diz:

8 AM → ask AI to do the job

Um gráfico pode dizer:

8 AM
 ↓
COLLECT NEW DATA
 ↓
CHECK WHAT CHANGED
 ↓
ROUTE
 ↙   ↓   ↘
A    B    C
 ↘   ↓   ↙
COMBINE
 ↓
VERIFY
 ↓
ACT

O agendamento apenas inicia o sistema.

O grafo decide como o sistema funciona.

Essa é uma maneira muito mais útil de pensar sobre a automação com IA.

Você pode começar sem aprender um framework

Esta parte é importante.

Não perca três dias instalando ferramentas antes de entender o fluxo de trabalho.

Primeiro, desenhe o gráfico em texto simples.

Algo como:

NEW REQUEST
   ↓
CLASSIFY
   ↓
 ┌───────────────┐
 ↓               ↓
SIMPLE          COMPLEX
 ↓               ↓
SMALL AI        STRONG AI
 ↓               ↓
 └───────┬───────┘
         ↓
       CHECK
         ↓
      APPROVAL

Execute-o manualmente.

Veja onde ele quebra.

Altere a forma.

Só então automatize-o.

Assim que quiser código real, bons lugares para explorar são LangGraph, Microsoft Agent Framework, OpenAI’s Agents API e Google’s ADK. O sistema de fluxo de trabalho atual da Microsoft, por exemplo, suporta diretamente trabalho sequencial, trabalho paralelo, transferências, intervenção humana, estado e pontos de verificação.

Pontos de partida úteis:

LangGraph Graph API

API de Agentes da OpenAI

Fluxos de Trabalho do Microsoft Agent Framework

Documentação do Código Kimi

Bot Grok

Se você quer se tornar bom nisso, construa um sistema

Não tente “aprender engenharia de grafos” como uma teoria.

Escolha um trabalho.

Construa:

one router

three useful workers

one shared state

one verifier

one repair loop

one human approval

Então execute-o 20 vezes.

Observe o que quebra.

Talvez seu roteador continue escolhendo o caminho errado.

Conserte o roteador.

Talvez um trabalhador receba informações demais.

Reduza seu contexto.

Talvez o verificador rejeite um bom trabalho.

Melhore a verificação.

Talvez um ramo consuma metade do orçamento de tokens.

Dê a ele um modelo menor.

Talvez o sistema repita o trabalho após a falha.

Adicione um ponto de verificação.

É assim que a habilidade começa a se tornar real.

O gráfico está se tornando a camada acima do modelo

Por muito tempo, melhorar em IA significava melhorar nos prompts.

Depois, começamos a trabalhar no contexto.

Depois, nas ferramentas.

Depois os agentes.

Depois a memória, habilidades e loops.

Tudo isso ainda importa.

Mas assim que vários deles vivem dentro do mesmo sistema, surge outra pergunta:

Como tudo deve se conectar?

Esse é o gráfico.

A próxima geração de sistemas de IA não será um modelo gigante fazendo tudo dentro de uma única conversa gigante.

Eles serão pequenas peças de inteligência, ferramentas, código, memória e automações trabalhando juntas.

Alguém ainda precisa decidir como essas peças se encaixam.

É isso que um engenheiro de gráficos faz.

E a parte útil é que você não precisa esperar que “engenheiro de grafos” se torne um cargo comum.

Você pode começar a se tornar um pegando um fluxo de trabalho de IA bagunçado que você já usa hoje e traçando as linhas certas entre suas partes.