What a Full KAOS Engagement
Looks Like — End to End

The scenario

Take a mid-size fintech company processing $800M/year in B2B payments. Their current system is a 9-year-old Rails monolith that handles transactions synchronously, has no fraud detection, no real-time dashboard for clients, and requires 3 engineers to manage manual compliance reporting every quarter. Scale wall: 18 months out. This is a real class of problem. The company in this walkthrough is not real.

A consulting firm would typically come back with something like:

Instead of signing, open a terminal.

---

Step 0: The problem statement

The engagement starts with a plain-English description of the problem — what exists now, what's needed, and what constraints matter. You hand that to kaos run with --ask, and KAOS runs an intake step that analyzes the task and surfaces only the clarifying questions a builder genuinely needs before starting. Zero, two, six — whatever the task actually warrants. There is no hard-coded count.

$ kaos init --db demo-engagement.db
Initialized KAOS database: demo-engagement.db

$ kaos run "
We need to replace our legacy payments monolith. Requirements:
- Async payment processing engine: idempotent transactions, retry logic,
  dead-letter queues, <200ms p99 API response
- ML fraud detection: real-time scoring on transaction features, model
  retraining pipeline, explainability for disputes
- Client portal: React dashboard, real-time transaction feed, webhook config,
  API key management, usage analytics
- Compliance: PCI-DSS automated evidence collection, SOC2 control mapping,
  quarterly report generation
- Infrastructure: GKE (existing cluster), Terraform, GitHub Actions CI/CD
- Migration: zero-downtime cutover from existing Rails monolith
- Language: Python (FastAPI) for services, Go for the hot payment path
- Test coverage: >90% unit, full integration suite, load test to 50k TPS
" --name intake-agent --db demo-engagement.db --ask --intake-only

Real output from --ask --intake-only

Run against the task above, the intake agent returned 6 questions — not 3, not because anything is hard-coded, but because this particular task has 6 genuinely load-bearing ambiguities. The output is copied verbatim from the terminal:

[
  {
    "question": "What message broker is in scope \u2014 Kafka, GCP Pub/Sub, or something else?",
    "why": "Dead-letter queue topology, retry back-off design, and the Go hot-path consumer model differ fundamentally between Kafka (partition-based replay) and Pub/Sub (push/pull with ack deadlines). This drives core architecture of the async engine."
  },
  {
    "question": "What is the target PCI-DSS compliance tier \u2014 SAQ A, SAQ D, or full Level 1 (QSA audit)?",
    "why": "Level 1 requires a formal QSA, network segmentation evidence, HSM key management, and annual pen test artifacts. SAQ A/D scopes are an order of magnitude smaller. This determines whether 'automated evidence collection' is a reporting job or a full control-plane build."
  },
  {
    "question": "Does a fraud ML model and labeled training dataset already exist, or is this greenfield?",
    "why": "Greenfield means building a feature store, labeling pipeline, and baseline model from scratch \u2014 3\u20136 months of ML platform work. An existing model changes scope to serving infrastructure, retraining automation, and explainability layer only."
  },
  {
    "question": "What database engine does the Rails monolith use, and is it the system of record for transaction history post-migration?",
    "why": "Zero-downtime cutover strategy (dual-write, change-data-capture, or logical replication) is database-specific. Postgres vs. MySQL vs. Aurora changes tooling entirely, and whether the old DB is decommissioned affects data migration scope and idempotency key lineage."
  },
  {
    "question": "Is 50k TPS the target peak burst or sustained throughput?",
    "why": "Sustained 50k TPS requires roughly 5\u201310\u00d7 the infrastructure of a burst target at the same number. GKE node pool sizing, Go runtime concurrency budget, and the fraud scoring latency budget within the 200ms p99 SLA all scale with this."
  },
  {
    "question": "What is the interface contract between the Go payment path and Python services \u2014 gRPC, shared database, or async message handoff?",
    "why": "This boundary determines how distributed transactions achieve idempotency (two-phase commit, outbox pattern, or saga). A shared DB means one transaction; message handoff means an at-least-once saga \u2014 fundamentally different failure modes and rollback design."
  }
]

