The Future of Service Design: The Agentic Practice

The Practice After Automation

The first thing that compounds in an agentic practice is not speed. It is continuity. A conventional project often loses its memory after each handoff: research sits in one tool, synthesis in another, delivery in tickets, and learning in whatever the team manages to remember six weeks later. ASD tightens that loop. Evidence is content-addressed. Methods are executable. Artifacts are typed. Review verdicts are stored. Factcheck can rerun the whole project. Human phase receipts say who decided what. That stack does save time, yes, but the deeper gain is that the service-design practice stops forgetting itself.

That continuity changes the economics of rigor. Once the cost of re-running a method, refreshing a blueprint, rebuilding a standards pack, or challenging a decision falls, teams can afford to stay honest for longer. The blueprint can be one day stale instead of forty-two. The review can happen before release instead of after harm. A junior designer can inherit method safety rather than only “tips.” A practice lead can see whether quality is actually improving or merely sounding more polished. The whole discipline gets less theatrical.

The series kept returning to this from different angles. Article 29 showed methods becoming executable. Article 22 showed service quality turning into a standing operating rhythm. Article 23 showed principles becoming merge gates. Article 24, the mastercase, shows cross-surface continuity as one workspace rather than several disconnected performances. By the time I get to this closing chapter, the pattern is hard to ignore: the practice gets stronger when its judgments are made more visible, more reviewable, and more portable.

Compounding also changes what “reuse” means. In the older mode, reuse often meant dragging yesterday's slide or framework into tomorrow's workshop. In the agentic mode, reuse means something stricter: the method keeps its provenance, the artifact kind keeps its contract, the review row keeps its evidence, and the emitted pack keeps its lineage. That is a much higher-quality reuse pattern. It creates memory with accountability attached instead of memory by copy-paste.

{
  "loop": [
    "evidence",
    "method-run",
    "typed-artifact",
    "critic-review",
    "factcheck",
    "human-phase-gate"
  ],
  "properties": {
    "deterministic_rendering": true,
    "draft_on_failure": true,
    "approval_receipt_required": true
  }
}

None of this means every service-design team needs to become a software platform team. It does mean the practice has to become infrastructural in its thinking. The output is no longer just the workshop summary or the final deck. It is the durable operating layer that keeps a service legible after the project team leaves. That is a different professional ambition. I think it is the right one.

Open Problems and Phase 2 Boundaries

There are also straightforward inventory facts worth holding onto because they keep the conversation concrete. The current practice contract spans 10 canonical roles, 80 shipped skills from 81 sources, 30 runtime sd_* tools, 228 corpus resources, 10 prompts, 38 registered artifact-kind contracts, 39 vocabulary rows, 7 authored templates, and 12 emitted targets. I do not cite those numbers as a vanity metric. I cite them because scale changes the design problem. Once the library is that broad, hand-waved consistency is no longer enough.

ASD is already useful, but it is also unfinished in visible ways. I do not see that as a weakness. I see it as part of the discipline's honesty contract. A mature platform should say which capabilities are live, which are bounded, and which are still architectural intent. Several of the most interesting problems sit exactly in that gap.

The first boundary is subtle but important. The platform knows 38 artifact-kind contracts and 39 catalog vocabulary rows, yet it is explicit that not every catalog row is already a live runtime form. That is good discipline. It stops teams from mistaking a documented idea for an enforced schema. Phase 2, in this context, means deeper per-kind typed runtime schemas that carry more of the artifact's structure directly into the write path. That would shrink ambiguity further, especially for report-like and orchestration-heavy outputs.

The ACP boundary is equally important. asd-acp/1 already gives typed record envelopes for identity, capability negotiation, session, handoff, orchestration, and related events. But the current contract is record-only. A record can say a host-agent spawn was requested or unsupported. It does not itself create transport, relay, or execution. That might sound restrictive. I think it is actually a sign of maturity. Too many systems pretend a logged intention is the same as a verified capability. ASD refuses that shortcut.

