CAF Restructure — Organizing Brief

Source: founder brain-dump 2026-06-14 (iMessage). Purpose: organize the dump into three aligned artifacts the team can divide work against — (1) strategic vision, (2) capability unbundling, (3) high-level architecture components — and push back where the thinking needs a sharper edge.

This brief reconciles the dump with the June 9 four-move proposal (plugin packaging / on-disk manifest / two orchestrators / 106→~20 objective-skill collapse). Most of the dump is additive to that proposal, but two things in the dump force an evolution of it (multi-collaborator state, and the demo-site as a real product) — flagged inline as ⚠️ EVOLVES.

0. The one reframe (read this first)

The catalog is the asset. Everything else is I/O around it. And the catalog is your fixed-bid actuarial table.

You're selling fixed bid, not T&M. Fixed bid is only profitable when three things are true: you can (a) scope accurately, (b) know your delivery cost, and (c) reuse aggressively. All three are downstream of one object: a use-case/agent catalog where each entry carries its proven deployment recipes, sandbox-proven status, and actual delivery effort/outcomes. That object is what lets a sales rep quote a number and a delivery lead hit it.

So I'd stop treating your five deliverables as peers. Center the catalog; the other four orbit it:

            CLIENT INTELLIGENCE  (input: who is this company)
                      │
                      ▼
   CATALOG  ◄────►  TAILORING  ────►  DEMO SITE   (output: what we pitch them)
  (the asset)        (catalog × intel)   (presentation layer)
      ▲                                      
      │ generalize-back loop (3× → promote)  
      │                                      
  DELIVERY ACCELERATION  =  the catalog's "how we build it" face
  (not a separate system — see §2)

