Agents: review questions

A workflow chains models and tools along code paths written in advance; an agent lets the model decide the process and the tools. When the steps can be listed in advance, when there is no verification signal, or when a wrong step is costly (sending, paying, deleting), do not reach for an agent directly: write a workflow first, or add a person's confirmation at the critical steps.

A model (decides the next step), tools (act on the world), a loop (results go back to the model), and a stopping condition (done, or out of budget), plus a context or memory holding intermediate state. ReAct's "think a step, take a step" is the most common form of the loop.

Because its verification signal is the strongest: code runs, tests pass, every step gets objective feedback, and the agent can try again in a sandbox, with a person still reviewing the diff once tests pass. Settings such as customer support or personal assistants are much harder to judge automatically and lean more on rules, permissions, and people. Even in coding, passing tests does not mean the change is right.

Not by single-run success alone: check whether the same task succeeds in every one of several independent repeats, as with τ-bench's pass^k (the probability that all k runs succeed). Also check policy compliance, whether tool calls are correct, whether hard cases are handed to a person, and read complete run traces rather than only the final answer.

Capability first: if an open model misses the bar on your own evaluation set, use a frontier model. If data has strict boundaries, first check whether an API's region, retention, contracts, and private connections satisfy them; self-host if they cannot. With high, steady traffic, spare compute, or deep customization needs, self-hosting may be cheaper and more controllable once idle capacity, operations, and maintenance are counted; there is no universal volume threshold. At low or uncertain volume, start on an API and measure quality and cost. In practice they are often mixed: routing, cascades, distillation, fallback.

If steps are independent and any failure is unrecoverable, errors compound: at 95% per step, all 20 steps are right only about 36% of the time; at 99% per step, about 82%. Real errors correlate and systems can retry or recover, so the product is a warning that motivates end-to-end evaluation and recording where failures happen, not a prediction.

A model optimizes the reward you actually give it, not the goal you had in mind, and any gap between the two gets exploited. In OpenAI's boat race the reward was the pickups along the course, so the agent spun in a circle farming them and outscored finishing the race. LLMs do the same: reward "the tests pass" and an agent may edit the tests; in RLHF, if the reward model favors long or agreeable answers, the policy learns to write longer and flatter more.

A cascade lets the small model answer first and decides whether to escalate after seeing the answer, so it judges better — but escalated requests are paid for twice, and wait for two models in series. A router decides before any answer exists: each request pays for one model call plus the router and waits less, but it can misroute; catching that takes an output check or a fallback, whose cost and delay count too. Either one only pays off when difficulty is judged accurately.