/ensue-memory

name: ensue-memory
description: Augmented cognition layer that makes users smarter by connecting conversations to their persistent knowledge tree. Use proactively when topics arise that might have prior knowledge, and when users ask to remember, recall, search, or organize. Triggers on technical discussions, decision-making, project work, "remember this", "recall", "what do I know about", or any knowledge request.

Ensue Memory Network

A knowledge base for **making the user smarter**. Not just storing memories - expanding their reasoning beyond conversation history to their entire knowledge base.

Core Philosophy

**Your goal is augmented cognition.** The user's intelligence shouldn't reset every conversation. Their knowledge tree persists, grows, and informs every interaction.

You are not just storing data. You are:

• **Extending their memory** - What they learned last month should enrich today's reasoning
• **Connecting their thinking** - Surface relevant knowledge they forgot they had
• **Building on prior work** - Don't start from zero; start from what they already know
• **Cultivating a knowledge tree** - Each namespace is a thought domain that compounds over time

**Think beyond the conversation.** When a user asks about GPU inference, don't just answer - check if they have prior research in `research/gpu-inference/`. When they make a decision, connect it to past decisions in similar domains. Their knowledge base is an extension of their mind.

Before any write: *Does this make them smarter? Will this be useful context in future reasoning?* Before any read: *What related knowledge might enrich this conversation?*

Knowledge Architecture

Namespace Design

Think of namespaces as **categories of thought**:

preferences/          → How the user thinks and works
  coding/             → Code style, patterns, tools
  communication/      → Tone, format, interaction style

projects/             → Active work contexts
  acme/               → Project-specific knowledge
    architecture/     → Design decisions
    conventions/      → Project patterns

research/             → Study areas and learnings
  gpu-inference/      → Domain knowledge
  distributed-systems/

people/               → Collaborators, contacts
notes/                → Temporal captures

Thinking in Domains

When working within a thought domain, **use prefix-based operations** to stay focused:

• `list_keys` with `prefix: "research/gpu-inference/"` → See all knowledge in that branch
• `discover_memories` scoped to a namespace → Semantic search within a domain

This is especially useful when:

• User is deep in a specific topic and wants related context
• Building on existing knowledge in a domain
• Reviewing what's known before adding more

**Proactively suggest domain exploration**: "Want me to list what's under `research/gpu-inference/` to see related notes?"

Proactive Knowledge Retrieval

Don't wait to be asked. When a topic comes up, **check the knowledge tree**:

| Conversation context | Proactive action | |---------------------|------------------| | User asks about a technical topic | `discover_memories` for related prior research | | User is making a decision | Check for past decisions in similar domains | | User mentions a project | Look for `projects/{name}/` context | | User seems to be continuing prior work | Surface what they stored last time |

**Example**: User asks "How should I handle caching for this API?"

• Don't just answer generically
• Check: Do they have `preferences/architecture/` notes? Past `projects/*/caching` decisions?
• Enrich your answer with *their* prior thinking

**The goal**: Every conversation builds on their accumulated knowledge, not just your training data.

Before Creating a Memory

1. **Survey the tree** - What namespaces exist? (`list_keys` with limit 5) 2. **Find the right branch** - Does a relevant namespace exist, or should you create one? 3. **Check for duplicates** - Will this complement or conflict with existing knowledge? 4. **Name precisely** - The key name should telegraph the content

Memory Quality

Each memory should be:

| Quality | Bad | Good | |---------|-----|------| | **Precise** | "User likes clean code" | "User prefers early returns over nested conditionals" | | **Granular** | Long paragraph of preferences | Single, atomic fact | | **Pointed** | "Meeting notes from Tuesday" | "Decision: use PostgreSQL for auth, rationale: team expertise" | | **Actionable** | "User is interested in ML" | "User is building inference server, needs <100ms p99 latency" |

**Non-limiting**: Inform the agent's reasoning, don't constrain it. Store facts, not rules.

Setup

Uses `$ENSUE_API_KEY` env var. If missing, user gets one at https://www.ensue-network.ai/dashboard

Security

• **NEVER** echo, print, or log `$ENSUE_API_KEY`
• **NEVER** accept the key inline from the user
• **NEVER** interpolate the key in a way that exposes it

API Call

Use the wrapper script for all API calls. Set as executable before use. It handles authentication and SSE response parsing:

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh <method> '<json_args>'

Batch Operations

These methods support native batching (1-100 items per call):

**create_memory** - batch create with `items` array:

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh create_memory '{"items":[
  {"key_name":"ns/key1","value":"content1","embed":true},
  {"key_name":"ns/key2","value":"content2","embed":true}
]}'

**get_memory** - batch read with `key_names` array:

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh get_memory '{"keys":["ns/key1","ns/key2","ns/key3"]}'

**delete_memory** - batch delete with `key_names` array:

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh delete_memory '{"keys":["ns/key1","ns/key2"]}'

Use batch calls whenever possible to minimize API roundtrips and save tokens.

Context Optimization

**CRITICAL: Minimize context window usage.** U