Naveo

STEP 12 / 22

B3 TOOL-HANDLER

IMPLEMENTÁ EL HANDLER

Implementá el handler del tool agent_loop.

SCHEMA DEL TOOL (READ-ONLY)

Un agente que recibe un objetivo del usuario, decide qué tool invocar,
lee el resultado, decide si necesita otro tool, y eventualmente termina
con una respuesta final.

El loop:

1. callModel(messages + tools) → devuelve { type: "tool_call", name, args } o { type: "final", text }
2. Si es tool_call: ejecutar el handler correspondiente, agregar el resultado a messages, volver al paso 1.
3. Si es final: devolver la respuesta al usuario y terminar.

Tu trabajo: implementar el loop con las **stop conditions correctas**.
Sin ellas, el agente puede entrar en bucles infinitos o quedarse
corto antes de tiempo.

ESCENARIOS · 4

Happy path: el modelo llama 2 tools, después devuelve respuesta final.

EXPECTED: ok: true, answer: el texto final.

Loop infinito potencial: el modelo llama el MISMO tool con los MISMOS args dos veces seguidas (señal de que está atascado).

EXPECTED: El loop se rompe antes de la 3ra llamada idéntica. Devuelve ok: false, error code 'stuck_loop' o similar.

Demasiados pasos: el modelo lleva 20 tool_calls sin llegar a final.

EXPECTED: El loop se rompe al alcanzar max_steps (típico: 10-15). Devuelve ok: false, error code 'max_steps_exceeded'.

Tool falla: handleTool lanza una excepción en la 3ra iteración.

EXPECTED: El error se captura, se inyecta al modelo como un tool_result con ok: false, y el loop CONTINÚA para que el modelo decida cómo recuperarse. NO termina silenciosamente.

TU CÓDIGO

838 CARACTERES

EVALUADO POR LLM-JUDGE · SIN EJECUCIÓN

MODO INVITADO

Estás viendo esta lección como invitado. Para guardar tu progreso, ganar XP y mantener tu racha, inicia sesión cuando estés listo para comprobar.

Cuesta 1 vida

El agente que sabe cuándo parar.

Orbit tiene una regla: cualquier loop sin condición de salida es un incidente esperando suceder. Si vas a dejar al agente correr solo, tenés que poder responder antes de presionar Run: ¿qué lo hace parar?

Un agente que llama tools en loop es la pieza central de cualquier sistema autónomo moderno. Suena simple: modelo elige tool, ejecutás, le mandás el resultado, repetís hasta que termine.

El problema: ¿cuándo "termina"? Tres formas de no terminar nunca:

Loop infinito. El modelo se "atasca" llamando el mismo tool una y otra vez con los mismos args.
Loop largo pero no infinito. El modelo va haciendo cosas razonables pero no converge. 30 turnos después seguís consumiendo tokens.
Error que cascadea. Un tool falla, el modelo no se entera, sigue llamando cosas que dependían de ese resultado.

Diseñar bien las stop conditions es lo que separa un agente que se puede dejar correr de uno que necesita supervisión humana constante.

Las tres stop conditions

max_steps. contador absoluto. Si llega a 10-15 sin un final, salí con error. Salvavidas universal.
Loop detection. si el modelo pide el mismo tool con los mismos args 2-3 veces seguidas, está atascado. Salí.
Tool errors propagados. cuando un tool falla, el error vuelve al modelo como input ({ ok: false, error: ... }). El modelo decide cómo recuperarse. El loop NO se rompe. solo se rompe si el modelo lo decide o si las otras stop conditions disparan.

El task

Implementá el loop. A la derecha tenés un starter que funciona en el happy path pero no tiene ninguna stop condition.

Por qué no ejecutamos tu código

Mismo principio que step 06 de Track 3: un LLM-judge lee tu implementación y razona si manejaría correctamente los 4 escenarios. Eso significa que tu código tiene que ser leíble. Nombres claros, control flow obvio, early returns para los errors.

Cómo se evalúa

5 criterios LLM-judge:

max_steps implementado correctamente.
Loop detection implementado.
Errores de tool vuelven al agente como input, no terminan el loop.
Happy path intacto.
Returns estructurados con ok boolean.