Escolher entre um agente único e um enxame multiagente para um fluxo de trabalho complexo.
→Comece com um agente único + ferramentas. Divida em múltiplos agentes apenas quando os limites da tarefa forem claros, as janelas de contexto transbordarem, ou diferentes níveis de modelo forem necessários por subtarefa.
Por quê: Múltiplos agentes adicionam latência, superfície de erro e custo de orquestração. A maioria das cargas de trabalho de produção é bem-sucedida com um agente bem equipado.
O agente deve raciocinar sobre as observações antes de agir novamente.
→Implemente um loop ReAct (Raciocinar + Agir): o modelo gera um pensamento, seleciona uma ferramenta, recebe o resultado e repete até que uma condição de parada seja atendida.
Por quê: ReAct torna o raciocínio intermediário visível, melhorando a capacidade de depuração e permitindo auditar a cadeia de pensamento.
O agente precisa interagir com sistemas externos (APIs, bancos de dados, sistemas de arquivos).
→Defina ferramentas via API `tool_use`. O modelo emite um bloco `tool_use`; seu código o executa e retorna um `tool_result`. O modelo então continua.
Referência↗
O orquestrador deve despachar subtarefas heterogêneas (revisão de código, pesquisa na web, análise de dados).
→Use um agente supervisor que decomponha o objetivo, delegue a subagentes especialistas e agregue os resultados. Cada subagente tem seu próprio `system prompt` e conjunto de ferramentas.
Múltiplos subagentes devem coordenar sem comunicação direta ponto a ponto.
→Encaminhe todas as mensagens entre agentes através de um supervisor. O supervisor decide qual subagente executa em seguida, passa o contexto e impõe restrições de ordenamento.
Por quê: Mensagens diretas entre pares criam ciclos e tornam o estado difícil de rastrear. Um supervisor central mantém o DAG de execução explícito.
O agente deve lembrar o contexto em uma sessão de múltiplas interações.
→Passe o histórico completo da conversa (`system` + interações anteriores do usuário/assistente) no array `messages`. Para sessões longas, resuma as interações mais antigas para permanecer dentro da janela de contexto.
O agente precisa de persistência entre sessões ou entre usuários.
→Armazene fatos em uma camada de memória externa (banco de dados vetorial, `key-value store`, arquivo). Recupere memórias relevantes via RAG e injete no `system prompt` a cada interação.
A equipe adota a arquitetura de agentes por padrão para cada recurso de LLM.
→Não use agentes quando um único `prompt` + saída estruturada for suficiente. Agentes adicionam latência, custo e modos de falha. Reserve loops de agente para tarefas que exigem iteração ou uso de ferramentas.
Uma tarefa de raciocínio complexo precisa de mais deliberação interna antes da resposta.
→Habilite o `extended thinking` com um parâmetro `budget_tokens`. O modelo usa um bloco de pensamento antes de responder, melhorando a precisão em problemas de múltiplos passos.
Por quê: O `extended thinking` troca latência por qualidade. Defina `budget_tokens` proporcionalmente à complexidade da tarefa; limite-o para controlar o custo.
Referência↗
Uma chamada de ferramenta retorna um erro; o agente deve se recuperar graciosamente.
→Retorne o erro como um `tool_result` com `is_error: true`. O modelo vê a falha e pode tentar novamente com parâmetros corrigidos, tentar uma ferramenta alternativa ou explicar a falha ao usuário.
Referência↗
Falhas transientes da API (429, 529) durante um loop de agente.
→Implemente `exponential backoff` com `jitter`. Em 429 (limite de taxa), respeite o cabeçalho `retry-after`. Em 529 (sobrecarregado), aguarde mais tempo. Nunca tente novamente erros da classe 400 cegamente.
Medir se um sistema de agente realmente melhora ao longo do tempo.
→Construa uma suíte de avaliação: defina pares de entrada-saída, execute o agente, pontue as saídas (`exact match`, LLM como juiz, revisão humana). Acompanhe a taxa de aprovação por lançamento.
Por quê: Sem avaliações, ajustes de `prompt` são suposições. A detecção de regressão requer pontuação automatizada e repetível.
O agente produz saída de baixa qualidade na primeira tentativa.
→Adicione uma etapa de reflexão: após gerar uma resposta, solicite que o modelo critique sua própria saída e revise. Use uma interação de mensagem separada ou `extended thinking`.
O fluxo de trabalho de agente realiza ações irreversíveis (excluir recursos, enviar e-mails).
→Insira um ponto de verificação antes de operações destrutivas. Apresente a ação planejada ao usuário, aguarde aprovação e, em seguida, execute. Registre a decisão para auditoria.