EnClaws Enterprise Experience Extraction

[rrmars]

---

summary: "Assess Claude Dream's current public and leaked-state mechanics, then define how EnClaws should absorb the transferable parts as an enterprise experience extraction pipeline."
owner: "codex"
status: "draft"
last_updated: "2026-04-03"
title: "EnClaws Enterprise Experience Extraction"

EnClaws Enterprise Experience Extraction

Overview

This document answers two questions:

• what Claude Dream appears to be today, based on the official public repository plus a local leaked source snapshot
• how EnClaws should absorb the useful mechanism ideas without copying Claude's personal auto-memory model directly

Bottom line:

• the official claude-code-anthropic repository does not publish Dream implementation code
• the leaked Claude snapshot shows a real two-stage mechanism: per-turn memory extraction plus periodic cross-session consolidation
• EnClaws already has most of the storage and retrieval substrate needed for this
• EnClaws should turn Dream into an enterprise capability called experience extraction, with provenance, review, desensitization, promotion, and auditability

Counter-intuitive finding:
EnClaws should not make MEMORY.md the enterprise system of record.
For enterprise memory promotion, MEMORY.md should be a published consumption view, while typed experience records and approval state should be the real source of truth.

What Claude Dream looks like today

Public status in the official repository

The official claude-code-anthropic repository does not expose the actual Dream runtime.
There is no public source tree for /dream, AutoDream, or extractMemories.

What is visible in CHANGELOG.md is only a feature trail:

• auto-memory existed and became user-manageable with /memory
• autoMemoryDirectory became configurable
• memory extraction had concurrency issues with transcript writes
• MEMORY.md has explicit size limits
• /memory can edit imported memory files
• --bare disables auto-memory

That is enough to conclude Dream is a real product feature, but not enough to treat the official repository as an implementation reference.

Mechanism visible in the leaked source snapshot

The leaked snapshot shows that “Dream” is not a single feature.
It is at least two cooperating background mechanisms:

1. extractMemories

   • runs at turn end
   • forks a background agent
   • extracts durable memories from the current transcript
   • writes only inside the auto-memory directory
   • skips itself when the main agent already wrote memory directly

2. AutoDream

   • runs on a longer cadence
   • uses time gate + session-count gate + lock file
   • reviews sessions touched since the last consolidation point
   • runs a consolidation prompt in a forked agent
   • reports progress through a background task surface

Important nuance:

• in the leaked snapshot, MEMORY.md is effectively an index and published entrypoint, not the full memory body
• Claude also uses topic files and append-only daily logs
• AutoDream is disabled in KAIROS mode, which uses a different disk-skill dream path

What EnClaws already has

EnClaws is closer to “enterprise Dream substrate” than it may look at first glance.

Product direction already matches the problem

The repository already states the right product goals:

• hierarchical memory across personal, department, company, and industry scope
• memory distillation and upgrade
• review, promotion, and reuse of valuable experience
• audit, replay, and visibility

That means the target capability is already part of the product thesis, not a foreign add-on.

Storage topology is already enterprise-ready

The documented tenant layout already gives EnClaws the separation Claude does not need to solve:

• tenant-level SOUL.md, TOOLS.md, MEMORY.md
• user-level isolated workspaces
• per-user workspace/MEMORY.md and workspace/memory/
• per-user session logs and cron state

This is the right base for promotion paths such as:

• user experience -> team artifact
• team artifact -> tenant artifact
• tenant artifact -> cross-tenant template or skill, if policy allows

Retrieval is already stronger than public Claude

EnClaws already has:

• Markdown memory as source-of-truth for agent consumption
• built-in memory indexing over MEMORY.md, memory.md, and memory/**/*.md
• file watchers and incremental sync
• hybrid recall with lexical plus vector search
• optional QMD backend
• optional sanitized session transcript export into a dedicated QMD collection

This means EnClaws does not need Dream in order to gain retrieval.
It needs Dream in order to gain structured extraction and promotion.

Prompt injection and editing paths already exist

EnClaws also already has the two paths that determine whether extracted experience can affect future behavior:

1. bootstrap and prompt assembly

   • workspace and bootstrap-file loading already feed IDENTITY.md, MEMORY.md, TOOLS.md, and USER.md into agent startup and prompt construction
   • this means published experience can influence behavior without inventing a second injection system

2. operator editing surfaces

   • tenant and user memory tools already write into workspace knowledge files
   • gateway memory methods and UI knowledge panels already provide operator-visible editing and inspection surfaces

That is important because enterprise experience extraction should end in the same durable surfaces operators already understand.

