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.htmlpage - “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:
| Operator widget | Customer widget | |
|---|---|---|
| System prompt | “Consigliere — analytical, candid, advisory” | “Brand voice — helpful, on-tone, never invent stock/policy” |
| Context-id | Per-decision / per-asset | Per-customer / per-booking |
| Trust posture | Full disclosure of cockpit data | Filtered — only what’s public + customer-relevant |
| Persistence | Long-arc (months/years) | Booking-lifecycle (weeks) |
| Editorial uplift | KB → Q&A captures on canonical pages | KB → FAQ on public pages, customer-service training |
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 foundationuser_throughline_connected_data_surfaces.md— adjacent compounding pattern (dates)feedback_capture_at_source_durable_substrate.md— the editorial uplift patternproject_ask_opus_portfolio_connector.md— original widget designparked_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.