Set release boundaries for the research-critique coordinator

Operational risks for the research+critique coordinator center on critique worker receiving secrets from research scratchpad logs, plus the earlier failure mode (workers sharing mutable state, or coordinator ignoring critique veto). 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: Research returns two sourced claims; critique rejects one unsupported claim; synthesis keeps one.. A failed assertion means stop, investigate, and do not publish the research-critique coordinator.

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 multi-agent-in-code.

Write the release blocker as a predicate, not a feeling: “Do not ship the research-critique coordinator if critique worker receiving secrets from research scratchpad logs.” Pair it with a passing control that shows the reviewed configuration still works for two workers with separate step budgets. 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 critique worker receiving secrets from research scratchpad logs.

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 research-critique coordinator is not shippable without both, even when veto rate; unsupported claim count after merge; total step budget looks healthy.

At the safety and operations stage for multi-agent-in-code, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about two workers with separate step budgets 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 agent without critique pass.

For this page specifically, success looks like an executable deny gate for the lab-specific threat while still centering the user decision to delegate research and critique to two bounded workers, then merge under a coordinator policy. If you cannot point to a file, command, or assertion that proves that for the research-critique coordinator, stay on this page instead of advancing.

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

Previous · Next