nvk/llm-wiki: Autonomous Multi-Agent Research Engine

Unix-Philosophy Agent Orchestration

Built entirely in Shell, the architecture rejects monolithic Python frameworks in favor of composable CLI primitives. The system implements a fork-join concurrency model where research tasks decompose into parallel agent streams, coordinated through POSIX-compliant process management rather than async event loops.

Multi-Agent Pipeline

State Management

Unlike vector databases that store embeddings, llm-wiki persists compiled knowledge graphs as flat Markdown with YAML frontmatter, enabling Git-native versioning and diff-based updates. The architecture treats the filesystem as the database, with directory structures representing ontological hierarchies.

Thesis-Driven Investigation

Traditional RAG systems answer questions; llm-wiki prosecutes research agendas. Agents don't merely retrieve—they formulate investigative theses, pursue evidentiary threads, and construct arguments. This moves beyond "context windows" to "knowledge compilation," where the output is a structured wiki rather than a single response.

The breakthrough isn't parallel processing—it's autonomous epistemology. The system decides what constitutes sufficient evidence before compilation, effectively implementing an AI-driven peer-review layer.

Agentic Conflict Resolution

When parallel investigators return contradictory findings (e.g., Agent A finds X is true, Agent B finds X is false), the system doesn't average embeddings or take a vote. Instead, it triggers a secondary investigation specifically targeting the conflict, sourcing additional primary documents until reaching confidence thresholds. This mimics academic adversarial collaboration rather than consensus algorithms.

IDE-Native Design

The explicit targeting of Claude Code and Codex represents a architectural bet: future knowledge work happens inside IDEs, not browsers. By functioning as a shell-accessible service rather than a web app, llm-wiki integrates into the .devcontainer workflow, allowing coding agents to maintain persistent, queryable research wikis alongside codebases.

Research Throughput Metrics

Compute Trade-offs

The architecture makes an explicit latency-vs-currency trade-off: initial compilation requires 5-15 minutes of parallel LLM calls (high upfront cost), but subsequent queries run against static compiled wikis at near-zero marginal cost. This favors use cases where knowledge changes slowly but queries happen frequently—like technical documentation or legal research.

Limitations

• Cold Start Penalty: No "quick answers"—the system insists on full compilation before serving queries
• Unix Lock-in: Heavy reliance on bash, fifo, and process signaling makes Windows deployment challenging without WSL2
• Token Burst Costs: Parallel agent initialization causes API rate limit hits and cost spikes compared to sequential approaches

Integration Topology

The 26 forks (13.5% fork-to-star ratio, significantly above the 5% GitHub average) indicate active customization across three primary integration patterns:

1. Claude Code Plugin: Functions as a /research command within the IDE, allowing developers to generate project-specific wikis from undocumented codebases
2. CI/CD Documentation: GitHub Actions integration that auto-compiles wikis on repository pushes, maintaining living documentation
3. Obsidian Bridge: Community adapters syncing compiled outputs to personal knowledge management systems

Deployment Options

Commercial Landscape

Currently unlicensed (implicit MIT), positioning it as infrastructure rather than product. The absence of a SaaS wrapper suggests the maintainer views this as a primitive for higher-level agentic systems. Watch for emergence of "Wiki-as-a-Service" platforms built atop this core, particularly in the legal and academic verticals.