06 - Open-Source Foundation Analysis

2026-07-18. Evidence: R7 (OSS candidates, GitHub API pulled live 2026-07-18) and R6 section 8-10 (TechDocs/ADR/glossary tooling), full dumps at evidence/r7-oss.md and evidence/r6-knowledge-qa.md. Question under test: is there an OSS foundation that provides most of “the loop” (dedup a duplicate question, route it to one human, resume every asker on one answer, write the answer back as a permanent artifact), or is the loop thin enough that adopting a foundation is pure freight.

Frame: what is actually missing

Per program ground truth, the substrate already in the monorepo provides four of the six things a “question loop” needs, built and running, zero new adoption required:

• Queueing - tasks service, assigneeGroupSlug group queues, GET /tasks?assigneeGroupSlug=...&status=pending already reads as a review queue (R1).
• Assignment - ACL on POST /tasks/:id/complete (assignee, group member, or ADMIN).
• Resume - TaskWorkflowStamp + Temporal _workflowSignalSend, idempotent on the stamp.
• Storage/retrieval - LightRAG, already deployed and operated via the lightrag-* skills, MIT-licensed, actively developed.

What is NOT built anywhere in the substrate or in any candidate surveyed below is: content-based dedup of concurrent questions, a write-back contract that turns an answer into a doc/glossary/skill diff, and the renderings (digest, glossary page) generated from that ledger. That is the actual delta. Every candidate below is scored against how much of that specific delta it closes, not against how good a wiki or memory product it is in general.

Classification legend

• Strong foundation - directly solves a real slice of the delta, low adoption risk, keep using or adopt outright.
• Useful component - solves an adjacent problem (a destination to render into, a UI pattern to copy) but is not itself the loop.
• Prototype only - right shape, too young or too thin a team to depend on in production.
• High-risk dependency - real capability but a live going-concern, licensing, or credibility flag makes it a bad bet as infrastructure.
• Not recommended - wrong shape for this problem regardless of quality.

Candidate table

