kaizen-agentic/wiki/ForwardDeployedAgencyBusinessModel.md

# Forward-Deployed Agency Business Model

**Status:** v1.0 accepted (ADR-007; pilot railiance01 complete)
**Date:** 2026-07-16
**Audience:** product owners, coulomb ecosystem operators, early client sponsors
**Companion tech spec:** [docs/forward-deployed-engagement-architecture.md](../docs/forward-deployed-engagement-architecture.md)
**Canon ADR:** [docs/adr/ADR-007-forward-deployed-engagement-convention.md](../docs/adr/ADR-007-forward-deployed-engagement-convention.md)
**Playbook:** [docs/integrations/forward-deployed-engagement-playbook.md](../docs/integrations/forward-deployed-engagement-playbook.md)
**Decisions:** [docs/decisions/DEC-FDA-001-working-defaults.md](../docs/decisions/DEC-FDA-001-working-defaults.md)
**Builds on:** [PricingModel.md](PricingModel.md), [RevenueModel.md](RevenueModel.md), [KaizenAgenticMission.md](KaizenAgenticMission.md), ADR-006

---

## 1. Positioning

**Kaizen-agentic is an agentic consulting practice** — a digital talent agency that
**forward-deploys specialized agents** into client environments (companies on the
coulomb ecosystem, and coulomb-operated infrastructure itself).

Unlike a library of one-shot prompts, engagements are **staffed roles**:

| Dimension | Meaning |
|-----------|---------|
| **Role competency** | The agent is good at its job (sysadmin, coach, TDD lead, release manager) |
| **Domain competency** | The agent learns *this* client's systems, jargon, constraints, and history |
| **Confidential custody** | Operational knowledge gained on engagement **belongs to the client** |
| **Reusable craft** | Role patterns, playbooks, and non-secret refinements improve the agency fleet |

Clients do not rent anonymous token burn. They engage a **named digital colleague**
with a ramp-up, steady-state duty, and orderly ramp-down — analogous to a
forward-deployed engineer, with measurement and continuous improvement baked in.

### Who is the customer?

1. **Coulomb internal** — ecosystem ops (e.g. railiance01 host operator, loop coaches)
2. **Coulomb-ecosystem companies** — product teams using railiance, state-hub, activity-core, etc.
3. **Later: external companies** — same model once trial currency proves unit economics

---

## 2. Value proposition

### For the client

- A competent agent **on their problem**, not a generic chatbot
- Knowledge that **stays in their custody** (engagement vault; see tech spec)
- Explicit lifecycle: request → staff → ramp-up → operate → ramp-down → handoff
- Transparent cost model that starts in trial currency and can convert to money
- Measurable duty: schedules, health reviews, SLAs stated in the engagement contract

### For the agency (kaizen-agentic)

- Recurring engagement revenue (or trial-currency demand signal) beyond one-off installs
- Dual learning loops:
  - **Role craft** compounds in supplier IP (prompts, protocols, coach patterns)
  - **Domain craft** compounds only where the client allows (engagement memory)
- Reference deployments inside coulomb that prove the model before external sales
- Natural upsell path: more roles, higher cadence, premium tiers (capability multipliers)

### What is *not* sold

- Client secrets, host fingerprints, incident narratives, or tenant topology as
  kaizen training data
- Unbounded autonomous change rights on production systems
- Transfer of client operational IP into the public agent catalog without scrubbing
  and explicit license

---

## 3. Engagement product units

### 3.1 Role (catalog product)

A **Role** is a supplier-owned agent definition family (e.g. `host-operator`,
`sys-medic`, `coach`, `tdd-workflow`). Roles have:

- Capability tier (1×–5× per [PricingModel.md](PricingModel.md))
- Standard protocols and metrics
- Default cadences (on-demand, daily, weekly)
- Required access classes (read-only shell, cert-bound SSH, no secrets, etc.)

### 3.2 Engagement (sold instance)

An **Engagement** is a time-bounded (or open-ended) staffing of one or more Roles
for a **Client** against named **Targets** (repos, hosts, clusters, product areas).

