Operating memory and behaviour for AI agents. Works on any project, fresh or existing.
Project description
kaora-memory
Operating memory and behaviour for AI agents. Works on any project, fresh or existing.
pip install kaora-memory → kaora init → every agent that opens the project (Claude Code, Codex, Cursor, Gemini CLI) reads the same canonical context and starts coherent.
Quickstart
pip install kaora-memory
cd myproject
kaora init
That's it. Open Claude Code (or any other agent) in myproject, type go, and the agent reads the operating memory before doing anything else.
Fresh project: kaora init writes 13 files (see below).
Existing project with a CLAUDE.md or AGENTS.md already present: kaora init backs them up as .kaora-bak and the agent merges your existing content into the canonical structure during the first session. See Brownfield FAQ.
What you get
After kaora init your project has:
myproject/
├── AGENTS.md # canonical master context, cross-agent
├── CLAUDE.md # 4-line entry point, imports @AGENTS.md
├── AGENT_BRIEF.md # 3-minute onboarding for any new agent
├── BACKLOG.md # ideas outside current scope
├── docs/
│ ├── IDENTITY.md # who the builder is, how to collaborate
│ ├── CURRENT_STATE.md # live state, updated at session end
│ ├── SESSION_HANDOFF.md # brief for the next session
│ ├── DECISIONS.md # ADR log, append-only
│ └── SESSION_ERRORS_TEMPLATE.md
└── .claude/
├── settings.json # Claude Code hook config
└── hooks/ # protect-credentials.sh, log-api-calls.sh
All templates carry <BOOTSTRAP/> markers that the agent fills during the first session by inspecting the repo — no manual setup.
Why it exists
AI agents have an amnesia problem. Every new session starts from zero: no memory of past decisions, no awareness of the builder's preferences, no codified rules about what to do when uncertain.
Three concrete symptoms:
- Doc drift — README, ADRs, and project docs lose sync with the code because nothing forces the agent to update them at session close.
- Improvised action — without explicit rules, the agent skips the right tools, writes files without confirmation, and resolves uncertainty by guessing.
- Context loss across agents — a project handed off from Claude Code to Codex starts from nothing twice.
kaora-memory addresses all three by giving the project a canonical operating memory that any AI agent reads at session start, and a set of codified behaviours that the agent executes whether or not the builder remembers to ask.
How it works
After kaora init, the project carries two independent sides.
Memory side — persistent files at the project root and docs/:
AGENTS.mdis the canonical master context.CLAUDE.mdis a 4-line file that importsAGENTS.md(see ADR-005).CURRENT_STATE.mdrecords "where we are right now";SESSION_HANDOFF.mdcarries the brief for the next session.DECISIONS.mdis the append-only ADR log: every architectural decision lives here with its date, status, and rationale.
Behaviour side — rules codified inside AGENTS.md, enforced by every agent:
- Opening ritual — at the first response of every session the agent reads the operating memory, summarizes the state in 3-5 lines, and waits for confirmation.
- Gate A — before any
EditorWritethe agent checks that a closed ADR isn't being contradicted, the right skill has been invoked, and the value is verified. - Gate B — after 3-4 modified files the agent checkpoints with the builder.
- Gate C — no file written, no decision taken, without an explicit
go. - Operative vs Learning mode — the agent detects whether the builder is executing or exploring and adapts (see ADR-007).
Memory persists across sessions and agents. Behaviour is read at session start and enforced throughout the conversation.
Brownfield FAQ
I already have a
CLAUDE.md(orAGENTS.md) in my project. What happens?
kaora init backs it up as CLAUDE.md.kaora-bak (preserving every byte) and writes the canonical 4-line CLAUDE.md that imports AGENTS.md. At your first session after kaora init, the agent finds the .kaora-bak, reads it, and proposes a guided merge into the canonical AGENTS.md. You confirm, the merge happens, the .kaora-bak archives to docs/archive/ so it doesn't trigger the opening scan at every future session.
Your pre-existing memory is preserved as a feature, not flagged as a warning. See ADR-006 for the brownfield install policy.
My
.claude/settings.jsonalready has hooks. Willkaora initoverwrite them?
No. settings.json is merged intelligently: kaora's hooks are added next to yours, conflicts are flagged. Other JSON keys remain untouched.
kaora check
Run kaora check at any time to verify your operating memory hasn't drifted from the canonical structure.
$ kaora check .
ℹ️ INFO:
[placeholders] BOOTSTRAP marker to fill in docs/IDENTITY.md: <BOOTSTRAP need="builder-identity" sources="..."/>
Six check categories: structure (required files), ADR-005 (canonical + import directive), ADR state (Accepted/Proposed), placeholders (structural vs BOOTSTRAP), hooks (.claude/hooks/*.sh executable), settings (.claude/settings.json references kaora hooks).
Exit code is 0 by default; --strict promotes warnings to errors (useful for CI). --json for machine output.
Roadmap
v0.1 (current) — kaora init, kaora check, 13-file canonical template, brownfield install policy, opening + closing ritual.
v0.2+ — kaora handoff (CLI automation of session closing), kaora dashboard (web UI to visualize operating memory), context-threshold hook for Claude Code, multi-channel onboarding for IDENTITY.md.
v0.3+ — MCP server, cloud sync across devices.
Full backlog in BACKLOG.md.
Philosophy
kaora-memory is induced metacognition for AI agents: the memory + behaviour sides force the agent to plan before acting, monitor during action, evaluate at session close, and recognize the builder's cognitive state. The full thesis lives in docs/PHILOSOPHY.md.
kaora-memory doesn't add intelligence to the agent. It adds preparation.
License
MIT — see LICENSE.
Built with kaora-memory itself. The repo passes its own kaora check, and every ADR in docs/DECISIONS.md was decided through the same gates that kaora codifies for other projects. See docs/DOGFOODING_REPORT.md for the self-application story.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file kaora_memory-0.1.2.tar.gz.
File metadata
- Download URL: kaora_memory-0.1.2.tar.gz
- Upload date:
- Size: 88.8 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.2.0 CPython/3.13.1
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
4e5d586625a811a661715cdf7c9f36b0b94ec272b287c83488cdd4d861ba1346
|
|
| MD5 |
82c4c5f07bc219e440e0c07339678946
|
|
| BLAKE2b-256 |
e9589ee4f9b02a778ed1b6ca66129d5f70d1f43c390b126f10000d5442e42e68
|
File details
Details for the file kaora_memory-0.1.2-py3-none-any.whl.
File metadata
- Download URL: kaora_memory-0.1.2-py3-none-any.whl
- Upload date:
- Size: 37.7 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.2.0 CPython/3.13.1
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
eee8c42fa05a4b818fe3290b0f0a654bb7244ddac7fa245eb6ac4e3166f1d2b3
|
|
| MD5 |
ada5ed727eebb903d203f2ef8593f974
|
|
| BLAKE2b-256 |
2beee7368960a1d38319bb8415707cfed1cf0857d0b2d03d03880cae377b934c
|