Candidate	License	Commercial-use restriction	Age	Activity (last push / release)	Contributors	Docs quality	Deploy complexity	Extensibility	Maintenance / forking risk	Est. % of Atlas-the-loop	Classification
Backstage + TechDocs	Apache-2.0	None	~6.5 yr (2020-01-24)	2026-07-17 push, v1.53.0 2026-07-14	367	Extensive platform docs; TechDocs subsystem docs undercut by its own foundation risk	High: external S3/GCS, dedicated CI render pipeline, often a search cluster; orgs report dedicating 3-12 FTE (roadie.io)	Plugin architecture, but each plugin has its own DB/context (Port.io: no shared schema)	TechDocs sits on MkDocs (unmaintained since Aug 2024) and Material for MkDocs (maintenance-mode only since Nov 2025); Backstage’s own RFC #33990 (open 2026-07-18) proposes replacing the engine	~5%	Not recommended
Outline	BSL-1.1 (shows NOASSERTION on GitHub)	Bars reselling as a hosted multi-tenant doc service to third parties; internal self-host unrestricted; converts to Apache-2.0 Jan 2030	~10.2 yr (2016-05-22)	2026-07-18 push, v1.9.1 2026-07-13	240	Good, real-time collab, documented API	Moderate: self-hosted app + Postgres + OAuth config	Has a write API; zero LLM/question-loop features, human wiki only	Low, large active contributor base	~15-20% (destination for renderings only)	Useful component
Wiki.js	AGPL-3.0	Copyleft; network-use disclosure obligations apply if modified and hosted, worth a legal look before any cross-org exposure	~9.9 yr (2016-08-16)	v2 patch 2026-05-01; v3 rewrite “Developer Preview” since Oct 2022, still “No ETA”	218	Adequate, standard wiki docs	Moderate: Docker + Postgres/MySQL/SQLite	Plugin/module system, but flagship rewrite stalled	v2 patches continue but a 3.5+ year stall on the project’s own stated roadmap is a real stagnation flag	~10%	Useful component (stagnation flag)
Docusaurus	MIT	None	~9.1 yr (2017-06-20)	2026-07-17 push, v3.10.2 2026-07-10, weekly releases	457 (largest here)	Excellent, industry reference for docs-as-code	Low: static site, git + build step	MDX/React plugin ecosystem, but no runtime write API; agent write-back means commit-and-rebuild, wrong shape for a live loop	Very low, Meta-backed, healthiest project surveyed	~5-10% (eventual human-facing publish target only)	Useful component
log4brains	Apache-2.0	None	~5.8 yr (2020-09-15)	Last push/release Dec 2024, v1.1.0; 45 open issues	10	Adequate for its narrow ADR-only scope	Low: CLI + static generator	Narrow, ADR-format only	18+ months stale as of 2026-07-18, effectively a one-person project	~5%	Prototype only / high-risk dependency
LightRAG (already adopted)	MIT	None	~1.8 yr (2024-10-02)	2026-07-18 push, weekly releases (rc 2026-07-13)	267	Good, active README/paper (EMNLP 2025), operator already running it	Low for this program: already deployed via lightrag-* skills	Pluggable storage backends, hybrid graph+vector retrieval, actively adding features (OpenSearch backend, setup wizard, Mar 2026)	Low; zero HITL/escalation primitive is a scope gap, not a maturity risk	~40% (storage/retrieval/write-back half)	Strong foundation
mem0	Apache-2.0	None	~3.1 yr (2023-06-20)	2026-07-18 push, daily commits, VC-backed	376 (most of any candidate)	Extensive marketing and docs, but credibility undercut by a public benchmark dispute	Moderate: hosted or self-hosted, needs a vector store	add/search personalization-memory API, not a question-router	Public LOCOMO dispute (Zep 84% to Mem0-disputed 58.44% to Zep counter 75.14%); independent test shows accuracy collapsing 61% to 38% to 25% as evidence items scale 1 to 3 to 6 (atlan.com, 2026)	~20%	Useful component (treat performance claims skeptically)
Letta / MemGPT	Apache-2.0	None	~2.8 yr (2023-10-11)	Last push 2026-07-03, releases slowing (0.16.8, 2026-05-14)	~139	Was solid, architecture now in flux	Moderate: server + DB	Tiered memory-server architecture, the exact thing being dismantled (see risk column)	Severe: Letta’s own 2026 blog “Letta’s Next Phase” confirms sunsetting server-side memory in favor of client-side MemFS, consolidating the company around Letta Code, a coding-agent product; standalone LettaBot archived May 2026	~25% if usable, but going-concern risk is severe	High-risk dependency / not recommended right now
basic-memory	AGPL-3.0	Same copyleft caution as Wiki.js	~1.6 yr (2024-12-02)	2026-07-18 push, release 2026-06-13	~30	Adequate, MCP-native	Low: single-user/Obsidian-integrated MCP server	LLM writes markdown KB via MCP, conceptually close	Unproven at multi-agent/production scale, no routing feature	~15%	Prototype only
Zep / Graphiti	Apache-2.0 per repo (Zep’s site says MIT, verify before adopting)	None on the code itself, but see risk column	~2.0 yr (2024-08-08)	2026-07-17 push, release 2026-06-08	44 (concentrated, single-company-driven despite 28.9k stars)	Good, but now requires self-managing Neo4j/FalkorDB/Kuzu	High post-April-2025: Zep discontinued the self-hosted Community Edition, self-hosters now run raw Graphiti plus a graph DB themselves	Temporal knowledge graph, same problem space as LightRAG	Vendor already pulled the easy self-host path out from under adopters once; largely redundant with what is already running	~35% if it replaced LightRAG (mostly overlap, not additive)	High-risk dependency
agent-inbox	MIT	None	~1.7 yr (2024-11-04)	2026-07-15 push, but zero releases ever tagged	6	Thin, a Gmail-style UI shell	Low code, but tightly coupled to a full LangGraph/LangSmith deployment, hidden lock-in	Genuine N:1 fan-in queue UI (many pending interrupts, one inbox), no dedup, no write-back of its own	6 contributors, zero release discipline, real bus-factor risk	~20%	Prototype only
Redis agent-memory-server	NOASSERTION (verify; Redis Inc. relicensed core Redis away from OSS in 2024, do not assume standard terms transfer)	Unclear, verify explicitly before any pilot	~1.35 yr (2025-03-14, ~16 months)	2026-07-16 push, release 2026-04-10	21	Decent, REST/MCP/Python client documented	Moderate: Redis plus the server, pluggable backends	Session-to-long-term automatic promotion pipeline, the closest architectural match found to “loop plus write-back”	Redis’s own docs call it “currently available in preview,” 16 months old	~40%	Prototype only (worth a bounded pilot)

