The product, as a whole

How to read this document. Five minutes, top to bottom: first the promise, then the loop — six capabilities in the order material flows through them, each embedded live with its current state — then what success will be measured by, and finally what is still genuinely open. For the agreed detail behind any capability, follow the Scope document; for why the architecture is shaped this way, the Solution document.

The platform (name pending — see Open below) is the operating platform for IT consultancies that deliver with AI agents. It exists because agentic delivery breaks in one predictable place: knowledge that never gets written down. The promise: everyone — consultant, client, agent — works from the same agreed truth, and no change to it can be invisible.

The loop

It begins when intake material hits the intake engine:

CAP-2 — Intake→draft engine (confirmed)

Turns raw intake — meeting notes, transcripts, old documents, chat — into PROPOSED items with source references and confidence, and files clarifications for every unknown instead of assuming. Humans confirm; agents never write truth directly.

Everything agents draft lands as proposals in the single record:

CAP-1 — Item store (confirmed)

The single record every other capability reads and writes: typed knowledge items (requirements, scenarios, risks, clarifications, decisions...) each with one home, a lifecycle, full version history, human keys (REQ-3), and typed links forming the scenario spine.

The consultant meets the draft as the scope document taking shape — reviewing in place:

SCN-5 — Consultant reviews an agent-drafted scope section (confirmed)

The daily discovery loop. An agent has drafted items from intake material; the consultant needs to turn drafts into agreed scope without leaving the document context.

When the provider side agrees, a review round carries it to the client:

SCN-6 — Consultant releases a scope draft to the client (confirmed)

The internal/external boundary. Nothing is client-visible until the consultant deliberately releases; releasing defines exactly what the client sees and which clarifications they are asked to answer.

CAP-3 — Client workspace (confirmed)

The client's side of the engagement: tokenized access (no account) to SHARED views — the same scope document, status and logs the consultant sees, read-only plus accept/comment per item, uploads of their own material, and over time a conversational way to correct the record.

At green readiness the agreement is frozen:

CAP-4 — Baseline engine (confirmed)

The agreement machinery: releases (what crossed to the client, immutable), baselines (what was signed), increments (parallel streams like v1-maintenance vs v2-discovery), and item-level diffs between any two points — scope drift made arithmetic.

Build runs on the same record:

CAP-5 — Briefing compiler (confirmed)

Compiles the minimal, directive context an agent needs for a task — from the same items everyone else reads — and takes structured results back (decisions, deviations, new items). Emits AGENTS.md/CLAUDE.md into working repos so agents meet the engagement in the format they already understand.

And underneath, status is computed, never claimed:

CAP-6 — Delivery telemetry (confirmed)

Append-only events from every mutation, turned into computed answers: where the engagement stands, how fast clarifications get answered, whether the review queue is rotting, whether build diverges from baseline. Status is calculated, never claimed.

Open

CLA-1 — What is the platform's name? (answered)

The platform needs a name before any client sees it. 'mkb' (methodology knowledge base) describes the engine, not the product. The name should carry the promise: agreed scope, visible status, no drift.

Answer: Yes — naming session agreed, to be held now that scope is confirmed.

Success criteria — engagement #1

1. Anyone — provider, agent, client — finds the right information in seconds.
2. Scope drift is never invisible: every deviation from the baseline is an item-level diff someone saw.
3. Clarification throughput holds: answer latency tracked, the queue never silently starves delivery.
4. All of it measured from instrumented telemetry, not impressions.

Why the economics work

The original methodology optimized for scarce writing — documentation was expensive and consultants hated it. Agents inverted that: writing is free, build is fast and parallel, and what became scarce is human attention (verification, decisions), client attention (clarifications, sign-offs), and context. The platform optimizes for scarce verification: agents may not assume, humans confirm truth, and the record briefs the next actor instead of anyone's memory.