The AI-First Service Design Operating System

The Death of Workshop Theater

I still believe in fieldwork. I still believe in synthesis walls, service journeys, and the disciplined act of reframing a bad brief into a better problem. What I do not believe in anymore is the theater that often surrounds those methods. The familiar pattern goes like this: three weeks of interviews, a room covered in sticky notes, a heroic synthesis sprint, a polished playback deck, and then a slow decay into screenshots, half-remembered rationale, and political reinterpretation. The team calls that rigor because the workshop felt intense. I call it an unversioned loss of evidence.

The problem is rarely a lack of intelligence. It is a lack of executable structure. A quote becomes a theme because somebody remembers why. A theme becomes an insight because the room nodded. An insight becomes a concept because it sounded plausible in a workshop. By the time engineering asks, “What exact evidence supports this service change?”, the answer lives in Slack fragments, slide speaker notes, or a designer’s memory. That is not a practice. That is oral tradition with brand typography.

Static deliverables make the problem worse. A journey map can be beautiful and still die on impact. A blueprint can look comprehensive and still hide invented dependencies. Traditional service design artifacts are usually final-form documents pretending to be living systems. They are snapshots of a team’s temporary conviction, frozen before the organization has the chance to test, challenge, or operationalize them.

That broken traceability destroys iteration economics. If the first loop required manual coding of transcripts, manual clustering, manual artifact cleanup, and manual review, the team quietly avoids a second loop. The language of iteration stays in the deck, but the operating reality becomes waterfall. Research compresses. Synthesis becomes decorative. Prototypes get staged late, when political sunk cost is already high. The service design process remains conceptually sound and operationally brittle.

ASD starts from a harsher premise: if a service design claim matters, it must survive machine scrutiny. That does not make the practice less human. It makes human judgment more valuable because the administrative sludge is forced into explicit contracts. Evidence rows are typed. Methods are executable. Artifact acceptance rules are machine-checkable. Critic review is explicit. Phase advance requires a human approval receipt. Once those rules exist, service design stops depending on personal heroics and starts behaving like a real operating system.

This is why I use the phrase operating system deliberately. An operating system allocates work, enforces boundaries, manages permissions, and keeps state coherent across interfaces. That is exactly the job here. Service design is no longer a stack of one-off workshop outputs. It is a governed runtime for continuous research, synthesis, ideation, prototyping, measurement, and decision support.

The ASD Operating System Architecture

Earlier drafts called this platform SDAP, short for Service Design Agent Platform. The name is retired because it was too narrow. ASD is wider than a platform and more disciplined than a loose agent bundle. It is an operating system for the practice itself.

At its center is one canonical practice and knowledge contract. The source tree holds ten role instructions in platform/agents, eighty-one skill sources in platform/skills that ship as eighty usable skills, seven authored templates in platform/templates, the compiler in platform/compiler, emitted targets in platform/packs, suite packages under suite/packages, and the book corpus under books/. The compiler projects that single source into twelve emitted targets: agy, buzz, claude-code, cli, codex, dsh, grok, kimi, mcp, omp, opencode, and pi. Different host. Same practice contract.

platform/
  agents/        # 10 canonical role instructions
  skills/        # 81 sources -> 80 shipped skills
  templates/     # 6 authored templates
  compiler/      # compile.mjs, generate-skills.mjs, emit-packs.mjs
  packs/         # 12 emitted targets
suite/packages/
  core/
  knowledge/
  engine/
  agents/
  render/
  runtime/
  ui/
books/           # 20-book corpus
articles/        # case studies and method articles

The first architectural shift is simple and profound: the system stores state in portable project files, not in a host chat transcript. A project can be opened from the CLI, an MCP client, a coding-agent host, BUZZ-linked workflows, or DeepSeek Harness Studio because the runtime state does not belong to the host. It belongs to the project workspace. That is why the same rules hold across surfaces.

The second shift is evidence discipline. ASD recognizes exactly three evidence kinds: quote, telemetry, and document. Each captured row is content-addressed with SHA-256. That sounds technical because it is technical. Service design claims become durable when every downstream artifact can point back to an exact evidence row instead of waving at a workshop memory.

