Skip to content

Canonical Conductor agent workflow

This is the one execution-authorizing workflow. Planning conversations, preflight validation, and estate queries may help construct the plan but cannot authorize work.

Lifecycle

  1. Read the authoritative Initiative and select one workstream, stage, and active role.
  2. Use discovery tools only as needed.
  3. Construct one exact plan-bundle.v1, including organization, Initiative, workstream, context/corpus revisions, exact targets and operations, artifacts, evidence, rollback, assumptions, and questions.
  4. Call consult_plan.
  5. If it returns rebind-required, bind the returned prepared_context_revision, rebuild the plan digest, and call again.
  6. The server-side Conductor supervisory reviewer returns questions, revision, refusal, escalation, or an authorization. Requester-authored review text cannot create the trusted resolved decision. An affirmative model review is advisory: authorization also requires an exact delegated-capability grant compiled from the explicit live corpus delegation unit, plus authoritative workstream state binding the active role and repository.
  7. Claim an issued authorization by calling authorize with authorization_json. The claim is one-shot and occurs immediately before execution.
  8. Execute only the exact plan using production tools outside Conductor.
  9. Write evidence, status, and next action to the authoritative system.
  10. Call complete_authorized_work with exact execution evidence and the writeback reference. Completion succeeds only when a configured server-side adapter reads back the external record and attests the reference; otherwise it fails closed. The first production adapter verifies a full GitHub commit SHA through authenticated gh, bound to the authorized repository, operation ID, success result, execution evidence, a GitHub push event after the durable claim time, and an exact changed-file set.
  11. Submit a reusable experience only when warranted. The background scheduler reviews due experiences weekly; candidates remain non-binding.
  12. Start a new cycle after any stage, role, material-plan, target, context, or corpus change.

Authority controls

  • start_conversation and follow_up are planning-only.
  • Public converse cannot write supervisory decisions.
  • Public authorize cannot issue authorization; it only claims an envelope issued by consult_plan.
  • The supervisory model recommendation is validated and then recorded through a server-only review-attestation boundary. A deterministic delegated-action policy runs before authorization. V1 permits exactly one operation with explicit safe relative paths under repository.modify-files.v1, and only when sw.capability.repository-modify-files delegates the role and authoritative workstream state binds that active role and repository. Every other capability fails closed regardless of model output.
  • The executing agent must resolve each authorized path inside the repository root and reject symlink escapes before writing; authorization never widens a path to a directory or repository-control data.
  • Public feedback is deprecated; it cannot bypass atomic completion.
  • Conductor never executes the plan or writes routine project state.
  • Exceptions, policy changes, and declared human judgment gates still require Hector.

Learning and policy

Authorization-bound feedback may become an organization-bound experience. Scheduled review can create a deduplicated improvement candidate after repeated independent evidence. Candidate promotion remains:

candidate → submit_proposal → Hector approval → PR → merge

Verification

On 2026-07-27, a targeted control-plane reviewer and a separate fresh release auditor independently passed this workflow after adversarial remediation. The release evidence was:

  • 186 service tests passed.
  • Changed-file Ruff checks passed.
  • Strict MkDocs build passed.
  • git diff --check passed.
  • Governed delegation proposal #41 and correction PRs #42–#47 were merged.