Cultivation > Accumulation

Your AI Agent Doesn't Have a Retrieval Problem. It Has a Knowledge Architecture Problem.

You’ve built an agent. It works well in a single session: It reasons clearly, follows instructions, produces useful output. But when its window runs out, the dreaded “compaction” message displays. You wait and what comes back is based on lossy, compressed summaries that often miss structure of what was previously learned. You have to re-explain steps, point to resources already shared, rebuild context that should have persisted. So you bolt on a conversation summary, system prompts, maybe a vector database, or RAG. And it sort of works. The agent can retrieve relevant past information when prompted. It can look things up. But it’s still waking up on Groundhog Day, starting fresh each time, assembling context from scratch.

The agent performs well when inside its context window. What it can’t do is carry forward the structure of what it learned. Each session rebuilds context from scratch. This means relationships between concepts don’t persist. The reasoning might be fine, but the conceptual architecture around it keeps eroding between sessions.

Letta’s August 2025 finding showed that a simple file-based interface scored 74.0% on the LoCoMo benchmark, outperforming Mem0’s specialized graph memory at 68.5%. The lesson: Agents are better at using tools they know, and they know file operations. But Letta’s finding is about retrieval. The Hu et al. survey on agentic memory maps where the field is heading: Toward structured and graph-based approaches, with the central open question shifting from “How do we retrieve?” to “How do we organize what gets stored?” The question Letta leaves open is what happens when you add explicit structure to those familiar file operations, and when the task goes beyond retrieval into conceptual navigation and knowledge maintenance.

Current solutions, though, have a common problem. Structure is being retrofitted onto existing retrieval infrastructure: Graph layers on vector stores, clustering algorithms on top of embedding pipelines, graph traversal bolted onto RAG. Even purpose-built graph approaches, which come closer to treating structure as foundational, still lock that structure inside databases, readable only through a query layer, editable only through an API, or portable only with the infrastructure that produced it. The knowledge is in there somewhere. You just can’t get to it directly, and neither can your agent.

WikiBonsai starts from the opposite direction: Instead of retrofitting structure onto retrieval, put the structure in the text itself. As covered in the previous post, WikiBonsai extends markdown with three primitives -- typed links, structured attributes, and an explicit semantic hierarchy -- that together form a complete knowledge graph in plain text files. No query layer. No running service. Legible to any human, LLM, or script that can read a file.

For an AI agent, this means the knowledge layer is mutually intelligible between the agent and the humans working alongside it. It is portable across models and databases. And unlike retrieval-only systems, it supports long-term conceptual navigation: The agent knows, not just that a concept exists, but where it lives relative to everything else. It is the only system where typed relationships and a semantic hierarchy live inline with the content in plain text files, maintained by deterministic operations rather than LLM-driven extraction.

WikiBonsai is not alone in betting on deterministic execution for structural operations. Multiple recent projects have independently adopted the same approach. The convergence suggests the principle is sound. What WikiBonsai adds is the cognitive grounding: The structure serves understanding, not just retrieval.

tendr-skill

The skill is a single markdown file. It instructs the agent to learn the WikiBonsai primitives (typed links, structured attributes, and semantic hierarchy in plain markdown), install tendr-cli for deterministic graph operations, and configure its relationship to the knowledge base through an auth mode.

The skill supports two auth modes: In agent mode, the knowledge base belongs to the AI agent and it reads and writes freely. In user mode, the knowledge base belongs to the human user and the agent must receive instructions in order to make changes. If no mode is set, the skill defaults to user mode. An agent that proposes before it commits is recoverable. An agent that writes freely to someone else’s knowledge base without permission is not.

tendr-cli

The skill’s second instruction is to install tendr-cli1 and use it for graph operations. Here is why that matters and what it looks like in practice.

You can install with:

$ npm install -g tendr-cli

