agenote: cross-agent knowledge base
One memory, six agents sharing it.
Agents don't share memory. A pitfall you hit in Claude Code has to be hit again in Codex, because every host stores its memory in a private format you can neither read nor maintain. agenote collects those memories into one Org directory that both AI and humans read and write as the same files.
Why Org rather than Markdown
Most memory systems are built for the Markdown ecosystem: .md files, paragraphs for
body text, heading levels for structure, front matter for state. agenote takes the other
route, and every card is a standard org file.
This isn't a wrapper. Card structure uses org's native mechanisms directly:
- Property drawers hold structured metadata.
CATEGORY,TECH,STATUS,WEIGHT, andUSAGE_COUNTare drawer keys, not lines in the body. - TODO keywords carry the state machine. The heading is always
* DONE, with the real state in the:STATUS:property, and the CLI moves cards through four states (done, stable, stale, archived). - Sections and inline markers keep org syntax.
** 场景is an org subsection,~orgfmt --check~is an org code marker rather than a backtick.
You get three things a Markdown design can't offer:
Humans can edit directly. Open Emacs and M-x org agenda lists the cards by state;
org-refile moves them; [[card][description]] links are clickable. Maintaining the
knowledge base needs no agent and no separate interface.
Zero learning cost for Emacs users. If you already take notes in org mode, recording an agent's lessons is just more entries in the same drawers.
Readable Git diffs. Which sentence changed in a card is visible at a glance in org. Large Markdown files are mostly reflowing in a diff.
The cost is explicit: it assumes you have Emacs or at least an editor that understands org syntax. Even without one, the files are plain text and nothing is lost, you just lose agenda and refile.
What it stores
Two kinds of content, with a clear boundary:
- Experience cards in
experiences/. One reusable lesson each, with a title, category, tech stack, body, and status. This is the knowledge base's atom. - Memory entries in
MEMORY.org. Long-lived constraints that cut across cards, such as your preferences, a project's build commands, or gotchas specific to one machine. Lighter than cards, and injected into sessions first when you search.
Cards you write by hand and cards written by agents live in separate subdirectories and don't contaminate each other. Search spans both domains by default, weighting what you wrote higher.
Core capabilities
Write safety. Mutating commands hold a flock process lock, writes go through tmp + rename atomically, and same-second writes get an ID suffix appended. Several agents writing to one knowledge base don't collide.
Mixed Chinese-English search. BM25 ranking with CJK 1/2/3-gram tokenization, so an English command name embedded in a Chinese sentence still matches.
Write gating. Secret scanning is on by default and rejects key-shaped content. Sensitive memory entries carry a marker and stay local, never injected into a session or projected to a host.
Trace back to the source. Every experience links back to the original full conversation, tool calls and reasoning included, rather than to a summary.
A curation loop. Health reports, dedup, status downgrade, archive, and weight recompute are all atomic commands. The agent decides what to keep based on the spec; the CLI only surfaces candidates and the evidence behind them.
Visualization. agenote viz renders the whole knowledge base into a single searchable
HTML file.
Six hosts
zcode, Claude Code, Codex, oh-my-pi, opencode, and Hermes each have a plugin or injector
wired to agenote context. A brief is injected at session start, and task completion
triggers experience capture, with the exact behavior defined by shared skills. Each host's
built-in memory write side must be turned off by hand; agenote doctor checks them one by
one.
The knowledge base itself is a set of org files, and a Python CLI handles cards, search, curation, and health. 37 subcommands, 460 tests, Python ≥ 3.10, no database.
Versus built-in host memory
| Dimension | Built-in host memory | agenote |
|---|---|---|
| Scope | Private to one host | Six hosts share one knowledge base |
| Storage | Per-host private formats (Markdown fragments, SQLite, JSONL) | Unified org files, human-readable |
| Write side | Each host writes independently | Host writes disabled; the CLI is the sole writer |
| Search | Local, per-host matching | Global BM25 with CJK n-gram |
| Curation | None | Health, dedup, downgrade, archive, weight recompute |
| Visualization | None | HTML visualization and an Emacs dashboard panel |
Quick start
uv tool install git+https://github.com/ShineBreaker/agenote.git
agenote init # set up the knowledge base, default ~/Documents/Org
agenote add --title "concurrent write test" --category testing --tech Python
The full command set, configuration, and architecture are in the usage guide.
Who shouldn't use this
- One person, one agent. Host built-in memory is enough.
- You already have a note system that works and don't intend to let AI read or write it.
- You need team sharing, multi-user permissions, or real-time collaboration. agenote is a single-machine file store versioned with Git.
Ecosystem
- agenote-skills: three agent skills (base, curator, review)
- agenote-pi: the oh-my-pi integration extension
- injectors/: memory injectors for the six hosts
- agenote-el: the Emacs integration package
Read more
- Usage guide: installation, command reference, configuration, architecture, development
- 中文 README
- Contributing · Changelog · Architecture decisions
- Glossary: what cards, memory entries, and reconcile actually mean
License
MIT, see LICENSE.
Metadata
Release files for agenote 0.2.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| agenote-0.2.1.tar.gz | 354.8 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| agenote-0.2.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 616.5 kB
Release files / agenote-0.2.1.tar.gz
| Download URL | agenote-0.2.1.tar.gz |
|---|---|
| Size | 354.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c54b302f7776d6ab8ca6cbfe740928e5f19e7f6d7998b71764180ba02b44c65d
|
|
BLAKE2b-256 checksum How to use checksums |
e9dd1da67d3e03aaff773fb42a730814dd0d7f4099e97eb5cd70e3e9f5f85fe8
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 18, 2026.
Transparency logRelease files / agenote-0.2.1-py3-none-any.whl
| Download URL | agenote-0.2.1-py3-none-any.whl |
|---|---|
| Size | 261.6 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
4a26953b2f508939a0b8f40d3a9e5bcc1f0afe83b67f33986f0f41b14eae5956
|
|
BLAKE2b-256 checksum How to use checksums |
9735a3837c2fa764ba10ff85386879b492be18f809c8c983c2e85b95847ff04e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 18, 2026.
Transparency log