Execution Mode and the CTO Orchestrator

Five issues on the Council. It decides. It does not build. Someone has to turn the memo into a thing an engineer can pick up on Monday. That someone is the Crew.

From Council to Crew

Issue 1 named both patterns and then spent five issues on one of them. The Council is broadcast deliberation: a room of biased agents argues a hard question, the Arbiter synthesizes, and the output is a memo with the dissent still bolted on. Good for decisions. Useless for delivery. A memo does not compile.

The Crew is the other half. Same primitives, opposite shape. Where the Council argues a question, the Crew executes a brief. It routes work to named agents in sequence instead of broadcasting to a full room, and it ends on an execution package instead of a memo: requirements, an architecture record, a phased plan, a task list, a risk review, assembled into something buildable. Issue 5 closed by promising this crossing. Here it is.

What is real here. The cto-execution profile and its eight-step workflow are real files, and everything I say about the machinery reads straight from them. New this issue: the auth-system content is a captured run, not a demonstration. The profile ran on the repo's sample brief under harness 0.11.0, session 2026-07-02-cto-execution-mr2zah6a, and the planning half of the chain (understand, design, challenge, plan, tasks) produced the artifacts below. The back half did not land clean. The security-review and stress-test steps wrote empty files, and the final synthesis produced a stub instead of a package. So I show you the real planning artifacts and describe the review and synthesis steps, rather than dressing up a package the run did not actually produce.

The CTO Orchestrator

The Council runs on the Arbiter. The Crew runs on a different orchestrator, the cto-orchestrator, and the swap is not cosmetic. The Arbiter's job is to run a debate and synthesize it. The CTO Orchestrator's job is to drive a lifecycle and hand off artifacts. One referees an argument. The other runs a production line.

That difference is in the config. The profile sets delegation.default: targeted and opening_rounds: 0. No all-hands round, because the CTO already knows the routing: requirements to the advocate and strategist, architecture to the architect, tasks to the operator. There is no broadcast because there is no question on the table, only work to route. Compare that to strategic-council, where broadcast and an opening round exist precisely so every voice hits the question cold.

The artifact chain

The whole workflow runs in order. Read it as a chain: each step's output is the next step's input.

1. understand: advocate and strategist produce requirements_analysis (user stories, acceptance criteria, the core problem).
2. design: architect takes requirements_analysis, produces the architecture_decision_record (components, tech choices with rationale).
3. challenge: architect and operator run as a tension pair over the ADR. Operator attacks it for buildability, architect defends or revises. Output: revised_architecture.
4. plan: strategist and operator take the revised architecture and the requirements, produce the phase_plan (2 to 4 phases, milestones, effort, risks).
5. tasks: operator turns the phase plan, against the revised architecture, into a task_breakdown (task, estimate, dependencies, assignee role, acceptance criteria).
6. security-review: sentinel reviews the architecture and tasks, produces the risk_assessment (attack surface, data privacy, failure modes).
7. stress-test: provocateur, speaking last with the full plan in hand, produces stress_test_findings (weakest assumption, where it fails first, what everyone agreed on too easily).
8. synthesize: the orchestrator folds it all, including the stress-test findings, into the final execution_package.

Look at step 3. The Council's tension pairs argue to inform a memo. Here the tension pair is load-bearing on the artifact itself: the architect's ideal design goes in, the operator's "what we can actually build" pushes back, and a revised architecture comes out. That revised doc, not the original, is what steps 4 and 5 build on. The disagreement never lands as recorded dissent. It gets folded into the next artifact.

This is the motif from Issue 1, evolved. The space between the models is where the Council argues. In the Crew it is where one artifact becomes the next one's input.

Review gates

Three of the eight steps carry a gate, and all three are user-approval: after understand, after design, after plan. A gate is a hard stop. The chain pauses and asks you a question before the next producer builds on the work. After understand: "Do these requirements capture what you're building?" After design: "Does this architecture direction look right?" After plan: "Does this phasing make sense for your team and timeline?" Reject, and the step retries with your feedback.

The gates sit exactly where a wrong artifact would be most expensive to inherit. Wrong requirements poison everything downstream. A wrong architecture makes the task breakdown busywork against the wrong design. Bad phasing hands your team a plan they cannot staff. The five other steps auto-proceed, including challenge, and that one is deliberate. The tension pair is the review. You do not gate a step whose whole job is to review the step before it.