The CLI gives your agent a set of discrete, deterministic knowledge operations. Each command does one thing, does it reliably, and leaves a clean audit trail. Here is what that looks like in practice.

tendr doctor

$ tendr doctor

✅ all clean

$ tendr doctor

⚠️ [config] [lint] is deprecated — rename to [format]
❌ [tree] duplicate entity names found:

- "duplicate-filename"
  - File "i.bonsai" Line 1
  - File "i.bonsai" Line 4

Check the health of your files with this command. For an agent that is continuously writing to a knowledge base, this is the equivalent of a compiler check: Run it regularly and catch structural errors before they propagate.

tendr list

$ tendr list

structure

  nodes              5
  tree               3
  web                3
  orphans            2
  isolates           2

references

  wikiattrs          1
  wikilinks          3
  wikiembeds         0

types

  doctypes           1
  attrtypes          1
  linktypes          1

Get a snapshot of the knowledge base at a glance. How many nodes, how many are in the tree, how many are connected through the web, how many are orphaned. This dashboard can help provide some general figures to get one’s bearings in any given knowledge base.

tendr stat

$ tendr stat text-retrieval

📄 fname-a [default]

🌳 Tree

  ancestors: i.bonsai
  children: fname-b, fname-c, fname-d, fname-e

🕸️ Web
          back                          fore
  attr    ◦ attrtype                    ◦ reftype
            • fname-b                   • fname-b
                                        ◦ attrtype
                                        • fname-c
  link    • fname-c [linktype]          • fname-d [linktype]
          • fname-d                     • fname-e
          • i.bonsai                    • no-doc
  embed   • fname-f                     --

Where does this concept sit? What’s above it in the hierarchy? What’s beside it? What depends on it? What’s related to it? The agent doesn’t just know the concept exists; it knows the concept’s address in conceptual space. That is the operational difference between retrieval and orientation. A retrieval system tells you a concept exists. A structured knowledge base tells you where it lives.

tendr tree

$ tendr tree

ai-agent-memory
├── context-management
│   ├── context-window
│   └── context-compression
├── memory-types
│   ├── working-memory
│   ├── episodic-memory
│   └── semantic-memory
├── retrieval
│   ├── vector-retrieval
│   ├── graph-retrieval
│   └── text-retrieval
└── storage
    └── vector-store

Print the full knowledge structure. What you see looks like a table of contents for a textbook on the domain, except it was generated in seconds, lives in plain markdown, and can be read, edited, or queried by any tool that handles text.

tendr rename

$ tendr rename "episodic-memory" "session-memory"

are you sure you want to rename "episodic-memory" to "session-memory"? [y/n]
y
UPDATED FILENAMES:
  episodic-memory -> session-memory
UPDATED FILE CONTENT:
  ai-agent-memory
  memory-types

Rename a concept holistically. Every reference across every file updates automatically. The knowledge structure evolves without breaking. When changing one thing propagates correctly through everything that references it, that is knowledge with structural integrity.

garden-beds

The fastest path to a working WikiBonsai knowledge base is a starter garden-bed. This repo houses pre-structured collections of markdown files you can clone and extend rather than starting from scratch. Drop them into any WikiBonsai vault and they integrate with whatever structure is already there.

garden-beds/
└── agent/
    ├── minima/       ← bare-bones starter for ai agents
    ├── foundation/   ← Anthropic AI constitution, ethics, game theory, prompt injection awareness
    └── guardrails/   ← constraints and guidelines for how an agent should conduct itself

If you build something worth sharing, the garden-beds repo is where it lives. Open a pull request with your transplantable notes and they become available to anyone building a WikiBonsai knowledge base.

Or bootstrap a structured ontology from a single concept with tendr seed (requires an API key):

$ tendr seed "ai-agent-memory"

[[computer-science]] > [[machine-learning]] > [[ai-agents]] > [[ai-agent-memory]]

