Frame the bounded research agent experiment

Success is not “I followed the tutorial.” Success is producing evidence that: agent stops at max_steps; every claim cites a KB id or abstains. The accepted input is narrow on purpose: user question, KB search tool, max_steps, citation requirement. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: single-shot LLM answer without search. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

export const acceptance = {
  project: "a bounded research agent that can search a fixture knowledge base and then produce a cited answer",
  invariant: "the loop has a step budget, deadline, abort signal, and deterministic terminal states",
  expected: "The agent searches once, cites kb://returns, and stops before MAX_AGENT_STEPS.",
} as const;

Expected evidence: The agent searches once, cites kb://returns, and stops before MAX_AGENT_STEPS.. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the bounded research agent over a fixture KB, a decorative win often looks like a clean run that never checks step count ≤ max; citation coverage; abstention on empty search. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: agent inventing tools outside the registry mid-run.

For agents-in-code, write the claim on a sticky note in this exact shape: “Given user question, KB search tool, max_steps, citation requirement, the bounded research agent will …”. Fill the ellipsis with the observable part of: agent stops at max_steps; every claim cites a KB id or abstains. Tape the baseline beside it: single-shot LLM answer without search. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to search a local knowledge base then produce a cited answer within a step budget. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (fixture KB with 4 notes + max_steps=3) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against fixture KB with 4 notes + max_steps=3. Note the metric you will eventually require (step count ≤ max; citation coverage; abstention on empty search) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is infinite tool loop, or final answer with no citations after search.

At the experiment brief stage for agents-in-code, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about fixture KB with 4 notes + max_steps=3 that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: single-shot LLM answer without search.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to search a local knowledge base then produce a cited answer within a step budget. If you cannot point to a file, command, or assertion that proves that for the bounded research agent, stay on this page instead of advancing.

Glossary: tool · Glossary: structured output · Cheatsheet: production ops signals

Next