Autonomous Agent Organization

The Team.

Nineteen specialized AI agents across two workspaces — one that decides what is worth building, one that takes it all the way to a published, live site. Structured handoffs and quality gates between every stage.

View ProjectsRead Blog
Agents
19
Workspaces
2
Delivery Commands
31
Gate Tokens
5
Architecture

Two workspaces, one organization.

Delivery and intelligence were one repo until July 2026, when they split — deliberately. They answer different questions on different clocks: delivery asks 'is this built and live?', intelligence asks 'is this worth building?'. Splitting them stopped a research cycle and a build pipeline from contending for the same context. They stay joined by one artifact — initiatives.md — where a research bet gets promoted into delivery via /create-prd or /create-frd.

13
Delivery Agents
6
Intelligence Agents
31
Delivery Commands
5
Gate Tokens
The Three Tracks

How the organization is arranged.

Three tracks across the two workspaces. Delivery runs here and owns everything from intake to go-live. Research & CI and Product Management run in the sibling intelligence workspace — same agent-identity model, same orchestration layer, their own repo and their own clock.

01Agents 00-14, 99this workspace

Delivery

Staged pipeline from raw idea to deployed code. Work enters at three weights — a full PRD, a bounded feature (FRD), or a contained bug — over one shared engine. Rubber Ducky brainstorm, spec with adversarial review, architecture + ADRs, UI design with clickdummies, task breakdown with § 4c contracts, TDD enrichment, and slim-context implementation. The engine itself knows nothing about any particular platform: domain knowledge arrives as a pack, resolved once at intake and injected into every stage that needs it.

/prime/rubber-ducky/triage/create-prd/create-frd/create-bug/challenge-prd/probe/discover-sitecoreai/architect/design/task-breakdown/provision-sitecoreai/implement/code-review/test/ship/discover-components/author-content/test-content/publish/document/research/status
02Agents 10-12sibling workspace

Research & CI

Vendor-neutral technology intelligence, competitive analysis, and a developer-experience industry brief across four research lenses: release tracking, security monitoring, ecosystem trends, and community voice. The track outputs strategic initiatives, not a task backlog.

/release-the-minions
03Agents PM-S, PM-J, PM-Csibling workspace

Product Management

Technical PM evaluation of managed repositories as product surfaces. Each PM specialization consumes upstream research and CI briefs, then produces a register of initiatives gated by altitude and control — the bets that repo actually owns.

/release-the-minions
Core Principle: Identity / Command Separation
Agent files define persona and expertise only — no task instructions, no output formats. Commands inject the task, input/output contracts, and handoff rules at runtime. The Product Manager can write a spec, challenge a spec, or revise one — depending on which command invokes it and in what mode. This separation means any agent can be reused for different tasks without creating new agent files. It was one axis short for a long time, and the missing one had a measurable cost: domain knowledge had nowhere to live, so it leaked into both. The principle now reads agents are identities · commands are tasks · packs are domains.
Explore the Framework→
Packs — the third axis

One engine, composed rather than forked.

Domain knowledge — what you build on, where the spec comes from, who is driving — used to be spelled inline across the shared commands. That works until there is a second of anything, and then adding one means editing every stage. So a run now answers three independent questions at intake and the answers COMPOSE: three dimensions, ten runnable combinations, one engine. The incoherent combinations are refused by name at resolution time rather than discovered halfway through a build. Adding a platform is writing one declaration file; it is not a new flow, and it is never a new repo.

platform

What are you building on?

Contributes the scaffold, the skills each stage loads, the definition of done, the release step and any stage the target genuinely needs. A platform may own stages — or none at all: one of mine owns zero, and its entire behaviour is data on stages the core already ran.

method

Where does the spec come from?

Greenfield means the spec is interrogated out of the operator one question at a time. The alternative is that an existing artifact IS the spec, in which case discovery is replaced by measurement and "done" becomes a score rather than a feature list. This is the only dimension permitted to remove a stage.

audience

Who is operating the run?

Additive only, and a validator enforces that rather than a convention — it may swap a template and add questions, never override a stage. Nothing is added to or removed from the flow; what changes is which artifacts a human is ever shown, and which answers are derived instead of asked.

Rule 88 — a gate must fail when nothing uses the thing
The most expensive lesson of the year, and it arrived five times in one day. Every gate verified that a thing was correctly SHAPED. Every defect lived in whether anything USED it. A declaration nothing read. An ordered sequence missing a step that every individual declaration got right. A generated artifact that validated but had never once been executed. A template whose placeholders were escaped, so the prose never rendered. A safety boundary that matched file paths while the thing it guarded lived in file contents. Structural green is not functional green, and the counter-move is not a cleverer gate — it is running the thing. Four of the six were found by execution and none by inspection.
The Core Pipeline