The third shift is that method execution is explicit. Agents do not improvise a service design method from vibes. They call method-run and receive the executable SOP: inputs, role-attributed steps, output kind, acceptance rules, and review gate. The runtime tells the team what the method is, what it expects, and how it will judge success.

{
  "method": {
    "id": "journey-from-transcripts",
    "phase": "synthesis",
    "outputKind": "journey-map"
  },
  "steps": [
    {"role": "researcher", "instruction": "Select evidence rows for the journey scope."},
    {"role": "synthesizer", "instruction": "Cluster moments, tensions, and transitions."},
    {"role": "mapper", "instruction": "Write the journey nodes and evidence references."},
    {"role": "critic", "instruction": "Review evidence sufficiency and structural coherence.", "gate": true}
  ],
  "acceptance": [
    {"rule": "min-nodes", "min": 3},
    {"rule": "min-evidence-per-node", "min": 1},
    {"rule": "field-non-empty", "field": "title"}
  ]
}

The fourth shift is a hard split between generation and enforcement. An agent may draft. It may not silently bless its own work. Artifact writes must satisfy structural integrity and acceptance checks. Failed acceptance does not disappear. It persists as a draft with machine-readable failure rows. If an artifact cites evidence that does not exist, the write fails closed. If an artifact passes structural checks, it still does not become final by default. The Critic reviews it, records evidence-cited rows, and either passes or vetoes it.

The fifth shift is governance. Phase progression is human authority, full stop. Agents can prepare recommendations, summarize evidence, and even draft the approval object, but only a human can authorize the transition. This boundary matters because service design is more than analysis. It is organizational commitment under uncertainty.

The shared loop is therefore exact, not aspirational. It is the same loop every surface must honor:

1. Create or open a project, then capture evidence as quote, telemetry, or document.
2. Run method-run to obtain the executable SOP with role-attributed steps.
3. Write a typed artifact and let acceptance rules check it.
4. Submit the draft to Critic review for a pass or veto.
5. Replay integrity, acceptance, and review through factcheck.
6. Advance the phase only when a human signs with an approval receipt.

That sequence is the heart of the book. The rest of the platform exists to make it portable, auditable, and cheap enough to run continuously.

Mapping the 4D Process to the TISDD Loop and Kumar's 7 Modes

The operating system is new. The underlying discipline is not. I still use Discover, Define, Develop, and Deliver because organizations understand those phase boundaries. I still value the TISDD loop because service design is a composite practice of research, ideation, prototyping, and implementation. I still use Kumar’s seven modes because they tell me what kind of thinking the team should perform, not merely what artifact it should output. ASD does not replace these models. It operationalizes them.

The main correction ASD makes is temporal. In traditional engagements, teams often treat research, synthesis, ideation, prototyping, and delivery as macro-sequential blocks. ASD makes them recur inside every phase. Discover includes evidence capture and early framing prototypes. Define includes research backfill when the evidence is thin. Develop includes measurement design before anything ships. Deliver feeds live telemetry back into the next research loop. The practice becomes recursive instead of ceremonial.

Mode 1, Sense Intent, deserves special treatment. In most organizations the brief arrives as if it were settled truth. ASD treats it as a provisional hypothesis. Because evidence handling and synthesis are faster, I can afford to challenge the client’s framing earlier and with more precision. That is not an AI novelty. It is a service design advantage finally backed by runtime economics.

The loop also gives Kumar’s modes an enforcement surface. “Know People” is not a slogan if the evidence register proves whose voices shaped the map. “Frame Insights” is not a performative workshop move if each insight node must meet minimum evidence density. “Realize Offerings” is not hand-wavy if blueprint consequences, review logs, and phase-gate receipts remain linked in one project store.

That makes the 4D process more honest. Discover is less romantic and more empirical. Define is less mystical and more accountable. Develop is less brainstorm theater and more option engineering. Deliver is less handoff and more operational learning. The phases remain human-readable, but the loop underneath is now machine-enforced.

The Ten-Role Agent Topology

