Definir o resultado antes da tecnologia
Uma equipa quer transformar os pedidos recebidos em respostas úteis. Antes de escolher um agente, deve definir o que significa útil: uma resposta completa, uma fonte identificável, informação em falta assinalada e um passo seguinte claro. Trata-se de um exemplo hipotético, não do resultado de um projeto. Se a tarefa não pode ser descrita e avaliada, chamar-lhe agente não a torna mais clara. Pode apenas esconder a incompreensão atrás de uma interface convincente.
Quando o percurso é conhecido
A Anthropic distingue os fluxos predefinidos dos agentes que escolhem dinamicamente os seus passos e ferramentas. No nosso exemplo, classificar o pedido, consultar uma fonte designada e redigir uma proposta podem formar um fluxo fácil de acompanhar. Uma pessoa pode verificar a proposta antes do envio. A pergunta prática é se existe uma situação importante que essa sequência não consegue tratar, e não se o fluxo parece suficientemente avançado.
Quando é preciso descobrir o passo seguinte
Suponhamos que os pedidos são muito diferentes e que a informação necessária só se torna evidente depois de uma primeira verificação. Um agente poderia escolher a fonte a consultar a seguir ou a pergunta a devolver ao utilizador. O valor proposto está na adaptação do percurso. Para o avaliar, a equipa deve observar quando as escolhas dinâmicas produzem uma resposta melhor do que o caminho fixo e quando acrescentam desvios desnecessários.
Fazer dos limites parte do produto
A Microsoft recomenda o nível de complexidade que cumpre os requisitos, considerando o custo e o tempo. Numa experiência, isso traduz-se em perguntas concretas: quantas verificações são aceitáveis, o que pode o sistema consultar e quando deve pedir ajuda? Preparar uma resposta e ter autorização para a enviar são coisas diferentes. Registar o motivo da paragem e a informação em falta torna o comportamento compreensível para quem usa o produto, além da equipa técnica.
Comparar alternativas na mesma tarefa
Uma avaliação útil poderia apresentar os mesmos exemplos a uma chamada simples ao modelo, a um fluxo e a um agente. Critérios propostos: resposta correta e completa, informação inventada, intervenções humanas, custo e tempo até ao resultado. Devem incluir-se pedidos ambíguos ou impossíveis de resolver com os dados disponíveis. Sem esta comparação, mais passos podem parecer progresso apenas por serem visíveis. A arquitetura merece ser ampliada quando uma melhoria observada justifica o esforço de operação e manutenção. Repetir a comparação depois das alterações também mostra se uma nova versão conserva a vantagem que a equipa observou inicialmente.