multi-agent-harness

Use when deciding whether to form an Agent Team and when running one as the host: when a team beats a sub-agent, how to split waves, the member configuration contract (name:role:provider[:model][@ownedPaths]), handoff/ACK discipline, and the authorization gate (deploy / remote deletion / payment decisions must be escalated to the user, never decided by you or a member). Pair with [[agent-team-member]] for the prompt contract given to launched members.

Use when an agent needs to author a standalone Dynamic Workflow at runtime: write a Starlark program (loops, conditionals, data-driven fan-out) that calls agent()/parallel()/phase()/log() over the harness runtime, declare a mandatory workflow(name, design_intent) header, run it with `harness workflow run-script`, and read the resulting WorkflowRun/WorkflowStep records back from the dashboard snapshot or store.

Use when designing, auditing, or productizing a multi-agent system: persistent agent members, SendMessage/mailbox protocols, task assignment delivery, busy/idle queues, runtime lifecycle, permission messages, hooks/plugins boundaries, dashboard visibility, and acceptance tests.

Use when operating as a launched MemberRun inside an AgentTeamRun, or when the host is writing a member prompt: the delivery contract (ownedPaths, completion standard, evidence requirements), the blocker escalation format, the ACK discipline for assignments/handoffs, and the handoff report format (RESULT / SUMMARY / FILES CHANGED / COMMANDS & TESTS / EVIDENCE / BLOCKERS / SUGGESTED NEXT). The host-side orchestration method lives in [[agent-team-orchestrator]].

Use when Codex needs to bootstrap, audit, or redesign a project's vision-driven docs, architecture, ADRs, CI/CD, task workflow, agent workflow, skills, tool adapters, responsibility boundaries, or evidence-backed acceptance process. Applies to new projects, new requirements, migrations, governance audits, and self-hosting workflow work.

Design or revise a governed Company OS business module from a new operating need. Use when a user introduces a new domain such as trademark registration, procurement, hiring, or content operations and needs its documents, typed records, relations, organization roles, WorkItems, approvals, finance links, permissions, views, automations, and archive policy defined before implementation.

Design, generate, implement, and visually verify a governed custom Company OS document page from an approved ModuleDesign. Use when a core page must combine multiple documents, typed records, relations, actors, work, approvals, finance, or decision controls beyond ordinary document blocks and standard views, while preserving scoped reads, governed Actions, human approvals, auditability, and a standard-view fallback.