Padrões agênticos e context engineering
- ⬜🛠️ Tool use profissional: desenhar o contrato entre modelo e sistema(AWS Bedrock — GenAI em Produção)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
A palavra "agent" virou guarda-chuva para coisas com custos e riscos radicalmente diferentes. Um roteador que classifica um chamado e um sistema que investiga um incidente sozinho por vinte minutos são chamados da mesma coisa em reunião — e não são a mesma coisa em nenhum aspecto que importe: custo, latência, previsibilidade, testabilidade. Este módulo dá a taxonomia profissional, o critério honesto de quando não construir um agent, e o que acontece com o contexto ao longo de um laço longo — que é onde a qualidade e a conta se deterioram juntas.
A distinção que organiza tudo: workflow ou agent?
Em um workflow, o caminho é definido por você em código; o modelo preenche as etapas. Em um agent, o modelo decide o próximo passo e quando parar. A diferença não é de sofisticação — é de quem detém o controle de fluxo, e é isso que determina se você consegue testar, prever custo e explicar o comportamento depois.
| Dimensão | Workflow | Agent |
|---|---|---|
| Controle de fluxo | Seu código | O modelo |
| Custo por execução | Previsível — dá para estimar antes | Variável; a cauda longa é o que assusta na fatura |
| Latência | Estável | Depende de quantos passos o modelo decidir dar |
| Testabilidade | Alta: cada etapa é testável isoladamente | Baixa: você testa comportamento, não caminho |
| Depuração | Você sabe onde quebrou | Precisa reconstituir a trajetória a partir do log |
| Onde brilha | Tarefa conhecida e decomponível | Tarefa aberta, cujos passos dependem do que se descobre no caminho |
A regra que economiza trimestres
Comece no padrão mais simples que resolve e suba um degrau só quando a evidência exigir. A maior parte dos casos corporativos que hoje roda como agent seria mais barata, mais rápida e mais confiável como workflow — e o time só descobre isso depois de operar seis meses. Autonomia é uma escolha cara: use onde ela paga.
Você realmente precisa de um agent? Os quatro critérios
Um "não" em qualquer um dos quatro derruba o caso
Os critérios são conjuntivos, não uma pontuação. Tarefa complexa e valiosa, mas com erro irreversível e indetectável, não deve virar agent — deve virar workflow com humano no laço. Alta viabilidade e baixo valor não paga o custo operacional. Rodar esses quatro numa reunião de trinta minutos evita a maior parte dos projetos de agent que morrem no semestre seguinte.
Os seis padrões, do mais barato ao mais caro
Estes são os padrões que cobrem praticamente todo sistema de IA em produção. Os cinco primeiros são workflows — o caminho é seu. O sexto é o agent propriamente dito. A coluna de custo é o multiplicador relativo típico contra uma chamada única para a mesma tarefa; use como ordem de grandeza para decidir, e meça no seu caso.
| Padrão | Como funciona | Custo relativo e quando usar |
|---|---|---|
| Chamada única | Um prompt, uma resposta | 1× — classificar, extrair, resumir, responder com contexto pronto |
| Encadeamento | Saída de um passo vira entrada do próximo, com verificação entre eles | 2–4× — tarefa decomponível em etapas fixas; permite validar no meio |
| Roteamento | Um classificador barato escolhe o especialista (ou o tier) certo | 1,1× — e frequentemente ECONOMIZA: manda o fácil para o modelo barato |
| Paralelização | Divide em partes independentes, ou pede N opiniões e agrega | N× em tokens, 1× em tempo — revisão multi-critério, votação em decisão sensível |
| Orquestrador-trabalhadores | Um coordenador decide a divisão em tempo de execução e delega | 5–15× — trabalho amplo cujas subtarefas você não conhece de antemão |
| Avaliador-otimizador | Gera, critica com outro papel, refaz até passar no critério | 3–10× — tradução, redação e código, onde há critério claro de qualidade |
| Agent autônomo | Laço aberto: o modelo decide passos e parada, usando ferramentas | 10× ou mais, com cauda longa — investigação, tarefa exploratória |
Roteamento é o único padrão que costuma reduzir a conta
Todos os outros somam chamadas. O roteamento acrescenta uma classificação baratíssima na frente e, em troca, manda a maior fatia do volume para o modelo barato — e só o que é difícil para o caro. É a primeira estrutura a montar em qualquer sistema com variedade de perguntas, e volta com força no playbook de custo como a alavanca de maior impacto depois do cache.
Roteamento em cascata na prática
A cascata pode sair mais cara — faça a conta
Se metade do volume escala, você está pagando o caminho barato inteiro mais metade do caro, e provavelmente perdendo para simplesmente usar o modelo caro direto. Antes de montar cascata, meça a taxa de escalada num piloto: abaixo de ~20% ela costuma valer muito a pena; acima de ~40% quase nunca vale. E acompanhe esse número em produção — ele deriva com o tempo, conforme o mix de perguntas muda.
Avaliador-otimizador: o laço que melhora de verdade
"Peça para o modelo revisar a própria resposta" é um conselho que funciona menos do que parece — o mesmo contexto que produziu o erro tende a produzir a mesma avaliação. O padrão que funciona separa os papéis: o avaliador recebe um critério explícito e devolve um veredito estruturado, e o gerador refaz com o feedback. E, principalmente, o laço tem teto.
import json
MAX_TENTATIVAS = 3 # teto duro: sem isso o laco vira incidente de custo
RUBRICA = """Avalie a traducao segundo estes criterios objetivos:
1. Nenhum numero, data ou nome proprio alterado.
2. Termos do glossario corporativo respeitados.
3. Registro formal mantido.
4. Nenhuma frase do original omitida.
Responda com aprovado true/false e, se false, o que corrigir."""
ESQUEMA_VEREDITO = {
"type": "object",
"properties": {
"aprovado": {"type": "boolean"},
"problemas": {
"type": "array",
"items": {
"type": "object",
"properties": {
"criterio": {"type": "integer"},
"trecho": {"type": "string"},
"correcao": {"type": "string"},
},
"required": ["criterio", "trecho", "correcao"],
},
},
},
"required": ["aprovado", "problemas"],
}
def traduzir_com_revisao(texto, tier_volume, tier_raciocinio):
feedback = None
candidato = None
for tentativa in range(MAX_TENTATIVAS):
# Gerador: barato. Refaz com o feedback da rodada anterior.
candidato = gerar(texto, feedback, modelo=tier_volume)
# Avaliador: papel separado, criterio explicito, saida estruturada.
# NAO recebe o historico do gerador — contexto limpo avalia melhor.
veredito = avaliar(texto, candidato, RUBRICA,
esquema=ESQUEMA_VEREDITO, modelo=tier_raciocinio)
if veredito["aprovado"]:
return {"texto": candidato, "tentativas": tentativa + 1}
feedback = json.dumps(veredito["problemas"], ensure_ascii=False)
# Nao convergiu: entregue com marca, nunca finja que passou.
return {"texto": candidato, "tentativas": MAX_TENTATIVAS,
"revisao_humana": True, "pendencias": feedback}
Três detalhes que fazem o padrão funcionar
O avaliador não recebe o histórico do gerador — contexto limpo avalia melhor e evita que a justificativa anterior contamine o julgamento. O critério é uma rubrica objetiva, não "está bom?": critério vago produz aprovação vaga. E o laço tem teto com saída marcada: se não convergiu em três rodadas, entregue sinalizando revisão humana em vez de girar. Sem o teto, um caso patológico consome tokens até o limite.
Uma tarefa de classificação de chamados tem caminho conhecido: extrair campos, classificar em uma de oito categorias e rotear. O time quer implementar como agent autônomo para ficar mais flexível. Qual é a avaliação correta?
Orquestrador-trabalhadores e o custo da delegação
É o padrão mais poderoso e o mais fácil de usar errado. Um coordenador decide, em tempo de execução, como dividir o trabalho, despacha subagents e junta os resultados. Ele brilha quando as subtarefas são genuinamente independentes e amplas — varrer muitos arquivos, checar muitos candidatos, investigar frentes distintas.
Quatro dos cinco passos são overhead
Delegar uma tarefa que o coordenador resolveria em três chamadas de ferramenta é quase sempre prejuízo: você paga briefing, reestabelecimento de contexto, relatório e integração para economizar um trabalho que era pequeno. Delegue por amplitude e independência, não por organização mental. E ponha um teto explícito no número de subagents — a ausência dele é uma das formas mais rápidas de transformar um dia de testes numa fatura memorável.
- Delegue quando as frentes são independentes e cada uma é grande o suficiente para pagar o overhead de contexto.
- Não delegue verificação: revisar o próprio trabalho é mais barato no laço principal, e o subagent verificador tende a concordar.
- Briefe bem na primeira vez — lançar, esperar e re-briefar dobra o custo da delegação.
- Se delegou, confie: refazer ou re-derivar o resultado do subagent joga fora tudo que você pagou.
- Dispare os subagents independentes de uma vez, não em série — o ganho do padrão é de tempo de parede.
- Ponha teto no número de subagents por execução, e alerte quando o teto for atingido.
Context engineering: o que degrada num laço longo
Num agent, o contexto cresce a cada turno: mais resultados de ferramenta, mais raciocínio, mais histórico. E ele cresce de forma quadrática no custo — porque cada turno reenvia tudo que veio antes. Junto com o custo, a qualidade cai: informação relevante se dilui, instruções antigas competem com novas, e resultados obsoletos continuam sendo apresentados como se fossem verdade atual.
| Técnica | O que faz | Quando aplicar |
|---|---|---|
| Limpeza de contexto | Remove resultados de ferramenta antigos e raciocínio já consumido | Laços com muitas chamadas cujos resultados intermediários não são mais necessários |
| Compactação | Resume o histórico antigo em um bloco e continua a partir dele | Conversas longas que se aproximam do limite da janela |
| Memória externa | O agent escreve o que aprendeu em arquivo ou store e relê depois | Trabalho que atravessa sessões, ou contexto que precisa sobreviver ao laço |
| Subagent como isolamento | Explorar num contexto separado e trazer só a conclusão | Investigação ampla cujo detalhe não precisa poluir o laço principal |
| Disciplina de resultado | Truncar e resumir o retorno da ferramenta antes de devolvê-lo | Sempre — é a medida mais barata e a mais esquecida |
| Teto de rodadas | Encerrar o laço com mensagem clara ao atingir o limite | Sempre — é o disjuntor do sistema |
Compactação e limpeza não são a mesma coisa
Limpeza remove: os resultados antigos somem do histórico. Compactação resume: eles viram um bloco condensado que continua no contexto. Use limpeza quando o detalhe já não importa (o log que você leu há dez passos) e compactação quando a linha do raciocínio precisa sobreviver. Aplicar as duas ao mesmo tempo sem critério é como o agent perde o fio e recomeça a investigação do zero — pagando de novo pelo que já tinha descoberto.
A ordem certa de otimizar um laço caro
Primeiro corte o tamanho dos resultados de ferramenta (quase sempre é aí que está o volume). Depois estabilize o prefixo para o cache trabalhar. Depois reduza rodadas melhorando as descrições das ferramentas. Só então mexa em limpeza e compactação, que são as mais complexas e as que mais arriscam qualidade. Times costumam fazer na ordem inversa.
Onde cada padrão roda na AWS
| Padrão | Implementação natural no Bedrock | Observação |
|---|---|---|
| Chamada única | Lambda chamando Converse | Nada mais é necessário |
| Encadeamento | Lambda em sequência, ou Bedrock Flows para fluxo visual | Flows facilita quando quem mantém não é o time de engenharia |
| Roteamento | Classificador barato no gateway, ou roteamento inteligente de prompt | O gateway é o lugar certo: a política de tier fica centralizada |
| Paralelização | Step Functions com estado de mapa, ou disparo concorrente na Lambda | Cuidado com quota de invocação por região no pico |
| Orquestrador-trabalhadores | AgentCore Runtime, ou Step Functions coordenando Lambdas | Ponha teto no fan-out desde o primeiro dia |
| Avaliador-otimizador | Laço na Lambda ou Step Functions com contador de tentativas | Encerre com marca de revisão humana quando não convergir |
| Agent autônomo | AgentCore Runtime com Memory, Gateway e Observability | Sessão longa, memória isolada por usuário e trilha completa |
- → classificar antes de tudo é o que barateia
- → a maior parte do volume termina aqui
- → escalada por exceção: acima de ~40% a cascata perde
- → avaliador com contexto limpo julga melhor
- Rede e entrega
- Compute
- Integração de apps
- IA e machine learning
- Gestão e governança
Repare que só o roteamento reduz a conta: ele põe um classificador barato na frente e manda a maior parte do volume para o tier de volume. Todos os outros padrões somam chamadas.
- Roteamento primeiro — o único que economiza. Um classificador de poucos tokens na frente, e a maior parte do volume resolve no tier de volume. Acompanhe a taxa de escalada: abaixo de ~20% compensa muito; acima de ~40%, quase nunca.
- Encadeamento quando as etapas são fixas. Caminho conhecido e decomponível: você escreve os passos e valida entre eles. Custo previsível e cada etapa testável isoladamente.
- Paralelização por tempo, não por custo. Divide em partes independentes ou pede N opiniões. Multiplica tokens e mantém o tempo de parede — vale quando a latência importa mais que o custo.
- Avaliador-otimizador com papéis separados. O avaliador recebe rubrica objetiva e NÃO recebe o histórico do gerador. E o laço tem teto: sem ele, um caso patológico gira até o limite.
- Delegar só por amplitude. Orquestrador-trabalhadores brilha em frentes genuinamente independentes. Quatro dos cinco passos de uma delegação são overhead de contexto.
- Agent autônomo por último. Laço aberto: o modelo decide passos e parada. Precisa de teto de rodadas, memória e observabilidade de trajetória — e de compute que não esbarre no teto de execução.
Anti-padrões agênticos
- Agent onde cabia workflow: o caminho era conhecido e você pagou autonomia para redescobri-lo a cada execução.
- Laço sem teto de rodadas: o disjuntor mais barato do sistema e o mais frequentemente ausente.
- Sem teto de subagents: fan-out sem limite transforma um bug num incidente de custo.
- Auto-verificação com o mesmo contexto: o modelo aprova o próprio erro, porque a premissa errada continua ali.
- Resultados de ferramenta gordos: o histórico infla e é reenviado a cada turno, com custo quadrático.
- Trocar o conjunto de tools no meio da conversa: invalida o cache e reprocessa tudo a preço cheio.
- Escalar sempre para o tier caro em caso de dúvida: a cascata só paga se a maioria termina embaixo.
- Nenhuma métrica por execução: sem tokens por execução concluída, você não sabe se o agent melhorou ou só ficou mais falante.
Você montou uma cascata: classificador barato, tentativa no tier de volume e escalada para o tier de raciocínio quando a confiança é baixa. Medindo em produção, 55% das requisições escalam. O que isso significa?
Um agent de investigação ficou lento e caro depois de crescer de 4 para 12 rodadas médias. Qual é a primeira coisa a atacar?
Próximo passo
Todo padrão deste módulo tem a mesma pergunta por baixo: como você sabe que ficou bom? E a versão cara dela: como você troca para um modelo mais barato sem descobrir a regressão pelo cliente? É o próximo módulo — evals — e ele é o pré-requisito técnico do playbook de custo que vem em seguida.
Perguntas frequentes
❓ Qual a diferença entre fluxo e agente?
❓ Quando paralelizar e quando encadear?
❓ Como manter o contexto do agente sob controle?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…