Autonomia de agentes precisa de recuperação, não de um manual infinito

Em uma palestra publicada pela InfoQ, Nimisha Asthagiri, da Thoughtworks, propõe pensar o ambiente de agentes como uma área de criação com limites claros, e não apenas como uma lista crescente de proibições.[4] A apresentação inclui persistência, observabilidade, ferramentas, controles e ciclos de melhoria nesse ambiente de execução.[4]

A tese que vale levar para o projeto é simples: autonomia deve ser avaliada também pelo que acontece quando uma dependência falha. Um agente que entrega no cenário ideal ainda não demonstrou capacidade de recuperação.

O que muda para quem desenvolve

A palestrante diferencia orientação antecipada, como objetivos e limites arquiteturais, de feedback produzido por testes, análise estática, métricas e revisões.[4] Ela também alerta que instruções excessivas podem inflar o contexto, fragilizar skills e dificultar adaptação quando ferramentas mudam.[4]

Minha análise é que essas duas ideias precisam ser aplicadas juntas. Reduzir instruções sem melhorar feedback deixa o agente sem direção. Acrescentar regras sem observar execução apenas desloca a confiança para um documento maior.

A apresentação recomenda registrar decisões de produto além das arquiteturais e conectar contexto de organização, produto, iniciativa e tarefa.[4] Para uma equipe pequena, eu traduziria isso em três registros curtos: objetivo da tarefa, decisão que não pode ser tomada autonomamente e evidência exigida para aceitar a entrega.

Como aplicar

Escolha uma automação reversível em ambiente controlado. Defina resultado esperado, orçamento de execução, arquivos permitidos e condições de interrupção. Deixe a documentação detalhada acessível por um índice curto, em vez de carregá-la integralmente em toda interação.

Depois, faça um exercício de recuperação proposto:

1. Execute a tarefa com uma ferramenta auxiliar temporariamente indisponível.
2. Observe se o agente diferencia ausência de resultado de falha de acesso.
3. Confirme que ele preserva o trabalho parcial e relata o impedimento sem inventar sucesso.
4. Restaure a ferramenta e verifique se a retomada evita repetir efeitos já realizados.

Registre tempo até detectar a falha, qualidade da explicação e quantidade de intervenção humana necessária. Esses critérios dizem mais sobre operação do que contar linhas de código. O exercício é uma recomendação, não um resultado já obtido.

Cuidados e limites

Asthagiri recomenda classificar decisões por reversibilidade e necessidade de revisão humana, e reconhece ter sofisticado demais sua própria estrutura antes de ajustá-la.[4] Os relatos de melhoria apresentados não constituem garantia universal de produtividade.[4]

Comece pequeno. Não transforme cada incidente em mais uma regra carregada para sempre. Minha recomendação é converter erros recorrentes em controles verificáveis e reservar documentação extensa para consulta. A autonomia útil termina onde o sistema já não consegue explicar, interromper ou recuperar o que está fazendo.

Fonte

[4] Fonte: InfoQ