{
  "protocolVersion": "asd-acp/1",
  "capabilities": [
    "record-only"
  ]
}

BUZZ exposes the same design ethic. The native Persona Pack is real. Ten keyless persona definitions are real. The safe operational sequence is real. The observed article slice is real. What is not yet fully proven is durable workspace persistence across the whole loop, visible Critic verdict persistence, ACP spawn, and recovery/reload/cleanup claims. That gap is not an embarrassment. It is exactly the kind of evidence boundary a trustworthy platform should publish before the market forces it to overclaim.

node scripts/buzz-live-identity-audit.mjs   --input ./audit.json   --channel-id 123e4567-e89b-12d3-a456-426614174000   --output ./identity-audit.json
buzz channels members --channel 123e4567-e89b-12d3-a456-426614174000

Then there is host execution evidence more broadly. The emitted targets are twelve: agy, buzz, claude-code, cli, codex, dsh, grok, kimi, mcp, omp, opencode, and pi. That generated breadth is useful. It is not a license to claim each host has been proven live in the same way. Selected surfaces have stronger evidence. Others are still structural projections awaiting runtime receipts. I want more of those receipts, not more confidence theater.

Per-kind typed schemas are the most immediate boundary because they determine how far the runtime can move from general discipline into truly artifact-specific guarantees. Today the platform can enforce shared contracts such as node minimums, evidence minimums, review gates, and non-empty fields. That already eliminates a lot of weak work. But richer typed schemas per artifact kind would let the platform express deeper rules natively: lane dictionaries for blueprints, explanation structures for decisions, or stronger form semantics for reports and orchestration outputs. That is Phase 2 work I want precisely because it would make the human review more meaningful, not less.

Richer ACP transport is the second open problem. The current asd-acp/1 layer is intentionally conservative. It records typed handoffs and capability events, but it does not pretend to be a universal session bus. A richer future ACP would need stronger proofs around spawn, relay, host capability discovery, and durable cross-host execution semantics. In other words, it would need to earn transport status instead of inheriting it rhetorically from its event vocabulary.

Live BUZZ persistence proofs are similarly specific. The bounded observed slice is already valuable because it proves the social choreography of identity, mentions, and Canvas linkage more honestly than many systems prove their whole runtime. Still, the unresolved questions remain real: what persists into the ASD workspace under reload, what survives recovery, how visible Critic verdicts remain, and how cleanup behaves over longer-lived channels. Those are not edge cases. They are the difference between a compelling live demo and a durable operating surface.

The Designer's Changing Craft

So what becomes of the designer when more of the method spine is executable? I think the craft gets sharper, not thinner. The designer becomes less valuable as a human template expander and more valuable as a framer of boundaries, tests, owners, risks, and consequences. Someone still has to decide which uncertainty matters. Someone still has to smell when a metric is becoming coercive. Someone still has to decide where a human gate must harden because dignity, law, or politics outruns the schema.

That means the future service designer needs a wider competence stack. Classic service craft is still the floor: research quality, synthesis, journey logic, blueprint literacy, facilitation, prototyping, measurement. On top of that sit prompt anatomy, evidence literacy, repository discipline, tooling judgment, and governance design. I do not mean that every designer must become an engineer. I mean the designer has to understand enough of the substrate to shape how service decisions survive contact with software.

The human line also gets more specific. Framing stays human. Ethics stays human. Vulnerability and dignity trade-offs stay human. Final escalation language in high-stakes domains stays human. Phase advance stays human. Taste stays human too, though I use that word carefully. By taste I mean the practiced judgment that knows when a service is technically consistent but socially wrong, when a clean-looking flow is hiding a burden shift, or when an audit pass still feels untrustworthy because the service has optimized the wrong thing.

The same broadening happens in team leadership. A future design lead needs to know when a method should become part of the shared library, when it should remain engagement-local, when a gate should fail closed, and when a team is mistaking throughput for value. Those are product decisions about the practice itself. They require strategic patience, operational literacy, and enough humility to publish a boundary instead of covering it with language.

