LLM-Wiki: Multi-Agent Memory Without RAG

changes. This creates a "human-in-the-loop" capability that is nearly impossible with vector stores or opaque JSON blobs.

Core Solution

The Wiki pattern relies on three architectural layers and a strict tool contract. The implementation replaces ad-hoc messaging with a protocol-based knowledge store.

Architecture Overview

1. Sources: Immutable raw inputs (documents, logs, user requests).
2. Knowledge Base: A directory of markdown files managed by agents. Each file contains YAML frontmatter for metadata and a structured body. Sections are categorized as either Snapshots (full rewrites) or Logs (append-only).
3. Schema: A configuration file defining section tags, access permissions, and update modes.

Implementation: The Knowledge Store Protocol

The engine interacts with the file system through a strict interface. This abstraction allows swapping the storage backend (e.g., to a database) without modifying agent logic.

interface KnowledgeStore {
  listEntries(): Promise<EntryMetadata[]>;
  fetchEntry(id: string): Promise<Entry>;
  commitEntry(id: string, content: string, version: number): Promise<CommitResult>;
  appendLog(id: string, line: string): Promise<void>;
  transferFocus(target: string, summary: string): Promise<Handoff>;
}

interface EntryMetadata {
  id: string;
  title: string;
  version: number;
  lastAuthor: string;
  wordCount: number;
}

interface Entry {
  id: string;
  content: string;
  version: number;
  metadata: Record<string, string>;
}

Agent Execution Loop

Each agent follows a deterministic five-step cycle. The agent's output is never prose; it is a state mutation.

1. Scan: Call listEntries() to retrieve metadata only. This provides a cheap catalog of available state without loading bodies.
2. Select: Identify 2–4 relevant entries based on the current task and previous handoff. Call fetchEntry() for each.
3. Reason: Process the task, handoff summary, and selected entries.
4. Persist: Mutate state using commitEntry() for snapshots or appendLog() for logs.
5. Handoff: Call transferFocus() to pass control to the next agent with a mandatory summary.

Load-Bearing Mechanisms

Three mechanisms ensure the pattern remains stable in production.

1. Role-Based Access Control Permissions are enforced at the tool wrapper level, not in the prompt. The LLM receives structured errors if it attempts unauthorized writes, allowing it to recover gracefully.

async function commitEntry(
  store: KnowledgeStore,
  role: AgentRole,
  id: string,
  content: string,
  version: number
): Promise<CommitResult> {
  if (!role.writableSections.includes(id)) {
    return {
      status: 'denied',
      error: `Role '${role.name}' cannot modify section '${id}'. Allowed: ${role.writableSections.join(', ')}`
    };
  }
  return store.commitEntry(id, content, version);
}

2. Optimistic Locking Every fetchEntry returns a version number. commitEntry requires the expected version. If the version mismatches, the write fails, and the agent receives the latest content to re-apply its intent. This prevents clobbering human edits or concurrent updates.

async function commitEntry(
  id: string,
  content: string,
  expectedVersion: number
): Promise<CommitResult> {
  const current = await readFromDisk(id);
  if (current.version !== expectedVersion) {
    return {
      status: 'conflict',
      latestContent: current.content,
      latestVersion: current.version,
      message: 'Version mismatch. Please re-apply your changes.'
    };
  }
  const newVersion = current.version + 1;
  await writeToDisk(id, content, newVersion);
  return { status: 'success', version: newVersion };
}

3. Forward-Only Handoff Enforcement Agents are restricted to a linear pipeline. The runtime enforces monotonic progression. Backward or self-handoffs are intercepted and forced forward. A maximum step cap prevents infinite loops.

const PIPELINE = ['planner', 'architect', 'engineer'];

function enforceHandoff(currentIndex: number, target: string): string {
  const targetIndex = PIPELINE.indexOf(target);
  if (targetIndex <= currentIndex) {
    const nextIndex = Math.min(currentIndex + 1, PIPELINE.length - 1);
    return PIPELINE[nextIndex];
  }
  return target;
}

Pitfall Guide

Implementing the Wiki pattern requires discipline. The following pitfalls are common in early deployments.

1. The "Read-All" Trap

