11 — Build vs Buy: the Atlas Answer Loop
2026-07-18. Scope: this document scores sourcing options for the one thing established as a real system in 01-initial-recommendation.md, the answer loop (dedup -> route -> one answer -> fan-out resume -> write-back -> rendering). Docs/glossary/digest are renderings of that loop’s data, not separate build decisions; they are covered in 10-architecture.md. Competitive landscape detail lives in 05-competitive-analysis.md and 06-open-source-analysis.md; this document does not re-derive it, only scores against it.
The single most decisive fact from the research pass, stated once up front: no product or open-source project found, anywhere, does content-based dedup of a question across N concurrent agent instances, routes the merged item to one human, and resumes every attached agent from one answer (R3 HITL landscape, evidence/r3-hitl-landscape.md, fetched 2026-07-18). That single finding rules out “buy” before security even gets a vote, and it rules out “adopt an OSS project as the core” before maturity even gets a vote. Every option below is scored against that ground truth, not around it.
The 8 options, made concrete for this case
- Build from scratch — a new Atlas service with its own queue, its own UI, its own storage, independent of Zaruba’s tasks/Temporal substrate.
- Build thin on substrate + OSS — the loop only (dedup + write-back + renderings) as a small internal-plane module riding Zaruba’s
INFORMATION_REQUESTtasks,agent-questionsgroup queue, and Temporal signal-resume, with git as the write-back target. LightRAG (already the operator’s running KB engine, R7) added later only if grep/structured-index proves insufficient. - Buy/license — Glean, Guru, Stack Overflow for Teams (now Stack Internal), kapa.ai-class docs bots.
- Integrate several tools, no new code — wire the existing tasks queue, a GChat webhook, and written conventions together; no dedup logic, no write-back automation.
- Partner/white-label — N/A. There is no partner or reseller channel for a two-human internal tool; nothing to white-label through. One line, as instructed.
- Managed service — “managed” here means Robert personally does the dedup and routing by eye, by hand, indefinitely; no software beyond what already exists.
- Process changes only — conventions in
CLAUDE.md+ skills + a manually-maintainedGLOSSARY.md; no queue logic, no automation, no digest generator. - Do not solve — accept duplicate interrupts as a permanent cost of running the fleet.
Scored comparison
Scale 1 (worst) to 5 (best) per criterion. TTV = time to value. Vendor = freedom from vendor dependency (5 = none). Fit = strategic fit with the rebuild-from-audit / substrate-reuse doctrine.
| Option | TTV | Cost | Maint | Flex | Agent UX | Reliability | Security | Vendor | Reversibility | Fit | Total /50 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1. Build from scratch | 1 | 1 | 1 | 4 | 3 | 2 | 3 | 5 | 1 | 1 | 22 |
| 2. Build thin on substrate + OSS | 4 | 4 | 4 | 4 | 4 | 4 | 5 | 5 | 5 | 5 | 44 |
| 3. Buy/license | 4 | 2 | 3 | 2 | 2 | 3 | 1 | 1 | 2 | 1 | 21 |
| 4. Integrate, no new code | 5 | 5 | 4 | 3 | 2 | 3 | 5 | 5 | 5 | 3 | 40 |
| 5. Partner/white-label | — | — | — | — | — | — | — | — | — | — | N/A |
| 6. Managed (Robert as router) | 5 | 3 | 5 | 5 | 2 | 2 | 5 | 5 | 5 | 2 | 39 |
| 7. Process only, no software | 5 | 4 | 3 | 4 | 1 | 1 | 5 | 5 | 5 | 2 | 36 |
| 8. Do not solve | 5 | 1 | 5 | 5 | 1 | 1 | 5 | 5 | 5 | 1 | 34 |
Reading the table
Option 1 (build from scratch) loses on the two dimensions that matter most for this program: reversibility and fit. It recreates the custom-UI/kanban/control-room shape that both sibling plans (work-ledger, fleet monitor) already rejected as an anti-pattern, and it throws away Temporal’s proven signal-resume and the tasks service’s existing group-queue routing to reinvent both. Nothing in the research pass argues for this; it survives in the table only as the reference floor.
Option 2 (build thin) wins on 8 of 10 criteria and is the only option that scores a 5 on fit. This is not a new conclusion, it is what plan 001 already decided (BUILD-ON-ZARUBA, v1 zero-PR) plus the two pieces the initial recommendation adds: a write-back contract and a generated digest. All three research streams converge on the same shape independently. R3: “treat this as build-not-buy… the dedup-by-content and write-back-to-shared-memory halves have no off-the-shelf answer.” R7: “building the thin loop from scratch…is not strategically irrational; it is the lower-risk, lower-TCO path versus importing Backstage’s cost profile, an unrelated wiki, or a memory vendor whose roadmap is currently in flux.” R6: the closest commercial patterns worth copying (Guru’s one-click chat-to-card plus verifier-and-decay-timer, help.getguru.com 2026-07-18; Inkeep’s PR-gated auto-draft write-back, inkeep.com 2026) are patterns to imitate in the thin build, not vendors to adopt, because both still gate on human review, which the substrate already provides through the tasks service’s own answer step. Cost is genuinely small: one cheap classification call per incoming question against the open-item index (MODELED, no measured token cost exists pre-launch), plus an occasional write-back diff for a human to approve through the existing answer action, not a new review queue. LightRAG is deliberately deferred, not adopted day one, matching the initial recommendation’s “not in MVP: embedding/RAG search.”
Option 3 (buy) fails on the finding stated at the top of this document before security even applies. Every buy-class product surveyed is a retrieval layer or a 1:1 ticket-review tool, not a dedup-and-fan-out-resume loop (R6: “does any product close question -> human answer -> durable artifact -> next asker self-serves? No.”). Buying one would mean paying SaaS pricing for a two-human team and then still building the actual loop on top, which is strictly worse than option 2 on cost and worse on fit. Security is the second, independently disqualifying problem: Groupon’s legacy system internals, migration decisions, and glossary content are exactly the confidential material an external SaaS index would ingest, and that data leaving the boundary is likely disqualifying on its own, full stop, regardless of the vendor’s stated security posture. Vendor dependency compounds this: the research pass surfaced Letta sunsetting its server-side memory product mid-2026, Zep discontinuing its self-hosted Community Edition in 2025, and HumanLayer’s founder confirming the original tool is deprecated in favor of a different product entirely (R3, R7) — three examples in one research pass of exactly this class of vendor pulling the ground out from under adopters.
Option 4 (integrate, no new code) is the real runner-up. It is cheap, fast, and safe, but it is missing the one piece of software that makes the concept different from plan 001’s original triage scope: without dedup logic, N agents hitting the same ambiguity still produce N separate items for a human to notice and merge by eye. It scores well because it is honest about what it is: a fallback shape, not an expansion. The initial recommendation already names this exact collapse condition: “if fewer than ~5 answers/week deserve write-back, glossary + digest are a human habit, not a product, and Atlas collapses back to plan-001 triage.” Option 4 is what that collapse looks like in build-vs-buy terms.
Options 6 and 7 (managed-by-Robert, process-only) both score deceptively well on cost and reversibility because they are, honestly, doing nothing new and calling it a decision. Both fail on the dimension the whole concept exists to protect: agent UX and reliability at volume. R2’s own modeled volume (“hundreds of questions/day vs ~101 contributors”) and R8’s wiki-rot literature both point the same direction: a human manually triaging by memory, or a hand-maintained GLOSSARY.md, degrades exactly as volume rises, which is precisely when it is needed most. R8’s own caveat is the sharpest point here: the “lightweight process beats tooling” literature is about human teams who can have hallway conversations; it does not transfer to 64 agents with no ambient channel who cannot absorb a Slack thread and need something written down machine-legibly. Option 6 also just relocates the bottleneck from Tomas to Robert rather than removing it, which is the opposite of the stated goal.
Option 8 (do not solve) is the null hypothesis, included for honesty, not as a candidate. It scores 1 on fit for a specific, falsifiable reason: the plan already commits to a kill metric (“questions/unit flat after 4 weeks” = failure), and doing nothing guarantees that exact outcome as volume scales toward the fleet’s proven 64-concurrent ceiling (MEASURED).
Recommendation
Build option 2: a thin dedup + write-back + digest layer on top of Zaruba’s existing tasks/Temporal substrate, zero PRs to his code in v1, LightRAG deferred until measured miss-rate demands it. It is the only option that scores well on both cost and fit, it is what all three independent research streams converge on unprompted, and it is a direct continuation of the plan 001 verdict rather than a new commitment.
Runner-up, named specifically: option 4, integrate existing tools with no new code. This is not a hedge, it is the plan’s own pre-declared fallback. Ship option 2, but gate the write-back and dedup investment on the one-week measurement test already defined in 01-initial-recommendation.md (questions filed, duplicate rate, human interrupts per day, answers-worth-persisting per week). If that test comes back under roughly 5 write-back-worthy answers a week, stop building option 2’s dedup/write-back logic and let the system degrade gracefully to option 4’s shape: existing queue, existing digest webhook, written conventions, nothing more. That fallback path does not exist for options 1 or 3; if either of those were built first, unwinding them costs real sunk work. Building option 2 first is what keeps option 4 a one-day fallback instead of a rewrite.
Ruled out permanently, not just for v1: option 1 (recreates a rejected anti-pattern, throws away proven substrate) and option 3 (fails the “no product closes this loop” finding and then fails again on data boundary). Neither should resurface later as “well, maybe if we had more budget”; the reasons they lose are structural, not a matter of v1 scoping.
Carried forward to PRD / pre-mortem
- The write-back review step must route through the tasks service’s existing answer action, not a new review queue, or option 2 quietly grows the same reviewer bottleneck the Cursor support-bot incident and the auto-merge guidance both warn against (R8): auto-merge or auto-write-back without a human confirmation step is the specific failure mode to design out from day one.
- LightRAG’s adoption trigger (measured miss-rate on grep/structured-index) needs a number before v2, not left as “later.”
- The 5-answers-per-week fallback threshold from
01-initial-recommendation.mdis now also this document’s trigger for de-scoping option 2 down to option 4; it should be stated once in the PRD’s kill criteria, not duplicated with slightly different wording across docs.