Subagentes e orquestração: quando um agente só não basta

Uma empresa automatiza um processo inteiro com um único agente: ele lê a solicitação, pesquisa, decide, redige, formata e envia. Funciona bem enquanto o processo é simples. Conforme cresce (mais etapas, mais exceções, mais contexto acumulado ao longo da execução), o mesmo agente começa a confundir uma etapa com outra, perder instruções dadas lá no início, gastar cada vez mais tokens processando o próprio histórico e, eventualmente, produzir um resultado que mistura decisões de etapas diferentes de um jeito difícil de rastrear.

O instinto comum é trocar para um modelo mais capaz. Às vezes ajuda um pouco. O problema estrutural continua, porque a causa está mais no excesso de responsabilidade concentrada num único agente, com um único contexto tentando fazer tudo ao mesmo tempo, do que na capacidade do modelo escolhido.

Quando um agente sozinho não basta

Alguns sinais indicam que um processo passou do ponto em que um agente único resolve bem:

• Etapas que exigem critérios diferentes: pesquisar exige tolerância a ambiguidade, redigir exige precisão de formato, revisar exige ceticismo em relação ao próprio resultado anterior. Pedir que o mesmo agente, no mesmo contexto, alterne entre esses modos tende a produzir uma mistura de todos, sem se destacar em nenhum.
• Contexto que deveria ficar separado, mas se acumula junto: informação da etapa um contaminando a decisão da etapa três, porque tudo ficou na mesma janela desde o início.
• Etapas que poderiam rodar em paralelo, mas rodam em fila porque estão presas dentro de um único fluxo sequencial.

Nenhum desses sinais aparece num teste rápido com um caso simples. Eles aparecem quando o processo real, com suas exceções e seu volume, começa a rodar de verdade.

Particionar o trabalho

Particionar significa dividir o processo em agentes menores, cada um com escopo claro e contexto próprio, em vez de um agente generalista carregando o processo inteiro. É o mesmo raciocínio por trás de dividir um time humano em funções: não porque uma pessoa não seria capaz de aprender tudo, mas porque separar responsabilidades reduz erro e permite que cada parte seja revisada e melhorada de forma independente.

Exemplo prático: um processo de triagem e resposta a solicitações de clientes pode ser dividido em um agente que classifica a solicitação (rápido, contexto pequeno, decisão simples), um agente que busca a informação necessária para responder (acesso a sistemas internos, contexto médio), e um agente que redige a resposta final no tom e formato certos (contexto pequeno, mas alto padrão de qualidade de texto). Cada um faz uma coisa, com um contexto dimensionado para aquela coisa, em vez de um único agente carregando classificação, busca e redação na mesma janela do início ao fim.

Contratos entre agentes

Dividir o trabalho só funciona se a passagem de um agente para o outro for previsível. Um contrato entre agentes define exatamente o que um agente entrega ao próximo: quais campos, em que formato, o que fazer quando uma informação não está disponível. Sem isso, dividir o processo troca um problema por outro: em vez de um agente confuso fazendo tudo, dois ou três agentes cada um interpretando à sua maneira o que o anterior quis dizer.

Na prática, isso significa tratar a saída de cada subagente como uma interface, do mesmo jeito que duas partes de um sistema de software trocam dados por um formato acordado, não por texto livre que a próxima etapa precisa adivinhar como interpretar. Quando o contrato é explícito, um erro fica visível na hora (o campo esperado não veio, o formato não bate), em vez de se espalhar silenciosamente pelas etapas seguintes.

Validação humana: onde colocar o ponto de parada

Nem toda etapa de um processo automatizado deveria seguir sem revisão. Um gate humano é um ponto definido do fluxo onde uma pessoa confirma antes de o processo continuar, especialmente antes de ações que são caras de reverter: enviar algo externamente, gastar dinheiro, alterar um registro que afeta terceiros.

Definir onde colocar esse ponto é uma decisão de desenho, não um detalhe técnico. Colocar demais gates deixa o processo tão lento quanto fazer tudo manualmente, o que anula o ganho da automação. Colocar poucos, ou nenhum, transfere para o agente decisões que talvez devessem continuar sendo humanas, sobretudo quando o custo de um erro é alto e a reversão é difícil. O critério prático costuma ser: automatizar as etapas de alto volume e baixo risco por decisão, e manter revisão humana nas etapas de baixo volume e alto risco por decisão.

