Resume work from a saved cognitive context.
This provides a narrative briefing to quickly orient you to:
- The investigation that was in progress
- Key discoveries and insights made
- Current hypotheses being tested
- Open questions and blockers
- Suggested next steps
- All relevant memories with their connections
The briefing reconstructs the cognitive state, not just the data. You'll understand
not just WHAT was discovered, but WHY it matters and HOW the understanding evolved.
Example of what you'll receive:
"[API Timeout Investigation - Resuming after 2 hours]
SITUATION: You were investigating production API timeouts that occur at exactly batch_size=100.
This investigation started when user reported timeouts only in production, not staging.
PROGRESS MADE:
- Identified sharp cutoff at 100 items (not gradual degradation)
- Disproved connection pool theory (monitoring showed only 43/200 connections used)
- Found root cause: MAX_BATCH_SIZE=100 hardcoded in batch_handler.py:147
- Confirmed staging uses different config override (MAX_BATCH_SIZE=500)
EVIDENCE CHAIN:
User report → Reproduced locally → Noticed batch_size correlation → Searched codebase for
limits → Found MAX_BATCH_SIZE → Checked staging config → Discovered config difference
CORRECTED MISUNDERSTANDINGS:
- Initially thought it was Redis connection exhaustion (disproven by monitoring)
- Assumed gradual performance degradation (actually sharp cutoff)
- Thought staging/production were identical (config differs)
CURRENT HYPOTHESIS: Production deployment uses default MAX_BATCH_SIZE=100 from code, while
staging has environment variable override. Fix requires either code change or prod config update.
BLOCKED ON: Need production deployment access to apply fix. User considering whether to
change code default or add production environment variable.
RECOMMENDED NEXT STEPS:
1. Verify production environment variables (check if MAX_BATCH_SIZE is set)
2. If not set, add MAX_BATCH_SIZE=500 to production config
3. If code change preferred, update default in batch_handler.py
4. Run load test with batch_size=100-500 range to verify fix
KEY MEMORIES FOR REFERENCE:
- 'Initial timeout report from user' - Starting point of investigation
- 'MAX_BATCH_SIZE discovery' - Root cause identification
- 'Redis monitoring data' - Evidence disproving connection theory
- 'Staging config analysis' - Explanation for environment difference"
This cognitive handoff ensures you can continue the work with full understanding of
the problem space, previous attempts, and current direction. The narrative preserves not
just facts but the reasoning process, mistakes made, and lessons learned.
SPECIAL CASE: restore_context("awakening")
The name "awakening" is reserved for loading the user's personality configuration.
This loads the Awakening Briefing which includes:
- Selected persona identity and voice style
- Custom personality traits (Premium+ users)
- Any quirks and boundaries from the persona preset
Args:
name: Name or ID of context to restore. Can be:
- Context name (exact match, case-sensitive)
- Context UUID (from list_contexts output)
- "awakening" for personality briefing
limit: Maximum number of memories to restore (default 20)
ctx: MCP context (automatically provided)
Returns:
Dict with:
- success: Whether restoration succeeded
- description: The cognitive handoff briefing
- memories: List of relevant memories
- context_id: The restored context identifier