GEO Universal Framework · Capítulo 19 de 29 · 24 min
Operar com agentes: qual modelo para qual tarefa, e quando não orquestrar
Você sai decidindo quando vale orquestrar agentes de IA e quando uma chamada resolve, com o critério para escolher o nível de modelo por tarefa e as perguntas que você faz a quem opera o pipeline.
Este capítulo faz parte do curso gratuito GEO Universal Framework. Para marcar como concluído e salvar o progresso, abra este capítulo na página do curso.
Orquestrar agentes de IA (sistemas que recebem um objetivo, dividem em passos, usam ferramentas e decidem o passo seguinte sozinhos) só compensa em três condições: volume repetido, tarefas de tipos diferentes no mesmo fluxo e alguém com nome para manter o pipeline. Fora disso, uma chamada única a um modelo resolve mais barato. Este módulo serve a quem aprova a conta de IA de uma operação de conteúdo ou pesquisa e precisa decidir isso sem ler código. Você sai com o critério que classifica cada tarefa antes de escolher o modelo, a fotografia de preços de 07/09/2026 e as cinco perguntas para quem opera.
Para quem decide: a decisão é aprovar ou recusar a montagem de um pipeline de agentes, e o critério é volume, heterogeneidade e dono nomeado. Errar custa nos dois sentidos: 40 mil títulos classificados no modelo mais caro por descuido de configuração, ou um texto institucional publicado com dado inventado pelo modelo mais barato (cenário ilustrativo). Pergunta para quem opera: qual é a taxa de aprovação de primeira do nível barato nesta tarefa, medida em quantos itens?
Ao final você consegue: (1) decidir, com critério explícito, quando uma chamada única resolve melhor que uma orquestração. (2) Classificar qualquer tarefa de conteúdo ou pesquisa em três propriedades (tolerância a erro, custo de verificar, valor do acerto) e ler uma política de roteamento que não cita marca. (3) Calcular quando o escalonamento em cascata economiza e quando multiplica custo. (4) Exigir de quem opera três guarda-corpos antes de qualquer sofisticação: o cache (a cópia guardada de uma resposta já obtida), o teto de orçamento por rodada e o circuit breaker (o disjuntor que para de insistir num fornecedor fora do ar). E pedir a data do catálogo de modelos.
Verificação rápida
Você vai escrever a primeira regra de roteamento da orquestração de conteúdo da sua equipe. Qual delas sobrevive à próxima geração de modelos?
Glossário rápido
Agente
Sistema que recebe um objetivo, decompõe em passos, usa ferramentas externas e decide sozinho o próximo passo. Difere de uma chamada de chat porque mantém estado e age.
Roteador
Componente que escolhe qual executor recebe cada tarefa, a partir de regras ou de pontuação.
Fallback
Executor alternativo acionado quando o primeiro falha ou reprova na verificação.
Escalonamento em cascata
Começar pelo executor mais barato e subir de nível apenas quando um verificador reprova a saída.
Cache
Cópia guardada de uma resposta já obtida, devolvida sem chamar o modelo de novo quando a mesma pergunta se repete dentro do prazo de validade.
Circuit breaker
Mecanismo que, após N falhas consecutivas de um provedor, para de tentar por um intervalo em vez de insistir. Estados: fechado (tráfego normal), aberto (bloqueado), meio aberto (uma tentativa de sondagem).
Orçamento por execução
Teto de gasto de uma rodada inteira, distinto do teto mensal. Sem ele, um laço com defeito consome o mês em uma madrugada.
Qualquer material que ensine orquestração dizendo 'use o modelo A para redação e o modelo B para análise' apodrece em meses. As posições relativas mudam a cada geração e o preço por token (a unidade em que o fornecedor cobra o texto lido e escrito) cai de forma irregular entre fornecedores. O que não apodrece é a taxonomia da tarefa: uma classificação em lote de baixa consequência continua sendo isso daqui a dois anos, mesmo que o modelo indicado para ela tenha mudado três vezes.
A fotografia de julho deste módulo durou sete semanas. Entre 01/09 e 03/09/2026 três fornecedores trocaram o topo do catálogo: Claude Fable 5.1 e Mythos 5.1 em 01/09, Gemini 3.8 Flash em 02/09, GPT-6 Astra em 03/09. E a Perplexity aposenta os endpoints Sonar em 27/09/2026, com a Agent API como sucessora. Quem escreveu política citando marca em julho reescreve tudo em setembro; quem escreveu por propriedade troca uma tabela.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
As três propriedades que classificam qualquer tarefa, medidas uma vez por tipo em vez de a cada execução.
Tolerância a erro. Um erro em classificação de intenção de busca custa um item mal etiquetado num lote de milhares, e o próximo passo do pipeline provavelmente absorve. Um erro numa afirmação factual sobre o cliente publicada na home custa credibilidade e, dependendo do setor, custa jurídico. Essa diferença manda no orçamento por tarefa, muito mais do que o volume.
Custo de verificar. Existe verificador automático barato? Saída em JSON com schema tem: valida ou não valida. Uma tabela de números com fonte tem verificação cara, porque exige conferir cada fonte. Quando o verificador é barato, você pode usar um executor mais fraco e deixar a verificação carregar o rigor; quando é caro, o rigor precisa vir do executor, e economizar na chamada sai mais caro no total.
Valor do acerto. Vinte mil classificações corretas valem o pipeline rodando. Um único parágrafo de posicionamento excelente pode valer o mês inteiro. Tarefas de cauda longa e alta repetição pedem otimização de custo unitário; tarefas únicas e de alta alavancagem pedem otimização de qualidade, e o custo da chamada é irrelevante diante do valor.
Da classificação nasce o roteamento (a regra que decide qual executor recebe cada tarefa, como a triagem de um pronto-socorro), e ele deve ser escrito por propriedade. Uma política madura tem regras que se leem assim. Tarefa de alto volume, baixa consequência e verificação amostral vai para o nível barato. Tarefa com verificador automático determinístico começa no nível barato e escalona no máximo duas vezes. Tarefa de alta consequência com verificação cara vai direto para o nível alto e passa por revisão humana antes de publicar.
Repare que nenhuma dessas regras cita marca. Os nomes ficam num único arquivo de mapeamento de níveis, isolado do resto, e é o único ponto que você atualiza quando o mercado muda. Essa separação entre política e catálogo é o que dá vida longa à arquitetura.
Há uma exceção honesta: pesquisa com fontes. Tarefas que exigem busca web em tempo real e retorno de citações verificáveis dependem de o executor ter acesso a busca, o que é uma capacidade, coisa diferente de preferência de qualidade. Essa regra pode citar capacidade ('executor com busca web ativada'), continuando sem citar marca. Desde 01/09/2026 a Anthropic aceita listas de domínios permitidos ou bloqueados na busca dos agentes gerenciados, o que faz dessa capacidade algo configurável por política.
Qual executor recebe esta tarefa?
Eixo horizontal: Custo de verificar a saída (barato à esquerda, caro à direita)Eixo vertical: Consequência do erro (alta em cima, baixa embaixo)
Nível barato com verificador determinístico obrigatório
- JSON-LD que precisa validar contra schema antes de publicar
- Extração de campos de uma resposta, com formato fechado
- O verificador carrega o rigor, então escalone no máximo duas vezes
Nível alto direto, com revisão humana antes de publicar
- Página institucional de cliente do setor de saúde
- Afirmação factual com número que vai para a home
- Aqui o verificador é uma pessoa, e o tempo dela é o recurso caro do sistema
Nível barato, sem escalonamento
- Classificação de intenção de busca em lote de milhares
- Geração de 300 meta descriptions de páginas de produto
- Verificação amostral resolve, e o próximo passo do pipeline absorve o erro residual
Nível médio com amostragem ampliada
- Resumos internos de reunião que ninguém vai conferir linha a linha
- Rascunho de pauta cujo erro só custa tempo de quem lê
- O quadrante que engana: consequência baixa convida a ignorar, e a verificação cara faz o erro sobreviver
Catálogo de níveis, fotografia de 07/09/2026 (reveja a cada trimestre)
| Nível | Modelo na fotografia | Preço por milhão de tokens | O que muda na política |
|---|---|---|---|
| Barato, alto volume | Gemini 3.8 Flash (Google, 02/09/2026) | US$ 0,75 de entrada e US$ 3,75 de saída, até 31/12/2026 | Nada; a regra de volume continua apontando para o nível barato |
| Alto, raciocínio | Claude Fable 5.1 (Anthropic, 01/09/2026); o Mythos 5.1 é o mesmo modelo com outro nível de salvaguarda, restrito a defensores cibernéticos e cientistas verificados | US$ 10 de entrada e US$ 50 de saída; o texto gerado sai com marca d'água da Anthropic | Nada na regra; a marca d'água entra na cláusula de contrato de conteúdo |
| Alto, raciocínio | GPT-6 Astra (OpenAI, 03/09/2026), em fases; Pro, Enterprise e Business Premium primeiro | US$ 10 de entrada, US$ 50 de saída, US$ 1 por entrada em cache | A busca do ChatGPT mudou de modelo: toda série de citação no ChatGPT passa a declarar o modelo |
| Pesquisa com fontes | Perplexity Agent API (sucessora do Sonar); o changelog de setembro adiciona glm-5.3-flash | Sonar aposentado em 27/09/2026; glm-5.3-flash a US$ 0,15 de entrada sem cache | Migrar o alias antes de 27/09, ou o braço de pesquisa cai |
Preços em dólar, sem impostos nem câmbio, lidos nas páginas oficiais em 07/09/2026. A coluna da direita é a prova de que a política por propriedade sobrevive: três lançamentos numa semana e nenhuma regra mudou.
Sem consultar o texto, classifique quatro tarefas nas três propriedades (tolerância a erro, custo de verificar, valor do acerto) e decida o nível de executor de cada uma. As tarefas: (a) gerar 300 meta descriptions de páginas de produto; (b) redigir a página institucional 'quem somos' de um cliente do setor de saúde. (c) Extrair, de 80 respostas de IA coletadas, quais concorrentes foram citados em cada uma; (d) montar o JSON-LD de Organization com sameAs para o site do cliente. Para pelo menos duas delas, escreva a frase 'escolhi o nível X porque Y', com o Y sendo uma das três propriedades e não uma intuição.
# Exemplo trabalhado: política de roteamento declarativa.
# O corpo das regras não cita marca. O catálogo de níveis fica isolado no fim,
# e é o único bloco que muda quando o mercado muda.
níveis:
# Fotografia de 07/09/2026, rotulada como tal de propósito. Em setembro o
# catálogo trocou três vezes numa semana e este bloco foi o único editado.
# Reveja a cada trimestre; o resto do arquivo sobrevive sem alteração.
barato: { descrição: "classe econômica de alto throughput" }
médio: { descrição: "classe intermediária de uso geral" }
alto: { descrição: "classe de raciocínio, maior custo por token" }
pesquisa: { descrição: "executor com busca web ativada e citação de fontes" }
# Sonar da Perplexity aposentado em 27/09/2026: o alias de pesquisa aponta
# para a Agent API a partir dessa data, ou o braço de pesquisa cai.
padrão:
nível: barato
# Escolhi barato como padrão porque o custo de um erro no caso NÃO classificado
# é sempre menor que o custo de rodar tudo no nível alto por precaução. Quem
# não define padrão acaba com o mais caro como padrão de fato.
orcamento_por_execucao_usd: 2.00
# Teto da RODADA, não do mês. O laço com defeito é o modo de falha real.
regras:
- nome: volume_baixa_consequencia
quando: { consequência: baixa, verificação: amostral }
nível: barato
escalona: nunca
# Escolhi não escalonar porque em lote grande o escalonamento aplica-se a
# uma fração alta dos itens e o custo total supera rodar tudo no nível médio.
- nome: saida_estruturada_verificavel
quando: { verificador: determinístico }
nível: barato
escalona: [médio, alto]
max_escalonamentos: 2
# Escolhi começar barato porque existe validador de schema: se o JSON não
# valida, eu SEI, sem julgamento humano. O verificador carrega o rigor.
# Limitei a 2 porque a terceira tentativa quase nunca vira, e a cascata sem
# teto é o jeito mais comum de gastar mais do que rodar tudo no nível alto.
- nome: afirmacao_factual_publicada
quando: { consequência: alta, verificação: cara }
nível: alto
revisao_humana: obrigatória
escalona: nunca
# Escolhi ir direto ao nível alto porque o verificador aqui é uma pessoa, e
# o tempo dela é o recurso caro do sistema. Economizar na chamada para gastar
# 40 minutos de revisão é trocar centavos por hora de especialista.
- nome: pesquisa_com_fontes
quando: { exige: busca_web_tempo_real }
nível: pesquisa
# Única regra que cita capacidade em vez de propriedade da tarefa, porque
# busca web é uma funcionalidade que o executor tem ou não tem.
verificação:
gates_deterministicos: [schema_valida, numero_tem_fonte_com_url, acentuacao_e_links]
juiz_llm: conselheiro
# O juiz-LLM opina; os gates decidem. Nenhuma nota do juiz anula um gate
# reprovado (arXiv 2609.02246, 02/09/2026).
resiliência:
circuit_breaker: { falhas_para_abrir: 5, janela_s: 60, meio_aberto_apos_s: 120 }
cache: { chave: hash_do_prompt_normalizado, ttl_h: 24 }
# Cache e circuit breaker vêm ANTES de qualquer sofisticação de scoring.
# Reexecutar tarefa idêntica é o desperdício mais barato de eliminar, e
# insistir contra provedor fora do ar é o jeito mais rápido de queimar o
# orçamento da rodada sem produzir uma linha de saída útil.Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
- Etapa 1 de 4: Fechado
Tráfego normal. O contador de falhas consecutivas roda dentro de uma janela de 60 segundos e zera a cada sucesso.
- Etapa 2 de 4: 5 falhas na janela
Gatilho de abertura. Cinco falhas consecutivas dentro dos 60 segundos indicam indisponibilidade do provedor, e não azar de uma chamada.
- Etapa 3 de 4: Aberto
Bloqueado por 120 segundos. Nenhuma chamada sai. É aqui que o orçamento da rodada é preservado, porque retry cego durante uma queda queima a verba inteira em minutos sem produzir uma linha útil.
- Etapa 4 de 4: Meio aberto
Uma única chamada de sondagem. Sucesso devolve ao estado fechado; falha reabre por mais um intervalo, sem consumir o lote inteiro para descobrir isso.
O contra-exemplo mais caro da orquestração é a cascata sem teto. A intuição diz que começar barato e escalonar só quando reprova é sempre mais econômico, e a conta desmente isso a partir de uma taxa de reprovação relativamente baixa. Se o nível barato reprova em metade dos itens e você escalona duas vezes, uma fração grande do lote paga o custo do barato mais o do médio mais o do alto, e sai mais cara do que se tivesse ido direto ao alto. Meça a taxa real de aprovação de primeira do nível barato para aquele tipo de tarefa antes de assumir que a cascata economiza. E limite o número de escalonamentos, porque a terceira tentativa raramente vira o resultado; ela repete o erro com mais tokens. A segunda armadilha, irmã dessa: retry automático sem circuit breaker durante uma indisponibilidade de provedor consome o orçamento inteiro da rodada em minutos, sem produzir uma única saída aproveitável.
O verificador barato da política costuma ser outro modelo julgando a saída do primeiro, e setembro trouxe o limite disso. Em arXiv 2609.02246 (02/09/2026), Wahi catalogou 11 modos de falha do juiz-LLM em laços de autoavaliação e encontrou agentes com 100% de aprovação do juiz que escondiam 68% de capacidade real. A conclusão que entra na política: o juiz é conselheiro, e o portão que decide publicar é determinístico e não pode ser anulado por ele.
Na prática são três portões que o juiz não abre nem fecha: o JSON valida contra o schema ou não; o número tem fonte com URL ou não; o texto tem acentuação e links íntegros ou não. O modelo-juiz opina sobre clareza e tom, e a opinião dele vai para o revisor humano quando a tarefa é de alta consequência. Um pipeline em que o juiz-LLM é o último portão vira, com o tempo, um gerador de saída degradada aprovada por unanimidade.
Orquestrar ou fazer uma chamada só?
Chamada única basta
Condições que dispensam pipeline
- Volume baixo e tarefa que não se repete.
- O tempo de engenharia para montar o pipeline supera o custo de fazer manualmente.
- Relatório mensal produzido 12 vezes por ano, que não justifica roteamento com fallback, cache e observabilidade.
- Ninguém precisará auditar depois qual executor produziu qual trecho.
Orquestração paga o próprio custo
Condições que justificam pipeline
- Volume repetitivo em lote, onde a economia unitária multiplicada pelo volume supera o custo de manutenção.
- Heterogeneidade real dentro do mesmo fluxo: pesquisa, extração e redação numa mesma rodada, com propriedades diferentes.
- Necessidade de auditoria, quando é preciso saber depois qual executor produziu qual trecho e a que custo.
- Passivo a contabilizar desde o dia um: cada orquestração é código que quebra quando um fornecedor muda o formato da API, como a Perplexity faz em 27/09/2026.
Vale a pena orquestrar este fluxo?
Pontue o fluxo que você tem em mente nas quatro dimensões. A soma é um instrumento de conversa, e não uma medida: ela existe para tornar explícito o que costuma ser decidido por entusiasmo. Ajuste os pesos ao seu contexto e registre a data da leitura ao lado do resultado.
0 para tarefa única no trimestre, 3 para lote recorrente de centenas de itens por semana.
0 quando tudo é a mesma coisa, 3 quando pesquisa, extração e redação convivem na mesma rodada com propriedades diferentes.
0 quando ninguém vai perguntar depois, 3 quando é preciso reconstruir qual executor produziu qual trecho e a que custo.
0 quando não há dono nomeado para o pipeline, 3 quando existe pessoa responsável e cadência de revisão acordada.
Orquestrar aqui cria um passivo de manutenção maior que o problema resolvido. Faça a tarefa na mão ou com um script de uma página, meça o tempo real gasto por mês e volte a este cálculo quando esse tempo incomodar de verdade.
Heurística de praticante para o primeiro mês: implemente na ordem cache, teto de orçamento por rodada, circuit breaker e só então roteamento. Essa ordem parece invertida porque roteamento é a parte interessante, e é justamente por isso que ela costuma vir primeiro e dar errado. Cache elimina o desperdício mais óbvio sem nenhuma decisão difícil. Teto de orçamento converte um bug de laço em um aviso em vez de uma fatura. Circuit breaker impede que uma indisponibilidade externa vire prejuízo interno. Roteamento fino, sem essas três camadas embaixo, otimiza centavos por chamada enquanto o sistema queima dezenas de dólares em tentativas contra um provedor fora do ar.
Desenhe, em meia página, a política de roteamento de um fluxo real seu. Escolha um processo que você repete pelo menos semanalmente, quebre-o em no mínimo três tarefas distintas, classifique cada uma nas três propriedades e atribua um nível de executor. Depois responda a pergunta que separa a teoria da prática: se o nível barato reprovar em 60% dos itens da tarefa mais volumosa, sua política continua sendo a mais barata? Mostre a conta, mesmo grosseira. Se não continuar, ajuste a regra antes de escrever qualquer linha de código.
Nas próximas 48 horas, escolha a tarefa de IA mais repetitiva da sua operação e meça a linha de base antes de otimizar qualquer coisa. Rode 30 itens no executor mais barato disponível, verifique manualmente a saída de todos os 30 e registre a taxa de aprovação de primeira. Critério de sucesso: você termina com um número, e não com uma impressão, e decide com ele entre três caminhos: rodar tudo no nível barato com verificação amostral, montar uma cascata com teto de dois escalonamentos, ou ir direto ao nível alto. Guarde esse número com a data. Ele será a sua régua quando a próxima geração de modelos sair.
Faça agora (15 min)
Cinco perguntas que a pessoa que decide faz a quem opera, por escrito, e que bastam para aprovar ou recusar a orquestração com número.
Passo 1: Liste os fluxos de IA que rodam hoje e o dono de cada um
Um fluxo sem dono nomeado não é candidato a orquestração; é candidato a chamada única com planilha ao lado.
Deu certo quando: Uma lista com nome de pessoa em cada linha.
Erro comum: Colocar 'o time' como dono.
Passo 2: Peça a taxa de aprovação de primeira do nível barato
Para o fluxo mais volumoso, pergunte a quem opera: em quantos itens foi medida e qual foi a taxa. Sem essa medida, a cascata é aposta.
Deu certo quando: Um percentual com o número de itens ao lado.
Erro comum: Aceitar 'funciona bem' como taxa.
Passo 3: Pergunte a data do catálogo de modelos
Peça o arquivo em que os nomes de modelo vivem e a data da última revisão. Se a política cita marca no corpo das regras, ela apodreceu com os lançamentos de 01 a 03/09/2026.
Deu certo quando: Um arquivo só, com data de setembro.
Erro comum: Política com nome de modelo espalhado em cada regra.
Passo 4: Confirme os três guarda-corpos
Cache, teto de orçamento por rodada e circuit breaker existem e têm parâmetro escrito? Se algum falta, ele entra antes de qualquer roteamento novo.
Deu certo quando: Três respostas 'sim', cada uma com o parâmetro.
Passo 5: Confira a data de 27/09 para quem usa Perplexity
Se algum fluxo de pesquisa chama os endpoints Sonar, a migração para a Agent API entra no calendário desta semana.
Deu certo quando: Migração agendada, ou a confirmação de que ninguém usa o Sonar.
Erro comum: Descobrir em 28/09 pelo erro no log.
No fim você tem: a lista de fluxos com dono, a taxa de aprovação medida do fluxo mais volumoso, a data do catálogo de modelos e os três guarda-corpos confirmados, o suficiente para aprovar ou recusar a orquestração com número.
Resumo em três linhas: Orquestrar compensa só com volume repetido, tarefas heterogêneas no mesmo fluxo e dono nomeado; fora disso, uma chamada única resolve mais barato. A política escolhe o nível de modelo pela tolerância a erro, pelo custo de verificar e pelo valor do acerto, e os nomes de modelo vivem num único arquivo datado, que setembro obrigou a reescrever três vezes numa semana. Na segunda-feira, peça a quem opera a taxa de aprovação de primeira do nível barato, a data do catálogo e a confirmação de cache, teto de orçamento e circuit breaker.