Cognition Wiki and Agent Onboarding

If you've ever watched an AI agent thrash around a repo for 20 minutes, you already know the problem. The model isn't "dumb" so much as underfed. It needs a map, and it needs one that survives across sessions.

Key Takeaways

• Auto-indexed repo docs give agents a durable memory layer instead of making them rediscover architecture every session.
• The best systems combine a static repo contract with evolving, source-linked wiki pages.
• Elastic memory and selective compression matter because raw transcripts get noisy fast [1].
• Agent onboarding improves when docs are organized around actions, dependencies, and decisions, not just file lists [1][2].
• Tools like Rephrase can help turn rough prompts into cleaner repo questions in seconds.

---

What is the Cognition Wiki?

A Cognition Wiki is a structured repository knowledge base that auto-indexes architecture docs, decisions, and workflow notes so an agent can reason about a codebase without re-reading everything from scratch. The key idea is simple: turn scattered repo knowledge into a persistent, queryable interface. That makes onboarding less about guesswork and more about retrieval [1][2].

Why do auto-indexed docs change agent onboarding?

Auto-indexed docs change onboarding because they give an agent a working memory of the repository, not just a one-off prompt. In AutoAgent, cognition is treated as an updatable state over tools, skills, peers, and task knowledge, while memory compresses history into useful context [1]. That maps perfectly to codebase onboarding: the agent can ask, recall, and refine instead of starting blank every time.

How does this improve over static docs?

Static docs are useful, but they freeze knowledge in place. Auto-indexed docs are better because they can be queried, reorganized, and expanded as the repo evolves. The research angle here is important: AutoAgent shows that structured cognition and elastic memory improve tool use and long-horizon reasoning by reducing token waste and preserving decision-critical evidence [1]. That's exactly what large repos need.

Approach	Strength	Weakness
README-only onboarding	Fast to write	Too shallow for complex repos
Manual wiki	Good depth	Easy to drift out of date
Auto-indexed Cognition Wiki	Searchable, layered, maintainable	Needs a clear structure and source hygiene

What should the wiki actually contain?

A good Cognition Wiki should contain architecture summaries, module relationships, decision records, and "how this repo really works" pages. The point is not to mirror the file tree. It's to compress the repo's mental model into something an agent can use during selection and action. That's the same logic behind wiki-building workflows that compile raw sources into source-linked pages, then keep them maintained [2].

How does this relate to memory systems in agent research?

This is where the architecture gets interesting. AutoAgent's Elastic Memory Orchestrator preserves raw records, compresses redundant trajectories, and builds episodic abstractions so the system can stay efficient over long tasks [1]. In a repo wiki, the analog is clear: keep raw source links, summarize into reusable pages, and promote repeated patterns into stable concepts. That's how onboarding stops being a scavenger hunt.

What does this look like in practice?

In practice, the agent should start with a small set of high-signal pages: project overview, architecture, key flows, and contribution rules. Then it should expand outward into component pages and source-linked notes. Community examples show the same pattern. Builders of repo memory systems repeatedly hit the same pain point: large codebases exceed context windows, so durable indexed memory beats re-explaining architecture over and over [3][4].

Before and after prompt example

Before:
Explain this repo to me and tell me how it works.

After:
Scan the architecture docs, identify the entry points, summarize the main data flow, and list any repo-specific conventions I should know before editing code.

The second prompt works better because it asks for retrieval targets, not vague summarization. If you want better first-pass prompts, a tool like Rephrase can rewrite messy intent into something the agent can act on fast.

Why source-linked structure matters more than volume

A big wiki is not automatically a good wiki. What matters is provenance. When each page links back to the source material, the agent can distinguish stable facts from speculation. That's also the core lesson from the DAIR-style wiki builder workflow: raw sources go in, compiled pages come out, and everything remains traceable [2]. Without that chain, the wiki becomes another pile of text.

What's the best onboarding workflow for agents?

The best workflow is: load the repo contract, index the architecture, compile a wiki, then ask questions against the compiled pages. I like this because it mirrors how humans actually ramp up. First I learn the rules. Then I build a map. Then I drill into the paths that matter. The agent should do the same, except faster and with better recall [1][2].

Closing thought

The real shift isn't "more docs." It's docs that think like memory. Once your repository knowledge is auto-indexed, an agent can onboard like a teammate instead of a tourist. That's a big deal, and it's where the next generation of repo tooling is headed. If you're experimenting with this workflow, Rephrase can help you shape better repo prompts before the agent ever sees them. For more practical writeups, check the Rephrase blog.

---

References

Documentation & Research

1. AutoAgent: Evolving Cognition and Elastic Memory Orchestration for Adaptive Agents - arXiv (link)
2. Wiki Builder: A Claude Code Plugin for Building LLM Knowledge Bases - DAIR.AI Academy (link)

Community Examples 3. Memento - a local-first MCP server that gives your AI durable repository memory - r/LocalLLaMA (link) 4. Wiki Builder: A Claude Code Plugin for Building LLM Knowledge Bases - Hacker News discussion (link)