De chatbot a sistema de decisão: quando usar uma arquitetura multiagente

Por que isso importa

O segundo agente criou uma etapa de coordenação, não uma solução#

Um time divide um assistente confiável em planejador e executor esperando especialização. Agora o planejador precisa passar ao executor o pedido, as restrições e o resultado parcial. Se uma restrição ficar de fora, o executor não sabe se isso foi intencional; novas tentativas podem duplicar o trabalho. Essa passagem de trabalho de um agente para outro é chamada de handoff e cria um novo ponto onde informações podem se perder.

Por isso, a quantidade de agentes deve responder a um problema específico, não a um diagrama. Primeiro diga o que um único fluxo não faz bem — por exemplo, pesquisar duas fontes independentes ao mesmo tempo ou impedir que o componente que redige a resposta acesse o banco de dados. Acrescente outro agente somente quando essa separação melhorar um resultado medido o bastante para compensar a coordenação adicional.

Antes de criar outra função, situe a tarefa entre uma sequência fixa e decisões realmente independentes.

Espectro de arquitetura

Comece com uma sequência fixa; adicione escolhas do agente quando necessário#

Avance para a direita somente quando a tarefa exigir uma escolha que a sequência fixa não consegue fazer bem.

1. 01

   Sequência fixa

   As etapas e alternativas são conhecidas de antemão — por exemplo: validar o pedido, consultar uma fonte aprovada e formatar a resposta.

2. 02

   Agente único

   Um agente escolhe entre recursos aprovados, como busca na web ou execução de código, para concluir uma tarefa delimitada.

3. 03

   Sistema multiagente

   Agentes diferentes cuidam de partes distintas, passam resultados definidos entre si e reúnem esses resultados no final.

Esse espectro reduz as opções; sinais concretos mostram se um segundo agente tem uma função que justifica seu custo.

Quando a separação ajuda

Dê a cada agente adicional uma razão concreta para existir#

A separação pode ajudar quando um componente pesquisa fontes, outro faz um cálculo, outro verifica uma regra e um último explica as evidências. Também pode manter um acesso sensível — como a credencial de um banco de produção — longe do componente que não precisa dele, ou executar buscas independentes ao mesmo tempo.

Para cada passagem, escreva o que o próximo componente recebe, o que deve devolver, quais recursos pode usar, quanto tempo pode levar, o que acontece se falhar e quem responde por essa falha. Isso torna a coordenação testável. Apenas permitir que agentes troquem mensagens não torna o sistema bem projetado.

Depois de nomear essa função, escolha o menor padrão de coordenação capaz de executá-la.

Padrões de coordenação

Escolha o padrão antes de escolher a ferramenta#

Cada padrão resolve um problema de coordenação diferente. Escolha pela informação e pela autoridade necessárias a cada função, não pelos recursos de uma ferramenta.

1. 01

   Cadeia de instruções

   Use uma sequência fixa quando cada etapa transforma e valida o resultado anterior.

2. 02

   Paralelismo com agregação

   Execute análises independentes em conjunto e agregue apenas evidências que atendam ao mesmo contrato.

3. 03

   Roteador e especialistas

   Classifique o pedido, envie-o a um especialista limitado e mantenha uma alternativa explícita.

4. 04

   Avaliador e otimizador

   Um componente propõe e outro critica com uma rubrica, sempre com limite rígido de iterações.

Um caso de análise conversacional torna essas diferenças visíveis em um único sistema.

Padrão sanitizado de produto

Um sistema de análise conversacional é mais que chat#

Em um produto de análise conversacional em produção, um pedido pode exigir classificação de intenção, recuperação de dados, cálculo estatístico, comparação e explicação. A interface parece uma conversa, mas as responsabilidades por trás dela são diferentes.

O padrão útil não é a quantidade de agentes. É resolver cedo caminhos baratos ou determinísticos, preservar continuidade em perguntas seguintes e exigir que a resposta final carregue as evidências produzidas pelos especialistas.

O caso também expõe a próxima decisão de projeto: o que ocorre quando um especialista, uma ferramenta ou a passagem de trabalho falha?

Contenção de falha

Decida o que acontece quando um componente falha#

Cada agente adicional cria outro ponto onde uma restrição pode se perder, o tempo pode se esgotar ou um resultado pode contradizer o anterior. Por isso, o componente coordenador precisa de um prazo, um limite de novas tentativas e uma alternativa útil — por exemplo, devolver a lista de fontes já verificadas se a etapa de síntese falhar.

