# OODA-Tool: Specialized OODA Loops for Tool-Using Agents
> Ficha editorial pública de Research IA. Estado: Lectura primaria completa. La interpretación editorial no sustituye la fuente primaria.

- Página canónica: https://luiseduardodemiguel.com/research-ia/papers/ooda-tool
- Fuente primaria: https://arxiv.org/abs/2608.24368
- Versión leída: arXiv v2 · 27 agosto 2026
- Fuente comprobada: 2026-08-31 · lectura primaria completa; HTML primario verificado
- Autores: Rongfeng Guo, Yinxuan Huang, Yusen Wu, Maoqing Zhong, Yunlu Chen, Meng Tang, Teng Long y colaboradores
- Fecha del corte: 25 AGO 2026 · v2 27 AGO
- Área: AGENTES · TOOL USE · LATENCIA

## Tesis y contexto

OODA-Tool entrena módulos especializados para distintos momentos del ciclo OODA y compara el resultado con una adaptación LoRA directa en modelos Qwen3 de 0.6B a 14B.

- Problema: Una política única tiende a mezclar observación, planificación y ejecución; esa mezcla puede ocultar dónde se pierde exactitud y cuánto cuesta cada mejora.
- Por qué importa: La arquitectura sugiere una regla de diseño: medir el beneficio por fase junto con la latencia multiplicativa de las llamadas adicionales.

## Evidencia reportada

- **reported-result**: Specialized OODA mejora Task Success frente a Direct-LoRA entre 4,48 y 6,99 puntos porcentuales según el tamaño del modelo. [localizador](https://arxiv.org/html/2608.24368v2#S5.T1)
- **reported-result**: Tool Exact queda entre 98,55% y 99,42% en los tamaños evaluados. [localizador](https://arxiv.org/html/2608.24368v2#S5.T1)
- **reported-result**: La variante de 1,7B presenta 2,36× de latencia normalizada por las llamadas secuenciales. [localizador](https://arxiv.org/html/2608.24368v2#S5)

## Lectura y límite

- Método: OODA-Tool divide la interacción con herramientas en un ciclo observar–orientar–decidir–actuar y especializa los módulos que aprenden cada fase. La comparación se realiza sobre Qwen3 de 0,6B a 14B y 11.111 sesiones, frente a una adaptación LoRA directa.
- Límite: La arquitectura añade llamadas y el agente de 1,7B llega a 2,36 veces la latencia normalizada. No debe extrapolarse una mejora de calidad a un workflow de baja latencia sin repetir el presupuesto completo.
- Confianza editorial: Alta
- Limitación: El coste temporal de las llamadas secuenciales puede dominar la ganancia de calidad.
- Limitación: La evaluación usa una familia de modelos y un protocolo de sesiones; falta validación en herramientas remotas con fallos reales.

## Localizadores de evidencia
- [Fuente primaria · canonical](https://arxiv.org/abs/2608.24368): tipo abstract
- [Fuente primaria · resumen](https://arxiv.org/html/2608.24368v2): tipo abstract
- [Metodología · §4](https://arxiv.org/html/2608.24368v2#S4): tipo section
- [Tabla 1 · resultados por tamaño](https://arxiv.org/html/2608.24368v2#S5.T1): tipo table
- [Figura 3 · análisis del ciclo](https://arxiv.org/html/2608.24368v2#S5.F3): tipo figure
- [Experimentos · §5](https://arxiv.org/html/2608.24368v2#S5): tipo section
- [HTML · fuente navegable](https://arxiv.org/html/2608.24368): tipo abstract

## Próxima prueba

- ¿Qué fases necesitan especialización para reducir errores sin pagar el ciclo completo?
- Métrica: Task Success, Tool Exact, llamadas por tarea, p50/p95 y coste por tarea.
- Regla de parada: No promover si la mejora no conserva al menos 98% de Tool Exact o si p95 aumenta más de 50% sin una mejora de calidad proporcional.

## Recursos reproducibles
- [HTML · fuente primaria v2](https://arxiv.org/html/2608.24368v2)

## Enlaces relacionados

- [MobilePA-Bench](https://luiseduardodemiguel.com/research-ia/markdown/papers/mobilepa-bench)
- [TOPAS](https://luiseduardodemiguel.com/research-ia/markdown/papers/topas)
- [The Devil Is in the Interface](https://luiseduardodemiguel.com/research-ia/markdown/papers/devil-interface)