From idea to production.

Seven agents in sequence: Team Lead orchestrates, Product Manager specs, Architect designs, UI Designer proposes, Lead Developer breaks down, QA enriches, Developer implements. A final /ship stage closes the loop with a release checklist. Each output becomes the next input through structured handoffs.

Orbital view — CSS 3D component
00
Team LeadOrchestration & Gates
Agent 00 — Orchestration & Gates
Sequences specialist agents, validates handoffs between stages, and enforces quality gates. Low ceremony — stops bad artifacts before they propagate downstream.
02
Product ManagerPRD & Spec Review
Agent 02 — PRD & Spec Review
Writes testable specs from brain dumps, defends MVP scope, and runs adversarial 'pessimistic roast' sessions to stress-test requirements before they reach architecture.
04
Software ArchitectArchitecture & ADRs
Agent 04 — Architecture & ADRs
Converts PRDs into concrete technical blueprints with explicit Architecture Decision Records. Consequence-oriented — names trade-offs and checks for conflicts with existing decisions.
05
UI DesignerDesign Proposals & Clickdummies
Agent 05 — Design Proposals & Clickdummies
Produces 1-3 fundamentally divergent design directions with full rationale and self-contained HTML clickdummies for browser evaluation. Research-grounded aesthetics — asks constraints before designing, not after.
06
Lead DeveloperTask Breakdown
Agent 06 — Task Breakdown
Breaks epics into atomic tasks with stable IDs and the mandatory § 4c execution contract — seven subsections that give the Developer everything needed without opening other docs.
07
QA SpecialistTDD Enrichment
Agent 07 — TDD Enrichment
Embeds test-first discipline directly into the task breakdown before implementation starts. Edits tasks in-place, reorders for RED-GREEN-REFACTOR, ensures tests are behavioral.
08
DeveloperImplementation
Agent 08 — Implementation
Slim-context executor who receives only prd-minimal + enriched task breakdown. Implements exactly what was planned — stops and asks rather than compensating for ambiguous specs.
On-Demand Specialists

Called when needed.

Six agents that operate outside the linear core pipeline. Four are pulled in when the context calls for them — to surface hidden assumptions before planning, ground a fuzzy claim mid-conversation, extract structure from an existing site, or run a heavy documentation pass. Two more are contributed by a platform pack rather than by the core: a DevOps Engineer that provisions infrastructure, and a Content Author that writes and lands content. They live inside the pack, and a run that does not compose that pack never sees them.

01
Rubber Ducky
Brainstorm & Discovery

Interrupt-first brainstorming facilitator that forces clarity through relentless questioning. Surfaces gaps, assumptions, and scope creep before they become costly.

Invoked via /rubber-ducky — standalone, pre-pipeline. Produces a concept brief that feeds into PRD creation.
03
Research Sidecar
Inline Research Delegate

On-demand research delegate invoked mid-conversation by the Rubber Ducky or Product Manager to ground a fuzzy claim. Returns a short, decision-grade synthesis from live sources — without polluting the caller's context.

Pulled in mid-conversation via /researchby the Rubber Ducky or Product Manager — returns a decision-grade synthesis from live sources without polluting the caller’s context.
09
Doc Writer
Documentation Passes

On-demand technical writer for heavy documentation — full README, architecture docs, decision logs, changelog. Invoked by /document after major milestones, and spawned by /ship in lite mode for the minimal README + CHANGELOG pair. The orchestrator never writes docs itself.

Activated via /document for heavy documentation passes — full README, architecture, and decision logs. /ship spawns it in lite mode for the minimal README + CHANGELOG pair — the orchestrator never writes docs itself.
99
Source Analyst
Source Discovery & Parity

Analyses reference URLs in greenfield mode (lightweight) or crawls a live site for full parity rebuild. Never invents content — labels everything as extracted or inferred.

Invoked via /source-analysis — on demand, only when the operator supplies URLs. Runs in greenfield (lightweight reference) or rebuild (full parity crawl) mode, and classifies which before doing any heavy crawl.
13
DevOps Engineer
Infrastructure Provisioning

Stands up the target platform's topology and deploys the baseline — non-interactive and idempotent, driven from one automation client. Also owns the final publish / go-live. Contributed by a platform pack rather than by the core, so a run that composes no platform never spawns it.

Invoked via /provision-sitecoreai — stands up the decoupled CM + editing host and deploys the baseline before implementation begins. Non-interactive and idempotent.
14
Content Author
Voice-Adaptive Authoring

Writes original, audience-facing content — blog, website, or CMS page content — in a switchable voice register, then lands it in the right channel through whatever authoring interface the active pack declares. A Content QA gate confirms it actually landed. Invoked by /author-content, and contributed by a platform pack.

