Agent loop

Crie uma pasta local e salve o código da resolução como agente.cjs. Antes de executar, escreva o contrato das ferramentas: lerPedido recebe um identificador e retorna item e destino; lerEstoque recebe o item e retorna quantidade; lerPrazo retorna uma estimativa; redigir recebe as observações necessárias. No código, os argumentos são simplificados pela captura do pedido e do estado. Ao transformá-los em chamadas de modelo, torne esses argumentos explícitos e valide tipos, tamanho e identificadores. O fato de o modelo produzir JSON não garante que o pedido exista ou pertença ao usuário.

Defina a recomendação como saída informativa. Ela não confirma compra, despacho ou reserva. Essa distinção muda o limite de autorização: consultar dados de um pedido autorizado é uma operação diferente de alterar seu estado. Uma ferramenta futura de reserva exigiria validação própria, chave de idempotência e a política de aprovação da aplicação. Manter quatro ferramentas pequenas ajuda a enxergar essa fronteira. Não reúna consulta e alteração em uma função que pareça apenas leitura; o runtime precisa saber quando um efeito externo está sendo proposto.

↗ Running agents

Rode o caso P7 e leia a ordem dos eventos. A primeira decisão escolhe lerPedido porque ainda falta identificar o item. A segunda usa a informação observada para obter estoque. Em seguida aparece prazo, e só depois redigir. Marque no papel qual campo do estado foi acrescentado a cada passo. Se você trocar a ordem para redigir primeiro, a recomendação deixa de possuir as premissas necessárias. O erro seria arquitetural, mesmo que uma saída padrão ainda parecesse plausível.

Altere o estoque para zero e observe se a recomendação continua dizendo disponível. No exemplo, ela usa a quantidade observada; uma versão com modelo precisa de casos de avaliação que detectem promessas incompatíveis com o estoque. Acrescente ao registro o argumento recebido por cada ferramenta quando expandir o código. Evite registrar dados pessoais completos. Para investigar uma consulta incorreta, normalmente bastam identificador interno, nome da ferramenta, duração e status, com os detalhes sensíveis guardados em armazenamento apropriado.

Execute com P404. A ferramenta lança um erro conhecido, e o runtime devolve status de falha. Confirme que redigir não foi chamada depois disso. Agora injete uma política que sempre escolhe lerPedido: sem a condição de observação ausente, ela consome o limite e termina por orçamento. Os dois casos precisam de rótulos diferentes porque pedem correções diferentes. O identificador inválido exige entrada válida; a repetição exige corrigir a política. Aumentar o teto resolveria nenhum dos dois problemas de maneira confiável.

↗ Running agents

Para praticar reflexão limitada, escreva uma nota sobre a repetição: a decisão ignorou observações anteriores. Corrija apenas essa regra e rode de novo o mesmo caso, depois um pedido diferente. Não altere objetivo, ferramentas e dados simultaneamente, pois perderia a capacidade de atribuir a melhora à mudança. Registre a contagem de passos antes e depois. Esse procedimento não prova que um modelo real se comportará igual; demonstra que o mecanismo de execução possui uma defesa mensurável contra decisões repetitivas.

↗ Reflexion: Language Agents with Verbal Reinforcement Learning

Seu README deve incluir o objetivo, a fronteira informativa, os contratos e os estados finais possíveis. Anexe o histórico nominal e os históricos de falha. Explique por que a execução é um único loop, mesmo usando várias ferramentas: existe um controlador que observa o resultado e decide a próxima transição. Compare com um workflow fixo que chama as quatro funções sempre na mesma ordem. A diferença relevante é a possibilidade de alterar o caminho conforme observações e de encerrar cedo quando não há dados válidos.

↗ Running agents