AI / LLM Integration
Agents: multiple-choice review
Crux Multiple-choice synthesis across the agents unit — the ReAct loop, quadratic context cost, termination exits, error-recovery traps, and when to script instead of agentify.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a decision you make designing or debugging a real agent — not a definition to recite, but a tradeoff to weigh when the loop is running on someone’s bill.
Goal
Confirm you can connect the loop mechanics, the economics of growing context, the several exits a loop needs, error-recovery hygiene, and the scripted-vs-agent call — the synthesis the lesson built toward.
Quiz
Completed
A task that takes 5 agent steps costs about $0.05. The same agent on a 15-step task costs about $0.40 — roughly 8×, not 3×. Why?
Heads-up The model is the same throughout. What changes is the token volume: each call re-reads the entire accumulated transcript, and that history grows every turn.
Heads-up Per-call overhead is roughly linear in step count; it cannot explain superlinear blowup. The quadratic term is re-sending a transcript that lengthens every turn.
Heads-up Retries cost the same per token as any call. Even a clean 15-step run with zero retries is ~8× a 5-step run purely from the re-sent, growing context.
Quiz
Completed
An agent request that should cost $0.08 ran nine minutes and burned $12. The trace shows search_orders called 142 times with identical arguments, each returning the same empty result. No exception was thrown. What is the root cause?
Heads-up An empty result is not an error — the tool worked. The failure is in the loop: nothing detected the repeated identical call or capped the spend. Treating 'not found' as terminal is the fix.
Heads-up A low cap would have stopped the bleed sooner, not caused it. The problem is the absence of dedup and a budget; raising the cap would make the bill worse.
Heads-up Window size is irrelevant — the result was empty each time. The agent was thrashing on an identical failing call, which more context cannot fix.
Quiz
Completed
A support flow always does the same three steps: look up the order, check refund eligibility, issue or deny the refund. A teammate proposes an open-ended agent with all three tools and recursion_limit=25. What is the better design and why?
Heads-up Flexibility you do not need is speculative complexity. The order never branches, so handing the model that freedom only adds cost, latency, and a class of thrashing failures you must now guard against.
Heads-up A cap of 3 still pays the agent tax — nondeterminism and re-sent context — to solve a problem with zero branching uncertainty. The fixed path should simply be scripted.
Heads-up It is an engineering tradeoff with real consequences: cost, latency, testability, and failure surface all favor the script when the path is known. Reserve the agent for steps you cannot enumerate in advance.
Quiz
Completed
A senior says 'treat the max-step cap as a seatbelt, not a steering wheel.' What does that mean operationally?
Heads-up A very high cap lets a quadratic loop run up a serious bill before it trips. The cap is a safety net to set low; the point is that hitting it regularly signals a deeper defect, not that it should be loosened.
Heads-up That inverts the metaphor. A loop that depends on the cap to stop is steering with the seatbelt — it should reach a genuine done state on its own, with the cap only catching the failure case.
Heads-up Even a perfect prompt meets empty results and confused models. The seatbelt is exactly for the night the steering fails; you keep it regardless of prompt quality.
Quiz
Completed
A long-horizon agent reaches step 40, and the history has grown past the model's context window. The framework silently truncates the oldest messages. What is the most likely consequence?
Heads-up Silent truncation does not throw — that is what makes it dangerous. The run continues with its own instructions missing, producing a plausible but wrong answer.
Heads-up Fewer tokens per call is true but irrelevant; the dropped tokens were the task definition and early findings. Cheaper calls that solve the wrong problem are not a win.
Heads-up The oldest messages usually hold the original instructions and the earliest tool results, exactly the context a long task depends on. Truncating them is how the agent loses the plot.
Quiz
Completed
When a tool call fails, the common pattern is to feed the error text back to the model as the next observation. Why is this both a superpower and a trap?
Heads-up Even capable models loop on identical empty/failed results. Without a retry cap, dedup, and 'I tried X, cannot find it' as an acceptable terminal answer, error-feedback becomes the thrashing bug.
Heads-up Hiding errors removes the model's main recovery channel. The fix is structural guards around error-feedback — caps and dedup — not suppressing the errors.
Heads-up That is a separate redaction concern. The loop-level trap is unbounded retries of an identical failing call, which is what produces runaway cost.
Recap
The through-line is one design discipline: the loop re-sends its whole history each turn, so cost is quadratic in steps and a long run overflows the window and drops its own instructions. A naive loop has a single exit the model may never reach, so you add independent ones — natural stop, a step cap (the seatbelt), a wall-clock/token budget that actually caps the dollar figure, and a dedup/progress check that kills thrashing. Error-feedback is the recovery superpower and the runaway trap; bound it with per-tool retry caps. And before any of that, ask whether the path is known — if it is, script it, and reserve the open-ended agent for steps you genuinely cannot enumerate in advance.