Domínio 1 — Agentic Architecture & Orchestration · Lição 3 de 7

Workflow ou agente? Padrões de orquestração

Objetivos de aprendizagem

• Diferenciar workflows (caminho de código pré-definido) de agentes (modelo dirige o próprio processo).
• Reconhecer e aplicar os cinco padrões de orquestração: prompt chaining, routing, parallelization, orchestrator-workers e evaluator-optimizer.
• Aplicar os critérios de decisão: complexidade da tarefa, valor, viabilidade das capacidades e custo do erro.
• Escolher entre decomposição fixa (pipeline sequencial) e decomposição adaptativa dirigida pelos achados intermediários (task statement 1.6).

Workflows vs. agentes

Na taxonomia da Anthropic ("Building effective agents"), os dois são sistemas agênticos, mas com diferença arquitetural clara:

• Workflow: LLMs e ferramentas orquestrados por caminhos de código pré-definidos. O desenvolvedor fixa a sequência; o modelo executa cada etapa. Previsível, testável, mais barato.
• Agente: o LLM dirige dinamicamente seu próprio processo e uso de ferramentas, decidindo em tempo de execução quais passos dar. Flexível, lida com ambiguidade, mas custa mais e é menos previsível.

Regra prática da prova: use a solução mais simples que resolve. Se a tarefa pode ser decomposta em passos conhecidos de antemão, um workflow basta; agentes são para tarefas abertas em que não dá para prever o número de passos nem fixar o caminho.

Os cinco padrões de workflow/orquestração

flowchart TD
    subgraph chaining[Prompt chaining — decomposição fixa]
      A1[Passo 1] --> A2[Gate] --> A3[Passo 2] --> A4[Passo 3]
    end
    subgraph orch[Orchestrator-workers — decomposição adaptativa]
      B0[Orquestrador] --> B1[Worker A]
      B0 --> B2[Worker B]
      B0 --> B3[Worker C]
      B1 --> B4[Síntese]
      B2 --> B4
      B3 --> B4
      B4 --> B0
    end
  

Quando vale a pena um agente: 4 critérios

Antes de construir um agente, avalie os quatro critérios (framework da Anthropic para decidir "should you build an agent?"):

1. Complexidade da tarefa: a tarefa é ambígua/aberta o suficiente para exigir raciocínio dinâmico? Tarefas mapeáveis num fluxograma ficam melhores (e mais baratas) como workflow.
2. Valor da tarefa: o valor por execução justifica o custo em tokens e latência do loop agêntico? Tarefas de alto volume e baixo valor pedem workflows enxutos.
3. Viabilidade (capacidades): o modelo consegue de fato executar todas as etapas com as ferramentas disponíveis? Derisque as capacidades críticas antes.
4. Custo do erro / descoberta do erro: erros são caros ou difíceis de detectar? Se sim, prefira fluxos com mais controle (workflow, gates, human-in-the-loop) ou restrinja a autonomia (ex.: read-only, sandbox).

Decomposição fixa vs. adaptativa (task statement 1.6)

Dentro do universo de decomposição de tarefas, a prova cobra saber quando cada estratégia se aplica:

• Pipeline sequencial fixo (prompt chaining): para trabalhos previsíveis e multi-aspecto. Exemplo clássico do exam guide: revisão de código grande — analisar cada arquivo individualmente (passe local) e depois rodar um passe separado de integração cross-file, evitando diluição de atenção.
• Decomposição dinâmica/adaptativa: para investigação aberta, em que as subtarefas emergem do que se descobre. Exemplo do exam guide: "adicionar testes abrangentes a um codebase legado" — primeiro mapear a estrutura, identificar áreas de alto impacto, criar um plano priorizado e adaptá-lo conforme dependências aparecem.

Um routing simples implementado como workflow — o classificador é uma chamada de modelo, mas o caminho é decidido por código:

import anthropic

client = anthropic.Anthropic()

def classify(ticket_text):
    """Passo 1 do workflow: classificar o ticket (routing)."""
    response = client.messages.create(
        model="claude-opus-5",
        max_tokens=100,
        system="Classifique o ticket em exatamente uma categoria: "
               "refund, technical, account. Responda apenas a categoria.",
        messages=[{"role": "user", "content": ticket_text}],
    )
    text = next((b.text for b in response.content if b.type == "text"), "")
    return text.strip().lower()

PROMPTS = {
    "refund": "Voce trata reembolsos seguindo a politica de devolucao...",
    "technical": "Voce e o suporte tecnico do produto...",
    "account": "Voce trata questoes de conta e acesso...",
}

def handle_ticket(ticket_text):
    category = classify(ticket_text)
    system = PROMPTS.get(category, PROMPTS["technical"])
    # Passo 2: fluxo especializado escolhido POR CODIGO (workflow),
    # nao pelo modelo em tempo de execucao (agente).
    response = client.messages.create(
        model="claude-opus-5",
        max_tokens=2000,
        system=system,
        messages=[{"role": "user", "content": ticket_text}],
    )
    return next((b.text for b in response.content if b.type == "text"), "")

print(handle_ticket("Quero devolver o pedido 4412, chegou quebrado."))

Pegadinhas da prova

• Distrator típico: propor um agente autônomo completo para uma tarefa com passos fixos e conhecidos (over-engineering). Se dá para desenhar o fluxograma de antemão, a resposta certa é workflow (chaining/routing).
• Distrator típico: o inverso — engessar em pipeline fixo uma investigação aberta cujo escopo depende dos achados. Aí a resposta é decomposição adaptativa/orchestrator-workers.
• Distrator típico: confundir parallelization (subtarefas independentes definidas por código) com orchestrator-workers (o orquestrador decide dinamicamente as subtarefas).
• Distrator típico: "use um modelo maior/contexto maior" para resolver diluição de atenção em revisões grandes. A solução cobrada é decompor em passes focados (por arquivo + integração), não escalar o modelo.
• Distrator típico: ignorar o custo do erro: dar autonomia total a um agente em operação financeira irreversível. Custo de erro alto pede gates, aprovação humana ou workflow controlado.

Resumo em 5 linhas

Documentação oficial

• Building effective agents (Anthropic Engineering)
• Tool use overview
• How we built our multi-agent research system

Questões de fixação