The useful version of an AI workforce is not twenty autonomous agents improvising in the same repo. It is a small technical org: one conductor, scoped workers, boring automations, and verification gates. Run it that way and the models save attention instead of consuming it.
Start with the minimum structure that can actually survive a week of work. Anything smaller becomes babysitting. Anything much bigger becomes coordination theater.
| Part | Owns | Keep it useful |
|---|---|---|
| Conductor thread | Priorities, architecture, sequencing, human questions, final synthesis | One visible place decides what matters next. |
| Durable repo truth | AGENTS.md, CLAUDE.md, tickets, current-state docs, verification guides | Keep it short, accurate, and close to the code. |
| Scoped workers | One ticket, one research slice, or one file family at a time | Worker context is disposable; conductor context is protected. |
| Worktrees | File isolation for parallel implementation | One worker owns one file set. No shared edits. |
| Automations | Recurring checks, reports, triage, and reminders | Prove manually before scheduling. Start read-only. |
| Verifier pass | Tests, lint, browser smoke, diff review, manual checklist | A green run is not proof. Evidence is proof. |
Think like a small technical org. The conductor is not a worker. Workers are not automations. Automations are not verifiers. Blurring those roles is where most waste starts.
Maintains the thread of intent: product goal, current plan, open risks, and what needs a human decision. It delegates search and implementation instead of reading everything itself.
Subagents, Codex threads, or Claude teammates that handle bounded work. Search workers can be cheap and read-only. Implementation workers use worktrees when parallel.
Scheduled or event-triggered runs for work that is repeatable and worth reading. Claude routines run in the cloud. Codex automations are useful but often depend on an awake host.
A separate pass that checks the artifact, not the story the worker told. Fresh-context review catches implementation bias. Hooks and test gates handle must-happen checks.
| Work | Default | Why |
|---|---|---|
| Repo search, log triage, file inventory | Haiku/read-only subagent | Verbose output stays out of conductor context. |
| Normal coding, tests, small refactors | Sonnet worker | Best default cost-to-capability trade. |
| Hard architecture, root-cause reasoning, final synthesis | Opus conductor or reviewer | Spend premium tokens where judgment matters. |
| Large independent orchestration run | Opus 4.8 + /effort ultracode Dynamic Workflow | Use when Claude should delegate the orchestration itself, not just the work. Expensive, so require lanes, ownership, evidence, and human checkpoints. |
| Long-running local shell command | Agent View ! cmd or claude --bg --exec | Attachable work that stays visible in the conductor dashboard instead of blocking your main session. |
| Same-file sequential work | One agent | Parallelism adds conflict and coordination overhead. |
| Independent modules or review lenses | 3-5 workers as a starting range | Enough parallelism to get real breadth without turning coordination into the work. |
This is the non-glamorous loop that makes the workforce useful. It is closer to running a tight engineering standup than summoning a swarm.
Start from tickets, failed checks, PR comments, user notes, and automation reports. Ignore anything nobody will act on.
The conductor chooses the next smallest valuable outcome. If the work fans out cleanly, partition it before spawning workers.
Each worker gets exact files, allowed areas, done criteria, and what evidence to return. Use worktrees for parallel implementation.
One integrator owns the final merge, resolves conflicts, updates durable docs, and removes stale plans from the repo.
Run tests, lint, browser/device smoke when relevant, and a fresh review pass. The verifier checks behavior, not confidence.
If a manual loop was useful twice, convert it into a skill, hook, routine, Codex automation, or one-off scheduled reminder.
If a run produces a report you will not read, delete the automation. Green-but-ignored automation is just another inbox.
The point is not to ask the human more often. It is to ask only when judgment, liability, or irreversible action is involved.
| Stop and ask | Why |
|---|---|
| Deploys, migrations, billing, webhooks, production data | Irreversible or externally visible changes need explicit approval and a rollback story. |
| New dependencies, auth/security changes, permission broadening | The worker can miss long-term maintenance or attack-surface cost. |
| Ambiguous product decisions | Models can rank options, but the owner decides tradeoffs. |
| Client-facing copy, emails, public announcements | External voice and commitments are not a place for silent autonomy. |
| Surprising diffs or test failures that do not match the task | Unexpected scope expansion is a signal to pause, not rationalize. |
Everything else should be handled by deterministic gates: hooks for blocked files/commands, tests for behavior, worktrees for isolation, and fresh-context review for sanity.
These are the common ways an automated workforce burns attention and tokens without producing leverage.
More agents only helps when the work is independent. Otherwise you pay for duplicated context, coordination, and merge cleanup.
Two workers touching the same file is not collaboration. It is a race condition with a prose interface.
CLAUDE.md and AGENTS.md should hold facts that prevent mistakes, not tutorials, stale preferences, or architecture tours no one maintains.
If the manual process is still vague, the scheduled run will be vague at 3 a.m. Start read-only/report-only.
Dynamic Workflows delegate orchestration itself. That is the power and the trap. Without owned lanes, stopping criteria, and evidence requirements, it becomes expensive momentum instead of useful work.
If the keyword trigger is on, talking about workflows can start a bigger run than you meant. Turn it off in /config if you prefer explicit workflow launches.
A routine or automation can exit cleanly while failing the actual job. Read the transcript or require an artifact.
Long threads full of failed attempts get worse. Use subagents for exploration and clear/compact between unrelated tasks.
Do these in order. Each one has a clear output, low blast radius, and teaches the operating model without pretending autonomy is magic.
| # | Automation | Start as | Done means |
|---|---|---|---|
| 1 | Morning triage report | Read-only routine or Codex automation | Lists new issues, PRs, failed checks, and recommended first task. |
| 2 | PR feedback watcher | Event or scheduled report | Summarizes unresolved review comments with exact files and owners. |
| 3 | Docs drift sweep | Weekly read-only worker | Flags docs that conflict with recent merged code or changed APIs. |
| 4 | Test failure investigator | Scoped subagent/worker | Returns likely cause, commands run, and the smallest proposed fix. |
| 5 | Fresh-context code review | Skill or dedicated reviewer agent | Findings are prioritized with file/line evidence, not style nitpicks. |
| 6 | Deploy health checker | Manual first, then API-triggered | Runs smoke checks, scans logs, posts go/no-go evidence. |
| 7 | Future cleanup reminder | One-off scheduled run | Reminds or opens a small cleanup ticket after a flag, migration, or experiment window. |
This page is synthesized from the public guide research and current product docs. The private repo notes are not required to use the blueprint.
/simplify.