Roteamento de modelo por complexidade

Nem toda etapa de um processo precisa do modelo mais capaz disponível. Classificar uma solicitação num conjunto pequeno de categorias é uma tarefa mais simples do que redigir uma resposta que representa a empresa perante um cliente. Usar o mesmo modelo, no nível mais alto de capacidade, para as duas coisas gasta orçamento na etapa simples sem necessidade.

Rotear por complexidade significa reservar o modelo mais capaz (e mais caro) para as etapas que exigem raciocínio mais elaborado ou julgamento mais fino, e usar modelos mais leves nas etapas estruturadas, repetitivas ou de decisão simples. O particionamento do trabalho, feito para separar responsabilidades, também abre essa possibilidade: uma vez que cada subagente tem uma tarefa bem definida, fica claro qual delas realmente precisa de mais capacidade e qual não precisa.

No exemplo da triagem de solicitações, classificar a categoria de um pedido costuma ser uma decisão estruturada, com um conjunto pequeno e conhecido de opções, o tipo de tarefa em que um modelo mais leve tende a ter desempenho equivalente a um modelo mais caro por uma fração do custo. Redigir a resposta final que o cliente vai ler já pede mais nuance, tom adequado e sensibilidade ao contexto da solicitação, o que justifica reservar ali o modelo de maior capacidade disponível. O ganho de custo não vem de usar um modelo mais barato em tudo, vem de usar o modelo certo em cada etapa.

Quanto particionar é demais

Particionar resolve o problema de um agente sobrecarregado, mas não é uma regra a aplicar sem limite. Cada divisão nova entre agentes introduz uma passagem de bastão, e cada passagem de bastão é um ponto onde informação pode se perder ou um contrato pode ser mal interpretado. Um processo dividido em muitos subagentes pequenos, cada um fazendo uma fração mínima do trabalho, troca o problema de um agente confuso pelo problema de coordenar várias peças pequenas, o que tem seu próprio custo de desenho, de revisão e de manutenção.

O critério prático para saber se uma divisão faz sentido é perguntar se cada parte resultante tem um motivo real para existir separada: um critério de qualidade diferente, uma fonte de dados diferente, uma necessidade de rodar em paralelo, ou um ponto onde faz sentido colocar validação humana. Dividir por dividir, sem que exista essa diferença real entre as partes, tende a adicionar complexidade de coordenação sem reduzir o risco que motivou a divisão em primeiro lugar.

O princípio central: o desenho vale mais que a execução

O ponto mais importante de tudo isso é de processo, acima de qualquer escolha técnica: a forma como o trabalho é dividido, os contratos entre as partes e onde fica o ponto de validação humana determinam o resultado muito mais do que a escolha de qual modelo executa cada etapa.

Um processo mal desenhado, com responsabilidades confusas entre as etapas e sem contrato claro entre elas, continua mal desenhado mesmo trocando para o modelo mais capaz disponível: ele só vai produzir o mesmo resultado ambíguo mais rápido e, em muitos casos, mais caro. Por outro lado, um processo bem desenhado, com etapas separadas por responsabilidade real, contratos explícitos e um gate humano no lugar certo, funciona bem mesmo com modelos mais simples nas etapas que não exigem sofisticação.

Isso inverte a pergunta que costuma abrir um projeto de automação. Em vez de "qual modelo usamos", a pergunta que define o resultado é "como esse processo deveria ser dividido, quem confirma o quê entre as partes e onde uma pessoa precisa validar antes de seguir". A escolha de modelo vem depois, e é uma decisão bem mais barata de corrigir do que um desenho de processo malfeito.

Próximo passo

Antes de adicionar mais um agente a um processo que já não está funcionando bem, vale parar e desenhar o processo no papel: quais etapas existem de verdade, o que cada uma recebe e entrega, onde uma pessoa precisa confirmar. Esse desenho, feito antes de qualquer linha de configuração de agente, costuma ser o que separa uma automação que se paga de uma que só troca um problema manual por um problema automatizado, e é o ponto de partida de um diagnóstico de automação de processos com IA.