: title    :: AI Agent Memory
: alias    :: ''
: hypernym :: [[ai-agents]]
: hyponym  ::
             - [[context-management]]
             - [[memory-types]]
             - [[retrieval]]
             - [[storage]]
: synonym  :: ''
: antonym  :: ''
: tldr     :: "AI agent memory refers to the mechanisms by which agents persist, organize, and retrieve knowledge across sessions."

- [[ai-agent-memory]]
  - [[context-management]]
    - [[context-window]]
    - [[context-compression]]
  - [[memory-types]]
    - [[working-memory]]
    - [[episodic-memory]]
    - [[semantic-memory]]
  - [[retrieval]]
    - [[vector-retrieval]]
    - [[graph-retrieval]]
    - [[text-retrieval]]
  - [[storage]]
    - [[vector-store]]

Almost instantly, you have a set of markdown files organized into a semantic tree where every concept knows its position relative to every other. From there, the agent can navigate, extend, refine, and validate the structure using the commands above.

Beyond Mechanics

The CLI handles knowledge operations. But operating a knowledge base over time raises deeper questions.

Discrete Knowledge Operations

Most agent memory systems ask the agent to read, parse, reason about, and rewrite knowledge files directly. That is expensive, error-prone, and opaque. tendr-cli takes a different approach: The agent reasons about what needs to change, and the CLI commands perform the surgery. Don’t generate what can be executed.

The token savings are real. Every graph operation tendr-cli handles is a graph operation that doesn’t have to enter the context window. Renaming a concept across fifty files costs the agent one command and zero tokens. Validating the entire tree structure costs one call to doctor. The agent’s context is reserved for reasoning, not file surgery. The interesting questions, “How do these concepts relate?” “What have I actually learned?” or “Where does this new information fit?”, are the ones worth spending tokens on.

When an agent reads its own knowledge base, edits it, and later reads that edited version as input for the next operation, it is engaged in recursive generation over its own output. Small errors compound: A missed reference, a hallucinated relationship, a structural simplification. This resembles the feedback loop that causes model collapse in training, except it happens at runtime, on persistent state, without any weight updates. Deterministic CLI operations break the loop. They introduce zero noise. The knowledge base after a deterministic operation is exactly what it should be.

Cultivation Compounds

A knowledge base that merely accumulates is a liability. A knowledge base that gets tended is an asset that appreciates.

Cleaning up a duplicate concept, clarifying a typed relationship, repositioning a note in the hierarchy: Each of these small acts of cultivation improves every future inference built on top of the structure. The agent navigating a well-tended tree finds the right concept faster, places new information more accurately, and draws better connections between existing nodes. The same is true for any human reading it.

This is the operational distinction between accumulation and cultivation. Accumulation adds. Cultivation refines. And because everything lives in plain text, the refined signal is portable: Across sessions, across models and traceable with version control. The work you do today doesn’t just help your current agent. It improves whatever comes next.

For a human, the act of tending a knowledge base is itself a form of learning. For an LLM, that experience doesn’t persist in the weights. But because the knowledge base is plain text, changes can be tracked, diffed, and reversed. The cultivation is preserved even if the cultivator forgets.

Co-Evolution

The field has confirmed that structure beats flat retrieval. WikiBonsai’s wager goes further: Cultivated knowledge compounds in a way accumulated knowledge never can.

The knowledge architecture problem is solvable. The tools already exist. They were built for human learners first, because the structure that helps a human understand a domain deeply turns out to be the same structure that lets any system do more than retrieve from it. By storing long-term knowledge in structured plain text, the confirmation loop stops being friction and becomes a genuinely collaborative mechanism: The human stays oriented, the agent stays grounded, and the knowledge base they share gets better every time either one tends it.

1. tendr-cli is currently optimized for project-scoped knowledge bases. Performance on large collections with dense connections is a known limitation. Pluggable database backends are on the roadmap. For best results today, use one knowledge base per project or domain rather than one monolithic vault.