Além da eficiência de tokens, o ReWOO demonstra um benefício adicional: robustez sob falhas de ferramentas. Se uma ferramenta falhar no ReAct, por exemplo, o sistema pode ficar preso em um loop infinito (à medida que o LLM consulta repetidamente um banco de dados defeituoso para o clima em Chicago, por exemplo).
O ReWOO é mais ágil. Mesmo que uma ferramenta não consiga retornar uma determinada evidência, o plano inicial abrangente ainda estará em vigor: o módulo Worker poderá progredir, e o módulo Solver poderá fornecer pelo menos uma resposta parcial. No exemplo do clima, em vez de ficar preso em um loop infinito ou excessivo consultando um banco de dados sobre o clima de Chicago, o módulo Solver pelo menos retornaria uma resposta informando ao usuário sobre o clima em Nova York e Milwaukee (supondo que o módulo Worker tenha conseguido recuperar esses bits de evidências), o que poderia, em última análise, ser suficientemente útil para as necessidades de planejamento do usuário.
Apesar dos benefícios do ReWOO, ele não é um framework universalmente superior; é simplesmente melhor para certos tipos de trabalhos, especialmente quando os tipos e quantidades de evidências necessárias são regulares e previsíveis. No entanto, onde o ReWOO fica aquém do esperado, há problemas menos previsíveis ou estruturados que podem exigir criatividade, exploração ou improvisação. Com desconhecidos conhecidos, o ReWOO se destaca; mas com desconhecidos, ele naufraga.
Por exemplo, o ReWOO não seria ideal para depurar código Python, um processo exploratório e iterativo em que cada correção pode gerar novos erros e pistas, com os planos mais bem elaborados rapidamente se tornando obsoletos. Um framework mais adaptável como o ReAct, embora menos eficiente em termos de tokens em abstrato, acabaria por ser mais adequado para esse problema.