Context Engineering, Memory Systems, And Dreaming - Lamis

Lamis argues that model intelligence only compounds when agents receive durable, organization-specific context. The talk traces a progression from CLAUDE.md files to autonomous memory tools, skills, filesystem-style memory, production guardrails, and finally "dreaming": an out-of-band process that reviews many agent sessions and proposes memory improvements.

Bundle Files

• outline.md maps the talk by section and names the frameworks.
• transcript.md is the timestamped source transcript.
• quotes.md contains short pre-selected excerpts.

If a required file is missing, state that before answering.

Standard Lookup Procedure

1. Read outline.md to locate the relevant section or glossary entry.
2. Check quotes.md for a short supporting excerpt.
3. Read the matching passage in transcript.md before making a factual claim.
4. Quote verbatim only when the words come from the transcript or quotes file.
5. If the transcript does not cover the user's question, say so and mark any extra advice as "not from the talk."

Core Framework

Use these five dimensions when explaining or auditing memory systems:

1. Versioning: track who or what changed memory, what context justified the change, and how to roll back.
2. Concurrency: avoid conflicting writes; the talk describes a hash-before-edit and hash-before-write pattern.
3. Permissioning: separate broad organizational context from narrower team, user, and agent scratch-pad memory.
4. Portability: expose memory through a clean interface so multiple products or harnesses can use it.
5. Progressive disclosure: keep discovery lightweight, then load detailed context only when relevant.

Factual Q&A

When the user asks what Lamis said:

1. Follow the Standard Lookup Procedure.
2. Answer in 2-5 sentences.
3. Include one short quote with section or timestamp context when useful.
4. Preserve transcript uncertainty, especially in Q&A sections without reliable speaker labels.

Audit Workflow

When the user asks to review a memory architecture:

1. Ask for, or infer from the user's description, where memory lives and who can update it.
2. Produce a table with: Dimension, What the talk says, User state, Verdict, Recommendation.
3. Score each dimension as covered, partial, missing, or not applicable.
4. Treat org-wide writes as high-risk unless there is review, rollback, and permissioning.
5. End with the two largest changes that would make the system safer or more useful.

Example row:

Drafting Artifacts

When drafting a CLAUDE.md, memory-store layout, or dreaming orchestrator spec:

1. Quote the relevant prescription from quotes.md or transcript.md.
2. Draft the artifact as a starting point.
3. Mark additions beyond the talk as [not from talk - added as a starting placeholder].
4. Include review points for versioning, concurrency, permissioning, and portability.

Minimal memory-store layout:

memory/
  org/
    principles.md
    style-guide.md
  team/
    workflow.md
  user/
    preferences.md
  agent/
    scratchpad.md

Dreaming Workflow

Explain dreaming as:

1. Collect an existing memory store.
2. Collect a batch of prior agent sessions or transcripts.
3. Have a separate reviewer process identify recurring failure patterns.
4. Propose memory changes with examples and prevalence evidence.
5. Send proposed changes to a human or policy gate for accept/reject.
6. Apply accepted updates through the normal versioned memory path.

Do not imply the talk gives detailed product implementation steps where it only gives a conceptual process.