Quando um produto precisa de múltiplos agentes

Um produto precisa justificar múltiplos agentes pela tarefa e pela forma de coordenação, não pela quantidade de papéis que consegue nomear. Antes de dividir o trabalho, descreva quais partes podem avançar separadamente, quais decisões precisam de contexto comum e como o resultado será verificado. Se um fluxo simples resolve a tarefa com os mesmos critérios, a arquitetura com vários agentes ainda precisa demonstrar por que merece ser mantida.

Separe divisão de trabalho e autonomia

Ter etapas diferentes não exige que cada uma seja um agente. Uma sequência conhecida pode ser implementada como fluxo predefinido. Um agente envolve escolha dinâmica de passos e ferramentas durante a execução.

A Anthropic sobre padrões de agentes diferencia esses arranjos e recomenda começar pela solução mais simples, acrescentando complexidade quando necessária. Essa distinção permite comparar alternativas antes de distribuir a tarefa entre vários componentes autônomos.

Proponha primeiro uma descrição sem nomes de agentes. Por exemplo: localizar documentos, verificar sua pertinência, extrair informações e produzir uma síntese. Depois pergunte em quais pontos o caminho precisa ser escolhido dinamicamente e em quais basta aplicar uma regra ou etapa conhecida.

Identifique uma fronteira de trabalho que possa ser verificada

A divisão fica mais clara quando cada parte tem entrada, saída e critério de aceite. Se todas precisam interpretar o objetivo inteiro e alterar o mesmo estado, a separação pode apenas deslocar o problema para a coordenação.

Examine quatro perguntas:

• As partes trabalham sobre dados ou artefatos suficientemente distintos?
• Uma saída pode ser verificada antes de entrar no resultado final?
• Há uma regra para resolver informações contraditórias?
• Está definido quem pode alterar o estado compartilhado?

Essas perguntas são critérios de desenho, não uma fórmula universal para escolher arquitetura. Uma resposta fraca indica qual dependência precisa ser compreendida antes de aumentar a autonomia.

Descreva a coordenação como parte do produto

Uma arquitetura com vários agentes precisa explicitar quem distribui trabalho, como recebe resultados, quando pede nova tentativa e em que condição encerra a tarefa. “Os agentes conversam entre si” não define um comportamento operacional suficiente.

Registre também como a execução reage a atraso, resposta incompleta ou discordância. Pode ser necessário seguir com resultado parcial, pedir revisão humana, restringir a ação ou interromper. A alternativa depende da tarefa e do efeito sobre o usuário.

Inclua a coordenação na observação. Conte tentativas, chamadas, transferências de contexto e revisões necessárias para chegar ao resultado. Não compare apenas o tempo de uma etapa isolada se o usuário espera pela tarefa completa.

Exemplo fictício: preparar uma síntese de documentos

Imagine um produto que ajuda uma equipe a preparar uma síntese de documentos de um projeto. Uma proposta distribui grupos de documentos para componentes separados e reúne as extrações em um texto final. Outra utiliza um único fluxo que processa os grupos em sequência.

A avaliação precisa verificar se os documentos relevantes foram considerados, se as contradições ficaram visíveis e se a síntese preservou a origem das informações. A divisão por grupos pode ser uma hipótese útil quando as partes podem ser verificadas separadamente. Não prova, por si só, que serão necessários agentes autônomos.

Se cada parte interpreta termos de forma diferente, a coordenação precisa lidar com isso. Se o resultado final esconde divergências, o problema não foi resolvido apenas porque todas as etapas terminaram. O exemplo ilustra o que comparar, sem presumir ganho de velocidade ou qualidade.

Compare com uma alternativa mais simples

Use a mesma tarefa e critérios para examinar um fluxo predefinido, um agente único ou a composição proposta. Documente quais ajustes pertencem a cada alternativa e quais condições foram mantidas.

A Microsoft ExP descreve a experimentação como uma forma de validar hipóteses, medir impacto e iterar produtos. Aqui, a hipótese pode ser que a divisão melhore um comportamento específico sem piorar condições importantes da operação. Defina esse comportamento antes da comparação.

Observe se a coordenação ajuda a resolver uma necessidade real ou apenas cria mais pontos de passagem. Se o problema principal está na qualidade do contexto, multiplicar participantes não elimina a necessidade de corrigir essa informação. Se está no critério de sucesso, distribua esse critério com clareza antes de distribuir a execução.

Defina quando reduzir ou abandonar a composição

Uma decisão de arquitetura deve incluir condições para revisão. Considere reduzir a composição quando as partes deixam de ter fronteiras claras, a coordenação exige intervenções frequentes ou a alternativa simples atende aos mesmos critérios com operação mais compreensível.

Não é necessário remover todos os componentes de uma vez. Uma etapa pode continuar especializada, mas passar a seguir um fluxo fixo. Outra pode permanecer assistida por uma pessoa. A mudança deve preservar o comportamento esperado e ser avaliada no conjunto.

Antes de acrescentar outro agente, escreva qual parte verificável da tarefa ele assumirá e qual decisão de coordenação deixará mais simples. Se a justificativa termina apenas no nome do papel, volte à descrição da tarefa e compare um desenho menor.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Inteligência no produto: como evoluir um software com IA
• Como comparar modelos para uma tarefa do produto
• Como escolher uma funcionalidade de IA para o produto

Fontes

• Anthropic: padrões de agentes
• Microsoft: plataforma de experimentação

Para continuar esta leitura

• Como desenhar aprovação humana dentro de um produto com IA