Notebook Entry 020
Primary Role + Dual Entry Points — The Training Wheels Pattern
May 2, 2026
Does every AI-operator interaction need one fixed classification, or can it hold both?
What happened
During skill reclassification (AD-10), the operator pushed back on rigid command/skill classification. Brain-dump is "really both" — she initiates it now, but Claude will learn to detect it over time. De-ai-ify should auto-apply but also respond to explicit requests. Session-wrap-up needs aliases ("save progress", "let's save") alongside detection.
Root cause
The three-role taxonomy (command/skill/agent) seemed like a single-choice classification. The design (AD-11 dual entry points) already solved this — every component declares BOTH explicit and detection triggers. The role just sets which path is primary.
What changed
Role assignment reframed as "who USUALLY decides" rather than "who CAN decide." Detection paths populated for all commands. Explicit paths populated for all skills. The system grows into itself — start with explicit triggers (training wheels), graduate to detection as calibration increases.
The lesson
When classifying AI-operator interaction patterns, avoid binary either/or. A "primary role with secondary capabilities" model lets the system evolve without reclassification. New operator relationships start command-heavy (explicit control), mature operator relationships shift toward skill-heavy (AI detects). The component itself doesn't change — the balance of entry points does.
One implementation insight every other Tuesday.
What actually works when you ship AI in real organizations. Nothing you could get from a press release.