In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks

1. Declaração do Problema

O artigo aborda a crescente complexidade e os problemas de confiabilidade associados aos Frameworks de Orquestração de Agentes (por exemplo, LangGraph, CrewAI, Google ADK, OpenAI Agents SDK). Esses frameworks tipicamente empregam um controlador externo (orquestrador) que se situa acima do Modelo de Linguagem de Grande Porte (LLM). O orquestrador rastreia o estado da conversa, gerencia um grafo direcionado de etapas de fluxo de trabalho e injeta instruções de roteamento específicas ou prompts específicos de nó a cada turno.

Os autores argumentam que essa arquitetura introduz uma sobrecarga de engenharia significativa, erros em cascata, falhas de roteamento e baixa consistência entre tentativas. Eles hipotetizam que, para tarefas procedimentais (conversas que seguem um fluxo de trabalho definido desde a entrada até a resolução), os LLMs de fronteira modernos possuem capacidades de raciocínio suficientes para auto-orquestrar-se quando fornecida a totalidade do procedimento em seu contexto, tornando a orquestração externa desnecessária e potencialmente prejudicial.

2. Metodologia

O estudo emprega uma comparação empírica controlada entre duas condições usando o mesmo modelo de fronteira (Claude Sonnet 4.5) em três domínios distintos com complexidade variável:

1. Reserva de Viagens: 14 nós, 3 hubs de decisão.
2. Suporte Técnico Zoom: 14 nós, 3 hubs de decisão (requer precisão técnica).
3. Processamento de Sinistros de Seguros: 55 nós, 6 hubs de decisão (alta complexidade com loops aninhados).

Condições Experimentais:

• Condição A (Orquestrada pelo LangGraph): O fluxo de trabalho é implementado como um grafo direcionado no LangGraph. O orquestrador gerencia o estado, toma decisões de roteamento por meio de chamadas adicionais de LLM nos hubs de decisão e injeta modelos de prompts específicos de nó no prompt do sistema a cada turno.
• Condição B (Linha de Base In-Context): O modelo recebe o fluxograma serializado completo (todos os nós, arestas, condições e estados terminais) em seu prompt do sistema. O modelo auto-orquestra-se, determinando a próxima etapa e roteando internamente, sem rastreamento de estado externo ou chamadas de roteamento.

Configuração de Avaliação:

• Dados: 200 conversas simuladas por condição por domínio ($N=1.200$ no total).
• Simulador: Um simulador de usuário (acionado pelo Claude Sonnet) gera respostas dinâmicas baseadas no histórico da conversa, sem conhecimento do fluxograma subjacente.
• Julgamento: As conversas foram avaliadas por um LLM como Juiz (inicialmente Claude Sonnet, replicado com GPT-4.1) em cinco critérios:
  1. Sucesso na Tarefa (Conclusão procedimental)
  2. Precisão da Informação
  3. Consistência (Coerência do estado)
  4. Tratamento Elegante (Adaptabilidade a ambiguidades/casos extremos)
  5. Naturalidade (Interação semelhante à humana)

3. Principais Contribuições

• Evidência Empírica de Obsolescência: Demonstra que, para tarefas procedimentais, uma abordagem simples de prompting in-context supera consistentemente frameworks complexos de orquestração em todas as métricas de qualidade.
• Análise de Modos de Falha: Identifica que a orquestração introduz modos de falha estruturais específicos (erros de roteamento, raciocínio fragmentado, conflitos de modelos) que não existem na abordagem in-context.
• Análise de Eficiência: Quantifica o trade-off entre o uso de tokens (maior no in-context devido à inclusão do procedimento) e a eficiência das chamadas de API (menor no in-context devido à falta de sobrecarga de roteamento).
• Verificação de Robustez: Valida as descobertas usando um juiz independente (GPT-4.1) para descartar o viés de auto-preferência no juiz principal.

4. Resultados

A. Desempenho de Qualidade

A linha de base in-context superou significativamente o orquestrador LangGraph em 15 de 15 comparações (3 domínios × 5 métricas) sob o juiz Claude, com todas as diferenças estatisticamente significativas ($p < 0,005$).

• Pontuações: As pontuações in-context variaram de 4,53 a 5,00, enquanto as pontuações do LangGraph variaram de 4,17 a 4,84.
• Consistência e Tratamento Elegante: A lacuna foi mais pronunciada aqui. O modelo in-context manteve uma coerência quase perfeita (4,83–4,99) e adaptabilidade (4,96–5,00), enquanto o sistema orquestrado lutou (4,32–4,55 e 4,38–4,62, respectivamente).
• Replicação: Usar o GPT-4.1 como juiz confirmou as descobertas principais: 11 de 15 comparações favoreceram o prompting in-context, com zero favorecendo a orquestração. A lacuna de "Naturalidade" diminuiu na avaliação do GPT-4.1, sugerindo que o juiz Claude pode ter um viés em direção a texto não restrito.

B. Taxas de Falha

O sistema orquestrado falhou significativamente mais vezes (definido como Sucesso na Tarefa ≤ 3):

• Viagens: 24,0% de falha (LangGraph) vs. 11,5% (In-Context).
• Zoom: 9,0% de falha (LangGraph) vs. 0,5% (In-Context).
• Seguros: 17,0% de falha (LangGraph) vs. 5,0% (In-Context).
• Causas Raiz: As falhas orquestradas foram atribuídas a erros de roteamento (classificação incorreta do estado da conversa nos hubs de decisão), perda de informação através das fronteiras dos nós e loops infinitos causados pelo agente perder o controle das fases concluídas.

C. Eficiência e Custo

• Chamadas de API: A orquestração exigiu 1,2x a 1,7x mais chamadas de LLM por conversa devido às decisões de roteamento nos hubs de decisão.
• Uso de Tokens: O prompting in-context consumiu mais tokens por conversa (por exemplo, 68K vs. 43K para Seguros) porque o procedimento serializado foi incluído em cada chamada de API.
• Custo: Apesar do maior uso de tokens, a abordagem in-context foi apenas 1,3x–1,4x mais cara por conversa. O prêmio de custo é modesto em comparação com os ganhos significativos em qualidade e confiabilidade.

5. Significado e Implicações

• Mudança de Paradigma: O artigo sugere que, para tarefas procedimentais bem definidas, a "estrutura" fornecida por frameworks de orquestração não é mais necessária para modelos de fronteira. Na verdade, essa estrutura degrada ativamente o desempenho ao fragmentar o raciocínio do modelo e introduzir pontos de falha.
• Recomendação de Engenharia: Os praticantes devem priorizar colocar o procedimento inteiro no prompt do sistema antes de recorrer a frameworks complexos de orquestração. Isso simplifica a pilha tecnológica, reduz a latência (menos chamadas de API) e melhora a confiabilidade.
• Limitações e Trabalho Futuro:
  • As descobertas aplicam-se especificamente a tarefas procedimentais com fluxos de trabalho definidos. Tarefas não procedimentais (criativas, abertas) ou pipelines de múltiplos modelos ainda podem se beneficiar da orquestração.
  • A abordagem exige que o procedimento caiba dentro da janela de contexto do modelo (embora procedimentos de 55 nós tenham usado apenas ~2% de uma janela de 200K tokens).
  • Para produção de alto volume, o custo de tokens mais elevado do prompting in-context pode motivar o ajuste fino do procedimento em modelos menores como uma alternativa custo-efetiva.

Conclusão: Os autores concluem que, à medida que os modelos de fronteira melhoram, o valor da orquestração externa para tarefas procedimentais diminui. O "gargalo" não é uma orquestração melhor; a própria orquestração é o gargalo.