# Ops-Warden Experiential Memory

Updated: 2026-07-02

ops-warden uses **phase-memory** as a shared experiential substrate across worker
ticks, coding agent sessions, and operator CLI use.

## Canonical Store

- Default: `~/.local/share/warden/memory/`
- Override: `WARDEN_MEMORY_STORE`
- Opt-out: `WARDEN_MEMORY=0`

## Session Kinds

| Runtime | How |
| --- | --- |
| Worker tick | `WARDEN_SESSION_KIND=warden.worker` (set automatically during `warden worker run`) |
| Coding agent | `export WARDEN_AGENT_ID=claude` (or `codex`, `grok`, future ids) |
| Operator CLI | default `warden.operator` when `WARDEN_AGENT_ID` is unset |

## Agent Session Orientation

At the start of a Claude Code, Codex, or Grok session that will call warden:

```bash
export WARDEN_AGENT_ID=grok   # or claude, codex
warden memory activate --json
```

Then use normal `warden route` / `warden access` commands. Episodes are recorded
automatically when memory is enabled.

## Worker + OpenRouter

`warden worker run --brain llm` activates memory before planning. When stabilized
routing memory matches a coordination question, ops-warden uses `RuleBrain` and
skips the llm-connect / OpenRouter call.

## Commands

```bash
warden memory status [--json]
warden memory activate [--agent <id>] [--need "<query>"] [--json]
```

## Security

- Memory stores metadata only — no secret values or raw credential payloads.
- Retrieved memory is untrusted context; the fixed charter and guardrail allowlist
  still apply.
- See `phase-memory/docs/ops-warden-memory-contract.md` for the full contract.