01 — Initial Product & UX Recommendation: Atlas
2026-07-18. Written BEFORE the research pass, per process; the research must challenge it, and 00-SYNTHESIS.md records where it survived or fell. Inherits the plans/001-factory-apps-validation verdict for question triage (row 3: BUILD-ON-ZARUBA, v1 zero-PR — INFORMATION_REQUEST tasks + agent-questions group queue) as the frame under test, not as settled truth. The concept under test here is the expansion of that triage core into “the intelligence and communication layer” for the whole refactoring program.
Context: internal product. Humans today: two (Robert as operator/router; Tomas as the scarce answerer and only external reader). Machine users: a Claude Code fleet, 64 concurrent proven ceiling, target hundreds of queued units. “Teams” that need to be “kept updated” are a future audience — right now there is no team to update except the two people already in the GChat thread.
What the product fundamentally is
A loop, not a layer. The concept bundles three different products under one name: (a) a question triage inbox, (b) a living documentation/glossary system, (c) a progress-communication platform. Bundling them is the first thing to challenge, and my pre-research position is that only one of them is a system — the other two are outputs of it.
The system is the answer loop: an agent hits ambiguity → checks the corpus of past answers first → on miss, files a structured question → dedup merges it into an existing open question or creates a new one → routing puts it in exactly one human’s queue → one answer resumes every attached agent → a write-back step turns the answer into a permanent artifact (doc section, glossary entry, skill edit, decision record) → the next agent finds the artifact before asking. Documentation freshness, the glossary, and the progress digest are then renderings of what flows through the loop (plus work-ledger state), not separately maintained systems that can rot on their own schedule.
One sentence: “Every question the program answers gets answered exactly once — everything downstream (docs, glossary, status updates) is a rendering of that ledger of answers and decisions, generated, never hand-maintained.”
What Atlas must NOT be: a portal, a wiki, a website, a chat-with-your-docs bot, or a status page. The consumers who matter (agents) read markdown from git and call APIs; the human consumers who exist (two people) already have a tasks UI and a GChat thread. Every pixel of new UI is speculative until a third human materializes.
The ten judgments
| Question | Recommendation |
|---|---|
| Serve first | The agent fleet (askers/readers, via API + files) and Tomas’s attention (the protected resource). Robert second as router/admin. “Teams/org comms” explicitly deferred — audience of two today. |
| Most important problem | Duplicate and un-routed interrupts burn the program’s only scarce resource — human decision-hours (“víc agentů mi nepomůže” is the customer stating this verbatim) — and answers given in chat evaporate instead of compounding, so the fleet re-asks forever. |
| Simplest useful version | (1) Triage core per plan 001 v1 (zero PRs: INFORMATION_REQUEST + agent-questions queue + dedup layer). (2) Write-back contract: an ANSWERED question is not closed until its answer lands as a diff (docs/skills/GLOSSARY.md/decision record) — enforced by the loop, executed by a cheap agent. (3) A generated digest (daily, GChat) of decisions made, questions open, progress from ledger rows. Nothing else. |
| Primary journey | Ambiguity → search past answers/docs (hit = no interrupt, the product worked invisibly) → miss = structured question → dedup/attach → route → one human answers once in the existing tasks UI → signal-resume all askers → write-back diff → digest line. |
| Interaction model | API-first + files-first. Agents: MCP tool / internal-plane API. Humans: Zaruba’s existing tasks UI for answering, GChat for the digest, git for the artifacts. No new human UI in MVP. |
| UX/UI direction | The UX is the two forms. Question form forces: what I’m blocked on, what I already searched/found, smallest answer that unblocks me, blast radius. Answer form forces: decision, rationale, scope (“Orders only” vs program-wide), expiry/confidence. Structure at capture-time is what makes dedup, write-back, and rendering possible at all. |
| Remove from concept | The portal/wiki; “communication layer for teams” (no teams); real-time status pages; chat interface over knowledge; hand-maintained documentation of the legacy estate (the 001 audit-extractor owns legacy evidence; Atlas links, never duplicates); the word “intelligence” as a feature (it’s retrieval + provenance, nothing more). |
| Not in MVP | Embedding/RAG search (v1 = structured index + grep, agents’ native motion; add retrieval machinery only when measured miss-rate demands it); LLM-generated answers without a human decision anywhere in the chain (auto-resolve ONLY on high-confidence duplicate match, citing the canonical past answer, always logged); SLA tracking; analytics; multi-team routing trees; any UI. |
| Biggest usability risk | Write-back producing doc-rot at machine speed — auto-generated docs nobody trusts poison the very corpus that prevents re-asking; one wrong dedup match silently feeds N agents a wrong answer. Mitigations are load-bearing, not optional: provenance stamps (which question, who answered, when), scope + expiry on every answer, dup-match confidence threshold with “attach vs auto-resolve” split. |
| Platform | API + markdown-in-git inside the internal-plane factory lane, digest to GChat. Not web, not mobile, not desktop, not a standalone SaaS. |
Fastest concept test: run the triage core live on the next real fleet wave for one week and count four numbers: questions filed, duplicate rate, human interrupts per day (before/after), and answers-worth-persisting per week. The last number sizes the expansion: 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. If dup-rate and re-ask rate are high, the loop pays for itself immediately.
Design lenses applied (Ive · Norman · Rams)
- Ive (focus, reduction, coherence): the concept as written is three products wearing one name — the discipline is to find the one gesture that matters (ask once, answer once, keep forever) and remove everything that does not serve it. A portal is decoration; the loop is the product. Success is invisible: fewer interrupts, not more screens.
- Norman (mental models, error prevention, feedback): the asker’s mental model is “raise hand, get unblocked”; the answerer’s is “my answer settles this permanently.” The design must make both true: capture-time structure prevents the garbage-in that kills dedup; provenance and expiry give the reader the feedback to calibrate trust; a stale answer served as fresh is a mapping failure worse than no answer. |
- Rams (less but better, honesty, durability): as little product as possible — the substrate (tasks, Temporal, git, GChat) already exists; Atlas adds only the dedup brain, the write-back contract, and two generated renderings. Honesty: every rendered fact carries its passport (MEASURED from ledger / decision with owner+date); durability: markdown in git outlives any app we could build.
Open questions the research pass must answer
- Does the expansion earn its name? Evidence for/against bundling comms+docs+glossary with triage — especially post-mortems of dedicated status/comms products (verify: Atlassian’s own “Atlas” team-status product and its fate) and of internal-wiki initiatives that rotted.
- Dedup precision in practice: what do 2025–26 agent-fleet reports say about question dedup / memory write-back quality? Is high-confidence auto-resolve safe, or does v1 need human-confirmed merges only?
- Docs-for-agents landscape: do AI codebase-documentation tools (DeepWiki-class, Swimm-class) actually stay fresh, or is generated-doc rot documented? Does anything justify ADOPT for the legacy-estate documentation job instead of the 001 audit-extractor?
- Foundation check: is there an OSS foundation (Backstage TechDocs, Outline, log4brains, LightRAG, memory frameworks) that provides >50% of the loop, or is the loop thin enough that foundations are freight?
- Name collision: “Atlas” is heavily overloaded (MongoDB Atlas, Apache Atlas, Atlassian Atlas). Internal name is probably fine; check nothing in the Groupon estate already claims it.
- The write-back contract’s failure mode: who reviews machine-written doc diffs at fleet scale, and does that review itself become the new bottleneck (the problem Atlas exists to kill)?