| Field | Example (pilot) |
|-------|-----------------|
| Client | coulomb / railiance ops |
| Role | `host-operator` (specialization of infrastructure / sys-medic craft) |
| Target | host `railiance01` (k3s production node) |
| Duty | keep OS current, security posture, load & workload review |
| Cadence | daily health review; weekly OS/security pass; on-demand incident assist |
| Knowledge plane | client-owned engagement vault on client infrastructure |
| Billing plane | trial Kai ledger → later EUR settlement |

### 3.3 Seat vs. duty

- **Seat** — right to run a role for a client (subscription-like)
- **Duty unit** — a scheduled or on-demand work session (usage-like)

Pricing can combine both (seat for continuity + duty units for heavy weeks).

---

## 4. Dual knowledge planes (commercial rule)

This is the commercial expression of the technical confidentiality design.

| Plane | Owner | Contents | May feed supplier IP? |
|-------|-------|----------|------------------------|
| **Client operational knowledge** | Client | Host baselines, incident history, topology, credentials pointers, “how we run X here” | **No** — unless client explicitly contributes a scrubbed lesson |
| **Role craft (agency IP)** | kaizen-agentic | Prompts, protocols, assessment methods, generic playbooks | Yes — always |
| **Shared anonymized metrics** | Negotiated | Aggregate success rates, quality scores, cadence stats | Opt-in only |
| **Engagement artifacts** | Client | Session reports, run logs, recommendations | Client; supplier may retain *billing* metadata only |

**Default contract language:** *“All operational knowledge acquired during the
engagement is Client Confidential Information. Supplier retains ownership of
generic Role definitions and non-identifying process improvements.”*

Violation of this plane split is a product defect, not a negotiation detail.

---

## 5. In-game currency: **Kai**

### 5.1 Purpose

**Kai** is a **trial and internal settlement unit** used while the agency model is
proven inside coulomb and with friendly clients. It:

- Creates real scarcity and budget discipline without invoicing friction
- Makes role tiers and duty costs *felt* before EUR conversion
- Produces ledger data to calibrate real prices
- Can later map 1:1 (or with a published FX) to currency

Kai is **not** a cryptocurrency, not publicly traded, and not legal tender.
It is a **ledger balance** in the coulomb / kaizen settlement system.

### 5.2 Units and denominations

| Symbol | Name | Typical use |
|--------|------|-------------|
| **Kai** | base unit | All ledger entries |
| **kKai** | 1 000 Kai | Monthly seat packages |
| **MKai** | 1 000 000 Kai | Portfolio budgets (optional) |

### 5.3 Minting (trial phase)

| Source | Amount (illustrative) | Notes |
|--------|----------------------|--------|
| **Bootstrap grant** | 50 000 Kai per new client | One-time, expires in 90 days if unused |
| **Internal coulomb ops grant** | 200 000 Kai / quarter | Ecosystem self-service (railiance, loop, etc.) |
| **Top-up voucher** | Operator-issued | For pilots and demos |
| **Earned credit** | Variable | Completing engagement feedback, contributing scrubbed lessons |

No automatic infinite mint. Empty balance **pauses new duty starts** (ramp-down of
in-flight work is always allowed without charge).

### 5.4 Spend catalog (trial price list)

Prices are in Kai and intentionally round for mental math. Capability multipliers
from [PricingModel.md](PricingModel.md) apply as **tier weights** on duty units.

**Seats (monthly, auto-renew while funded):**

| Product | Tier weight | Seat / month |
|---------|-------------|--------------|
| Baseline role seat (1×) | 1 | 2 000 Kai |
| Professional role seat (3×) | 3 | 6 000 Kai |
| Expert / host-operator seat (4×) | 4 | 10 000 Kai |
| Premium meta / coach fleet seat (5×) | 5 | 15 000 Kai |

**Duty units (per executed session, in addition to seat):**

| Duty | Base cost | After tier weight *M* |
|------|-----------|------------------------|
| On-demand short assist (≤30 min wall) | 100 Kai | 100 × *M* |
| Standard review session (scheduled) | 400 Kai | 400 × *M* |
| Deep assessment / change window | 1 200 Kai | 1 200 × *M* |
| Ramp-up package (fixed, once) | 5 000 Kai | 5 000 × *M* / 2 (half weight) |
| Ramp-down package (fixed, once) | 3 000 Kai | 3 000 × *M* / 2 |