Invoked via /author-content — writes on-brand content and lands it in the target system through whatever authoring interface the platform pack declares, then a Content QA gate confirms it actually landed.
Development Track

The builders.

13 agents that take a raw idea through brainstorming, specification, architecture, design, planning, testing, implementation, and shipping. 7 form the linear core pipeline; 6 are on-demand specialists — Rubber Ducky, Research Sidecar, Doc Writer and Source Analyst from the core, plus a DevOps Engineer and a Content Author contributed by a platform pack — invoked when the context calls for them.

00

Team Lead

Orchestration & Gates

Sequences specialist agents, validates handoffs between stages, and enforces quality gates. Low ceremony — stops bad artifacts before they propagate downstream.

01

Rubber Ducky

Brainstorm & Discovery

Interrupt-first brainstorming facilitator that forces clarity through relentless questioning. Surfaces gaps, assumptions, and scope creep before they become costly.

02

Product Manager

PRD & Spec Review

Writes testable specs from brain dumps, defends MVP scope, and runs adversarial 'pessimistic roast' sessions to stress-test requirements before they reach architecture.

03

Research Sidecar

Inline Research Delegate

On-demand research delegate invoked mid-conversation by the Rubber Ducky or Product Manager to ground a fuzzy claim. Returns a short, decision-grade synthesis from live sources — without polluting the caller's context.

04

Software Architect

Architecture & ADRs

Converts PRDs into concrete technical blueprints with explicit Architecture Decision Records. Consequence-oriented — names trade-offs and checks for conflicts with existing decisions.

05

UI Designer

Design Proposals & Clickdummies

Produces 1-3 fundamentally divergent design directions with full rationale and self-contained HTML clickdummies for browser evaluation. Research-grounded aesthetics — asks constraints before designing, not after.

06

Lead Developer

Task Breakdown

Breaks epics into atomic tasks with stable IDs and the mandatory § 4c execution contract — seven subsections that give the Developer everything needed without opening other docs.

07

QA Specialist

TDD Enrichment

Embeds test-first discipline directly into the task breakdown before implementation starts. Edits tasks in-place, reorders for RED-GREEN-REFACTOR, ensures tests are behavioral.

08

Developer

Implementation

Slim-context executor who receives only prd-minimal + enriched task breakdown. Implements exactly what was planned — stops and asks rather than compensating for ambiguous specs.

09

Doc Writer

Documentation Passes

On-demand technical writer for heavy documentation — full README, architecture docs, decision logs, changelog. Invoked by /document after major milestones, and spawned by /ship in lite mode for the minimal README + CHANGELOG pair. The orchestrator never writes docs itself.

99

Source Analyst

Source Discovery & Parity

Analyses reference URLs in greenfield mode (lightweight) or crawls a live site for full parity rebuild. Never invents content — labels everything as extracted or inferred.

13

DevOps Engineer

Infrastructure Provisioning

Stands up the target platform's topology and deploys the baseline — non-interactive and idempotent, driven from one automation client. Also owns the final publish / go-live. Contributed by a platform pack rather than by the core, so a run that composes no platform never spawns it.

14

Content Author

Voice-Adaptive Authoring

Writes original, audience-facing content — blog, website, or CMS page content — in a switchable voice register, then lands it in the right channel through whatever authoring interface the active pack declares. A Content QA gate confirms it actually landed. Invoked by /author-content, and contributed by a platform pack.

Slim Context Chain
Later stages load only what they need. The Developer (08) receives prd-minimal + enriched task breakdown — never the full PRD, architecture, or UI specs. If the task breakdown's § 4c execution contract is incomplete, that's a planning gap to fix upstream, not a context gap for the implementer to fill.
Operator Gates

Five stops, and you can remove all five.

Autonomy here is a dial, not a posture. There are exactly five places the pipeline stops for a human — and each one is a token you can untick independently. Tick all five and you get a supervised run. Untick all five and it is fully autonomous: even the live publish goes unattended. The point of naming them is that the set is finite and inspectable; you always know exactly where you will be asked.

spec
Fires at /challenge-prd close

The reviewed spec. A cold-read gap analysis has already grilled the operator over the ranked gaps and merged the answers back in — this is the look at what that produced.

design
Fires at /design close

The clickdummy. One stop, one decision: which POC wins. With the token off, the top-scored variant is auto-selected and recorded rather than skipped.

build
Fires at /test close

The single look at the whole implementation, on whatever preview surface the active platform pack provides. Platforms that have no such surface fold this stop into final.

final
Fires at /test-content close

The last look before go-live, after the content phase has run against preview. For non-content runs this is /test.