• Explanation: Agents attempt to fetch every section in the knowledge base during each turn. This causes token costs to spike and degrades reasoning quality due to context overload.
• Fix: Implement a read cap in the tool wrapper (e.g., max 4 entries per turn). Sharpen the system prompt to emphasize selective retrieval. Use the listEntries metadata to help agents make informed selection decisions.

2. Silent Overwrites

• Explanation: Without version checks, an agent may overwrite a section modified by a human or another agent. This leads to data loss and corrupted state.
• Fix: Enforce optimistic locking on all commitEntry calls. Ensure the agent logic handles conflict responses by re-reading and merging.

3. Infinite Feedback Loops

• Explanation: Agents may pass control back and forth indefinitely, exhausting token budgets without progress. This often occurs when agents disagree or fail to complete their tasks.
• Fix: Enforce forward-only handoffs via the runtime. Implement a hard maxSteps limit based on the pipeline length. Log loop attempts for debugging.

4. Role Bleed

• Explanation: Agents write to sections outside their domain, causing schema drift and inconsistent state. For example, an engineer modifying the project vision.
• Fix: Define a capability matrix in the configuration. Enforce permissions in the tool wrapper. Provide clear error messages when violations occur.

5. Unbounded Growth

• Explanation: As the knowledge base expands beyond 50 sections, the catalog becomes too large to list efficiently, and navigation becomes difficult.
• Fix: Introduce hierarchy (subdirectories) and per-section summaries. For large-scale deployments, add a search tool layered on top of the file system.

6. Schema Rigidity

• Explanation: Fixed sections may not accommodate evolving project needs. Agents may struggle if they cannot create new sections.
• Fix: Start with a fixed schema to prevent chaos. If dynamic sections are required, implement a createSection tool with strict validation and approval workflows.

Production Bundle

Action Checklist

• Define the knowledge schema with YAML frontmatter, section tags, and access roles.
• Implement the KnowledgeStore protocol with optimistic locking and version tracking.
• Configure role-based permissions in the tool wrapper to prevent unauthorized writes.
• Enforce forward-only handoffs and set a maximum step cap in the runtime loop.
• Limit read operations per turn to control token costs and focus agent attention.
• Add error handling for version conflicts, ensuring agents can merge or retry.
• Monitor agent behavior for loop attempts and read-all patterns during testing.
• Plan for scale by introducing hierarchy or search tools if sections exceed 50.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Rapid Prototyping	JSON State	Fastest implementation; no infrastructure required.	Low initial, high scaling.
Large Corpus Search	RAG	Necessary for querying massive, unstructured datasets.	High embedding and storage costs.
Collaborative Design	Wiki Pattern	Best for structured, human-readable state with multi-agent handoffs.	Moderate write cost, low read cost.
Long-Running Analysis	Wiki Pattern	Maintains stable, auditable state over extended sessions.	Predictable token usage.
High-Concurrency Writes	Database + Locking	Wiki pattern struggles with parallel writes; DB handles concurrency better.	Higher infrastructure complexity.

Configuration Template

Use this YAML schema to define sections, permissions, and update modes.

schema:
  sections:
    - id: vision
      title: Project Vision
      mode: snapshot
      writable_by: [planner]
      description: High-level goals and success criteria.
    - id: architecture
      title: System Architecture
      mode: snapshot
      writable_by: [architect]
      description: Component design and data flow.
    - id: decisions
      title: Key Decisions
      mode: log
      writable_by: [planner, architect, engineer]
      description: Append-only log of architectural choices.
    - id: handoffs
      title: Agent Handoffs
      mode: log
      writable_by: [planner, architect, engineer]
      description: Summary of work passed between agents.
  pipeline:
    - planner
    - architect
    - engineer
  max_steps: 10

Quick Start Guide

1. Initialize the Repository: Create a directory structure with a schema.yaml file and empty markdown files for each section defined in the schema.
2. Implement the Store: Build the KnowledgeStore interface with file-system adapters. Add optimistic locking and permission checks.
3. Configure Agents: Set up agent roles with corresponding permissions. Define the pipeline order and handoff logic.
4. Run the Pipeline: Execute the agent loop. Monitor the knowledge base files to verify state mutations and handoff summaries.
5. Audit and Iterate: Review the markdown files for correctness. Adjust permissions, read caps, or schema as needed based on agent behavior.