Set release boundaries for the bounded research agent

Operational risks for the bounded research agent over a fixture KB center on agent inventing tools outside the registry mid-run, plus the earlier failure mode (infinite tool loop, or final answer with no citations after search). Safety lives in executable gates, allowlists, redaction, and a named owner—not in a warning paragraph under an unsafe function.

function authorize(ctx: Context, action: Action) {
  if (!ctx.permissions.has(action.permission)) {
    throw new SafeError("forbidden");
  }
  if (action.risk === "write" && !ctx.approvalToken) {
    throw new SafeError("approval_required");
  }
}

Expected evidence: The agent searches once, cites kb://returns, and stops before MAX_AGENT_STEPS.. A failed assertion means stop, investigate, and do not publish the bounded research agent.

Name who can disable the feature, what data is retained, and how to roll back to the last known good artifact. Pin the reviewed configuration (versions, thresholds, allowlists) so “what shipped” is reconstructable for agents-in-code.

Write the release blocker as a predicate, not a feeling: “Do not ship the bounded research agent if agent inventing tools outside the registry mid-run.” Pair it with a passing control that shows the reviewed configuration still works for fixture KB with 4 notes + max_steps=3. Name an owner and a rollback handle (git tag, docs_version, previous image).

Security pages must not paste the happy-path demo. If your gate code looks like the implementation page, replace it with a deny/allow check aimed at agent inventing tools outside the registry mid-run.

State the data retention rule in one line (what is stored, for how long, who can read it). Then state the kill switch (env flag, config pin, or feature owner). The bounded research agent is not shippable without both, even when step count ≤ max; citation coverage; abstention on empty search looks healthy.

At the safety and operations 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 an executable deny gate for the lab-specific threat 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

Previous · Next