Ask-Opus portfolio deployment strategy — where it goes + where it compounds

Date: 2026-05-21 · Status: strategic memo · Originated from: Dan’s question — “foundationally, it can live within all our properties, thinking where does it make sense, what’s the edge-cases where it can compound learning”

The deployment matrix — audience tier × surface type

Three audience tiers, three surface types. Star ratings reflect where the widget compounds (★★★) vs. accumulates incrementally (★★) vs. is rarely used (★).

                       │ Decision-grade  │ Editorial      │ Archival       │
                       │ (active work)   │ (knowledge)    │ (reference)    │
   ────────────────────┼─────────────────┼────────────────┼────────────────┤
   OPERATOR (Dan)      │  ★★★ COMPOUNDS  │  ★★ accumulates│  ★ rarely useful│
                       │ claim cockpit   │ equipment recs │ resolved claim │
                       │ contractor      │ vehicle recs   │ archive        │
                       │   vetting       │ household recs │ old reports    │
                       │ gate-quote      │ service logs   │                │
                       │   decision      │                │                │
   ────────────────────┼─────────────────┼────────────────┼────────────────┤
   CURATOR (Audrey)    │  ★★ active edit │  ★★★ COMPOUNDS │  ★ rare use    │
                       │ gift-guide      │ product care   │                │
                       │   curation      │   + story      │                │
                       │ review-reply    │ brand voice    │                │
                       │   drafting      │   consistency  │                │
   ────────────────────┼─────────────────┼────────────────┼────────────────┤
   CUSTOMER (public)   │  ★ booking flow │  ★★ assistance │  ★ rare use    │
                       │ member-dog      │ gift selection │                │
                       │   handoff Qs    │ scarf care     │                │
                       │ service-spec Qs │ dog-stay prep  │                │
                       │                 │                │                │
   ────────────────────┴─────────────────┴────────────────┴────────────────┘

Compound-learning mechanics

The widget compounds value over time via four mechanisms. Understanding which mechanism is in play on a given surface determines whether deployment is worth the editorial discipline.

1. Context-id design is the architecture decision

Every conversation thread is keyed by a context-id. The granularity of the context-id determines what knowledge compounds.

   context-id granularity      compounded knowledge type
   ─────────────────────       ──────────────────────────
   per-claim                   high-resolution thread on
   (claim-046414618)           ONE active matter

   per-asset                   service history + troubleshooting
   (asset-z665-mower)          across years of one piece of equipment

   per-portfolio               cross-asset patterns
   (portfolio-pa)              ("what equipment fails most?")

   per-relationship            collaboration archive
   (audrey-dan)                long-arc working notes

   per-customer                customer service history
   (customer-<id>)             across booking lifecycle

Current state: only per-claim. Each new context-id is a new memory stream growing independently. The granularity choice should match how the question topology actually runs — claim work is per-claim; equipment service is per-asset; gift-guide curation might be per-recipient OR per-occasion.

2. KB density → insight depth

After 30 turns on a claim, Opus knows: - The carrier’s tactical patterns - The adjuster’s personality + preferred channels - What arguments have/haven’t worked here - Which sub-limits we’ve challenged + their responses - How long their replies take + what slows them

The 31st question gets answered with that accumulated muscle. Fresh-start chat-models can’t do this; the persistent KB is the only way to make this compounding happen.

Edge case where this matters most: claims, contractor relationships > 6 months, multi-year asset service histories, long-running editorial projects.

3. Editorial uplift — KB turns become canonical Q&A captures

The widget’s ephemeral chat is the staging area for editorial canonization. High-value Opus turns get distilled into Q&A captures (per the existing pa_qa_block_inject.py pattern) and become part of the static record.

�STASH3�

This is the bridge from RUNTIME (chat) to BUILD-TIME (HTML) — adjacent to feedback_capture_at_source_durable_substrate.md. The KB is the editorial substrate.

Edge case where this matters most: pages with a long-lived decision history (claim cockpits, contractor vetting records, asset service decisions). Customer-facing pages where the same question gets asked repeatedly (dogwood’s “what’s the drop-off process” — distill to FAQ).

4. Pattern detection — meta-questions across context-ids

Opus reading its own KB history can surface emergent patterns:

• “You’ve asked about depreciation 4 times — here’s a consolidated playbook” → becomes a permanent /playbooks/depreciation.html page
• “Three of last year’s claims had sublimit gaps for tree debris” → becomes a memo for future claim cockpits
• “Customers ask ‘what’s the typical drop-off process’ 15 times this month on dogwood” → becomes a FAQ on the public page
• “This equipment line fails on the same component every 18 months” → becomes a preventive-maintenance schedule

The widget’s KB becomes source material for the next generation of editorial content. This is the AI-relationship-as-asset loop.

Edge case where this matters most: when the KB has crossed ~50 turns. Below that, patterns are noise. Above that, emergent themes become editorial gold.

Where it makes sense to deploy first

Ranked by ROI (effort to deploy × ongoing compound value):

�STASH6�

Where it does NOT make sense

• Static reference pages — old reports, archived documentation, anything where no NEW decisions get made
• Pure marketing surfaces — landing pages where the visitor isn’t in a decision context
• One-shot lookups — pages where the answer is “the data is right there, no thinking needed”
• High-volume public pages without auth — the widget assumes a stable identity; anonymous high-traffic surfaces would mix conversations chaotically
• Time-sensitive surfaces with no follow-up — if you ask once and never ask again, no compound benefit

The customer-facing tier — a distinct product

Customer-facing widgets on dogwood / audreyinc are a different product from operator widgets, even though the technical primitives are the same:

Deploying customer-tier widgets is a Phase 2+ move. Operator-tier first.

The compound-flywheel

�STASH7�

Resume conditions per stage

• Stage 2 enrichment (contractor records, asset records get widgets): build when contractors directory crosses 5+ records OR asset records cross 10+
• Stage 3 distillation (KB → Q&A captures): build when any context-id crosses 30 turns AND has reusable insight
• Stage 4 pattern detection (cross-context meta): build when portfolio KB crosses 200 total turns
• Stage 5 customer-facing (dogwood/audrey public widgets): build when customer FAQ volume justifies it, NOT before

Sibling memories + sketches

• user_static_site_plus_living_brains_stack.md — the architectural foundation
• user_throughline_connected_data_surfaces.md — adjacent compounding pattern (dates)
• feedback_capture_at_source_durable_substrate.md — the editorial uplift pattern
• project_ask_opus_portfolio_connector.md — original widget design
• parked_sketch_widget_page_context_extraction_2026-05-21.md — Pattern A/B context architecture (today)

The aphorism

A widget on every decision page. A persistent thread per context. A distilled Q&A capture per insight that reaches escape velocity. A playbook page per pattern that recurs three times. The portfolio’s thinking becomes its own infrastructure — invisible to outsiders, compounding daily.