# CoS, DDP, and Koan: The Systems Behind the Architecture Author: Pramod Prasanth Published: 2026-02-27 Canonical: https://pramod.ch/essays/cos-ddp-and-koan Description: The synchronous orchestrator, the 10-stage pipeline, and the async agent. How the governance principles actually work in production. --- *This is the companion to [The Architecture That Emerged From Failure](https://pramod.ch/essays/the-architecture-that-emerged-from-failure), which describes the principles. This essay describes the systems.* --- Principles without implementation are just opinions. The [companion essay](https://pramod.ch/essays/the-architecture-that-emerged-from-failure) described why AI agents need governance architecture. This one describes three systems that implement it. Each runs daily across a production codebase with 50+ microservices and 20,000+ automated tests. ## CoS: The Synchronous Orchestrator CoS (Chief of Staff) runs inside terminal sessions. It is an orchestration layer with persistent memory and composable skills. Each skill is a standalone capability with typed inputs and outputs: specification review, technical design generation, test generation, codebase reconnaissance, implementation planning, multi-model code review. Skills compose into pipelines where the output of one becomes the input of the next. When I open a new session, CoS loads context from the previous one: which pipelines need attention, what decisions are pending, what changed since last time. No re-explanation. No lost threads. Session state persists across days and weeks through structured handover documents. CoS doesn't write code. It orchestrates the process around the code. The system that builds the system. The governance principle at work: **expertise encoded as auditable skills, not locked in a person's head.** Specification review criteria, codebase patterns, test generation standards. Each one persists, improves with use, and transfers. When the senior planner leaves an enterprise, the reasoning usually leaves with them. CoS proved that the encoding works. Skills accumulate institutional knowledge instead of losing it. ## DDP: The 10-Stage Pipeline The Development Decision Protocol is where the governance principles become concrete. It is a state machine that every feature flows through, from research signal to merged pull request. Ten stages. Four automation zones. Four entry types. **The stages:** Research is manual. I explore the problem space, gather signals, draft the functional specification. Then Auto Zone 1 fires: the specification goes through a multi-model review council, a technical specification is generated, tests are generated from the technical spec, the codebase gets scanned for integration points, an implementation plan is produced, and a build prompt is assembled. All without me touching it. A manual trigger starts the build. Then Auto Zone 2 takes over: the code review council scores the implementation against the original specification, a correction loop runs until the score meets threshold, and validation prepares the pull request. Stage 10, Pattern and Skill Evolution, feeds lessons from completed features back into the review criteria, the pattern registry, and the skill definitions. **The entry types:** Not every milestone enters at stage one. New features start at the beginning. Remediations (fixing incomplete prior work) skip to reconnaissance. Hotfixes skip to build. Refactors skip the specification stages. Each type has its own stage matrix that determines which stages run and which get skipped. **The gates:** Every stage transition is a quality gate with typed entry and exit criteria. Every human decision at a gate is recorded with rationale, timestamp, and who decided. The code review report is a mandatory persistent artifact with a specification coverage matrix, standards compliance checks, and correction loop history. No report, no merge. **The self-improving loop:** DDP version 1.0 ran for less than a week before version 1.1 was needed, incorporating failure modes discovered in production: remediation entry types for incomplete implementations, mandatory review artifacts, test mock tautology detection. Every few features, the pipeline that builds software gets rebuilt by its own feedback. **Typed contracts between stages. Non-bypassable quality gates. An auditable decision trail.** After 20 features pass through the pipeline, the decision corpus becomes analyzable. Which patterns predict specification rework. Which review scores plateau and why. Which stages are bottlenecks. ## Koan: The Async Agent Between terminal sessions, CoS sleeps. Koan watches. Emails arrive, pull requests get approved, calendar conflicts surface, tasks go stale. Koan monitors all of it and reaches me when something needs attention. **Three components, separated by concern:** Reflex runs heuristic rules before any language model call. If CI failed, immediate alert. If a meeting starts in 30 minutes, notify. If the sender is in the ignore list, discard. Zero cost, instant. This is the pre-filter that keeps language model costs near zero for the 80% of events that have obvious dispositions. Mind handles what Reflex cannot classify. Language model triage, correlation across sources, pulling context from stored records of people and projects. For complex tasks, Mind spawns purpose-built agents with the right tools and context for the specific job. The spawner can switch between Claude and Gemini without rewiring the system. The intelligence lives in the orchestration and agent construction, not in any single model. Gateway delivers. Telegram for quick actions. A native app (iOS and macOS) for content that needs a proper reading surface: meeting prep documents, detailed briefings, generated reports. **The daily briefing connects both systems.** Koan assembles it overnight. I review it in the native app over coffee. When I open a CoS session that morning, the briefing is already loaded as context. CoS knows what Koan surfaced. Koan knows what CoS accomplished. They share state, not just data. **The feedback loop:** Every notification is scored implicitly. Acted on, ignored, or snoozed. A monthly self-evaluation surfaces what's noise. If 78% of GitHub PR notifications get ignored, the system recommends tightening the threshold. If meeting prep has a 92% action rate, keep the settings. Agency requires enforcement boundaries. Action safety lives at the Gateway, not inside the reasoning layer. Three levels: safe actions auto-execute silently, sensitive actions execute then notify with undo, critical actions block until I explicitly approve. Mind cannot bypass these policies. External content passes through input sandboxing before reaching any agent. ## What Breaks Next These three systems are stable. They run daily. They improve with use. But they were designed for a single operator across a handful of projects. The question I am working toward now: what happens when the same patterns need to serve a team? When five people need shared pipeline state, shared skill libraries, shared decision audit trails? When the agent spawner needs to route across organisational boundaries instead of personal ones? That is what ChainAlign is for. The personal system found the patterns. The enterprise system will test whether they hold at scale. None of this is finished. I am documenting the journey at the start, not writing from the end. These systems are months old, not years old. The patterns feel right but they have not survived every stress test yet. I am sharing them now for two reasons: to create a record of what I have learned so far, and because the best feedback comes from people building in the same territory. If that is you, I would like to hear what you have found.