go_live
Fires at before any real-tenant mutation

Provisioning, the first real write, live writes, the /publish go-live. The one gate that guards irreversible things happening to somebody else’s tenant.

What a gate token actually controls
A gate token gates the stop — never whether the operator exists. That distinction cost me a real defect: the wiring read gates.spec: false as “nobody is watching” and silently turned both spec stages into monologues, shipping unvalidated assumptions into the build. Turning one token off describes someone who wants fewer interruptions, not an absent human, so the interrogation still runs and the stage simply closes soft. Only every token off means nobody is there to answer. Two invariants hold regardless: the build phase is autonomous — never per-component, never mid-build — and genuine blockers always stop. Autonomy removes review stops, not error handling.
The Interrogation Protocol

Rigor is a question budget.

The spec stages are interrogations, not questionnaires. One question per turn, each derived from the last answer, pushing back on every hedge — run inside the spawned Product Manager against an on-disk ledger the next agent reads by path. The rigor dial sets the budget: light 3–5, standard 8–12, thorough 20+ and uncapped. It is a floor, not a target. A grill ends when the budget is met, when the questions stop finding anything, or when the operator takes the standing 'Enough — stop asking' option.

This replaced a batching scheme — one to three rounds of grouped questions — and the replacement is the whole point. Batched questions are answerable without thinking. You skim eight of them, answer the four you already have opinions about, and the other four get a plausible shrug that reads as a decision downstream. Asking one at a time, derived from what you just said, is what makes a spec stage feel like being interviewed instead of like filling in a form — and it is the difference between a spec that records what I actually decided and one that records what I could produce quickly.

Deliverable vs execution unit
A spec is a deliverable; a tranche is the unit of execution. When work grows, it buys more tranches inside one spec — never more specs by default. All three “this is too big” signals (three or more new SDK surfaces, five or more new ADRs, the length caps) now propose phases inside the spec, each closed by a probe or a real-tenant smoke, so the failure-cliff protection survives without fragmenting the thing being delivered. Splitting into several specs has to pass a three-leg shippability test — standalone value, standalone ship, standalone truth, stated per piece — and a confirmed split writes a program with a finite member count that /ship stamps as phase N of M — not feature-complete on the report, the PR and the changelog until the last member lands.
Research & CI Track · sibling workspace

The researchers.

3 specialists producing vendor-neutral intelligence briefs. The Research Specialist covers technology topics across the modern web stack, the CI Specialist profiles competing platforms with factual SWOT analysis, and the DevX Specialist distils a developer-experience industry trend brief. All apply four shared lenses: release tracking, security monitoring, ecosystem trends, and community voice — and the track outputs strategic initiatives, not a task backlog. Lives in the sibling intelligence workspace since July 2026.

10

Research Specialist

Technology Intelligence

Produces vendor-neutral intelligence briefs across four research lenses: release tracking, security monitoring, ecosystem trends, and community voice. One merged report per technology topic.

11

CI Specialist

Competitive Analysis

Profiles competing platforms with factual SWOT analysis, version tables, and ecosystem assessment. Supplier of downstream PM synthesis.

12

DevX Specialist

DevEx Industry Trends

Produces a single trend-only developer-experience industry brief from signal-quality evidence — the shared get-ahead driver consumed by every PM specialization alongside the technology and CI briefs.

Product Management Track · sibling workspace

The product managers.

3 specialized PMs that evaluate managed repositories as product surfaces. Each consumes upstream research and CI briefs, inspects the actual repo, and produces a register of initiatives — JPD-altitude bets gated by altitude and control — rather than a granular task backlog. A chosen initiative is promoted into delivery via /create-prd or /create-frd.

PM-S

SCB Product Manager

Starter-Repo Evaluation

Technical PM for a managed starter repository. Evaluates repo layout, host assumptions, template maintenance, and alignment with the platform's current direction.

PM-J

JSS Product Manager

JSS Monorepo Assessment

Technical PM for the JSS monorepo. Assesses package topology, peer dependencies, migration pressure, release channels, and developer friction across packages.

PM-C

Content SDK Product Manager

Content SDK Lifecycle

Technical PM for the Content SDK repository. Focuses on package maturity, scaffolding quality, docs alignment, and the JSS-to-Content-SDK lifecycle transition.

Where this leads

Go deeper into how this gets shipped

Methodologies and case studies show the agentic pipeline in motion — the patterns the agents converge on, and what that produced when run end-to-end against real systems rather than mocks.

Read the methodologies→Read the case studies→
Interested?

Build your own agentic workflow

This framework is extensible by composition rather than by forking. The same agents adapt to any domain through command injection and a declarative pack — never a prompt rewrite, and never a second copy of the engine.