Theory of Mind
Navigator’s Theory of Mind (ToM) features are built on a finding from Riedl & Weidmann (2025) human–AI synergy research: how well a person models a collaborator’s capabilities predicts collaborative ability — but not solo ability. The paper reports a 23–29% boost to collaborative outcomes from stronger mutual modeling. That distinction is the whole point. Working well with Claude is a different skill from working well alone, and it improves when each side has an accurate picture of what the other can do.
Why this matters for human + Claude work
If collaboration quality rides on accurate mental models, then the friction in an AI coding session is rarely raw capability — it’s mismatched expectations. You assume Claude knows a constraint it never saw; Claude assumes a preference you never stated. ToM features exist to close that gap deliberately rather than hoping it closes itself.
Bilateral modeling
Modeling runs in both directions:
- Claude models you. Through
nav-profile, Claude learns your preferred frameworks, communication style, and conventions, and auto-learns from the corrections you make during a session. - You model Claude. Verification checkpoints and belief-state anchors make Claude’s working assumptions visible, so you can calibrate what it does and doesn’t understand before code is generated.
Neither direction alone is enough — synergy comes from both.
The five ToM features
- Verification checkpoints — on high-stakes skills, Claude states its understanding before generating, so a wrong assumption gets caught at the cheapest possible moment.
- Bilateral modeling — Claude carries your preferences across sessions instead of relearning them each time.
- Quality detection — watches for collaboration drift (repeated corrections, confusion) and prompts a re-anchor before the session degrades.
- Enhanced markers — capture intent and goals, not just file state, so a resumed session restores why you were doing something, not only what.
- Belief-state anchors — let Claude declare assumptions explicitly (known / assumed / unknown) so you can correct the unknowns up front.
Why it’s opt-in and high-stakes only
Calibration has a cost: stating understanding and declaring assumptions adds turns. Applying that to every trivial edit would tax exactly the work that doesn’t need it. So checkpoints default to high-stakes skills (migrations, endpoints, components, task docs) and belief-state anchors stay off until you turn them on. The goal is alignment where mistakes are expensive, and speed everywhere else.