ASD ships ten canonical roles. These are not ten personalities for style. They are ten bounded responsibilities in the operating system: Orchestrator, Researcher, Synthesizer, Mapper, Ideator, Prototyper, Measurer, Critic, Presenter, and Librarian. Together they form a topology of labor that mirrors what a serious service design team already does, except the handoffs are explicit and the boundaries are testable.

The reason this topology works is that it matches the real shape of service design labor. Research and synthesis are different kinds of work. Mapping and ideation are different kinds of work. Measurement and presentation are different kinds of work. When one general-purpose assistant tries to do all of them in one prompt, it collapses the practice into a single opaque reasoning blob. ASD resists that collapse. It externalizes the roles so the project can inspect where judgment happened and where it still needs a human.

The Critic is the load-bearing role here. It sits on the write path. That means the operating system has an internal adversary by default. The Critic’s veto writes a review-veto-log instead of just scolding the draft in chat. Now the defect becomes part of the project’s memory.

{
  "kind": "review-veto-log",
  "reviewOf": "artifact-7f3c",
  "verdict": "veto",
  "rows": [
    {
      "rowKind": "defect",
      "severity": "high",
      "rule": "min-evidence-per-node",
      "message": "The wait-state node cites no evidence rows.",
      "fix": "Add at least one resolvable evidence reference or remove the claim."
    }
  ]
}

That is the difference between agent theater and an operating system. The system does not merely say a draft is weak. It records how the draft failed the contract. In practice this changes team behavior quickly. People stop treating AI output as a clever first draft and start treating it as a submission that must earn promotion through evidence and review.

The Librarian matters more than many teams expect. Service design breaks when method language drifts. A blueprint becomes a process map. A persona becomes a stereotype card. A KPI tree becomes a random metric dump. The Librarian forces the operating system back to canonical method intent, which is essential when eighty skills are meant to remain selectable and distinct across many hosts.

The Autonomy Spectrum: When Agents Lead and When Humans Decide

AI-first service design fails when teams ask the wrong question. The question is not, “Can the agent do this task?” The question is, “What kind of authority should this task carry?” ASD answers by distributing work across an autonomy spectrum rather than pretending every step deserves the same freedom.

At the most autonomous end, I want agents doing volume work that benefits from consistency: parsing transcripts, checking evidence references, generating option sets, scaffolding pilot materials, building KPI trees from approved structures, and replaying fact checks. These are high-friction, rule-shaped tasks where machine stamina beats human patience.

In the middle sit recommend-only tasks. Here the agents can propose insight framings, compare operating models, draft service blueprints, or suggest KPI structures, but they should not treat those proposals as decisions. This is where human design judgment earns its keep. Naming the real tension, deciding what political trade-off matters, and choosing which risk is acceptable are not formatting problems.

At the hard-gated end sit explicit human authorities: participant ethics, scope reframing with sponsors, approval of phase progression, commitment to pilots, and any decision that changes rights, responsibilities, or organizational exposure. The operating system can prepare the packet. It cannot own the consequence.

asd phase-advance \
  --projectId <project-id> \
  --toPhase define \
  --idempotencyKey gate-discover-1 \
  --approvalReceipt '{"receiptId":"gate-discover-1","decision":"approve","rationale":"Discover complete","approvedBy":"service-lead","approvedAt":"2026-08-23T12:00:00Z"}'

That command tells the whole story. The system expects a human approval receipt because human gatekeeping is not implied by a polite sentence in chat. It is an object the runtime can inspect. Agents prepare decisions; humans authorize them. That one boundary protects the practice from a thousand small acts of automation theatre.

Once teams internalize this spectrum, the fear around agentic service design usually drops. People realize the operating system is not trying to replace the designer’s hardest work. It is trying to clear everything around that work so the designer can spend more time on the parts that should remain stubbornly human: building trust, reading institutional power, reframing the brief, and deciding when a service promise is ethically or operationally unsound.

This is the chapter’s core claim. Service design becomes stronger, not weaker, when its repetitive labor is delegated into an evidence-gated operating system and its consequential judgment is made more visible. ASD does not flatten the craft into automation. It sharpens the craft by forcing clarity about what must be explicit, what may be automated, and what still requires a human to stand behind the decision.