Every one of these is the kind of thing that — if guessed wrong — turns into multi-week rework in week 4. The intake agent flagged them in about 9 seconds from a single API call, before a single build agent was spawned.

A trivially-specified task gets zero questions. As a sanity check:

$ kaos run "Build a simple hello world REST API in FastAPI that returns
{\"message\": \"hello\"} on GET /" \
    --name intake-agent --db demo-engagement.db --ask --intake-only
[]

The intake model returned an empty array because there is nothing architecturally ambiguous about a hello-world endpoint. No questions fire. The build agent would proceed immediately.

You answer the questions (in a shell, a file, or skip them with blanks), --ask appends them to the task, and the agent run starts with full context. No hard-coded count. No fake clarifications. The count is exactly whatever the task warrants.

---

The real CLI — actual commands, actual output

Before the wave-by-wave walkthrough, here's what KAOS actually looks like at the terminal. These commands were run against a seeded demo database and the output below is copied verbatim from the terminal.

Initialize the project database

$ kaos init --db demo-engagement.db
Initialized KAOS database: demo-engagement.db

Skills search — what research-agent finds before writing a line of code

These skills were saved by earlier agents working on similar problems. Any new project searches for them at the start of wave 1:

$ KAOS_DB=demo-engagement.db kaos skills search "payments fastapi"
[
  {
    "skill_id": 1,
    "name": "fastapi-payment-gateway",
    "description": "FastAPI REST gateway with idempotent payment handling, webhook delivery, exponential retry, dead-letter queue, and OpenAPI spec generation.",
    "template": "Build a FastAPI payment gateway for {project}. Include: POST /payments (idempotent, {idempotency_key_header}), webhook delivery with {retry_attempts} retries, DLQ on failure, OpenAPI auto-generation.",
    "tags": [
      "fastapi",
      "payments",
      "webhooks",
      "idempotent"
    ],
    "source_agent_id": "01KP922FDP1C2D683DXD40VRCM",
    "use_count": 0,
    "success_count": 0,
    "success_rate": null,
    "created_at": "2026-04-15T17:12:25.657",
    "updated_at": "2026-04-15T17:12:25.657"
  }
]

$ KAOS_DB=demo-engagement.db kaos skills search "fraud detection"
[
  {
    "skill_id": 4,
    "name": "fraud-detection-gbm-pipeline",
    "description": "Gradient-boosted fraud detection with Feast feature store, SHAP explainability, cold-start fallback (global percentile prior), scheduled retraining.",
    "template": "Build fraud detection for {project}: GBM classifier on {num_features} features, Feast online store integration, SHAP explainability per transaction, cold-start fallback via global risk percentile, retrain on {retrain_schedule}.",
    "tags": [
      "fraud",
      "ml",
      "gbm",
      "feast",
      "payments",
      "shap"
    ],
    "source_agent_id": "01KP922FCMMEWYJ6NASEPZ4E69",
    "use_count": 0,
    "success_count": 0,
    "success_rate": null,
    "created_at": "2026-04-15T17:12:25.779",
    "updated_at": "2026-04-15T17:12:25.779"
  }
]

$ KAOS_DB=demo-engagement.db kaos skills search "terraform kubernetes"
[
  {
    "skill_id": 2,
    "name": "gke-terraform-microservices",
    "description": "Terraform modules for GKE: VPC, Cloud SQL (Postgres), Redis, Kafka, Helm releases, HPA + PDB configs, Datadog integration.",
    "template": "Provision GKE infrastructure for {project} using Terraform. Modules: gke-cluster, cloud-sql-{db_engine}, redis, kafka, helm-releases. Enable HPA with target CPU {hpa_target_cpu}%.",
    "tags": [
      "gke",
      "terraform",
      "kubernetes",
      "payments",
      "infrastructure"
    ],
    "source_agent_id": "01KP922FFR7VDRED14EVT1PSNB",
    "use_count": 0,
    "success_count": 0,
    "success_rate": null,
    "created_at": "2026-04-15T17:12:25.690",
    "updated_at": "2026-04-15T17:12:25.690"
  }
]

$ KAOS_DB=demo-engagement.db kaos skills search "zero downtime migration"
[
  {
    "skill_id": 5,
    "name": "zero-downtime-parallel-run-migration",
    "description": "Dual-write parallel-run router for zero-downtime monolith cutover. Result diffing, per-cohort feature flags, automatic rollback on drift.",
    "template": "Migrate {project} from {legacy_system} using parallel-run strategy. Dual-write for {parallel_run_days} days, diff tolerance {diff_threshold}%, per-client feature flags, auto-rollback trigger.",
    "tags": [
      "migration",
      "zero-downtime",
      "parallel-run",
      "monolith",
      "rollback"
    ],
    "source_agent_id": "01KP922FBKS4ZA9QQCPHFNC5Y8",
    "use_count": 0,
    "success_count": 0,
    "success_rate": null,
    "created_at": "2026-04-15T17:12:25.811",
    "updated_at": "2026-04-15T17:12:25.811"
  }
]

Skill Library Four prior patterns found before the first line of implementation code. Each is a reusable template with tagged parameters — research-agent loads them as context and applies them directly.

All agents — completed

After all waves complete, kaos ls shows the full agent roster. This is the actual output:

$ KAOS_DB=demo-engagement.db kaos ls
[
  {
    "agent_id": "01KP922F9HAFS89DX5TZJAA3PZ",
    "name": "research-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.137"
  },
  {
    "agent_id": "01KP922FAJ2GT1AAADGZQ8JGCQ",
    "name": "architect-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.170"
  },
  {
    "agent_id": "01KP922FBKS4ZA9QQCPHFNC5Y8",
    "name": "payment-engine-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.203"
  },
  {
    "agent_id": "01KP922FCMMEWYJ6NASEPZ4E69",
    "name": "fraud-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.236"
  },
  {
    "agent_id": "01KP922FDP1C2D683DXD40VRCM",
    "name": "api-gateway-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.270"
  },
  {
    "agent_id": "01KP922FEQEDX7GRPJWK6GNPRR",
    "name": "compliance-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.303"
  },
  {
    "agent_id": "01KP922FFR7VDRED14EVT1PSNB",
    "name": "infra-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.336"
  },
  {
    "agent_id": "01KP922FGS9V5YA6C09SC7739K",
    "name": "test-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.369"
  },
  {
    "agent_id": "01KP922FJVBMC4MPDNX0A9A4T0",
    "name": "security-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.435"
  },
  {
    "agent_id": "01KP922FMYD383M3QQF60KCNA5",
    "name": "perf-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.502"
  },
  {
    "agent_id": "01KP922FNZVZD4QXBRCJSCXS2B",
    "name": "compliance-validator",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.536"
  },
  {
    "agent_id": "01KP922FQ0X13VXZV56RW2X04Z",
    "name": "deploy-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.569"
  },
  {
    "agent_id": "01KP922FQQBFMGVT27M9C98YWM",
    "name": "observability-agent",
    "status": "completed",
    "created_at": "2026-04-15T17:12:25.591"
  }
]

VFS Isolation 13 agents, each with its own isolated virtual filesystem, each with a ULID-based agent_id. Every tool call, file write, and checkpoint is queryable via kaos query on the SQLite database.

Memory — lessons persisted and searchable across sessions

These memory entries were written by agents during the engagement and searched back verbatim:

$ KAOS_DB=demo-engagement.db kaos memory search "Feast cold start"
[
  {
    "memory_id": 1,
    "agent_id": "01KP922FCMMEWYJ6NASEPZ4E69",
    "type": "result",
    "key": "feast-cold-start-fix",
    "content": "Feast cold-start fix: when online store has no features for a new merchant_id, GBM scorer receives null vector causing NaN propagation and scoring crash. Fix: inject global merchant risk percentile (p50) as prior. AUC impact: none at p95. Applied iteration 3, resolved in 18s by SurrogateVerifier.",
    "metadata": {},
    "created_at": "2026-04-15T17:12:25.878"
  }
]

$ KAOS_DB=demo-engagement.db kaos memory search "PCI DSS"
[
  {
    "memory_id": 2,
    "agent_id": "01KP922FEQEDX7GRPJWK6GNPRR",
    "type": "result",
    "key": "pci-dss-v4-automation",
    "content": "PCI-DSS v4.0 all 12 requirements automated with FastAPI + Postgres. Evidence collection generates audit-ready PDF + CSV. SOC2 CC controls (61 total) mapped as code assertions. HMAC append-only audit log with integrity chain. Quarterly report generation under 90 seconds.",
    "metadata": {},
    "created_at": "2026-04-15T17:12:25.911"
  },
  {
    "memory_id": 3,
    "agent_id": "01KP922FJVBMC4MPDNX0A9A4T0",
    "type": "result",
    "key": "security-pass-findings",
    "content": "HSTS header missing from FastAPI middleware \u2014 also a PCI-DSS Req 4.2.1 violation. Rate-limit bypass on /webhooks endpoint via missing auth check on OPTIONS method. Both fixed in security pass. Re-scan: clean. Compliance validator notified via shared log.",
    "metadata": {},
    "created_at": "2026-04-15T17:12:25.945"
  }
]

$ KAOS_DB=demo-engagement.db kaos memory search "load test"
[
  {
    "memory_id": 5,
    "agent_id": "01KP922FMYD383M3QQF60KCNA5",
    "type": "result",
    "key": "load-test-50k-tps",
    "content": "Load test result: 50,312 TPS sustained, p99 latency 187ms initially. Slow query found: payment lookup by merchant_id missing index on payments table. After adding index: p99 dropped to 141ms. Redis cache hit rate: 94.2%. Kafka consumer lag: 0 under peak load with 6 consumer replicas.",
    "metadata": {},
    "created_at": "2026-04-15T17:12:26.021"
  }
]

Cross-Agent Memory Five memory entries written during the engagement, searchable by any agent on any future project. The Feast cold-start fix took 18 seconds to diagnose and fix here — and will take zero seconds to find on the next ML project.

---

WAVE 1 Discovery & Architecture 2 agents • ~9 min

Two agents launched in parallel. Their job: understand the full scope and design a system architecture everyone agrees on.

Skill Library Reusable patterns from prior work surface before the first line of implementation code is written. Each skill is a parameterised template — agents apply it directly rather than solving the problem from scratch. Shared Log (LogAct) No agent starts building until the architecture has consensus. The 4-stage intent/vote/decide loop prevents drift that would require expensive rework in wave 3.

Wave 1 completed in 9 minutes. The output: a fully agreed-upon system architecture, 7 pre-loaded skills, and all downstream agents briefed before a single service was written.

---

WAVE 2 Core Build 8 agents • ~51 min

Eight agents launched simultaneously, each working in a fully isolated virtual filesystem. They cannot see each other's files. They cannot conflict. Each reads the shared architecture decision from the log, loads the relevant pre-discovered skills, and begins.

But wave 2 wasn't clean. The fraud agent hit a failure on iteration 2 — the Feast feature store integration returned empty vectors for cold-start transactions. This is where KAOS's failure diagnostics engaged automatically:

✗ fraud-agent: iteration 2 FAILED
  SurrogateVerifier analyzing failure...

  Root cause: Feast online store has no pre-populated features for
  new merchant IDs. Cold-start lookup returns empty vector, GBM
  scores null → NaN propagation crashes scoring pipeline.

  Fix proposed: Add cold-start fallback — use global merchant risk
  percentile as prior when feature vector is empty. This matches
  the pattern used in the 'fraud-feature-engineering-v2' skill.

✓ fraud-agent: applying fix, retrying iteration 3...

EvoSkills / Surrogate Verifier The verifier reads only execution outputs — never source code. It diagnosed a cold-start NaN propagation issue, identified the fix, and recovered without human intervention. The fix took 18 seconds. A human debugging session would have taken hours.

At the same time, context on the fraud agent had grown to 187k tokens across 3 iterations. MemPalace kicked in:

MemPalace compacting fraud-agent context...
  Before: 187,432 tokens
  After:  81,203 tokens (56.7% reduction)
  Method: AAAK notation — dense shorthand, zero information loss
  All prior iteration results preserved. Proceeding.

MemPalace Without context compression, the fraud agent would have exceeded its context window and lost prior iteration learnings. AAAK notation compresses context by 56% while preserving 100% of the information needed for the next iteration.

---

WAVE 3 Quality Gates 4 agents • ~22 min

Before anything touches production, four validation agents run in parallel. Their findings feed each other in real time via the shared log.

Now here's where KAOS's co-evolution kicks in. The security agent's finding that HSTS was missing was automatically visible to the compliance validator via the shared log. The compliance agent cross-checked — HSTS is a PCI-DSS requirement in Req 4.2.1. It updated its evidence collection accordingly and flagged the fix as satisfying two concerns simultaneously. Neither agent had to be told about the other's findings — the shared log made them visible, and CORAL's stagnation detection recognized the cross-agent insight as a compounding win.

CORAL Shared Log Agents sharing discoveries in real time via the shared log, with CORAL enabling the co-evolution where one agent's fix propagates value to another's domain — automatically.

---

WAVE 4 Deploy & Observe 2 agents • ~13 min

---

What the dashboard showed

The KAOS Gantt view showed each agent as a horizontal bar across the session timeline. Waves 1–4 visible at a glance. Clicking any agent bar revealed its complete tool call trace, the files it created, and every checkpoint it took. The CTO could answer "what exactly did the payment-engine agent do on iteration 2?" in under 3 seconds.

$ kaos ui   # open web dashboard

Wave 1  [architect-agent    ████░░░░░░░░░░░░░░░░░░░░░░░░░  9m]
        [research-agent     ██████░░░░░░░░░░░░░░░░░░░░░░░  9m]

Wave 2  [payment-engine     ░░░░░░████████████░░░░░░░░░░░░ 18m]
        [fraud-agent        ░░░░░░░░░░████████████████░░░░ 24m ← SurrogateVerifier fired at 12m]
        [api-gateway        ░░░░░░██████████░░░░░░░░░░░░░░ 15m]
        [portal-agent       ░░░░░░████████████████░░░░░░░░ 22m]
        [compliance-agent   ░░░░░░████████░░░░░░░░░░░░░░░░ 14m]
        [infra-agent        ░░░░░░██████████████░░░░░░░░░░ 20m]
        [test-agent         ░░░░░░██████████████████░░░░░░ 26m]
        [migration-agent    ░░░░░░████████░░░░░░░░░░░░░░░░ 14m]

Wave 3  [security-agent     ░░░░░░░░░░░░░░░░░░░░░░░████░░  8m]
        [perf-agent         ░░░░░░░░░░░░░░░░░░░░░░░████░░  9m]
        [compliance-val     ░░░░░░░░░░░░░░░░░░░░░░░██████ 11m]
        [integration-agent  ░░░░░░░░░░░░░░░░░░░░░░░██████ 12m]

Wave 4  [deploy-agent       ░░░░░░░░░░░░░░░░░░░░░░░░░░░███  8m]
        [observability      ░░░░░░░░░░░░░░░░░░░░░░░░░░░███  5m]

                                                        Total: 1h 37m ✓

---

What KAOS learned — and saved for next time

This is where the compounding begins. Every insight from this session was automatically persisted — as skills for the next project to reuse, as memories for future agents to search, and as a full execution trace for the Meta-Harness to optimize from.

The 14 skills saved

Every reusable pattern discovered during this session was written back to the SkillStore. Any future project can now find and apply them at the search stage, before writing a single line of code:

Skill	What it encodes	Value
go-payment-engine-idempotent	Idempotent tx handler, retry, DLQ in Go	Saves ~4 iterations
fraud-cold-start-fallback	Global percentile prior for cold-start features	Prevents AUC collapse
pci-dss-v4-fastapi-postgres	All 12 requirements, automated evidence, FastAPI + PG	Saves $490k/engagement
gke-terraform-payment-services	Full GKE module for stateful payment workloads	Saves ~3 iterations
okta-jwt-fastapi-middleware	Okta JWT + TOTP validation, scope enforcement	Reusable across projects
zero-downtime-parallel-run	Dual-write router + result diff + auto-rollback trigger	Prevents data loss migrations
kafka-consumer-lag-alerting	Lag-based alert + auto-scaling policy for Kafka consumers	Prevents queue buildup
feast-feature-store-integration	Online/offline Feast setup for real-time ML inference	Saves ~5 iterations
webhook-delivery-engine-py	Webhook retry, exponential backoff, dead-letter, audit log	Battle-tested pattern
locust-50k-tps-scenario	Locust config for distributed 50k TPS load tests	Copy-paste for any perf test
datadog-payment-slo-pack	SLOs + 23 alert policies + runbook template for payments	Day-1 observability
soc2-cc-controls-fastapi	61 CC controls, code assertions for FastAPI services	Audit prep in minutes
shap-explainability-gbm	SHAP values per prediction, dispute-ready output format	Regulatory-ready ML
blue-green-gke-github-actions	Blue/green deploy workflow for GKE via GitHub Actions	Zero-downtime deploys

The 112 memory entries

Beyond reusable templates, every decision, tradeoff, and lesson was written to cross-agent memory. Future agents on any future project can search for "PCI compliance FastAPI" or "Feast cold start" and immediately find the hard-won answers from this session. Here's what that actually returns:

$ KAOS_DB=demo-engagement.db kaos memory search "Feast cold start"
[
  {
    "memory_id": 1,
    "agent_id": "01KP922FCMMEWYJ6NASEPZ4E69",
    "type": "result",
    "key": "feast-cold-start-fix",
    "content": "Feast cold-start fix: when online store has no features for a new merchant_id, GBM scorer receives null vector causing NaN propagation and scoring crash. Fix: inject global merchant risk percentile (p50) as prior. AUC impact: none at p95. Applied iteration 3, resolved in 18s by SurrogateVerifier.",
    "metadata": {},
    "created_at": "2026-04-15T17:12:25.878"
  }
]

---

Continuing the project — or starting the next one

Three months later, you need to add buy-now-pay-later (BNPL) to the platform. New scope, new functionality — but the same infrastructure, compliance posture, and deployment stack. A new session opens against the same database:

$ kaos run "
Add BNPL product to the payments platform. Installment plan engine,
credit scoring integration (Experian API), risk-based pricing,
collections workflow. Must reuse existing auth, compliance,
and monitoring setup.
" --name bnpl-expansion --db payments-platform.db

The intake agent immediately searches the skill library. It finds pci-dss-v4-fastapi-postgres, datadog-slo-alerting-pack, gke-terraform-microservices. All load before wave 1 begins. The compliance agent searches memory: finds the entire PCI evidence collection structure already documented. The infra agent finds the Terraform modules already proven on your GKE cluster.

The BNPL feature ships in a fraction of the original time. No onboarding. No discovery phase. No re-explaining the stack. The agents already know.

Cross-project knowledge transfer

A completely different project — a logistics SaaS building their own payment processing integration — starts a new KAOS session. They point at a fresh database, but KAOS has the skills from the payment platform session saved. Here's what the skills search returns for them:

$ KAOS_DB=new-project.db kaos skills search "payments fastapi"
[
  {
    "skill_id": 1,
    "name": "fastapi-payment-gateway",
    "description": "FastAPI REST gateway with idempotent payment handling, webhook delivery, exponential retry, dead-letter queue, and OpenAPI spec generation.",
    "template": "Build a FastAPI payment gateway for {project}. Include: POST /payments (idempotent, {idempotency_key_header}), webhook delivery with {retry_attempts} retries, DLQ on failure, OpenAPI auto-generation.",
    "tags": [
      "fastapi",
      "payments",
      "webhooks",
      "idempotent"
    ],
    "source_agent_id": "01KP922FDP1C2D683DXD40VRCM",
    "use_count": 0,
    "success_count": 0,
    "success_rate": null,
    "created_at": "2026-04-15T17:12:25.657",
    "updated_at": "2026-04-15T17:12:25.657"
  }
]

$ KAOS_DB=new-project.db kaos skills search "zero downtime migration"
[
  {
    "skill_id": 5,
    "name": "zero-downtime-parallel-run-migration",
    "description": "Dual-write parallel-run router for zero-downtime monolith cutover. Result diffing, per-cohort feature flags, automatic rollback on drift.",
    "template": "Migrate {project} from {legacy_system} using parallel-run strategy. Dual-write for {parallel_run_days} days, diff tolerance {diff_threshold}%, per-client feature flags, auto-rollback trigger.",
    "tags": [
      "migration",
      "zero-downtime",
      "parallel-run",
      "monolith",
      "rollback"
    ],
    "source_agent_id": "01KP922FBKS4ZA9QQCPHFNC5Y8",
    "use_count": 0,
    "success_count": 0,
    "success_rate": null,
    "created_at": "2026-04-15T17:12:25.811",
    "updated_at": "2026-04-15T17:12:25.811"
  }
]

The skills were saved during the first engagement. Any project using the same database — or any project you point at your shared skill database — gets the hard-won answers without doing the discovery work again.

---

The numbers

Output	Consulting	KAOS
Unit tests	Varies	847 (92.4% coverage)
Integration tests	Varies	94 (100% passing)
Load test	Often omitted	50k TPS @ 141ms p99
PCI-DSS compliance	Manual, quarterly	Automated, continuous
SOC2 controls	Manual mapping	61 controls automated
Observability	Add-on scope	23 alerts, 5 dashboards, 3 SLOs
Reusable for next project	Nothing	14 skills, 112 memories
Rollback points	Git tags	6 named checkpoints
Full audit trail	No	Every tool call, SQL-queryable

---

Every KAOS capability, in one session

In this walkthrough, every KAOS capability gets exercised because the problem genuinely needs it:

• Skill Library — Prior skills loaded before wave 1 begins. New skills saved after. The next project skips the discovery work entirely.
• Cross-Agent Memory — Every decision, lesson, and tradeoff persisted with a searchable key. Future agents find them with kaos memory search. Real output shown above.
• Shared Log (LogAct) — Architecture requires consensus before wave 2 begins. Security findings are automatically visible to the compliance agent. No agent acts on an unreviewed decision.
• CORAL — The HSTS fix propagates from security-agent to compliance-validator via the shared log. One agent's finding satisfies two concerns simultaneously.
• EvoSkills / Surrogate Verifier — Diagnoses the Feast cold-start failure, proposes the fix, applies it. The memory entry for this fix is searchable for any future ML project.
• MemPalace — Compresses long-running agent context without losing prior iteration results. Agents stay coherent across many iterations without hitting context limits.
• Meta-Harness — The full execution trace is stored in demo-engagement.db. When the follow-on session runs, Meta-Harness reads the prior traces and proposes an optimized wave strategy before a single agent is spawned.
• VFS Isolation — 13 agents, zero file conflicts. Each works in its own isolated filesystem. The integration agent can read any other agent's output via kaos read. Nothing leaks between agents.

---

The paradigm shift

A consulting firm wouldn't deliver something bad. They'd build a reasonable system, document it reasonably, and hand it over with a transition plan. But when they leave, the knowledge leaves with them. You'd own the code, but not the understanding behind it.

KAOS doesn't just deliver a system. It delivers the system, the full audit trail of how it was built, every lesson learned stored in searchable memory, every reusable pattern in the skill library, every decision logged and queryable with SQL, and six rollback points in case anything goes sideways.

The consulting firm charges for their expertise. KAOS compounds it. Every session makes the next session cheaper, faster, and more likely to succeed on iteration 1. The gap between KAOS and a blank-slate engagement grows with every project you run.