Additional candidates surfaced, lighter scrutiny

Found during the search but outside the original list; each gets one line, not a full evaluation, because none was cross-checked as deeply as the table above.

• Cognee (Apache-2.0, 28.2k stars, active daily) - markets a “remember / recall / improve / forget” memory API, closest philosophical match to write-back; worth a quick bake-off against LightRAG before ever considering it, not before then. Useful component, unverified.
• Supermemory (MIT, 28.5k stars, active daily) - positions specifically for coding-agent memory (Claude Code plugins), relevant given the operator’s own fleet, but unverified at 64-agent multi-tenant scale. Prototype only.
• Memary - described in its own positioning as for experimentation and prototyping, not production-scale deployment. Prototype only, self-declared.
• adr-tools (npryce, ~5.6k stars, 631 forks) - latest release 2018-07-25, no archive banner but no 2025-2026 activity either, de facto frozen. The Nygard ADR format itself needs no tooling; per root CLAUDE.md’s description, Tomas’s decision log already follows this pattern as a flat, append-only file (path known from CLAUDE.md, reasons-and-decisions/07-decision-log.md itself not read), no tool gap exists to fill. Not recommended (nothing to adopt, the practice is already running per CLAUDE.md).
• Contextive (dev-cycles, 363 stars, v1.17.8 2025-10-07, actively maintained) - IDE extension that surfaces a YAML glossary via hover/autocomplete in code, comments, and markdown. Real candidate for the glossary rendering specifically, small footprint, low risk. Useful component, worth a look when the glossary rendering is actually being built, not now.

Where candidates map onto the loop

flowchart LR
    A[Agent hits ambiguity] --> B{Search past answers}
    B -- hit --> Z[No interrupt, resume]
    B -- miss --> C[File structured question]
    C --> D["DEDUP<br/>(nothing surveyed does this for<br/>cross-agent content-match; build it)"]
    D --> E["ROUTE / QUEUE<br/>Zaruba tasks service, already built<br/>assigneeGroupSlug group queue"]
    E --> F["ONE HUMAN ANSWERS<br/>existing tasks UI, no new UI"]
    F --> G["RESUME ALL ASKERS<br/>Temporal signal-resume, already built"]
    G --> H["WRITE-BACK CONTRACT<br/>(nothing surveyed does this; build it)"]
    H --> I["STORAGE / RETRIEVAL<br/>LightRAG, already adopted, strong foundation"]
    I --> J["RENDERINGS<br/>digest, glossary page<br/>Docusaurus/Outline/Contextive optional later, human-facing only"]
    I --> B

    style D fill:#7a2e2e,color:#fff
    style H fill:#7a2e2e,color:#fff
    style E fill:#2e5c2e,color:#fff
    style G fill:#2e5c2e,color:#fff
    style I fill:#2e5c2e,color:#fff
    style J fill:#2e4a7a,color:#fff