This single reframe resolves half the architecture questions, because it tells you what must be durable, shared, and schema-governed (the catalog + its provenance) vs what is ephemeral (a given conversation's reasoning).

1. Strategic vision

CAF is the machine that makes fixed-bid agent engagements profitable by industrializing reuse across the sales→delivery seam.

• Catalyst (sales side) = productized pre-sales assessment that turns "what could we build for you" into a tailored, scoped, quotable portfolio — fast and consistently, so we can bid fixed.
• Vector (delivery side) = AI-accelerated normal engineering that executes the won use cases. "Vector engineer" is branding over standard delivery; the leverage is that they inherit catalog entries with proven recipes instead of starting cold.
• The connective tissue is the catalog + a persistent artifact store. The June 11 addendum already named this: the manifest turns the Stage-5 "Sales→Delivery Knowledge Transfer" from a meeting into a file handoff. Today's dump extends that — it's not just a handoff file, it's a shared, multi-collaborator data store that both halves read and write.

North-star test for every design debate: does this drive marginal delivery cost down or scoping accuracy up? If a proposed feature does neither, it's not CAF's job.

What CAF stops being: a 106-skill linear monolith you run end-to-end in one context window. What it becomes: a graph of separable capabilities over a shared catalog, runnable piecemeal or orchestrated, consumed from any harness.

2. Capability unbundling (for alignment + work division)

Six capabilities. Five are yours; I've added Orchestration as an explicit cross-cutting seventh concern because "it's a monolith / judges never fire" is really an orchestration gap, not a per-deliverable gap. Each is specified as purpose / inputs / outputs / can-run-standalone? / owner-candidate.

A. Client Intelligence

• Purpose: rapidly build a grounded picture of ONE target company.
• Inputs: public domain (10-K/10-Q, blog, press, news), prior call transcripts + notes, key-personnel map (who we've talked to, who has authority), optional proprietary (D&B, PitchBook, Crunchbase).
• Outputs: a structured client-intel record (not a doc — a typed artifact) with provenance + confidence per claim.
• Standalone? Yes — and it's reusable far beyond CAF (account planning, QBRs, renewals). Build it so the intel record is a first-class object other workflows can read.
• Owner: whoever owns account research / the DSA.

B. Use-Case / Agent Catalog ← the asset

• Purpose: the durable, growing library of categorized use cases.
• Structure: verticals (quick-serve, construction, healthcare-provider…) × horizontals (finance, marketing, product…). Each entry is a typed record (schema in §3) carrying: problem, value hypothesis, vertical/horizontal tags, deployment recipes per stack {Anthropic, AWS, Snowflake}, sandbox-proven status, est. delivery effort, # times deployed, outcomes.
• Standalone? It's the substrate everything else reads/writes.
• Owner: needs a catalog librarian role (see pushback #7) — not a free-for-all.

C. Use-Case Tailoring

• Purpose: catalog × client-intel → a prioritized, company-specific pitch.
• Behavior: enrich generic catalog entries with research, or mint new company-specific entries.
• The reverse loop: when a tailored/new use case recurs 3× independently, it's a candidate to generalize back into the catalog — via a curator gate, not an automatic write (pushback #7).
• Outputs: a tailored-portfolio artifact that saturates the demo site.
• Standalone? No — depends on A + B existing.

D. Sales Demo Site (the "321GO" surface)

• Purpose: a client-facing, hosted, take-home site that presents the tailored portfolio; client selects use cases → contacts sales for a custom quote.
• Hard requirements from the dump: reps can edit/add/rearrange (persists to the store); clients cannot edit (especially the handed-over copy); must be a real hosted, gated URL, not a local HTML file.
• ⚠️ EVOLVES the current mechanic: today it's Claude-design → one-off local HTML (80-90% boilerplate, taken to demos on a laptop). Replace with one templated static shell + data-driven content (see §3).
• Standalone? Presentation layer over C's output; no bespoke per-client build.

E. Delivery Acceleration = the catalog's delivery face (⚠️ do not build twice)

• Purpose: prove use cases turnkey in an internal sandbox before the client engagement starts; qualify which use case runs on which partner stack.
• My pushback: this is not a separate system — "stack-qualification + sandbox-proven + effort estimate" are attributes of a catalog entry (B). Sales reads the value/tailoring face of the entry; delivery reads the recipe/effort face. One object, two faces. Build it once.
• Owner: delivery (Vector) leads contribute recipes + proven-status back into the catalog.

F. Orchestration (cross-cutting)

• Purpose: resolve the dependency graph and dispatch ready nodes; enforce gates.
• Why judges never fire today: nothing enforces the gate. Make a node's artifact status:draft until a judge/Meta-Council tool flips it validated; the orchestrator refuses to pass a non-validated artifact downstream. The gate becomes a required state transition, not advisory prose. (Reconciles Move 3 + the DO-NOT-COLLAPSE Meta-Council gates.)

Suggested work-division seams: A (research/DSA) · B+E (catalog+delivery, owned together so they never fork) · C (tailoring, the "AI core") · D (web/platform) · F (orchestration/platform). These are clean ownership lines because the artifact contracts between them are explicit.

3. High-level architecture components (outline only — detail in the next step)

Five components. This is the skeleton to align on before we draw the ERD or pick the host.

(1) Separate the data plane from the agent plane — this dissolves 3 of your concerns at once

Your collaboration + state + multi-harness concerns are really one concern: state is in the context window, and it shouldn't be. Split:

• Data plane: ONE source-of-truth datastore holding client-intel records, the catalog, tailored portfolios, deployment-qualification, and run/manifest state. SQLite/local-FS is correct for a single-user demo and wrong for multiple collaborators — you already called this. ⚠️ EVOLVES Move 2: the June 9 engagements/<client>/manifest.yaml artifact model is right; the backend graduates from local YAML to a shared store.
• Agent plane: the harnesses (Claude Code / Desktop / Cowork) become stateless clients of that store.

(2) ONE remote MCP server over the datastore → solves "same tools in every harness"

You don't get cross-harness tool parity by copying skills into Desktop/Code/Cowork. You get it by exposing the data-plane operations (read/write catalog, intel, tailored portfolio, manifest) as a remote MCP server that every harness connects to as a client.

• ⚠️ Reconciles the June 9 decision (plugin = Claude Code only): skills/reasoning prompts ship in the Code plugin (engineers); data tools live in the remote MCP server (everyone — Desktop/Web/ Cowork reps included). Two distribution channels, one data store. Sales reps on Desktop/Cowork get the MCP tools (+ maybe a hosted tailoring agent); engineers on Code get plugin + MCP.

(3) Contracts become enforced schemas at the write boundary — not prose

Your "contracts.md isn't consistently followed" is a symptom. Cause: contracts are advisory prose that gets evicted from context. Cure: each deliverable's output is written via an MCP tool that validates against the contract schema — it cannot be silently violated. This is exactly RDCO's multi-agent pipeline pattern (StructuredOutput tool, schema-validated). Contracts 0–6 move from "YAML blobs in conversation" to "typed rows the store enforces."

(4) Orchestration = a DAG of deliverable nodes with artifact handoffs, not monolith-vs-skills

The binary is false. Model it as a dependency graph: each node runs standalone if its input artifacts exist, or under the orchestrator (which resolves the graph and dispatches ready nodes). Client-intel is a node whose output feeds tailoring — exactly your "capture phase -1 as context for other deliverables." Judges are first-class nodes (gate state transitions, per F).

(5) Demo site = static shell + data-driven content + gated host (the quick-sites pattern, ported)

• Agent emits structured use-case records (JSON), never HTML. Build the boilerplate shell once. Site reads client content from the datastore at build/request time. Kills the 80-90% token waste.
• Rep-editable / client-read-only = role/auth on the datastore + a thin admin UI. Take-home = real gated URL.
• RDCO already shipped this (quick-sites: static shell + R2 content + Cloudflare Access OTP). The architecture ports directly; only the host swaps. Host is a deploy-time choice behind a thin content API, so make it cloud-agnostic and let partner politics decide per-deal:
  • Cloudflare Pages / Quick-Sites analog — fastest, what we know, but off the phData partner stacks.
  • CloudFront + S3 — AWS-native, boring/robust.
  • Snowflake Native App — strongest "dogfood our partner + the client's data already lives here" story if delivery data lands in Snowflake. Real decision; needs your input (see Q6).

4. Pushback / refinements summary

1. Center the catalog; demote the site. The site is presentation; the catalog (with provenance) is the moat and the fixed-bid actuarial table. Your list had them as peers — they aren't.
2. Unify "catalog" (B) and "delivery acceleration" (E). Stack-qualification + proven-status + effort are attributes of a catalog entry, not a second system. Build once or they'll fork and rot.
3. Data plane vs agent plane. "Sync to a DB" undersells it — the real move is making harnesses stateless clients of one store, which dissolves collaboration + state + multi-harness together.
4. One remote MCP server, not skills-copied-everywhere. This is how you get cross-harness parity and stay consistent with the June 9 "plugin = Code only" decision.
5. Contracts → enforced schema, not better prose. Discipline won't fix it; a validating write tool will.
6. Judges fire because the orchestrator requires a validated state transition — that's why they're dead today (nothing enforces the gate).
7. The 3×-generalize reverse loop needs a curator gate + dedup, or the catalog fills with near-duplicates. "Independent recurrence" is a clustering judgment + a human promotion approval, not an auto-write. The catalog needs a librarian owner.
8. Make fixed-bid the explicit forcing function in the vision doc, so the team has one yardstick to settle design arguments.

5. Where I need expanded detail (your homework / next-step inputs)

Ranked by how much they block architecture:

1. Data governance / tenancy (biggest). Public 10-Ks are fine to pool, but call transcripts + D&B/ PitchBook are sensitive and phData clients are often regulated. Can intel live in a shared multi-tenant store, or does each client need isolation + retention rules? This can force per-client partitioning and changes the datastore choice.
2. Collaborator personas + harness + technical level. How many sales reps vs engineers? Are reps on Desktop/Cowork only (non-technical) or can some use Code? This sets how thin the MCP/admin layer must be.
3. Scale numbers. Clients/year, catalog size at maturity, concurrent collaborators → Postgres vs Snowflake vs object-store-plus-search.
4. 321GO — existing phData product/brand or net-new? What's locked vs greenfield, and who owns it today?
5. The actual Contracts 0–6 + one phase's skills — I need the real artifact shapes to draw the schema/ERD. (Still gated on the standing blocker below.)
6. Partner politics for the demo-site host — mandate to feature Snowflake (or another partner), or free choice? Where does the client's delivery data already sit?
7. Meta-Council / judge intended trigger points — per-phase or per-deliverable? Determines where gates slot into the DAG.
8. Delivery-acceleration sandbox — do we have standing Anthropic/AWS/Snowflake sandbox envs to prove use cases turnkey, or is that to-be-built?

Standing blocker (unchanged from June 9/11)

The CAF repo is still not on this machine. I can outline architecture from your dump, but I cannot finalize the schema/ERD, the skill-collapse map, or the contract typing without the actual repo (contracts.md, the 106 skills, manifest example). This is the gate to the "next step" you described.

6. How this maps onto the June 9 proposal (the delta, for the team)

Suggested next step

Lock §1–§2 with the team (cheap, no repo needed — it's vision + ownership lines). Then, the moment I have repo access + your answers to Q1/Q2/Q5, I draft the datastore ERD + contract schemas + the demo-site content model as the promised "next step" architecture detail.

Addendum 2026-06-14 (live session) — harness portability + the Glean integration

Two refinements surfaced in the founder thread same day. Both reinforce §3's data-plane/agent-plane split.

Three swappable layers on one durable loop

Nadella's "swap the model without losing the company veteran" ([[2026-06-14-satya-nadella-frontier-ecosystem-learning-loop]]) has a layer above it the founder named: the client/harness. Generalize: there are three swappable layers sitting on one durable loop:

1. Model (generalist swap).
2. Client/harness (Claude Code ↔ Cowork ↔ Desktop/Web).
3. Connector source (Glean vs direct — below). The "company veteran" you never lose = the loop underneath: catalog + datastore + the MCP tool layer. Founder's own framing: porting the skills (the company expert) is useless without portable tools (the potter's turntable). Tool portability across harnesses = the remote MCP server. That is the unlock.

Code vs Cowork — a floor and a ceiling, not either/or

• Floor (portable to every harness via MCP): read/write catalog, pull client intel, generate a tailored pitch, query the knowledge base. ≈ the whole contributor/rep surface. Enable Cowork here → more colleagues run + contribute.
• Ceiling (Claude Code only): arbitrary code execution, filesystem, the orchestrator firing Task/Agent/Skill, build/deploy, the delivery-acceleration sandbox. Engineers stay on Code.
• Do NOT rebuild Code's tooling inside Cowork. Put shared capability in the MCP server; point both harnesses at it. The "Code vs Cowork" debate dissolves into "shared floor + Code-only ceiling."

Glean — consume it, don't fight it (flips the internal objection into the integration)

Internal pushback: "can't connect Claude Code to GDrive/Slack/email, Glean already owns those." IT is partly right (duplicating governed connectors = permission/governance mess). But Glean can't be CAF's build substrate. Resolution, confirmed via web check 2026-06-14: Glean now ships a secure MCP endpoint explicitly built to connect "any agent" (Claude included) to enterprise context, permission-aware (users only see what they're allowed to); 275+ connectors; Glean agents exposable as MCP tools. So:

• CAF consumes Glean's MCP endpoint as one of its tools. IT keeps governance; CAF gets the governed internal data AND builds the workflow layer Glean can't. The "no" becomes the path.
• Three-way data-needs split (use this in the room):
  1. Internal enterprise data (Drive/Slack/email/transcripts) → via Glean MCP (governed).
  2. External public/proprietary (10-K/10-Q, D&B, PitchBook, Crunchbase) → CAF fetches direct — not Glean's job.
  3. CAF-generated artifacts (catalog, intel records, tailored pitches) → CAF's own datastore.
• Verify in the phData tenant: that Glean's MCP endpoint is licensed/enabled, and that its retrieval is good enough. If retrieval is weak for a given source, that is the specific, defensible case for direct access to that one source (rather than a blanket "let me reconnect everything").
• Refs: Glean MCP — https://www.glean.com/blog/mcp-mar-drop-2026 · dev platform — https://developers.glean.com/

Addendum 2026-06-15 — Verified harness mechanics: plugin can bundle a REMOTE MCP server

Founder asked (iMessage 2026-06-15): can Claude Code plugins ship tools as well as skills? Verified against current docs (code.claude.com/docs/en/{plugins,mcp,plugins-reference}.md) via two claude-code-guide passes — NOT from memory:

• Tools are not a first-class plugin primitive. The only way a plugin provides callable tools is by bundling an MCP server. (Live proof: this machine's discord/imessage/cloudflare plugins all ship tools as plugin MCP servers.)
• A plugin can bundle: skills, slash commands, subagents, hooks, MCP servers, LSP servers, monitors, themes.
• Plugin-bundled MCP servers support REMOTE transports (http/sse/ws), not just local stdio — same .mcp.json schema as a project config. Shape: { "type": "http", "url": "https://...", "headers": { "Authorization": "Bearer ${TOKEN}" } } (env-var interpolation supported; auth is header-only).

CAF implication (confirms the data-plane/agent-plane split): the Code plugin ships the skills + a one-step pointer to the shared remote MCP server; the data tools live on that one remote server. This is exactly the June-14 "skills in the Code plugin, data tools in the MCP server" call, now mechanically confirmed. Caveat for the multi-harness goal: the plugin only turnkeys the Code side — Claude Desktop and Cowork connect to the same remote URL via their own MCP config. The remote server is the shared data plane all three harnesses hit; the plugin just makes Code install-and-go.