The execution package

The planning half of the package landed as real artifacts. Excerpts from the captured run follow, on the auth brief. Real IDs and structure.

One decision from the architecture_decision_record:

AD-1: Better Auth as the auth engine. Adopt Better Auth (open source, MIT, $0) with its Prisma adapter and its organization plugin. Every table it needs gets generated into our own Prisma schema. We own the data model. The library is an engine over our tables, not a hosted service. Sessions live in Postgres, DB-backed and sliding, so revocation is real: log out everywhere or reset a password and the session dies server-side, with a short cookie cache holding a role change to about five minutes rather than instant. Stateless JWT was rejected because logout-invalidates and reset-invalidates-all-sessions are acceptance criteria a pure token cannot meet. Alternatives got named and rejected. Auth.js treats credentials as second-class and makes revocation awkward under a JWT strategy. A Lucia-style DIY build is two engineer-weeks of security-critical code and the highest OWASP risk on this team and timeline.

The tension-pair step is where this got sharp. The operator took the ADR and reviewed it as the person who has to ship in ten working days and not get paged at 2am in week three. Verdict: sound and buildable, but strongest where the risk is lowest and thinnest where projects actually die. Two blocking findings came back. First, two architectures were fighting over the same tables. AD-1 adopts Better Auth's generated org schema (Member, Invitation, Organization), while a later decision sketched a hand-written Prisma schema with different names, and the plugin will not run against the sketch. The ADR has to declare which schema is authoritative. Second, the design routed everything through Postgres, sessions and rate-limit counters included, with no connection-pooling or region story between Vercel and Railway, which is the single most common way that stack falls over in week three. That revised assessment, not the original ADR, is what plan and tasks build on.

One task from the task_breakdown. Effort runs S/M/L/XL, roughly half a person-day up to three-plus:

T1.2: Better Auth schema generation committed as law. Effort: M. Owner: backend (Senior). Depends on: T1.1. Run @better-auth/cli generate with the organization plugin, commit the output as the canonical schema, and document the rule that generated tables get no hand-edits and domain tables FK alongside. Acceptance: the generated schema migrates clean and the plugin boots against it, and the repo README states the schema-authority rule.

That task is the direct answer to the tension pair's first blocking finding. The chain threaded it through: a design conflict surfaced at challenge became a committed rule at tasks. The tasks step did the same honest accounting on effort. It totaled Phase 2 at roughly thirteen person-days against twelve available, said so in the artifact, and fixed it in the plan instead of burying it: land the milestone midday on day 7 and start the next task in parallel. A producer that flags its own overrun is doing the job.

Then the back half. The security-review step routes to the sentinel and the stress-test step to the provocateur, and on this run both wrote empty artifacts. The synthesis step, which is supposed to fold everything into the final execution_package, produced a stub. So there is no clean package file to show you here.

That is still the difference from a memo. You can hand the planning artifacts to an engineer and they can start Monday. The requirements have acceptance criteria. The architecture has a decision with a rationale you can argue with. The tasks have effort, owners, dependencies, and acceptance criteria, and they already absorbed the tension pair's blocking findings. It is a package, not a chat log. The review and stress passes are where this run fell short, and I would rather show you that than fake the sections that did not fill in.

Why a chain, not a workflow engine

A generic workflow engine coordinates concurrent worker nodes and passes state between them. It cares about the task graph, retries, and throughput. Execution mode does something narrower. It runs sequential producers, and each leg finishes a real document a human could act on alone.

The unit is the artifact, not the task. requirements_analysis is a document. architecture_decision_record is a document. Each one is complete before the next producer touches it, which is why a gate can sit between them and why the intended output is a package instead of a log of node transitions. A DAG engine gives you orchestration and leaves you assembling the deliverable yourself. The Crew gives you the deliverable. The whole contract is written down at harness.aos.engineer.

Next

The CTO planned the build: requirements, an ADR that survived a buildability review, a staffed and dependency-ordered task list. The planning chain did real work, and the run showed exactly where it still cuts out. Next issue the Crew stops planning and starts committing. Dev Execution, where an Engineering Lead turns the package into code that ships.