# ForgeDock vs. Other AI Context Tools Developers evaluating ForgeDock often ask: how is this different from DeepWiki, AGENTS.md, Cursor Memories, or Devin's Knowledge Base? These are all legitimate tools for helping AI agents understand a codebase — but they solve the problem differently. The core distinction: **ForgeDock writes structured context during pipeline execution. Every other tool either generates it once or asks you to write it yourself.** --- ## The Problem All These Tools Are Solving AI coding agents forget everything between sessions. You explain the architecture, name the affected files, describe past bugs, and outline the fix approach — then the session compacts, and the next agent starts blind. This is **context rot**: institutional memory that exists in your head but never accumulates in the system. Every tool below addresses context rot. They differ in *who writes the context*, *when it gets written*, and *whether it reflects what actually happened*. --- ## DeepWiki (Devin) **What it is**: An auto-generated, read-only wiki built from your codebase. Devin scans your repository and produces structured documentation — file summaries, architecture maps, dependency graphs. **The structural difference**: DeepWiki generates context once, from the static state of your code. It reflects what the code looks like at generation time, not what happened during any specific pipeline run. ForgeDock generates context *during* pipeline execution. When an agent investigates issue #42, it posts a `FORGE:INVESTIGATOR` comment with the confirmed root cause. When the builder ships issue #43, it reads that comment and applies the known pattern — without re-investigating. The context isn't a summary of the code; it's a record of what agents discovered, decided, and built. | | DeepWiki | ForgeDock | |---|---|---| | **Generated by** | Auto-scanner | Pipeline agents (during execution) | | **When written** | On demand / scheduled | During every issue run | | **What it captures** | Static code structure | Decisions, root causes, review findings | | **Updates automatically** | When re-run | After every merged PR | | **Survives session resets** | Yes (external wiki) | Yes (GitHub annotations) | | **Reflects execution history** | No | Yes | **When to use DeepWiki**: You want a human-readable wiki of your codebase architecture for onboarding or exploration. **When to use ForgeDock**: You want agents to accumulate execution history — confirmed bugs, past review findings, architectural decisions — so future agents don't repeat mistakes. --- ## AGENTS.md and CLAUDE.md **What they are**: Static configuration files (usually markdown) that you write and maintain in your repository. AGENTS.md (OpenAI Codex convention) and CLAUDE.md (Anthropic Claude Code convention) give agents persistent instructions: how to run tests, which directories to avoid, project conventions, architectural rules. ForgeDock itself uses CLAUDE.md for base project conventions. This is not a competing approach — it's complementary. **The structural difference**: AGENTS.md and CLAUDE.md are *author-maintained*: a human writes them and keeps them current. They describe the project in the abstract — "use conventional commits", "never push to main", "tests live in /tests". They capture rules, not outcomes. ForgeDock annotations are *pipeline-maintained*: agents write them automatically during execution. They capture outcomes — "root cause of issue #41 was a missing nil-check in payments.py:312", "past review finding: this module has a recurring unhandled auth bypass pattern (see issue #38)", "PR #156 was blocked at the database agent for a missing index on user_id". A CLAUDE.md file can tell an agent "check for SQL injection risks." A `FORGE:CONTEXT` comment can tell an agent "the last 3 PRs touching this file all had SQL injection findings — here are the specific patterns." | | AGENTS.md / CLAUDE.md | ForgeDock annotations | |---|---|---| | **Written by** | Developer (manually) | Pipeline agents (automatically) | | **Content** | Rules and conventions | Execution history and findings | | **Maintenance** | You keep it updated | Self-updating after every run | | **Specificity** | General project guidance | File-level, function-level, issue-specific | | **Reflects past bugs** | Only if you add them manually | Automatically from review findings | | **Re-explanation pain** | Reduces it for conventions | Eliminates it for execution history | **Recommendation**: Use both. CLAUDE.md for project conventions (what ForgeDock itself uses). ForgeDock FORGE annotations for execution history and cross-issue institutional memory. --- ## Cursor Memories **What it is**: Cursor IDE's in-editor memory system. Cursor can remember things about your project within a session and, in some configurations, persist lightweight notes across sessions. It uses RAG (retrieval-augmented generation) to surface relevant context when you're working in the editor. **The structural difference**: Cursor Memories are editor-scoped and session-adjacent. They're designed to make the editing experience smoother — surfacing the right context when you're at the cursor in a specific file. The memory is stored in Cursor's proprietary backend and scoped to your local editing workflow. ForgeDock context is GitHub-native and pipeline-scoped. It doesn't care what editor you use. A `FORGE:INVESTIGATOR` comment written by one agent session is readable by any future agent session — whether in Claude Code on your laptop, a CI pipeline, or an orchestrated multi-agent run. Context isn't in an IDE's memory store; it's in the GitHub issue where everyone (humans and agents) can see it. | | Cursor Memories | ForgeDock | |---|---|---| | **Storage location** | Cursor proprietary backend | GitHub issues and PRs | | **Scope** | Editor session | Cross-session, cross-agent | | **Readable by** | Cursor only | Any agent, any tool, any human | | **Triggered by** | Editor interaction | Pipeline execution | | **Survives tool switch** | No | Yes (GitHub is tool-agnostic) | | **Structured for agent consumption** | No (prose recall) | Yes (machine-readable FORGE annotations) | **Session boundary** is where the difference is sharpest. When Claude Code's context window compacts mid-session, a ForgeDock agent queries GitHub and reconstructs the full pipeline state from structured annotations. Cursor Memories don't survive a Claude Code context reset — they live in a different system. --- ## Devin Knowledge Base **What it is**: Devin (Cognition's autonomous AI developer) maintains a proprietary knowledge base per-repository. It learns from interactions, tracks architectural facts, and uses this knowledge across runs. The knowledge base is managed by Devin's cloud service. **The structural difference**: Devin Knowledge Base is opaque and proprietary. The agent writes to it; you can't easily inspect or edit what it contains. It's part of a paid cloud service. The context is vendor-locked to Devin. ForgeDock context is fully transparent and GitHub-native. Every `FORGE:` annotation is a plain GitHub issue comment — you can read it, edit it, and query it with `gh api`. The context lives in a system you already own (your GitHub repository). There's no proprietary backend, no vendor lock-in, and no black box. | | Devin Knowledge Base | ForgeDock | |---|---|---| | **Storage** | Proprietary cloud (Cognition) | GitHub (your repository) | | **Transparency** | Opaque | Fully readable — plain text comments | | **Editable by you** | Limited | Yes — edit any annotation via GitHub | | **Vendor lock-in** | Yes (Devin-only) | No (works with any agent that can read GitHub) | | **Cost** | Included in Devin subscription | Free (GitHub) | | **Queryable programmatically** | Via Devin API only | `gh api repos/{owner}/{repo}/issues/{number}/comments` | --- ## Summary: The Core Distinction | Tool | Who writes context | When | Where | Static or dynamic | |------|-------------------|------|-------|-------------------| | **DeepWiki** | Auto-scanner | On demand | External wiki | Static (snapshot) | | **AGENTS.md / CLAUDE.md** | Developer (you) | Manually | Repo file | Static (manual updates) | | **Cursor Memories** | IDE memory system | During editor use | Cursor backend | Session-adjacent | | **Devin Knowledge Base** | Devin agent | During Devin runs | Proprietary cloud | Dynamic but opaque | | **ForgeDock FORGE annotations** | Pipeline agents | During every issue run | GitHub (open) | Dynamic, structured, transparent | The pattern ForgeDock is uniquely suited for: **execution history that accumulates automatically, lives in GitHub, and is structured for agent consumption**. If you ship 100 issues through ForgeDock, you end up with 100 investigation reports, 100 architectural decisions, hundreds of review findings — all structured, all on GitHub, all readable by the next agent that works on any related file. The 101st agent doesn't re-investigate. It queries the knowledge graph and finds the answer. That's what "GitHub as a structured knowledge graph" means. Not a wiki. Not a config file. A living record of what actually happened. --- ## Related Documentation - [How the Knowledge Graph Works](site/how-it-works.md) — FORGE annotations, context relay, compaction resilience - [ForgeDock vs. Manual Workflows](site/vs-manual-workflows.md) — structured pipelines vs. ad-hoc prompting - [FORGE Annotation Protocol](site/forge-annotation-protocol.md) — open standard spec for AI context passing