Naveo

STEP 12 / 22

B3 TOOL-HANDLER

IMPLEMENT THE HANDLER

Implement the handler for the agent_loop tool.

TOOL SCHEMA (READ-ONLY)

An agent that receives a user goal, decides which tool to invoke,
reads the result, decides if it needs another tool, and eventually
finishes with a final answer.

The loop:

1. callModel(messages + tools) → returns { type: "tool_call", name, args } or { type: "final", text }
2. If it's a tool_call: run the corresponding handler, append the result to messages, go back to step 1.
3. If it's a final: return the answer to the user and stop.

Your job: implement the loop with the **correct stop conditions**.
Without them, the agent can enter infinite loops or stop too early.

SCENARIOS · 4

Happy path: the model calls 2 tools, then returns final answer.

EXPECTED: ok: true, answer: the final text.

Potential infinite loop: the model calls the SAME tool with the SAME args twice in a row (signal that it's stuck).

EXPECTED: The loop breaks before the 3rd identical call. Returns ok: false, error code 'stuck_loop' or similar.

Too many steps: the model goes 20 tool_calls without reaching final.

EXPECTED: The loop breaks at max_steps (typical: 10-15). Returns ok: false, error code 'max_steps_exceeded'.

Tool fails: handleTool throws on the 3rd iteration.

EXPECTED: The error is caught, injected back to the model as a tool_result with ok: false, and the loop CONTINUES so the model can decide how to recover. Does NOT silently terminate.

YOUR CODE

818 CHARACTERS

JUDGED BY LLM · NO EXECUTION

GUEST MODE

You're viewing this lesson as a guest. To save your progress, earn XP, and keep your streak, sign in when you're ready to check.

Costs 1 heart

The agent that knows when to stop.

Orbit has a rule: any loop without an exit condition is an incident waiting to happen. If you're going to let the agent run on its own, you have to be able to answer before hitting Run: what makes it stop?

An agent that calls tools in a loop is the central piece of any modern autonomous system. Sounds simple: model picks a tool, you execute, send back the result, repeat until done.

The problem: when does "done" happen? Three ways to never finish:

Infinite loop. The model gets "stuck" calling the same tool over and over with the same args.
Long but non-infinite loop. The model does reasonable things but doesn't converge. 30 turns later you're still burning tokens.
Cascading error. A tool fails, the model doesn't know, keeps calling things that depended on that result.

Designing good stop conditions is what separates an agent you can let run from one that needs constant human supervision.

The three stop conditions

max_steps. absolute counter. If it hits 10-15 without a final, exit with error. Universal safety net.
Loop detection. if the model requests the same tool with the same args 2-3 times in a row, it's stuck. Exit.
Tool errors are propagated. when a tool fails, the error goes back to the model as input ({ ok: false, error: ... }). The model decides how to recover. The loop does NOT break. it only breaks if the model decides to or if the other stop conditions trigger.

The task

Implement the loop. On the right you have a starter that works on the happy path but has no stop conditions.

Why we don't execute your code

Same principle as Track 3, step 06: an LLM-judge reads your implementation and reasons whether it would correctly handle the 4 scenarios. That means your code has to be readable. Clear names, obvious control flow, early returns for errors.

How it's evaluated

5 LLM-judge criteria:

max_steps correctly implemented.
Loop detection implemented.
Tool errors go back to the agent as input, don't terminate the loop.
Happy path intact.
Structured returns with an ok boolean.