Orchestration

Orchestration é o padrão acima do agente único: pipeline (sequência fixa), supervisor (um agente comanda N) ou swarm (N agentes se auto-organizam). Define quem fala com quem, quando e em que ordem.

TemporalLangGraphApache AirflowPrefect

O que é

Orchestration coordena múltiplos agentes (ou múltiplas etapas de um agente) em um fluxo maior. Enquanto agent frameworks tratam do loop interno de um agente, orchestration trata do meta-loop: quem entra, quem sai, quanto tempo dura, onde o estado fica persistido.

A pergunta que orchestration responde não é 'o que esse agente faz', mas 'como esse agente conversa com o próximo'. Sem orchestration, cada agente vira uma ilha e a única cola entre eles é copiar e colar texto.

Os três padrões clássicos

Três padrões cobrem 90% dos casos reais. A escolha entre eles depende de quem decide o próximo passo:

pipeline: sequência fixa. Cada etapa recebe a saída da anterior; a ordem é conhecida em tempo de design. Boa para ETL com LLM, pré-processamento, ou qualquer caso onde a divisão de trabalho é clara.

supervisor: um agente (o supervisor) olha o estado e decide qual subagente chama agora. A estrutura existe, mas o caminho é decidido em runtime. Boa para fluxos com ramos dependentes de contexto.

swarm: N agentes se coordenam por mensagens, sem dono central. Mais flexível, mais difícil de auditar; reservado para exploração ou tarefas mal definidas.

comparação dos três padrõestext

  pipeline    A -> B -> C -> D
              ordem fixa, custo previsível, fácil de auditar

  supervisor  A (decide) -> B ou C -> A (decide de novo)
              ramo dinâmico, custo variável, supervisor é ponto único de falha

  swarm       A <-> B <-> C <-> D
              sem dono, mais caro, mais difícil de reproduzir

Estado e checkpoint: como sobreviver a falhas

Agentes são flaky por natureza: APIs externas caem, modelos retornam respostas ruins, timeouts acontecem no meio do fluxo. Sem checkpoint, uma falha de 5 minutos significa começar do zero, com prompt gasto e dinheiro queimado.

Checkpoint é o ato de persistir o estado do fluxo em um storage durável após cada etapa, com um ID único. Quando a execução recomeça (por crash, deploy ou retomada manual), o runtime lê o último checkpoint e continua de onde parou, sem repetir trabalho já feito.

Temporal e Prefect modelam isso como workflow durable: cada função pode ser async, o runtime sabe reexecutar do ponto de falha. LangGraph expõe o mesmo conceito como thread_id com persistência em Redis ou Postgres.

orchestrator.pypython

from temporalio import workflow, activity
from datetime import timedelta


@activity.defn
async def extract(pdf_url: str) -> dict:
    return {'text': '...'}


@activity.defn
async def summarize(text: str) -> str:
    return 'resumo'


@workflow.defn
class ReportFlow:
    @workflow.run
    async def run(self, pdf_url: str) -> str:
        # Cada execute_activity vira um step persistido pelo Temporal;
        # se o worker cair no meio, o workflow retoma do ponto de falha
        # sem repetir a atividade já concluída.
        extracted = await workflow.execute_activity(
            extract,
            pdf_url,
            start_to_close_timeout=timedelta(minutes=2),
        )
        return await workflow.execute_activity(
            summarize,
            extracted['text'],
            start_to_close_timeout=timedelta(minutes=2),
        )

Pipeline com LangGraph: supervisor + subagentes

LangGraph deixa modelar supervisor e pipeline no mesmo grafo: cada nó é uma função (ou um subagente), e cada aresta condicional carrega a lógica 'qual nó agora'. O grafo é determinístico o suficiente para auditoria e flexível o suficiente para reagir ao estado.

No exemplo abaixo, um orquestrador decide entre chamar 'researcher' ou 'writer' dependendo do estado; cada um deles é um subagente com seu próprio loop interno.

supervisor.tsxtypescript

import { StateGraph, END } from '@langchain/langgraph';

type S = { messages: any[]; stage: 'pending' | 'researched' | 'written' };

async function orchestrator(s: S) {
  if (s.stage === 'pending')  return 'researcher';
  if (s.stage === 'researched') return 'writer';
  return END;
}

const graph = new StateGraph<S>({ channels: { messages: [], stage: 'pending' } })
  .addNode('orchestrator', orchestrator)
  .addNode('researcher',  async (s) => ({ ...s, stage: 'researched' as const }))
  .addNode('writer',      async (s) => ({ ...s, stage: 'written' as const }))
  .addEdge('__start__', 'orchestrator')
  .addConditionalEdges('orchestrator', (s) => s.stage,
    { researcher: 'researcher', writer: 'writer', written: END, [END]: END })
  .addEdge('researcher', 'orchestrator')
  .addEdge('writer',     'orchestrator')
  .compile({ checkpointer: redisCheckpointer });

Onde orchestration encontra o resto do sistema

filas e workers: orchestration transforma chamadas longas em jobs assíncronos; cada etapa vira um worker
idempotência por design — checkpoint sem idempotência significa reexecutar e duplicar efeito colateral
observabilidade: cada etapa emite métricas, logs e spans; sem isso, debugar multi-agente é adivinhar
human-in-the-loop: em fluxos críticos, o supervisor pausa e espera aprovação antes da próxima etapa

Limitações

orquestrador é um lugar para más decisões se acumularem — supervisor mal calibrado vira loop infinito
checkpoint tem custo: cada persistência adiciona latência e acoplamento a um banco
swarm e supervisor flexível são difíceis de reproduzir — mesmo prompt pode dar fluxos diferentes
tooling ainda é jovem: Temporal é sólido para código determinístico, mas o suporte a LLM dentro dele é recente

conexões no mapa

Agent frameworkscoordena comOrchestration

atualizado em 14/10/2026 · fontes para aprofundar · reportar erro

Estude antes

Agent frameworks

teste o que entendeu

Carregando perguntas…