Internally Used · V1
Governed Agent Orchestration

Shokunin

A governed operating method for AI agents working across complex, multi-step workflows.

Shokunin separates context, roles, authority, process state, and verification. Agents can act within bounded responsibilities, but completion is determined by evidence—not by the model declaring itself done.

The CTO never writes code directly — it dispatches jobs to born-clean subagents (Tester, Coder, Reviewer) operating in a sequential Swarm HOLD cycle with disk-mediated handoffs.

Internally Used
Active Lab Harness
Powers multi-agent orchestration and delivery for Hard Machine Labs projects.
Role-Separated
Bounded Autonomy
CTO, PO, Tester, and Coder execute with bounded responsibilities and disk-mediated state.
Mechanical Gates
Executable Release Gates
Completion is determined by script exit codes and evidence—never by prose narration.
CONCEPT PAPER · VERSION 1.1

Shokunin: A Governed Operating Method for AI Work

The complete methodological foundation: bounded authority, durable state, lean context, controlled process, independent challenge, and proof over promises.

FIG. 03 — ASSEMBLY LINEVideo
Amnesiac chat vs. disk-based state · The four pillars of execution
System architecture

Zone Topology & Isolated Zones

Every zone reports to the human. No cross-zone dialogue.
Zone & role topology (disk-state isolation)
HUMAN ── (isolated session, one actor at a time)
   │
   ├── GATE AGENT      (Z2 Bootstrap)      ← Scaffold & router
   ├── PROJECT OWNER   (Z1 Governance)     ← Verdict: KILL / PASS / PASS_CONDITIONAL
   ├── PRODUCT OWNER   (Z3 Elicitation)    ← Requirements contract (PRD, Brief)
   ├── CTO             (Z5 Code Pipeline)  ← Dispatches jobs, manages the team
   │     ├─ Tester     (Subagent born clean · HOLD)
   │     ├─ Coder      (Subagent born clean · HOLD)
   │     └─ Reviewer   (Subagent born clean · HOLD)
   ├── OPS             (Z9 Release)        ← Woken by a RELEASE_{NNN}.md artifact
   └── MARKETING       (Z12 Distribution)  ← Content creator (npm / hardmachine-labs)
1No Direct Cross-Zone Dialogue Each zone owns a local .shokunin/handoffs/{zone}/ folder. Continuity between zones passes only through disk artifacts read by a freshly spawned agent.
2Subagents Born Clean A subagent's context is strictly limited to its AGENT.md, its JOB.md, and the artifacts explicitly listed for it — never the CTO's full conversation.
3The CTO Never Codes Even for a 5-line patch, the CTO dispatches to a lightweight Coder subagent (Fast-Track).
Guiding framework

Founding Principles V1 (Non-Negotiable)

PR-1

Reliability Through Reproduction

The system reproduces identically, project after project. Nothing depends on an agent's improvisation.

PR-2

Strict Where the Risk Requires It

Every situation has a rule, and every rule has an executable check. Corollary P-002: “A rule without an executable check does not exist.”

PR-3

Structural Token Economy

JSON + Scripts First. The LLM only does what only an LLM can do (judgment, design, writing). Everything deterministic — validation, counting, state, compliance — runs through scripts and JSON files.

PR-4

Skills Written in English

Every artifact loaded by an agent in production (skills, AGENT.md) is written in English. No linguistic ambiguity.

PR-7

Governed Harness

The harness lives in its own space, owns its own scripts and tests, and validates its own health.

Token budget efficiency

The Swarm HOLD Cycle

5 acts · reused, not reloaded

Instead of invoking disposable subagents that reload their context on every iteration, the CTO keeps the Tester, Coder, and Reviewer awake in HOLD across an entire job. The 5 acts of one cycle:

Cycle 01Context reloads: 0HOLD token burn: 0
1
Wake the Tester.

The CTO wakes the Tester, which writes the tests, then enters HOLD.

2
Wake the Coder.

The CTO wakes the Coder, which implements the solution, then enters HOLD.

3
Audit the diff.

The Reviewer audits the diff and issues a report.

4
Resume from HOLD on a bug.

The Reviewer reports the bug to the CTO only — never directly to the Tester or Coder. The CTO re-dispatches the Coder first to apply the fix, then the Tester to re-verify — sequential, zero context reload.

5
Dismiss the trio.

On job success, the CTO dismisses the trio collectively — gate VERIFIED.

See it in action

Parallelism Is Not Free

See it in action

The Shokunin Debate

Who this is for

Built for teams past the trust gap

Industry-wide 2026 figures (not Shokunin-specific measurements)

Engineering leaders piloting AI coding tools who need the output governed before it reaches production. Teams already paying down AI-generated technical debt. Founders who want a real engineering process without hiring a team yet.

92% · 29%

The Trust Gap

Industry surveys report widespread AI tool usage with low trust in unverified output. Shokunin closes that gap mechanically: nothing is marked done until a script says so. VERIFIED, never DECLARED (PR-2).

Debt

AI-Generated Technical Debt

Industry analyses show technical debt increases after unreviewed AI coding tool adoption. The same agent never writes and reviews its own diff here: Tester, Coder, and Reviewer are always separate, isolated sessions.

Context loss

Agent Amnesia

Multi-agent hand-offs lose context on every step — summarize and it's lossy, pass everything and you blow the window. Tester, Coder, and Reviewer stay in HOLD instead of reloading: a fix resumes with full memory intact, no role-context reload during the measured HOLD cycle.

Governance

Adoption Without Review

Teams are shipping AI-written code faster than they're building the process to govern it. Role separation and mechanical gates are that process here — built in from Z1 (governance) to Z9 (release), not bolted on after.

Trust-gap and technical-debt figures: industry-wide 2026 developer surveys and engineering analyses, not Shokunin-specific measurements.

What Is Verified Today

  • Role separation between CTO, Coder, Tester, and Reviewer agents
  • Sequential HOLD cycle with disk-mediated handoffs
  • Mechanical validation gates before code commit
  • Internally used on Shokunin's own development

What Remains to Be Proven

  • Performance on external production codebases
  • Scaling beyond single-project workflows
  • Quantified defect reduction vs ungoverned prompting
  • Third-party validation
Want your own Shokunin?

I'll build your version of this harness — same role separation, same mechanical gates, same governed-reload discipline — designed around your team's specific workflow.

Tell me what you're building. I design governed multi-agent systems with the same verification rigor as Shokunin.

Build My Shokunin