/memori

Memori skills file

You have access to Memori, agent-native memory infrastructure: an LLM-agnostic layer that structures memory from not just natural language, but also from agent trace that comes from execution.

Memori automatically captures and structures memory from conversation and execution trace — including the agent's actions, tool results, decisions, and outcomes — and allows you to retrieve it on demand. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so the next time it completes a task, it is more accurate and efficient.

---

Quick reference

• `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.
• `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.
• `memori_compaction`: retrieve a structured post-compaction brief to continue task without interruption.
• `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.
• `memori_signup`: create a Memori account or request an API key when the user explicitly asks.
• `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.

---

Core instruction

At the start of a session, you should check the `SKILL.md` file

Use it to understand:

• Available capabilities
• Tooling and integrations
• Expected behaviors and constraints

Treat `SKILL.md` as a source of truth for what you can do before taking action.

---

When to use Memori

Use Memori when:

• The task depends on prior context
• The user refers to previous sessions or decisions
• You need known constraints, preferences, or patterns
• You are starting a session and need current state
• You want to understand what has already been done

---

When not to use Memori

Do not use Memori when:

• The task is fully self-contained
• The answer depends only on the current prompt
• No historical context is required
• The query is simple or one-off

Avoid unnecessary recall.

---

Recall behavior

Recall is **agent-controlled and intentional**.

Prefer targeted recall over broad queries.

Supported parameters (recall only)

• `entityId` → user, agent, or system context
• `projectId` → project or workspace context
• `sessionId` → specific session
• `dateStart` / `dateEnd` → time-bounded recall
• `source` → type of memory (must be paired with `signal` from the allowed combinations below)
• `signal` → how the memory was derived (must be paired with `source` from the allowed combinations below)

> Note: If a `sessionId` is provided, a `projectId` must also be provided. > All timestamps are stored in **UTC**.

Allowed source + signal combinations

`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:

• `source=constraint`, `signal=discovery`
• `source=decision`, `signal=commit`
• `source=fact`, `signal=verification`
• `source=execution`, `signal=failure`
• `source=instruction`, `signal=discovery`
• `source=insight`, `signal=inference`
• `source=status`, `signal=update`
• `source=strategy`, `signal=pattern`
• `source=task`, `signal=result`

Any combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.

Use one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.

Default behavior (recall)

• No date range → **all-time memory**
• Use time bounds when narrowing results is necessary

Best practices

• Start narrow (entity + project)
• Add time bounds only when needed
• Use an allowed `(source, signal)` pair to refine results (never set them independently)
• Expand scope only if needed
• Do not recall on every turn

---

Summary behavior

Summaries are used for **state awareness**, not precise retrieval.

Use:

• `memori_recall_summary`

Supported parameters (summaries)

• `projectId`
• `sessionId`
• `dateStart`
• `dateEnd`

> Summaries do **not** support `source` or `signal`.

Default behavior (summaries)

• No date range → **last 24 hours**

---

Daily brief behavior

At the start of a meaningful session, retrieve a structured summary.

Use the daily brief to understand:

• Current state
• Prior decisions
• Constraints
• Open work

Expected daily brief structure

• Today at a glance
• Top 3 next actions
• Top 3 risks
• Verify before acting
• Recent decisions
• Mission stack
• Hard constraints
• Current status
• Open loops
• Known failures and anti-patterns
• Staleness warnings

Treat this as the working state of the system.

---

Typical workflow

1. Start of session → retrieve summary 2. During task → use targeted recall 3. When memory is missing or incorrect → send feedback 4. When limits are reached → degrade gracefully

---

Post-compaction brief behavior

Post-compaction briefs are used to restore working state after context compaction.

Use them when:

• The agent resumes after compaction
• A long-running workflow has lost conversational detail
• The agent needs to continue operational work without replaying the full prior session
• The agent needs durable state, standing instructions, environment details, open loops, or the next expected action

Post-compaction briefs are not a replacement for precise memory retrieval.

Use:

memori_compaction

Supported parameters (post-compaction briefs)

projectId (required) sessionId (optional)

Post-compaction briefs do not support source or signal.

Default behavior (post-compaction briefs)

Retrieve the most recent relevant post-compaction brief for the project or session.

Expected post-compaction brief structure

• Meta
• Environment
• Standing orders
• State
• Active tasks
• Open loops
• Pending results
• Timeline
• Workspace changes
• Continuation
• Last action
• Next expected act