Version. 0.1
Date. 2026-05-09
Status. Investigation. Thinking material — pattern crystallized, not yet specified for build.
Author. Claude.ai (investigation layer). Operator: Marvin Percival.
Provenance. Conversation initiated by the Operator's question: Would it be possible to have the Companion present and listening on my mobile (iPhone or Android) similar to how Siri is always present on my iPhone? I would like to be able to say "Hey Companion, I parked on level 10." The conversation surfaced two engagements rather than one — a capture-device engagement (mobile presence) and a substrate intent-class engagement (quick-capture). This document is the second of the pair, drafted first because it is substrate-shaped, methodology-richer, and applies regardless of which capture device delivers the utterance.
Informed by. Phase 41 (Companion identity, personal engagement). Phase 42 (intent classification, three-stage pipeline). Phase 43 (personal memory contribution, remember_about_me / forget_about_me, cross-promotion instruction). Methodology v0.20 (Companion identity, executor opacity, Memory expectations). Companion as Agent Investigation v0.1 (capability tiers, attribution model). Closed-loop Engagement Investigation v0.1 (the Companion as attribution channel; observation distributed and attribution centralized — relevant by analogy). Knowledge Elevation Pathway Investigation v0.1 (held + commit lifecycle as the universal write path).
The Operator's question carries three claims worth unpacking, because each has its own answer:
Claims 1 and 2 are mobile-presence questions, treated in the companion investigation. This document treats claim 3.
The payload is subtly different from anything the converse pipeline currently handles. I parked on level 10 is not a project conversation. It is not a remember_about_me (the fact is not about the Operator's identity, preferences, or constraints — it is about the world, and only briefly). It is not add_knowledge (no project context). It is not general_conversation (no expectation of dialogue). It is closer to dictation that lands somewhere.
The framing question this document treats: what intent class does Loomworks need to handle utterances whose shape is "log this fact to the right engagement, acknowledge briefly, and stop"?
The architectural form of the answer is:
There is a class of turns — call them quick-capture turns — that are structurally distinct from conversation. The Operator emits a fact; the Companion identifies the right destination engagement, authors a held assertion (per Phase 43 lifecycle), produces a minimal acknowledgment, and stops. No dialogue follow-up. No conversation history accumulation in the conversational sense. No engagement context loading beyond what's needed to identify the destination.
Quick-capture is not one new intent in the existing taxonomy; it is a different mode of turn that the existing taxonomy can serve once augmented. The methodologically interesting question — raised but not answered here — is whether quick-capture is an eighth/tenth/Nth intent on the existing classifier path, or a different pre-classifier mode that bypasses the conversational pipeline's full machinery.
The following crystallize:
held and progress through the standard lifecycle. Whether commit is conversational (Phase 43 pattern) or auto (delegation contract) is a Phase 45-shaped question.What does not land in this document: which of the two architectural shapes (intent-class extension vs. pre-classifier fast path) wins. That is the central open question at §6.
remember_about_me?
Initial framing under consideration. I parked on level 10 is a personal fact. Phase 43 already added remember_about_me. Quick-capture is just remember_about_me reached from a voice surface.
Why it fell. Three structural mismatches.
First, scope. remember_about_me was defined for facts about the Operator's identity, preferences, schedule, and constraints — facts that should be remembered across all projects per Phase 43 §S2. "I parked on level 10" is none of those. It is a transient fact about the world that has utility for hours, not lifetimes. Placing it in personal Memory pollutes the long-lived personal-memory layer with ephemeral state.
Second, lifecycle. remember_about_me operates with held + conversational commit (Phase 43 §S2 / §S6): the Companion responds with an acknowledgment-and-confirmation ("I'll remember you're allergic to all shellfish — is that right?"); the Operator commits or refines on the next turn. Quick-capture must not require a follow-up turn. Its whole point is capture and stop. A conversational confirmation is structurally wrong.
Third, conversational shape. remember_about_me lives inside the converse pipeline — classifier prompt, persona system prompt, conversation history, engagement context loading. The full machinery is overkill for "log this fact." The classifier-LLM call alone takes longer than the dictation took to utter.
What landed. Quick-capture is a different kind of turn. It might use remember_about_me-style routing for personal facts among its destinations, but the turn shape itself is distinct.
Stepping outside the existing intent taxonomy: what does a dictation-class turn structurally require?
Notably absent from the requirements: classifier-LLM-call between seven-or-more intents; persona-system-prompt assembly; engagement context loading beyond destination resolution; full responder LLM call.
The dictation-class turn requires less of the converse pipeline than the conversational classes do. Whether that "less" is best expressed by extending the pipeline with a new intent that bypasses some of its phases, or by sitting alongside the pipeline as a separate fast path, is the §6 open question.
The piece with the most methodology depth is routing. The capture and acknowledgment ends are mechanical; the lifecycle is Phase 43 standard; the open architectural question (intent vs. fast path) is structural but not deep. Routing is where the work is.
Three routing-shape candidates surfaced:
Candidate A — engagement-context routing. If the Operator is currently active in an engagement (a chat is open, an engagement is "focused" in the Operator Layer), default the utterance there. Names work as overrides. Personal facts route to personal Memory. Catch-all to a designated engagement.
Candidate B — content-classification routing. A small classifier (LLM or heuristic) reads the utterance and decides destination based on content. "I parked on level 10" → daily log. "The soil samples need to be retested" → soil-irrigation project. "I'm allergic to peanuts" → personal Memory.
Candidate C — Operator-pre-declared routing. The Operator declares routing rules at engagement-creation time or via Memory: "Route parking, errands, and groceries to the daily-log engagement. Route project-language to the active project. Route personal facts to personal Memory." The router applies the rules; ambiguity routes to personal Memory or asks at next chat surface open.
Why each survives or falls.
Candidate A composes well with the Phase 41-onward Companion model — the Companion already knows which engagement is active. It fails on capture devices that have no notion of "active engagement" (a watch face; a Siri shortcut from the home screen; a keyboard shortcut from any text field). The capture device must surface enough context to identify which engagement is active, and that context isn't always present.
Candidate B is closest to how the existing classifier already works. It fits the converse pipeline naturally. It fails on cost: a classifier LLM call per dictated fact is the wrong economics. "I parked on level 10" should not cost a classifier call. The Operator dictates dozens of these per day; the call cost is felt.
Candidate C composes with Phase 43's remember_about_me cross-promotion pattern (Memory-driven behavior governance) and aligns with the methodology's emphasis on Operator authority. It fails when no rules are pre-declared — the alpha onboarding case — and produces a chicken-and-egg: the Operator needs Memory to declare rules in, which means the system needs default routing for at least the first utterances.
What landed. The three are not exclusive — they are layers. A workable router likely uses all three:
The heuristic in step 3 is small — string matching on engagement names, simple keyword-to-engagement maps the Operator can extend, and personal-fact detection (Phase 43's existing remember_about_me boundary). LLM classification is reserved for ambiguity the deterministic layers can't resolve, and even then, it should be the exception path.
The acknowledgment is short. Short enough that the conventional voice register (warmth, expertise, plain-English fluency) is too much. "Got it. Level 10." is closer to a confirmation tone than a conversational one — the voice equivalent of a checkmark.
Three properties seem load-bearing:
This is a different voice register than the conversational pipeline's. It probably wants its own template and its own composition seam (analogous to loomworks/orchestration/credit_voice.py from Phases 49 and 50 — a domain-specific voice loader). The methodology question of whether this is one voice template or several (per destination type, per disambiguation level) is open.
Phase 43 established that personal-fact assertions land held and commit on conversational confirmation. Quick-capture cannot afford a conversational confirmation turn. So one of two things must happen:
Option 1 — quick-capture lands committed directly. Trust the speech-to-text + routing + the ack-checks-the-utterance pattern. Skip the held layer for quick-capture. Methodologically, this is the dictation analogue of the delegation contract (Phase 45): pre-authorized auto-commit for a specific class of turns the Operator has signed off on as acceptable to commit without per-turn approval.
Option 2 — quick-capture lands held; commit is asynchronous. Held assertions accumulate; the Operator confirms a batch later (in the chat surface, or at engagement close, or at end-of-day). Methodologically conservative; preserves the methodology's commit-by-Operator stance without exception.
Option 3 — quick-capture lands held with auto-commit-after-N-hours-unless-Operator-touches. Hybrid. The held lifecycle is preserved on the substrate side; the Operator practically experiences commit-by-default through a delay-and-decay mechanism. Closer to how email "undo send" works. Methodologically more complex; needs careful thinking about what "auto-commit" means for the engagement event log.
The closest precedent: Phase 45's delegation contract for auto-issue of low-stakes actions. The Phase 50 alpha posture for the analogous credit case is always-require-approval at alpha; auto-issue gated by future config flag (P50-D2). The same gradient applies here: alpha probably wants Option 2 (conservative; held + asynchronous batch commit), and a future delegation-contract phase enables Option 1 (auto-commit) for specific quick-capture categories the Operator trusts.
What landed. Three viable options, with Option 2 as the alpha posture and Option 1 as the post-delegation-contract posture. Option 3 is structurally more complex than Option 1 and probably not worth the complexity given Option 1 is reachable through the same mechanism Phase 45 already defined.
Subtle case worth surfacing: "Add milk to the grocery list."
There is no grocery-list engagement. Should there be? Three responses:
What landed. Option (b) matches the methodology's engagement-creation discipline — engagements are first-class objects whose creation is a Companion-proposes / Operator-commits act. Quick-capture should not auto-create engagements; it should surface the gap as a proposal for the Operator to act on at the next chat surface. Option (c) is the alpha fallback when (b) hasn't fired yet — the assertion still lands somewhere, and the Operator can sort it out later.
This connects to the queued direction Engagement creation assistance + Discovery-to-seed skill tracked in loomworks-queued-directions-and-deferred-work-v0_2.md. Quick-capture is a forcing function for that queued direction: dictation surfaces engagement gaps the Operator might not otherwise notice.
A workable shape, distilling §3:
[Capture device]
│
▼ (utterance text + minimal context — active engagement if known,
│ capture device id, timestamp, optional explicit engagement tag)
│
[Quick-capture entry surface] ──────────┐
│ │ (this is the Phase 50-shape question:
│ │ intent-class extension or pre-classifier
│ │ fast path; both reach the same router)
▼ │
[Router — three layers] │
1. Operator-declared rules │
2. Engagement-context default │
3. Light heuristic / classifier │
Fallback: personal Memory │
│ │
▼ │
[Held assertion authored in destination engagement]
│ │
▼ │
[Acknowledgment — short voice register, capture-confirming, destination-confirming when ambiguous]
│ │
▼ │
[Stop. Turn ends.] │
│
[Asynchronous commit path — Operator's chat surface accumulates batched held assertions
from quick-capture; commit/retract/edit through standard Phase 43 controls]
The substrate work is small to moderate: a router (modest); a voice surface (small); an entry surface (the architectural question — small if it's an intent extension, larger if it's a fast path). The methodology weight is in the routing rules and the held + asynchronous-commit lifecycle.
Quick-capture composes cleanly with the existing methodology. Worth tracing the composition explicitly because each composition is a property the methodology already has, used in a new combination.
Phase 41 — Companion identity. The Companion is the actor on the held assertion. ActorRef(kind="companion") is exactly the existing pattern. Quick-capture is the Companion's voice on a thin turn rather than a thick one.
Phase 42 — intent classification. Maybe the entry surface — see §6. If quick-capture is an eighth/tenth/Nth intent, the classifier extends. If it's a fast path, the classifier is bypassed.
Phase 43 — held + commit lifecycle. Inherited directly. Quick-capture lands held; commit is conversational (Phase 43 standard) or asynchronous (the §3.5 alpha posture) or auto (post-Phase-45 delegation).
Phase 43 — remember_about_me boundary. The classifier prompt's existing personal-fact-vs-project-fact boundary is exactly the boundary quick-capture's heuristic layer (3.3 layer 3) needs. Reuse, not re-implementation.
Phase 45 — delegation contract. Quick-capture is a delegation-contract case in waiting. Auto-commit for trusted quick-capture categories is structurally identical to Phase 45's pre-authorized engine-operation execution.
Phase 49 — bimodal dispatch. Quick-capture is plausibly Operator-direct (no Companion-as-Authority decision-making — the Companion routes but does not propose for approval). The bimodal dispatch surface from Phase 49 (delegation_required: bool) is the natural seam.
Phase 50 — Companion-as-Authority pattern, by contrast. Quick-capture is not Companion-as-Authority. The Companion is not making a proposal for the Operator to approve before action — the Companion is logging a fact. The methodology distinction between Companion-proposes / Operator-commits (Phase 49 closed-loop, Phase 50 delivery-class) and Companion-routes / Operator-views-later is worth naming. Quick-capture surfaces a third class: Companion-routes-and-records, with commit happening later through standard Memory lifecycle.
Closed-loop investigation v0.1 — the Companion as attribution channel. Quick-capture is a clean instance of "many possible observers, single attribution channel." The phone is one observer. The browser extension is another. The watch is a third. All route through the Companion to author the held assertion. The investigation's principle — observation distributed, attribution centralized — generalizes to capture devices.
Knowledge elevation pathway investigation v0.1 — held + commit as universal write path. Quick-capture is a high-frequency exercise of this pattern. Worth verifying that the held queue UX scales to dozens of held assertions per day.
The central design question: is quick-capture an intent-class extension on the existing Phase 42 classifier path, or a pre-classifier fast path?
Shape. Quick-capture is one or more new intents on the existing Phase 42 classifier. "I parked on level 10" enters the converse pipeline normally; the classifier identifies it as quick_capture (or a more granular variant — quick_capture_personal, quick_capture_engagement); the router dispatches to a quick-capture handler that does the routing-and-write work; the responder produces the short acknowledgment.
Composition advantages.
Composition costs.
Shape. Quick-capture utterances enter through a different surface (a POST /quick-capture endpoint; a Siri shortcut delivering directly to a fast-path handler). The fast-path handler runs the deterministic router (rules → context → heuristic), authors the held assertion, and emits a short voice template-rendered acknowledgment. No classifier LLM call. No persona system prompt. No responder LLM call. The conversational pipeline is bypassed entirely.
Composition advantages.
POST /quick-capture from any client) with the same machinery. The conversational pipeline is not on the critical path for quick-capture; the fast path is.Composition costs.
A third possibility worth naming: option (b)'s surface for the high-frequency case (mobile shortcut, watch complication, keyboard shortcut — all routing to POST /quick-capture directly) and option (a)'s intent for cases that come in through the chat surface (the Operator typing "I parked on level 10" into a chat box). Same router, two entry points.
This is methodologically sound: the same intent class can have multiple surfaces, just as add_knowledge can be reached through the Memory contribution UI (Phase 16) or through chat (Phase 42). What's distinctive is that the chat-pathway version pays the conversational pipeline's cost (which is acceptable when the user is already in a conversation), while the dedicated-surface version skips it (which is appropriate when the user is dictating).
What landed in this investigation. The hybrid is the most likely shape, but the question is open. The deciding factors are likely (i) operational cost expectations (how frequently quick-capture fires; what the LLM-call cost looks like at expected dictation frequency), (ii) UX cohesion (how confusing is it to have two surfaces), (iii) implementation complexity (the fast path is more new substrate code than the intent extension is). All three are scoping-time questions, not investigation-time questions.
voice_loader analogous to credit_voice?).These are scoping questions. The investigation's job is to surface them; the scoping note's job is to settle them.
personal_engagement, the existing assertion lifecycle, the existing event log). Or it might warrant a quick_capture_log table for capture-device tracking. Scoping decides.This investigation produces architectural framing and a list of decisions for the next stage. The output is thinking material, not building material.
Carrying forward into next-stage scoping:
loomworks/orchestration/quick_capture_voice.py analogous to the credit_voice loader?Quick-capture is not implementation-ready. The §6 architectural question and the §6.4 sub-decisions need scoping work. A scoping note is the next document; a CR follows after.
Two upstream considerations bear on implementation timing:
The earliest reasonable phase is post-Phase-50 close, post-mobile-presence-investigation, post-scoping-pair. Phase 53+ feels right (one phase for routing substrate; one for acknowledgment voice; one for capture-device entry surfaces — mobile, keyboard, browser-extension; potentially folded if scoping reveals smaller surface than this investigation suggests).
The investigation calls forward:
loomworks-queued-directions-and-deferred-work-v0_2.md for the pair, with cross-references to:DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Quick-capture Engagement Investigation — v0.1 — 2026-05-09