**Access class surcharges (per session):**

| Access class | Surcharge |
|--------------|-----------|
| Read-only / docs-only | +0 |
| Host observe (non-root shell / metrics) | +100 Kai |
| Privileged ops (root, package upgrade, firewall) | +400 Kai + human approval gate |
| Multi-host or cluster-wide | +200 Kai per additional host |

**LLM token pass-through (optional, trial):**
Recorded as `token_kai = ceil(actual_vendor_cost_EUR * kai_per_eur_fx)` for
transparency; may be waived in pure internal coulomb trials.

### 5.5 Example: railiance01 host-operator pilot

| Line item | Calc | Kai |
|-----------|------|------|
| Expert seat (4×), 1 month | 10 000 | 10 000 |
| Ramp-up package | 5 000 × 4 / 2 | 10 000 |
| Daily standard review × 20 business days | 20 × 400 × 4 | 32 000 |
| Weekly deep OS/security pass × 4 | 4 × 1 200 × 4 | 19 200 |
| Privileged surcharges (est. 4 sessions) | 4 × 400 | 1 600 |
| **Month-1 total** | | **~72 800 Kai** |

Internal coulomb quarterly grant (200 000 Kai) covers ~2–3 such seats with
headroom — enough to run the pilot and still force prioritization.

### 5.6 Conversion to real payments

When trial ends (client or product decision), **Kai balances convert**:

```
EUR_due = remaining_committed_work_EUR
        + (optional) unused_Kai_forfeit or credit_at_FX
```

**Published FX (initial, revisable):**

| Mode | Rule |
|------|------|
| **Trial learning FX** | 1 000 Kai ≈ 1 EUR of agency list price *for calibration only* |
| **Commercial FX** | Seat and duty price lists republished in EUR; Kai ledger frozen or becomes loyalty credit |
| **Grandfathering** | Active engagements keep trial Kai rates for one more full billing cycle after conversion notice |

**Transition states:**

1. `trial_kai` — only Kai ledger
2. `hybrid` — seats invoiced in EUR; duty still in Kai (or reverse)
3. `commercial_eur` — full EUR; Kai optional loyalty only

Settlement systems (invoice, SEPA, etc.) are **out of repo**; this model only
defines the commercial units and conversion rules.

### 5.7 What Kai deliberately does *not* buy

- Secrets or elevated access without ops-warden / OpenBao routing
- Guaranteed zero-incident outcomes
- Ownership of supplier Role IP
- Training the public catalog on client confidential data

---

## 6. Competency model (what improves over time)

### 6.1 Role competency (agency asset)

Improved via:

- Metrics (success, quality, time) across *many* engagements
- Coach + optimizer loops (existing agency framework)
- Protocol runbooks refined after generalized lessons
- Capability tier promotion of Role products

**Commercial effect:** higher tier weight → higher Kai/EUR price, justified by
lower client risk and better outcomes.

### 6.2 Domain competency (client asset)

Improved via:

- Engagement memory and node/host profiles
- Client runbooks and decisions in the engagement vault
- Session logs and cleared-issue history

**Commercial effect:** longer engagements get more efficient (fewer duty units for
the same outcome). Discounts for multi-quarter renewals reflect reduced ramp cost,
not ownership transfer of client knowledge.

### 6.3 Learning tax and learning credit

| Event | Effect |
|-------|--------|
| First engagement of a new Role for a client | Ramp-up package mandatory |
| Client contributes scrubbed “lesson learned” accepted into Role craft | Kai credit (e.g. 1 000–5 000) |
| Supplier extracts confidential detail into public Role without approval | Contract breach; engagement freeze |

---

## 7. Lifecycle commercial view

```
Request → Quote (Kai) → Fund → Staff → Ramp-up → Operate → (Renew | Ramp-down) → Close
```