Registre qual agente recebeu a tarefa, qual recurso aprovado ele usou e qual resultado devolveu. Se a resposta final estiver errada, esse registro de execução ajuda o time a descobrir se o pedido foi enviado ao especialista errado, se a evidência era fraca, se um cálculo saiu errado ou se a explicação final distorceu um resultado correto.

Tratar falhas aumenta o custo; por isso, a arquitetura multiagente precisa superar uma alternativa simples em um resultado medido.

Experimento de arquitetura

Faça a arquitetura mais complexa superar uma alternativa simples#

Execute o mesmo conjunto representativo em uma sequência fixa com entradas e saídas definidas, na versão com agente único e na arquitetura multiagente proposta. Compare primeiro a conclusão da tarefa e as falhas críticas. Depois examine a latência p95, o custo por tarefa concluída, a intervenção humana e quantas execuções devolvem apenas um resultado parcial, mas ainda útil.

Adote a arquitetura multiagente somente quando o ganho persistir em execuções repetidas e vier da especialização ou do isolamento de falhas. Se a qualidade não melhorar e a latência, o custo e a dificuldade de diagnóstico aumentarem, mantenha a alternativa mais simples.

from dataclasses import dataclass
import json

@dataclass(frozen=True)
class Request:
    intent: str
    question: str

def generalist(request: Request) -> dict:
    return {"path": ["generalist"], "answer": "baseline", "evidence": []}

def data_specialist(request: Request) -> dict:
    if "timeout" in request.question.lower():
        raise TimeoutError("data specialist timed out")
    return {
        "path": ["router", "data_specialist"],
        "answer": "compare two validated segments",
        "evidence": ["segment_a", "segment_b"],
    }

def route(request: Request) -> dict:
    if request.intent != "compare_segments":
        return generalist(request)
    try:
        return data_specialist(request)
    except TimeoutError:
        return {
            "path": ["router", "data_specialist", "safe_fallback"],
            "answer": "comparison unavailable",
            "evidence": [],
            "degraded": True,
        }

cases = [
    Request("small_talk", "hello"),
    Request("compare_segments", "compare the top two"),
    Request("compare_segments", "force timeout"),
]
print(json.dumps([route(case) for case in cases], indent=2))

[
  {
    "path": ["generalist"],
    "answer": "baseline",
    "evidence": []
  },
  {
    "path": ["router", "data_specialist"],
    "answer": "compare two validated segments",
    "evidence": ["segment_a", "segment_b"]
  },
  {
    "path": ["router", "data_specialist", "safe_fallback"],
    "answer": "comparison unavailable",
    "evidence": [],
    "degraded": true
  }
]

A comparação troca preferência arquitetural por uma decisão sobre o valor comprado por cada fronteira adicional.

Regra de decisão

Pergunte o que a complexidade entrega#

Responda a estas perguntas com medições da mesma tarefa nas mesmas condições. Um diagrama não é evidência de melhoria.

• ✓Uma sequência fixa com entradas e saídas definidas resolve a tarefa?
• ✓Um único agente tem contexto suficiente e acessos bem separados?
• ✓As responsabilidades são realmente diferentes?
• ✓As etapas podem rodar de forma independente ou em paralelo?
• ✓É possível observar o que cada componente recebe e devolve?
• ✓Está claro quem responde quando cada especialista falha?
• ✓Se uma etapa falhar, o sistema ainda entrega um resultado parcial útil?
• ✓A avaliação compara a alternativa simples com a mais complexa?

Mesmo uma arquitetura multiagente justificada não elimina os limites comuns de modelos, ferramentas e responsabilidade organizacional.

Conclusão

Adicione um agente somente quando ele remover um gargalo comprovado#

A conclusão não é que sistemas multiagente sejam melhores. O padrão deve continuar sendo a menor arquitetura capaz de cumprir o contrato. Agentes adicionais só se justificam quando contexto, permissões, ferramentas, responsabilidade ou trabalho realmente independente não cabem com clareza em um único fluxo.

Antes de criar um papel, nomeie o gargalo que ele remove e a nova falha que introduz. Tipifique a transferência, preserve a evidência, defina tentativa, parada e quem responde pelo estado final. Se o time não consegue isolar e recuperar uma transferência com falha, simplificar é a decisão arquitetural mais segura.