Self-Adaptive Knowledge System: How to Grow a Senior Agent
As a project manager with over 10 years of experience, I’ve always been interested in artificial intelligence and machine learning. With the emergence of full-fledged AI agents, I began experimenting with my pet projects on weekends. One such project was a mobile app for memorizing cards/words, which I created to learn Japanese.
While working on this project, I discovered an interesting idea wikiLLM by Andrej Karpathy. The idea was to store knowledge in a structured wiki that the agent reads, updates with raw data, and uses in responses. The logic was simple and appealing: provide the agent with a well-organized knowledge base, and it will work more accurately.
However, when I started using this approach, I encountered some issues. My requirements for the agent didn’t fully fit this method. I needed not a librarian, but a developer who would solve my product tasks. I would write to it: “make a button…” or “there’s a bug…” – and it should solve it, relying on the context of our specific project.
Then I wondered: what if the agent creates its own raw context in moments of surprise?
Discovery
As a project manager, I’m used to noticing “extra” and “insufficient” things. And this case was no exception. I realized that the agent doesn’t become “better” if it’s not provided with raw data. But what if the agent creates its own raw context?
The answer to this question became the concept, which I called Self-Evolving Knowledge (SEK).
SEK Architecture
SEK organizes knowledge into four levels of context based on the principle of “load only what’s needed now”.
L0 – Bootstrap (always in context)
This is my main instruction – it’s also CLAUDE/AGENTS/GEMINI and others similar .md. But radically compressed.
The goal is to fit in a minimal number of tokens everything necessary for the start:
- Who I am and what language I respond in
- What knowledge categories I have
- What triggers to load
L1 – Routing & Index (as needed)
wiki/_routing.md – full routing table in YAML format. The agent reads it if the task is not covered by the core from main_instruction.md.
wiki/_index.md – table of contents: file path + one-line description. About 200-300 tokens. Backup level if routing didn’t give a result.
L2 – Validated knowledge (by trigger)
All project expertise: wiki/rules/, wiki/references/, wiki/architecture/, wiki/workflows/. Loaded only when the task explicitly relates to the topic.
L3 – Ephemeral state (where new knowledge is born)
Here, the most important thing is the “self-learning” mechanism.
memory/inbox.md – this is not an archive of lessons. This is a conveyor.
From Junior to Senior
Here’s how the growth of an agent on the same project might look:
| Stage | wiki/rules | memory/inbox | Behavior |
|---|---|---|---|
| Junior (start) | 5-10 core-rules | empty | Asks more often, climbs into web-docs, rarely refers to internal rules |
| Middle | 20-40 validated rules | 5-10 fresh observations | Confidently refers to rules, recognizes patterns, less often web-search |
| Senior | 60+ rules + cross-references | inbox almost empty | “This is a [TAG] case, see rule X”, offers architectural solutions |
What changes?
SEK – this is not rewriting from scratch.
Doesn’t change: folder structure (wiki/, memory/), category logic (rules, references, services), content of existing files, git history, all runtime.
Changes: what’s loaded into the agent’s context, in what order, and – most importantly – who creates new knowledge. Not just you. The agent too.
Summary
SEK is not a new model, not a finetune, and not an expensive tool. It’s a different look at who creates knowledge for the agent and how it accumulates.
The agent may not be smarter – it should know more about your specific project. This knowledge is born not from documentation, but from live experience: surprise → draft → rule. Just like any specialist grows.
What’s next?
I’ll continue to explore context organization. Even though Anthropic recently released its own “memory” for the agent =)