EnClaws already has two capture hooks

1. Pre-compaction memory flush

   • EnClaws already runs a silent extra turn when context approaches compaction
   • this captures durable notes before context loss
   • it is token-aware and also supports a transcript-byte threshold

2. Session-finalization memory hook

   • the bundled session-memory hook writes a dated Markdown file on /new or /reset
   • it recovers the previous session transcript when rotation already happened
   • it generates a slug via LLM and stores a session summary file under memory/

These are not equivalent to Claude Dream.
But they are excellent insertion points for an enterprise extraction pipeline.

What EnClaws does not have yet

EnClaws does not currently have a true review pipeline for durable knowledge promotion.

It has approval surfaces for execution and planning, but that is not the same thing as memory governance.
So the missing piece is not only extraction logic.
It is also a dedicated review and promotion control plane for experience artifacts.

Gap analysis

EnClaws has the memory substrate, but not the full Dream loop.

Capability	Claude leaked snapshot	EnClaws today	Gap
Turn-end durable extraction	Yes	No dedicated background extractor	Add lightweight post-turn candidate extraction
Cross-session consolidation	Yes	No Dream-like consolidator	Add scheduled distillation jobs
Tool-scoped extraction sandbox	Yes	Partial via existing agent sandbox	Add extractor-specific allowlist and write scope
Background task visibility	Yes	Partial via cron and reply pipeline	Add extraction/distillation task states
Typed memory categories	Yes	Markdown-centric, not typed records	Add typed experience records
Promotion across scopes	Limited in visible snapshot	Product goal exists, implementation missing	Add review and promotion workflow
Compliance and desensitization	Not central in visible snapshot	Not yet embodied in memory flow	Add mandatory review/policy gates
Provenance and replay	Implicit from transcript paths	Strong platform fit, not wired to memory distillation	Attach evidence and lineage to every promoted artifact

Design goal for EnClaws

EnClaws should not ship “Dream” as a background summarizer.
It should ship enterprise experience extraction with five explicit stages:

1. capture
2. distill
3. review
4. promote
5. recall

That preserves Claude's best mechanism idea, while adapting it to enterprise requirements that Claude's personal auto-memory model does not address.

Recommended architecture

1. Capture lane

Goal:
extract reusable experience candidates from live work with very low overhead.

Recommended triggers:

• post-turn, only on main agent turns
• pre-compaction flush completion
• /new and /reset
• scheduled idle-time catch-up for sessions that ended without reset

Recommended inputs:

• transcript tail
• existing memory/YYYY-MM-DD.md
• current MEMORY.md
• optional QMD-exported session snippets
• user, agent, tenant, and channel metadata

Recommended outputs:

• append-only experience candidate records
• small candidate summaries grouped by day or session
• no direct promotion to higher scopes

Candidate schema should include:

• candidateId
• scope and originScope
• tenantId, userId, agentId
• sourceSessionKey
• sourceTranscriptRefs
• kind such as fact, preference, workflow, policy_hint, failure_pattern, tool_recipe
• confidence
• sensitivity
• entities
• summary
• evidence
• createdAt

2. Distill lane

Goal:
merge noisy candidates into reusable knowledge units.

Recommended cadence:

• nightly per user workspace
• periodic per team or tenant
• manual /distill trigger for operators

Distillation tasks should:

• cluster near-duplicate candidates
• split personal preferences from organization knowledge
• separate descriptive experience from prescriptive guidance
• resolve contradictions with evidence counts and recency
• generate “promotion candidates” instead of writing directly to tenant memory

This is where Claude AutoDream is most transferable:

• time gate
• session-count gate
• lock to prevent overlapping consolidation
• bounded background execution
• explicit tool restrictions

3. Review lane

Goal:
make enterprise promotion safe.

Every promotion candidate should enter a review queue with:

• provenance
• desensitization status
• scope recommendation
• policy classification
• diff against currently published knowledge

Required actions:

• approve
• reject
• redact
• narrow scope
• merge into existing artifact
• rollback previously published artifact

This is the biggest place EnClaws must go beyond Claude.
Without review, “Dream for enterprise” becomes uncontrolled data propagation.

4. Promotion lane

Goal:
publish approved experience into the right scope.

Promotion paths should be explicit:

• personal workspace -> personal durable memory
• personal workspace -> team queue
• team knowledge -> tenant memory
• tenant memory -> reusable skill, rule, or template

Publishing targets should include:

