Además de la eficiencia del token, ReWOO demuestra un beneficio adicional: robustez en caso de fallo de la herramienta. Si una herramienta falla en ReAct, por ejemplo, el sistema puede quedar atrapado en un bucle infinito (ya que el LLM consulta repetidamente una base de datos rota para el clima en Chicago, por ejemplo).
ReWOO es más ágil. Incluso si una herramienta no puede devolver una prueba determinada, el plan general inicial sigue en vigor: el módulo Worker puede progresar y el módulo Solver podrá ofrecer al menos una respuesta parcial. En el ejemplo del tiempo, en lugar de quedar atrapado en un bucle infinito o excesivo consultando una base de datos sobre el tiempo en Chicago, el módulo Solver al menos devolvería una respuesta informando al usuario sobre el tiempo en Nueva York y Milwaukee (suponiendo que el módulo Worker pudiera recuperar esos datos), lo que en última instancia podría ser suficientemente útil para las necesidades de planificación del usuario.
A pesar de los beneficios de ReWOO, no es un marco universalmente superior; simplemente es mejor para ciertos tipos de trabajos, especialmente cuando los tipos y cantidades de pruebas necesarias son regulares y predecibles. Sin embargo, donde ReWOO se queda corto es con problemas menos predecibles o estructurados que pueden requerir creatividad, exploración o improvisación. Con incógnitas conocidas, ReWOO destaca, pero con incógnitas desconocidas, fracasa.
Por ejemplo, ReWOO no sería una solución óptima para depurar código Python, un proceso exploratorio e iterativo en el que cada corrección puede generar nuevos errores y pistas, y en el que los planes mejor trazados pueden quedar rápidamente obsoletos. Un marco más adaptable como ReAct, aunque menos eficiente en términos de tokens en abstracto, sería en última instancia más adecuado para este tipo de problema.