| Phase | Client pays | Client receives | Agency obligation |
|-------|-------------|-----------------|-------------------|
| **Request / quote** | 0 | Scope options, tier recommendation | Respond with Role fit + Kai estimate |
| **Staff** | Seat (pro-rate) | Named engagement + agent definition bound to targets | Provision definition + access plan |
| **Ramp-up** | Ramp package | Orientation, baselines, coach brief, first metrics | Achieve “operationally aware” exit criteria |
| **Operate** | Seat + duty | Scheduled work, reports, continuous memory | Meet cadence & safety policy |
| **Renew** | Next seat period | Continuity; optional tier change | No re-ramp if knowledge vault intact |
| **Ramp-down** | Ramp-down package | Handoff pack, knowledge export, revoke access | Clean exit; no residual client secrets at supplier |
| **Close** | Settlement | Final ledger + EUR conversion if any | Archive billing metadata only |

---

## 8. Go-to-market inside coulomb

### Phase A — Internal dogfood (now)

- Clients: coulomb projects and railiance ops
- Currency: Kai only
- First Role: **host-operator** on **railiance01**
- Success: 30 days of reviews, OS/security pass documented, load findings actionable

### Phase B — Ecosystem companies

- Same Kai ledger; bootstrap grants
- Roles: host-operator, coach/optimizer loop, release manager, TDD
- Playbook reuse from coulomb-loop (ADR-006) + this model

### Phase C — External commercial

- EUR price list derived from Kai consumption data
- Hybrid then commercial_eur
- Optional professional services (custom Role design) as separate line items
  (see [RevenueModel.md](RevenueModel.md) §4)

---

## 9. Relationship to existing pricing docs

| Document | Role after this model |
|----------|----------------------|
| [PricingModel.md](PricingModel.md) | **Capability multipliers** remain the tier engine (*M*) |
| [RevenueModel.md](RevenueModel.md) | **Margin story** for EUR phase; Kai is pre-revenue instrumentation |
| This document | **Engagement packaging**, confidential knowledge, trial currency, lifecycle |

Token markup formula `Price = C × M` still applies when vendor tokens are
pass-through. Engagement pricing adds **seat + duty + access class** so that
value is not *only* token volume (a careful weekly review can be high value with
modest tokens).

---

## 10. Risks and mitigations

| Risk | Mitigation |
|------|------------|
| Kai inflation (infinite grants) | Quarterly mint caps; empty balance pauses duty |
| Client confuses trial with free forever | Expiry on grants; conversion notice period |
| Knowledge leak into public agents | Dual planes; automated redaction gates (tech spec); legal default |
| Over-autonomous privileged ops | Access class + human approval; safety-first Role principles |
| Underpriced expert seats | Recalibrate FX after 2–3 pilots using actual duty mix |
| Scope creep on “operator” Role | Engagement contract lists hosts, cadences, change windows |

---

## 11. Success metrics (business)

1. **Pilot completion** — railiance01 host-operator engagement runs full lifecycle once
2. **Ledger fidelity** — ≥95% of duty sessions post a Kai charge event
3. **Knowledge boundary audit** — zero confidential client artifacts in supplier `agents/` without scrub + license
4. **Renewal signal** — client chooses renew or ramp-down with documented handoff
5. **Price calibration** — published EUR draft list within ±30% of Kai-implied spend after conversion FX

---

## 12. Open decisions (for sponsor)

**Phase 1 locked** in DEC-FDA-001: file JSONL ledger; pilot path under
`engagements/pilots/`; one engagement × N targets; metrics opt-in default off.

Still open for later:

1. Is internal coulomb billed only in Kai forever, or eventually soft EUR for cost visibility?
2. Multi-tenant companies: one client account or one per product line?
3. Can unused Kai transfer between sister projects in the same company?
4. When to introduce a shared settlement service beyond JSONL?

---

## Related

- Canon ADR: [ADR-007](../docs/adr/ADR-007-forward-deployed-engagement-convention.md)
- Playbook: [forward-deployed-engagement-playbook.md](../docs/integrations/forward-deployed-engagement-playbook.md)
- Technical architecture: [docs/forward-deployed-engagement-architecture.md](../docs/forward-deployed-engagement-architecture.md)
- Customer loop convention: [ADR-006](../docs/adr/ADR-006-customer-engagement-convention.md)
- Agency framework: [docs/agency-framework.md](../docs/agency-framework.md)
- Mission: [KaizenAgenticMission.md](KaizenAgenticMission.md)
- Pilot: `engagements/pilots/eng-coulomb-railiance01-ho-001/`