Red = the actual delta, nothing surveyed closes it. Green = substrate or already-adopted, keep using as-is. Blue = optional later renderings, human-facing, not the system.

Direct answers

(1) Would building the thin loop from scratch be strategically irrational?

No. The evidence points the other way. The only two projects shaped like the missing half (dedup plus human-escalation plus write-back) are agent-inbox (6 contributors, zero releases ever tagged, hard-coupled to a full LangGraph/LangSmith runtime) and Redis agent-memory-server (vendor’s own docs call it “currently available in preview,” 16 months old). Adopting either means importing an entire adjacent runtime (LangGraph, or Redis’s memory-server stack) to get a sliver of relevant logic, then still writing the dedup-by-content and the write-back contract yourself, because neither project has it. The broader memory platforms that look more mature by star count (mem0, Letta, Zep/Graphiti) each carry a live disqualifying flag: mem0’s headline accuracy claims are disputed in public and independently shown to collapse as evidence scales; Letta’s own maintainers are dismantling the exact server-side memory architecture that would matter, mid-pivot to a different product; Zep already discontinued its self-hosted path once. None of the three is a safe place to anchor infrastructure that Tomas’s decisions must flow through. And critically, all of them would duplicate capability the substrate already has for free (queueing, assignment, resume) or that LightRAG already provides (storage, retrieval) - so even a mature version of any of them would be redundant, not additive, on the two things Atlas does not need to build. Building the delta (dedup plus write-back contract plus renderings) from scratch, on top of the tasks service and LightRAG, is the lower-cost, lower-risk path versus any surveyed alternative.

(2) Which components should be adopted as-is versus never adopted?

Adopt as-is, no further evaluation needed:

• Git plus markdown as the document format (the pattern every scrutinized doc-generation tool converges on independently, per R4; AGENTS.md and SKILL.md are both this pattern standardized industry-wide in 2025).
• Zaruba’s tasks service, group queues, and Temporal signal-resume (already built, already proven, adding an agent-questions queue is config not code per plan 001).
• LightRAG for storage and retrieval (already deployed, MIT, actively maintained, no reason to swap or add a second knowledge-graph engine alongside it).

Never adopt for this problem:

• Portal/developer-catalog frameworks (Backstage/TechDocs) - wrong shape, 3 to 12 FTE TCO reported for self-hosters, and its own docs-rendering subsystem is on a named risk clock (Nov 2026) independent of anything Atlas does.
• General-purpose wikis (Outline, Wiki.js) as anything more than an optional later human-facing rendering target; neither has a question-loop or dedup feature, and Wiki.js’s flagship rewrite has been stalled 3.5+ years.
• Standalone memory platforms as infrastructure dependencies (mem0, Letta, Zep/Graphiti) - each carries a going-concern, credibility, or vendor-precedent flag serious enough to disqualify it as something Tomas’s answers route through.
• agent-inbox as a runtime dependency - fine as a UX reference (the N:1 fan-in inbox pattern is worth copying), never as adopted code, given 6 contributors and zero release discipline.

One line: the substrate (queueing, assignment, resume) plus LightRAG (storage, retrieval) already covers the majority of what a “loop” needs; nothing surveyed closes the actual gap (dedup, write-back contract, renderings), so that gap is what gets built, and it is small enough that building it is the right call, not a shortcut being rationalized.

Open items this analysis does not resolve

• Whether Outline or Contextive is worth adopting later specifically for the glossary/digest renderings (not now, only once the loop itself is running and a rendering choice is actually blocking someone).
• Whether Redis agent-memory-server’s session-to-long-term promotion pattern is worth studying as a design reference for the write-back contract, even though the project itself should not be a dependency.
• License verification before any pilot touching Redis agent-memory-server (NOASSERTION, post-2024-relicensing context) or the Zep/Graphiti site-vs-repo license mismatch (MIT claimed on zep site, Apache-2.0 in the repo file) if either is ever considered beyond reading their source for ideas.