This is why I resist the lazy story that AI makes service design either obsolete or effortless. It does neither. It removes some mechanical drag. It raises the value of explicit judgment. It punishes vague ownership. It rewards designers who can hold evidence, operations, policy, and human experience in one frame at once. That is a demanding future. It is also a better one than the old theater of static artifacts and implied wisdom.

must_remain_human:
  - service_framing
  - vulnerability_and_dignity_tradeoffs
  - final_escalation_language
  - approval_receipt_for_phase_gate
  - consequential_go_no_go_decisions
agent_supports:
  - evidence_synthesis
  - artifact_drafting
  - deterministic_checks
  - standards_regression
  - telemetry_refresh

In other words, the future designer is not the last manual craftsperson standing between machines and a deck. The future designer is the author of service constraints, the keeper of accountability, the builder of reviewable methods, and the person who notices when the whole system is getting good at the wrong thing. That is a serious profession. I want more of it, not less.

Build in the Open

If this book has one practical closing instruction, it is this: build the practice in the open enough that your claims can be challenged. That does not mean exposing private client data. It means publishing the method boundaries, the emitted packs, the receipts, the provenance, and the explicit unknowns. ASD already points in that direction. The distribution repos separate concerns cleanly: imehr/asd-plugin carries the coding-agent host packs and native Claude Code plugin surface; imehr/asd-mcp carries the standalone MCP server. Both are emitted from the canonical suite, and both can ship a provenance.json file that records the source commit. The public website at sammozaffari.github.io/portfolio makes the practice legible outside the repo.

{
  "distribution": "imehr/asd-plugin",
  "sourceCommit": "e94f006f2283",
  "emittedTargets": [
    "claude-code",
    "codex",
    "buzz"
  ]
}

I care about this because service design has a long history of hiding method quality behind charisma, bespoke decks, and selective storytelling. Build-in-the-open is the opposite move. Show the pack. Show the contract. Show the receipt. Show the unresolved boundary. Show the exact place where you stopped claiming more than the evidence allowed. That is how a field becomes trustworthy under automation.

The repos and the website are distribution surfaces, but the deeper commitment is cultural. When a method changes, the diff should be reviewable. When a gate fails, the reason should be inspectable. When a host is only structurally emitted, the docs should say so. When BUZZ proves one bounded slice and no more, the caption should say so. When ACP is record-only, the team should resist the urge to narrate it as transport. The future practice is more agentic and more precise about truth.

That open posture is why I care so much about the distribution split. imehr/asd-plugin and imehr/asd-mcp are not marketing side projects. They are accountability surfaces. The plugin repo proves what host packs actually receive. The MCP repo proves the standalone server contract. The website makes the practice legible to people who will never read the monorepo. Together they create a public trail from source practice to emitted distribution to human-readable explanation. That is how an agentic design system earns trust over time.

node scripts/publish-distribution-repos.mjs
node platform/compiler/emit-packs.mjs --output /tmp/asd-packs

There is also a cultural reason to prefer this explicitness. Once a practice starts publishing its receipts and its missing proofs side by side, internal conversations improve. Engineers stop treating design as handoff theater. Operators stop treating standards as abstract ideals. Designers stop pretending confidence can substitute for traceability. The work becomes calmer because the claims get smaller and truer.

That is where I want to leave this second edition. The agentic practice is not a fantasy of autonomous designers replacing human work. It is a way of making service design more durable, more explicit, more reviewable, and more accountable under real operating conditions. The tools are finally good enough to force the question. The answer, I think, is to encode what should be encoded, verify what can be verified, publish the evidence boundaries, and keep the consequential human judgments visible. If we do that, the field does not shrink in the age of agents. It grows up. And a grown-up discipline is exactly what services shaped by software, policy, operations, and AI now require. That is the future this platform is trying to practice in public.