• MEMORY.md for curated durable memory
• memory/YYYY-MM-DD.md for append-only narrative context
• typed knowledge pages such as workflow or policy artifacts
• optional skill/rule material when the experience is procedural rather than factual

5. Recall lane

Goal:
make extracted experience usable by agents without exposing the raw control-plane internals.

Recall should continue to use familiar agent-facing surfaces:

• MEMORY.md
• memory/*.md
• memory_search
• memory_get
• optional QMD-backed search

This keeps the agent experience simple.
The complex enterprise machinery stays behind the scenes.

Source of truth model

Recommended split:

• system of record: typed experience records plus approval metadata
• published working memory: Markdown views consumed by agents

Why this split is necessary:

• Markdown alone is easy to read, but weak for lineage, approval state, conflict resolution, and rollback
• enterprise promotion needs durable provenance
• the same approved artifact may need to publish into multiple Markdown projections

Suggested storage model:

• append-only candidate and review metadata in SQLite or another local structured store already aligned with EnClaws state management
• published Markdown views under the existing workspace and tenant memory paths
• optional JSON export for external audit or BI systems

Concrete EnClaws integration points

Existing code to reuse

• src/agents/workspace.ts and src/agents/bootstrap-files.ts

  • already define and load workspace bootstrap files
  • best place to keep published experience connected to prompt assembly

• src/auto-reply/reply/agent-runner-memory.ts

  • already runs silent memory flush turns near compaction
  • already tracks metadata such as memoryFlushAt and memoryFlushCompactionCount
  • best place to add a post-turn candidate extractor or enqueue one

• src/hooks/bundled/session-memory/handler.ts

  • already persists dated session summaries on /new and /reset
  • should become a boundary-capture fallback for the experience pipeline, not the primary distillation mechanism

• src/memory/internal.ts

  • already defines which files are memory-bearing and how they are discovered
  • should remain the published-memory discovery layer

• src/memory/manager.ts

  • already manages watchers, sync, and hybrid search
  • should index published experience projections, not raw unreviewed candidates by default

• src/memory/qmd-manager.ts

  • already supports separate session exports for search
  • should become an input source for extraction and distillation jobs

• src/gateway/server-cron.ts and src/cron/*

  • already provide scheduling primitives
  • natural place to run nightly and periodic distillation jobs

• src/gateway/server-methods/memory.ts

  • already exposes memory listing and mutation surfaces
  • likely extension point for future review queue and promotion APIs

• existing approval and planning surfaces

  • useful as inspiration for operator workflow, but not sufficient as the long-term review system for promoted experience

New module boundary to introduce

Add a dedicated src/experience/ subsystem rather than hiding enterprise logic inside src/memory/.

Recommended slices:

• src/experience/capture.ts
• src/experience/distill.ts
• src/experience/review.ts
• src/experience/promote.ts
• src/experience/publish.ts
• src/experience/policy.ts
• src/experience/store.ts

Reason:
memory retrieval and enterprise experience governance are related but not the same concern.
Keeping them separate avoids turning src/memory/ into a mixed retrieval plus workflow subsystem.

Execution model

Lightweight extractor

This is the EnClaws equivalent of Claude extractMemories.

Recommended rules:

• run only for main sessions, not subagents by default
• skip when the main run already performed explicit memory writes
• cap runtime aggressively
• keep tools restricted to read-only exploration plus writes into the candidate store
• prefer same-session context reuse where possible, but do not block on prompt-cache-sharing support

Scheduled consolidator

This is the EnClaws equivalent of Claude AutoDream.

Recommended rules:

• run per user and per tenant on explicit cadence
• use time gate, session-count gate, and lock file or lock row
• use lower-cost models when the extraction workload is mostly clustering and summarization
• generate promotion candidates and diffs, not silent cross-scope writes

Manual operator controls

Add operator surfaces rather than relying only on automation:

• /distill
• /experience status
• /experience review
• /experience promote
• /experience rollback

Safety model

Enterprise experience extraction must be conservative by default.

Recommended policy gates:

• no cross-user promotion without review
• no tenant-scope promotion from private channel context without explicit policy approval
• no direct promotion of secrets, credentials, personal data, or one-off incidents
• dedupe and contradiction checks before overwriting published durable memory
• every promoted artifact must retain source evidence and actor identity

Recommended classification fields:

• privacy: public, internal, restricted, secret
• reviewStatus: pending, approved, rejected, redacted, superseded
• promotionScope: personal, team, tenant
• artifactKind: fact, workflow, policy, preference, skill-seed, incident-pattern

Recommended rollout

Phase 0: schema and control-plane design

Deliver:

• experience candidate schema
• promotion and review states
• published-memory projection rules

Estimate:

• human team time: 2 to 4 days
• AI-assisted time: 1 to 3 hours

Coverage:
substantial design coverage, no user-facing feature yet

Phase 1: post-turn capture MVP

Deliver:

• lightweight candidate capture after main turns
• boundary capture from /new and /reset
• candidate persistence and basic operator inspection

Estimate:

• human team time: 1 to 2 weeks
• AI-assisted time: 4 to 8 hours

Coverage:
partial, but immediately useful

Phase 2: scheduled distillation plus review queue

Deliver:

• nightly consolidation
• review queue
• promotion candidate generation
• basic desensitization and dedupe

Estimate:

• human team time: 2 to 4 weeks
• AI-assisted time: 1 to 2 days

Coverage:
substantial

Phase 3: scope promotion and rollback

Deliver:

• personal -> team -> tenant promotion
• rollback and supersession
• published-memory projections
• provenance-aware audit trail

Estimate:

• human team time: 3 to 6 weeks
• AI-assisted time: 2 to 4 days

Coverage:
complete for a first enterprise-grade release

Non-goals

• cloning Anthropic-specific rollout gates such as GrowthBook tengu_*
• depending on prompt-cache-sharing to make the design viable
• auto-promoting private experience across users without review
• treating raw transcripts as directly publishable organizational memory
• forcing all extracted knowledge into MEMORY.md

Recommendation

EnClaws should absorb Dream as mechanism, not as product shape.

The transferable mechanism is:

• cheap capture at turn boundaries
• scheduled consolidation
• strict tool sandboxing for background jobs
• explicit gating and lock control

The required EnClaws upgrade beyond Dream is:

• typed experience records
• review and compliance workflow
• scoped promotion
• provenance and rollback
• Markdown publication as a view, not the primary control plane

If implemented this way, EnClaws will not merely replicate Claude's Dream.
It will turn Dream into an enterprise learning pipeline.

[Jianping-Xiong]

Three thoughts on MVP scope.

1. MVP = capture + recall. Nothing else.

Five stages is the right end goal, but Phase 1 should only do capture and recall. No LLM distillation — just dedup by date. No review, no promotion.

Claude Code's AutoDream (their distill equivalent) is still feature-flagged off with no production data. Their extractMemories (just capture) is the part that actually works. Do that first.

2. Test it on git-monitor and issue-guard.

Don't validate in the abstract. Use what's already running in production:

• git-monitor: each commit analysis produces structured output — commit patterns, rule violations. Natural workflow candidates. Tests org-level pattern capture.
• issue-guard: each successful answer with a satisfaction signal. Natural fact candidates. Tests the capture → recall loop directly.

Both already have code, data, and users. team-pm is still design-only — can't validate on something that doesn't exist yet.

3. Let the LLM fill 6 fields, not 14.

The candidate schema has 14 fields. That's fine as a data model, but don't ask the LLM to produce all 14 in the extraction prompt. It'll get sloppy — bad summaries because it's busy scoring confidence and classifying sensitivity.

MVP extraction prompt should require only: candidateId, kind, summary, evidence, createdAt, sourceSessionKey. The rest (tenantId, userId, agentId, scope...) can be filled by code from context. Add more LLM-produced fields later when you can measure extraction quality.

For reference, Claude Code's extractMemories uses 4 categories + free-form text. Works fine.

[Jianping-Xiong]

Three more MVP-scoped suggestions, continuing from the previous comment.

4. Route candidates through memory_search, not prompt injection.

When extraction produces candidates, recall them via memory_search on demand. Don't bulk-inject into system prompt. Bulk injection = token cost grows linearly with memory size, stale and fresh knowledge mixed.

Rule: search first → get candidate list → fetch specific items into context.

5. MVP experience candidates: 3 types, not 6.

The proposed 6-type taxonomy is too fine for MVP. Start with:

• fact — precise info that must be quoted verbatim (commit hash, API endpoint, config value)
• workflow — repeatable process or template
• lesson — success/failure case worth remembering

Preferences don't need auto-extraction at MVP — users can write USER.md manually. Add more types when there's enough data to tell them apart.

6. Retrieval weights: fixed thresholds for MVP.

BM25 + vector hybrid search is already in place. For MVP:

• Cold start (< 50 entries): BM25 0.8, vector 0.2
• Normal (≥ 50): BM25 0.5, vector 0.5

Hardcode these. A/B testing needs hundreds of queries for statistical significance — not available at MVP scale.