02 - Research: Problem Discovery, Advisory Board, Steelman

Purpose: subject the Atlas concept (the expansion of factory app #3 from question triage into “the intelligence and communication layer” for the whole refactoring program) to critical scrutiny. This document does not assume the idea is good. It sorts every conclusion by evidence strength, runs the concept past five analytical lenses, and closes with an adversarial steelman in both directions plus one independent opinion that does not split the difference.

Evidence base: eight research sweeps (R1 substrate, R2 prior decisions, R3 HITL landscape, R4 AI docs, R5 comms products, R6 knowledge/QA, R7 OSS, R8 negative evidence). Raw dumps in ./evidence/. External claims carry a source and date; internal claims cite file paths from the substrate read. Labels used throughout: FACT (verifiable), INTERPRETATION (reasoned inference from evidence), ASSUMPTION (asserted, not yet evidenced).

Scope discipline: this is an internal product with two human users today. Sections that only fit an external commercial product (pricing funnels, purchase, renewal and churn economics, marketing) are marked N/A with a reason rather than fabricated.

PART 1 - Problem Discovery

1.1 The core customer problem

A 64-agent fleet rebuilding a 1.05M-LOC legacy estate generates a stream of ambiguities it cannot resolve on its own, and the program has exactly one person authorized to resolve most of them. Tomas Zaruba is decision-bound by his own account (“more agents won’t help me”). Every ambiguity that reaches him costs a slice of the program’s single scarcest resource: architect decision-hours. Two things then make it worse than a simple queue:

Duplication. N agents hitting the same ambiguity file N questions. Without merging, the human answers the same thing repeatedly.
Evaporation. An answer given in chat or on a one-off task settles that instance and then disappears. The next agent to hit the same wall re-asks, because the answer never became something an agent could find first.

So the problem is not “we need a place to put questions.” Tasks already exist. The problem is the human answer does not compound: it is neither de-duplicated on the way in nor persisted on the way out, so the same scarce hours get spent again and again.

FACT: the fleet ceiling is 64 concurrent; two humans total; Tomas is the scarce answerer (program ground truth).
FACT: EOL/dead-owner legacy code is a known question generator. VIS frozen ~2013, orders frozen ~2017 will produce “is this even alive / who owns this” questions at volume (R2; analysis/legacy/SYNTHESIS.md).
INTERPRETATION: the binding constraint is answer-reuse, not answer-capture. Capture is a solved substrate feature; reuse (dedup in, persist out) is not.

1.2 Who experiences it

Three distinct roles, only two of them human:

Who	Role in the problem	What they feel
Fleet agents (64 concurrent)	Askers and readers. They hit ambiguity, and they are the ones who would benefit from a prior answer being findable.	Nothing (no affect). But they are the volume source and the re-ask source.
Tomas Zaruba (architect)	The scarce answerer. Almost every real ambiguity routes to him.	The repeat-question cost lands here. His stated identity is decision-bound.
Robert (operator/router)	Today’s manual dedup-and-route layer. He relays questions in GChat and decides who answers.	He is the human bottleneck that a loop would automate.

FACT: “teams to keep updated” do not exist yet. The audience for any “communication layer” is Robert plus Tomas plus the fleet, and the fleet does not read prose digests (R2, program ground truth).
INTERPRETATION: the problem is real for exactly one scarce human (Tomas) and one router (Robert). The “audience of two” is a structural fact the concept must survive, not a detail.

1.3 Circumstances: when it arises

The ambiguity is generated at a predictable moment in the rebuild-from-audit doctrine: an agent is reconstructing behavior from legacy telemetry evidence (never porting code), and the evidence underdetermines the decision. Concretely:

The legacy code is dead or frozen and no living owner exists to confirm intent.
Two legacy behaviors conflict and only a human can pick the canonical one.
A domain term is used inconsistently across 26 repos and needs a single ruling.
A new-monorepo convention has not been decided yet and the agent needs it to proceed.
FACT: the substrate already routes blocked work through Temporal and can resume it on a signal (TaskWorkflowStamp, #completeTask → _workflowSignalSend, R1). The “resume on answer” half is built.
ASSUMPTION: that these four circumstances are the dominant question generators. Plausible from the doctrine, but the actual distribution of question causes is unmeasured.

1.4 Frequency

This is the single largest hole in the evidence base, and it is load-bearing. No measured fleet-scale question-volume data exists anywhere. Every number in every prior plan is MODELED or reasoned by analogy (R2, confirmed twice).

FACT: no industry data exists on cross-agent question volume, duplicate rate, or interrupt cost at fleet scale (R2; R3 found no paper on the fleet-dedup problem).
FACT: the closest measured analog is AI-PR review-pickup lag: AI-authored PRs picked up 4.6x slower, 32.7% vs 84.4% acceptance (R2). This measures human-attention drag on agent output, not question volume, so it is an analogy, not a measurement of this problem.
UNKNOWN: questions filed per day, duplicate rate, human interrupts per day before/after, answers-worth-persisting per week. All four are needed to size the product and all four are unmeasured. The initial recommendation already names these as the fastest concept test (01, section “Fastest concept test”).

Consequence: frequency is a validation target, not an input. Any claim that “the fleet asks hundreds of questions a day with a high duplicate rate” is currently an ASSUMPTION. If duplicate rate is low, the dedup half of Atlas has little to do; if answers-worth-persisting is under ~5/week, the docs/glossary half is a human habit, not a product.

1.5 Pain and cost

The cost is denominated in the one currency the program cannot print: Tomas’s decision-hours. Secondary costs:

Silent-wrong-assumption cost. An agent that cannot get an answer does not stop; it guesses. At 64x concurrency a wrong guess propagates into rebuilt code before anyone sees it. HumanLayer’s own “dark factory” experiment (fully automated agents, no human) corrupted a codebase within 3 months (R3, BigGo Finance 2026). That is direct negative evidence for what happens when the escalation path is missing.
Re-ask cost. Every evaporated answer is paid for again the next time an agent hits the same wall.
Router cost. Robert’s manual relay is a human in the hot path for every question.
FACT (negative evidence): auto-answering or auto-merging wrong is not a hypothetical harm. Air Canada was held liable for its bot’s hallucinated policy (2024 BCCRT 149). Cursor’s support bot fabricated a policy in April 2025, non-deterministically, and users canceled before it was corrected (R8). The cost of a wrong shared answer is real and, worse, silent.
INTERPRETATION: the pain is asymmetric. A missed question costs one agent’s progress; a wrong shared answer costs N agents’ progress and is invisible until the rebuilt code is wrong. This asymmetry is the whole argument for human-gated write-back over autonomous auto-resolve.

1.6 How it is solved today

Three mechanisms, all partial:

Robert relays in GChat. Manual dedup, manual routing, manual answer-relay. Works at two-human scale; does not scale to fleet volume and keeps a human in every hop.
Raw INFORMATION_REQUEST tasks. The substrate has TaskType.INFORMATION_REQUEST, a group-queue field (assigneeGroupSlug), a completion ACL, and Temporal signal-resume (R1). An agent’s question can already become a task that resumes the agent on answer. What is missing: dedup on the way in, and any write-back on the way out.
Conventions, skills, docs, grep. Root CLAUDE.md, .claude/rules/*, 10 skills, 23 bundled docs, and in-memory substring search (R1). This is how an agent “checks before asking” today. There is no project-wide glossary and no per-decision ADR files, only an append-only decision-log convention (R1; contents not read here).

FACT: the legacy Groupon notification service had a Chat-based triage gateway (“Sherlock”) that was deliberately not ported when the new monorepo was built (R1, services/notifications/README.md). A conceptually adjacent triage-over-chat tool already existed in the estate and was a deliberate deletion, not an oversight. Atlas’s “communication layer” ambition re-proposes part of what the architect chose to remove.
FACT: subagents on Claude Code cannot natively ask a human. AskUserQuestion is unavailable to subagents, and a background subagent auto-denies any tool call that would prompt for permission (R3, official docs). So even mechanism 2 requires a custom MCP “ask_human” tool to work from a worker agent. This is a build requirement regardless of how big Atlas gets.

1.7 Why today’s solution is insufficient

Manual relay (Robert) does not scale and is itself the bottleneck the loop exists to remove.
Raw tasks have no dedup, so N duplicate questions become N human answers.
Raw tasks have no write-back, so answers evaporate and get re-asked.
Conventions/docs/grep only help if the answer was written down, which today it is not, because nothing writes answers back.
Notifications service has no group broadcast, no digest, and no rate-limiting (R1), so it cannot be the comms half without new code.
INTERPRETATION: the gap is specifically the two ends of the loop (dedup in, persist out). The middle (queue, route, resume) is already substrate. This is why the honest product is thin: it adds a dedup brain and a write-back contract to machinery that already exists, not a new platform.

1.8 What is blocked

Concretely, three things are blocked today:

Answer compounding. Nothing turns an answer into a findable artifact, so the corpus that would prevent re-asking never grows on its own.
Attention protection at scale. With only manual dedup, the human interrupt rate tracks raw question volume rather than unique-question volume.
Program memory. Decisions made in chat are not queryable. R5’s cross-product finding is that this exact gap (“durable, queryable decisions-and-why layer”) is the one thing no surveyed comms product ever filled.

1.9 Is software even the right solution?

This is the fair adversarial question, and the answer is split by half:

The 2-human comms half: process, not software. The lightweight-process literature (Dunbar’s number, “10 engineers need cooperation not a platform”) says informal coordination is the right default well past this headcount (R8 bucket 6). For two people in one GChat thread, a “communication layer” is over-tooling. Verdict: process-only for the humans. Do not build a status product for an audience of two. This is reinforced by the product graveyard: Atlassian’s own Atlas (team-status) was retired 21 May 2025, and Friday.app died in 2022 with the founder admitting no moat and predicting the job would be absorbed by adjacent tools (R5). Even Atlassian-scale distribution could not sustain team-status as a standalone product.
The 64-agent coordination half: software, but narrowly. The “just talk, skip tooling” argument does not transfer to agents. Agents have no hallway, no ambient Slack context; they only know what is written down (R8 bucket 6, explicitly flagged as the biggest misapplication risk). So the agent-coordination half genuinely needs something written, and the dedup-then-resume-then-persist loop has no off-the-shelf answer (R3, R6, R7 all confirm the gap). Verdict: software is justified for the answer loop and only the answer loop.
INTERPRETATION: “is software the right solution” resolves to “yes for the loop, no for the comms layer.” That single split is the core finding of Part 1 and it directly attacks the bundling in the concept name.

1.10 Every conclusion sorted into five tiers

Tier 1 - Confirmed facts (verifiable, cited)

Atlassian Atlas (team-status product) was retired as a standalone SKU; new workspaces blocked 1 May 2024, fully retired 21 May 2025 (R5, Atlas Help Center, accessed 2026-07-18).
Friday.app shut down 3 June 2022; founder post-mortem states no defensible moat or business model and predicted absorption by adjacent tools (R5, friday.app/p/shutting-down; HN 30933379).
HumanLayer’s original contact-a-human tool is founder-confirmed deprecated; team pivoted to a collaborative IDE (R3, github.com/humanlayer, accessed 2026-07-18).
On Claude Code, subagents cannot use AskUserQuestion, and background subagents auto-deny permission-prompting tool calls (R3, code.claude.com/docs, accessed 2026-07-18).
No surveyed product closes the loop “N agents hit one ambiguity → merge to one question → one human answers → all resume → answer persists to shared memory” (R3, R6, R7).
DeepWiki has a documented confident-hallucination failure mode (invented a nonexistent VS Code extension; independent contributor reports); CodeWiki benchmark scored its baseline 64.06% (R4, 2025).
AGENTS.md reached 60,000+ repos and was placed under the Linux Foundation’s Agentic AI Foundation on 2025-12-09; the industry converged on git-committed markdown, not a vendor format (R4).
Treude and Baltes (arXiv 2606.09090, 2026-06-09): 23.0% of 356 repos had >=1 stale code reference in AGENTS.md-style files; manual validation found 64% genuine rot (R4).
Substrate facts (R1): TaskType has only APPROVAL/SIGNATURE/INFORMATION_REQUEST (no agent-question type); assigneeGroupSlug group-queue and #completeTask→Temporal signal-resume both exist; the task-events fan-out topic is explicitly not built (“add when a consumer exists”); no project-wide glossary exists; the notifications service has no group broadcast, digest, or rate-limiting; adding an MCP tool is a one-file-plus-registry change; the only search is in-memory substring over 23 bundled docs.
The legacy “Sherlock” Chat-triage gateway was deliberately not ported into the new monorepo (R1, services/notifications/README.md).
No measured fleet-scale question-volume, duplicate-rate, or interrupt-cost data exists (R2).
Backstage 3-year TCO ~ $1.52M; external-org adoption averages ~10% vs Spotify’s ~99%; TechDocs sits on MkDocs, unmaintained since Aug 2024 (R6, R7, R8).
DailyBot (YC-backed) shipped, in 2026, ingestion of AI coding-agent activity so standups auto-fill from agent sessions (R5, dailybot.com 2026).
MINJA memory injection achieved 95%+ success via query-only interaction (NeurIPS 2025, R8); Air Canada held liable for its bot’s hallucination (2024 BCCRT 149); Cursor support bot fabricated policy non-deterministically, April 2025 (R8).
Program constraints: v1 is zero-PR (INFORMATION_REQUEST + agent-questions queue + dedup layer); the ask surface to Tomas is capped at three items; no core-to-internal event bridge exists yet; comm standards are binding; “teams to update” do not exist (R2, program ground truth).
The name “Atlas” is free in the estate (only Atlassian substring collisions) (R1).

Tier 2 - Strongly supported interpretations (multiple converging sources)

The dedup-in / persist-out answer loop is the only defensible system in the concept; documentation, glossary, and progress digest are renderings of it, not independent products (R3+R6+R7 confirm the loop is the gap; R5 confirms the comms/status category has no standalone moat; R4 confirms docs-for-agents is git-markdown, not a product).
Standalone status/comms products have no moat and get absorbed into adjacent tools (Atlassian Atlas retired; Friday dead with founder’s own moat admission; DailyBot commoditized agent-status ingestion) (R5).
LLM-generated documentation of an EOL legacy estate is unsafe for ground-truth capture because the failure mode is confident hallucination, which is strictly worse than staleness (R4, DeepWiki evidence; R8 bucket 3).
Autonomous auto-merge and auto-answer are unsafe at this scale; write-back and merges should be human- or PR-gated in v1 (R8 bucket 4, converging vendor guidance + adjudicated harm; R6, even the closest-match products gate through human PR review).
Building the thin loop from scratch on the existing substrate is lower-risk and lower-TCO than adopting Backstage, an unrelated wiki, or a memory vendor whose roadmap is in flux (R7).
The “skip tooling, just coordinate informally” argument covers the two humans but not the 64 agents, which need written artifacts because they have no ambient-context channel (R8 bucket 6).
markdown-in-git by filename convention (AGENTS.md/CLAUDE.md, SKILL.md) plus PR-review discipline for rot is the industry-converged answer for docs-for-agents (R4, two standards bodies independently).

Tier 3 - Reasonable hypotheses (plausible, one-sided or indirect evidence)

EOL/dead-owner legacy code will generate “is this alive / who owns this” questions at high volume (R2; reasoned from the frozen-repo facts, not measured).
The concurrent-duplicate rate at 64-agent scale will be high enough for dedup to pay off (plausible from concurrency, unmeasured).
A generated daily digest to a single reader (Tomas) will actually be read and useful (one-reader case; the general “digest gets skimmed once and ignored” critique from R5 cuts against it).
Guru-style owner+expiry stamps plus Inkeep-style PR-gated write-back will keep the answer corpus trustworthy enough to be worth reading first (R6, best-available reference patterns, not proven in this setting).
Cheap agents executing the write-back diff under a PR gate will not turn review into the new bottleneck (asserted mitigation, unproven).

Tier 4 - Unsupported assumptions (asserted in the concept, no evidence yet)

That comms + docs + glossary + triage belong in one product called “the intelligence and communication layer.” (Evidence points the other way: one system, two renderings.)
That “keeping teams updated on progress” is a real job today. (No teams exist.)
That agents will reliably search-before-asking. (The behavior is not built or measured; it is the precondition for the whole reuse benefit.)
That “one human answer unblocks every agent who asked” reliably at scale. (Depends entirely on dedup precision, which is unmeasured.)
That documentation freshness is achievable “at machine speed.” (R8 bucket 3 shows shared agent-memory write-back degrading; 64 writers is a large poisoning surface.)

Tier 5 - Unknowns requiring validation (must be measured before scaling)

Actual question volume, duplicate rate, and human-interrupt count before/after (the four numbers from 01).
Achievable dedup precision and the false-merge rate at a chosen similarity threshold.
Answers-worth-persisting per week (this number sizes the docs/glossary expansion; under ~5/week collapses Atlas back to plan-001 triage).
Whether Tomas grants the internal-plane lane (assumption A1; fallback is the Robert-owned A-lite repo).
Whether human/PR-gated write-back review scales with volume or becomes the new bottleneck.
Whether the custom MCP ask_human tool plus dedup plus Temporal resume works end-to-end on a live fleet wave.

PART 2 - Advisory Board

Five analytical lenses. Each is a principle-based simulation, not a source of quotations. No personal quotes are fabricated. For each lens: strongest argument in favor, strongest criticism, features challenged, questions demanded, recommended changes, likely MVP principle, and evidence required before backing it.

2.1 Steve Jobs - the “what are you saying no to” lens

Strongest argument in favor. There is one true product here and it is invisible when it works: an agent hits a wall and, because a human once answered this, it never even asks. That is a real, focused idea. Jobs would like that the win condition is fewer interruptions, not more screens.

Strongest criticism. The name is the tell. “The intelligence and communication layer” is three products hiding under an abstraction, and Jobs’s entire method is to kill two of them so the third can be great. Calling it a “layer” is how you end up shipping a portal nobody asked for. The concept is currently a committee’s wish list, not a product.

Features he would challenge. The progress-comms/digest (audience of one, and every comparable product is dead, R5). The “documents legacy systems” ambition (that is the audit extractor’s job; duplicating it is scope theft). The word “intelligence” as if it were a feature.

Questions he would demand answered. What is the one sentence? If you can only ship one of the three, which one, and why are the other two still in the deck? Who is the single user whose day gets visibly better on day one?

Recommended changes. Rename it around the single gesture (ask once, answered once, kept forever). Cut comms and docs from the v1 pitch entirely; let them re-earn their way in as renderings only after the loop is live. Ban the word “layer.”

Likely MVP principle. Ship the one loop that makes the fleet visibly quieter for Tomas, and nothing else. If it does not reduce his interrupts in week one, no amount of glossary makes it a product.

Evidence required before backing. A single before/after interrupt count from one real fleet wave. One number, measured, not modeled.

2.2 Jony Ive - the reduction-and-coherence lens

Strongest argument in favor. The material honesty is right: the substrate (tasks, Temporal, git, GChat) already exists, and the product adds only the dedup brain and the write-back contract. Ive respects building from what is already true rather than fabricating a shell.

Strongest criticism. Three products wearing one name is incoherent by construction. Coherence comes from one gesture repeated, and the concept has three unrelated gestures (ask, document, broadcast). The “communication layer” is decoration on a machine that does not need it.

Features he would challenge. Any new human UI. The two humans already have a tasks UI and a chat thread; a portal is a screen added for its own sake. Ive would challenge whether Atlas should render any pixel that did not exist before.

Questions he would demand answered. What is the smallest number of new surfaces? (Answer from the substrate read: potentially zero new human surfaces, R1.) Does every element serve the one gesture, or is it there because “a layer should have it”?

Recommended changes. Zero new human UI in v1. The UX is the two structured forms (question, answer) that already flow through the tasks service. Everything else is generated markdown and a generated digest line, not a designed screen.

Likely MVP principle. The best interface here is no new interface. Success looks like absence: fewer tasks reaching the human, not a beautiful new dashboard.

Evidence required before backing. Proof that the loop works with zero new human-facing surfaces (forms + MCP tool + git + existing GChat only).

2.3 Marty Cagan - the product-risk lens, with named riskiest assumptions

Strongest argument in favor. The problem is a genuine value-and-viability question with a real, scarce customer (Tomas) stating the pain in his own words. That is a stronger starting point than most internal tools ever have.

Strongest criticism. The team is at risk of building a solution (a “layer”) before validating the four risks. Cagan’s four product risks, scored here:

Value risk (will they use it): HIGH and unmeasured. Depends entirely on whether the reuse actually reduces interrupts, which is the unmeasured Tier-5 number.
Usability risk: MEDIUM. The dangerous mode is doc-rot-at-machine-speed poisoning the corpus (R8 bucket 3+4).
Feasibility risk: MEDIUM-LOW for the loop, HIGH for dedup precision. Substrate exists; resume works; but content-based dedup with a safe false-merge rate is unsolved off the shelf (R3).
Viability risk (does it fit the business/constraints): the constraints are explicit and tight. Zero-PR v1, three-item ask cap, no core-to-internal bridge yet (R2). The “much bigger product” vision must argue against these, not ignore them.

The riskiest assumptions, named (Cagan’s specific ask):

RA-1 (value): That merging duplicate questions materially reduces Tomas’s interrupt count. If the real duplicate rate is low, the flagship benefit does not exist. This is the single riskiest assumption in the whole concept.
RA-2 (usability/trust): That machine-written-back answers stay correct enough that agents trust the corpus and read it before asking. If trust collapses once (one wrong doc, and per R8 trust collapses to zero, not gracefully), the whole reuse loop dies.
RA-3 (feasibility): That content dedup can hit a false-merge rate low enough to be safe, given that a wrong merge feeds N agents a wrong answer silently.
RA-4 (viability): That the human/PR-gated write-back review does not become the new bottleneck, recreating the exact problem Atlas exists to remove.
RA-5 (scope): That bundling comms+docs into the product does not drag it into the dead status-product / hallucinating-wiki categories the market has already killed.

Features he would challenge. Everything except the loop, until RA-1 is measured. Cagan would refuse to fund the docs/glossary/comms expansion before the triage core proves the duplicate rate is real.

Questions he would demand answered. What is the smallest test that could disprove RA-1 this week? What is the kill criterion? (Already set: questions-per-unit flat after 4 weeks = failure, R2.)

Recommended changes. Sequence the whole thing behind RA-1. Run the plan-001 triage core on one real fleet wave, measure the four numbers, and let the measured duplicate rate and answers-worth-persisting rate decide whether the expansion is a product or a habit.

Likely MVP principle. Test the riskiest assumption for the least money. Here that is: instrument the existing INFORMATION_REQUEST flow on one wave before writing a line of dedup code.

Evidence required before backing the expansion. RA-1 measured positive (duplicate rate high enough to matter) plus RA-3 (a workable dedup threshold) demonstrated on real questions.

2.4 Teresa Torres - continuous-discovery and the opportunity-solution tree

Strongest argument in favor. The desired outcome is crisp and measurable (protect scarce human decision-hours), and it maps cleanly to distinct opportunities, which is exactly the structure that keeps a team from jumping to a bloated solution.

Strongest criticism. The concept jumped straight to a solution (“a layer”) without mapping opportunities, so it bundled solutions to different opportunities into one product. An opportunity-solution tree pulls them back apart and shows they do not have to ship together.

Opportunity-solution tree.

graph TD
  O["OUTCOME: fewer architect decision-hours consumed<br/>per unit of refactoring progress, fleet stays unblocked"]

  O --> P1["Opportunity 1<br/>Agents re-ask questions<br/>already answered"]
  O --> P2["Opportunity 2<br/>Concurrent duplicate<br/>questions hit human N times"]
  O --> P3["Opportunity 3<br/>Answers evaporate in chat,<br/>never become findable"]
  O --> P4["Opportunity 4<br/>Questions about dead /<br/>unowned legacy code"]
  O --> P5["Opportunity 5<br/>Wrong-human routing<br/>wastes a hop"]

  P1 --> S1["Search-before-ask:<br/>MCP tool checks answer<br/>corpus first"]
  P2 --> S2["Content dedup:<br/>attach new asker to<br/>existing open question"]
  P3 --> S3["Write-back contract:<br/>answer not closed until<br/>it lands as a git diff"]
  P4 --> S4["Ownership map lookup:<br/>route 'is this alive' to a<br/>batched human ruling"]
  P5 --> S5["Group-queue routing:<br/>one queue, ACL by group<br/>(substrate exists)"]

  S1 --> T1["Test A: baseline miss-rate.<br/>Does search-first cut asks?<br/>(disproves RA-1/search)"]
  S2 --> T2["Test B: false-merge rate at<br/>threshold on real questions<br/>(disproves RA-3)"]
  S3 --> T3["Test C: answers-worth-persisting<br/>per week; corpus trust after<br/>4 weeks (disproves RA-2)"]
  S4 --> T4["Test D: how many questions are<br/>'dead code' class; do batched<br/>rulings clear them"]
  S5 --> T5["Test E: routing already works<br/>on substrate; measure hops saved"]

Torres’s point in one line: the tree shows the comms/status digest and the legacy-documentation ambition are not on this tree at all. They do not serve the outcome; they were bundled in by the concept name. The tree’s five solutions are all facets of the one answer loop.

Features she would challenge. The digest and the “documents legacy systems” scope, on the grounds that no opportunity on the tree needs them. She would also challenge shipping S1 (search-before-ask) as an assumption rather than testing whether agents actually search.

Questions she would demand answered. For each solution, what is the assumption test, and what result kills it? (Filled in as T1-T5 above.)

Recommended changes. Run the assumption tests in order of risk (T1 and T2 first), and let the tree, not the concept name, decide what ships.

Likely MVP principle. Smallest experiment per opportunity, sequenced by which assumption failing would hurt most. Do not build a solution whose assumption test has not run.

Evidence required before backing. T1, T2, T3 producing green results on one real fleet wave.

2.5 Clayton Christensen - jobs-to-be-done and disruption theory

The job-to-be-done. When my agent hits an ambiguity it cannot resolve from the repo, I want to get an authoritative decision and keep the fleet moving, without spending my one architect on a question he (or the corpus) has already answered.

Functional dimension: get a correct, authoritative decision for a blocked agent, once, and make it reusable so it is never bought again.
Emotional dimension: the operator wants to stop worrying that 64 agents are silently building on wrong guesses; the architect wants to feel his scarce time is spent on genuinely new decisions, not repeats.
Social dimension: the architect’s stated identity is decision-bound (“more agents won’t help me”); he does not want to be the visible blocker of a 64-agent fleet, and the operator wants to be able to show the program compounds knowledge rather than re-litigating it.

What is hired today to do this job (the real competition, per Christensen these are what Atlas must beat):

Robert relaying in GChat (hired for routing + dedup; fired when it does not scale).
Raw INFORMATION_REQUEST tasks (hired for capture + resume; fired for having no dedup and no memory).
Conventions, skills, docs, grep (hired for self-service; fired because nothing writes new answers into them).

Strongest argument in favor. The job is real, frequent (plausibly), and badly served. The current hires each do one third of the job and none does the compounding part. A tool that does the whole job once would be hired immediately by the operator.

Strongest criticism (the disruption read). Atlas-as-answer-loop is a sustaining innovation relative to Zaruba’s substrate: it makes the existing INFORMATION_REQUEST flow better along the dimension the existing customer already cares about. That is fine, sustaining innovations are valuable. But the “intelligence and communication layer” framing dresses a sustaining enhancement up as a new-market disruptive platform, and that is where it overreaches. There is no new customer, no new market, no non-consumption being served; there are two people who already coordinate. Christensen’s warning: do not build a platform to serve a job that a feature satisfies.

Features he would challenge. The platform framing itself. The comms layer (serves no under-served job; the “teams” non-consumers do not exist). The separate documentation system (the job is “get an answer,” not “browse a wiki”).

Questions he would demand answered. Is there a real non-consumer here, or just two existing users? (Answer: just two.) Is the “layer” solving a job, or is it solving an org-chart aspiration?

Recommended changes. Position and scope Atlas as a sustaining enhancement to the tasks service (dedup + write-back on top of INFORMATION_REQUEST), not as a new platform. Kill the platform vocabulary.

Likely MVP principle. Integrate against the job the substrate already does, and add only the missing third (compounding). Do not create a category.

Evidence required before backing. Evidence that the compounding third (write-back reuse) is what actually gets the fleet unblocked, versus the capture+resume the substrate already provides.

Advisory board convergence

All five lenses independently arrive at the same place from different premises: there is one product (the answer loop), the other two are renderings, and the “layer/platform” framing is the main risk. Jobs says cut to one gesture; Ive says one coherent gesture, zero new UI; Cagan says sequence behind the riskiest value assumption; Torres shows comms and docs are not even on the outcome tree; Christensen says it is a sustaining feature mis-framed as a platform. That is unusual unanimity and it is the strongest signal in Part 2.

PART 3 - Steelman

3.1 The strongest complete case FOR Atlas

Build Atlas, and build it as one product, because the loop and its renderings are genuinely one system and separating them is what causes rot.

The core is a real, unfilled gap. Three independent sweeps (R3 HITL, R6 knowledge/QA, R7 OSS) each concluded that nothing on the market closes the loop “N agents hit one ambiguity → merge → one human answers → all resume → answer persists.” This is not a crowded space where we would be the ninth me-too tool; it is empty. The closest primitives (LangGraph Agent Inbox, Redis agent-memory-server) are a thin queue and a preview-grade memory store, respectively, and both explicitly lack dedup and shared write-back. When the market has a hole this specific and the substrate to fill it already exists in-house, building is the rational move, and R7 says so outright.
The substrate makes it cheap. The expensive parts are already built and paid for: Temporal signal-resume, group queues, an MCP skeleton where a new tool is one file, a git-markdown docs convention, and an existing GChat channel. Atlas adds only the dedup brain and the write-back contract. This is the opposite of the Backstage trap (a $1.52M 3-year platform to serve a catalog job that may not exist here); it is a thin loop on rich substrate.
Bundling is correct precisely because the outputs are renderings, not separate systems. The reason internal wikis rot (R8 bucket 1) and status products die (R5) is that they are hand-maintained on their own schedule, decoupled from the work. Atlas inverts that: the glossary is generated from answers that flowed through the loop; the digest is generated from ledger rows and closed questions; the docs get a diff as a condition of closing a question. Nothing is separately maintained, so nothing can rot on its own. Splitting the loop from its renderings would recreate the decoupling that kills every comparable tool. The unity is the feature.
The agents genuinely need something written. The one negative-evidence bucket that could argue “skip it” (lightweight process beats tooling) explicitly does not transfer to 64 agents, which have no ambient channel (R8 bucket 6). The humans can coordinate in chat; the agents cannot. So the artifact half is not optional decoration, it is the only way agents share a decision.
The one gap nobody has filled is exactly the differentiator. R5’s cross-product finding: every comms/status product failed to preserve “the decisions and reasoning underneath,” so their digests were skimmed once and useless in three weeks. Atlas’s write-back is precisely a durable, queryable decisions-and-why layer. We would be building the one thing the graveyard proves is missing, on substrate that makes it cheap, for a customer stating the pain in his own words.

Conclusion of the FOR case: build the loop, keep the renderings attached, ship thin, and you have the one tool in this entire landscape that closes the loop, at a fraction of platform cost, serving a real and scarce customer.

3.2 The strongest complete case AGAINST Atlas

Do not build Atlas as a product. Ship the plan-001 triage core, keep everything else as process, because the expansion is a feature dressed as a product, for an audience of two, whose core mechanism is the exact thing the evidence shows failing.

Feature, not product (the Christensen and Friday.app case). Atlas-the-expansion is a sustaining enhancement to the tasks service, mis-framed as a platform. Friday.app reached 100,000 users and still died because the founder could never answer who the buyer was or whether it replaced anything (R5). Atlas has a harder version of that problem: it has two users, one of whom is the router the tool would automate. There is no market, no non-consumer, no second team. A feature that improves one existing flow does not need a name, a “layer,” or a product plan; it needs a pull request.
Audience of two, and the comms half serves an audience that does not exist. “Keeps teams updated” is Tier-4 unsupported: there are no teams. The one human reader of a digest is Tomas, and R5’s own finding is that single-reader digests get skimmed once and ignored. Every dedicated status product surveyed is dead (Atlassian Atlas, Friday) or survives only by hybridizing with auto-pulled data and staying tiny (Range, Standuply). Even Atlassian could not sustain team-status with global distribution. Building the comms third is building into a proven graveyard.
Doc-rot at machine speed is not a risk, it is the base rate (the R8 case). Atlas’s core mechanism is 64 agents writing persistent knowledge back for other agents to read. That is precisely the mechanism the negative evidence shows degrading: MINJA shows 95%+ memory-injection success; Chroma’s Context Rot shows 30-50% accuracy drops before context limits; ChatGPT memory stores wrong facts with full confidence; corrections vanish and go stale (R8 bucket 3). One wrong doc collapses trust in all docs, not gracefully (R8 bucket 1). And a wrong dedup merge feeds N agents a wrong answer silently, the Air Canada / Cursor failure mode (R8 bucket 4). Atlas’s flagship benefit (a trusted reusable corpus) and its worst failure mode (a poisoned corpus nobody can trust) are the same mechanism. At 64 writers the poisoning surface is large and the review that would catch it is unstaffed (two humans).
The review becomes the new bottleneck (RA-4). If write-back must be human- or PR-gated to be safe (and section 3.3 concludes it must), then every persisted answer needs review, and there are two humans to do it. The tool that exists to protect scarce human attention now demands scarce human attention for every artifact it produces. The bottleneck moves; it does not disappear.
It re-proposes a deliberate deletion. The legacy estate already had a Chat-based triage gateway (Sherlock) and the architect deliberately did not port it (R1). Reintroducing a “communication layer for triage” reverses a decision the scarce answerer already made, and the ask surface to him is capped at three items (R2). Spending scope and political capital to rebuild what he removed is the wrong bet.
Absorbed-by-platform risk. DailyBot already ingests Claude Code agent activity into status; Guru already does chat-answer-to-durable-card with owner and expiry; Inkeep already does gap-detection-to-PR write-back; Geekbot shipped an MCP server for agents to read/write standups (R5, R6). The renderings Atlas wants to own are being commoditized by funded incumbents. The only genuinely uncommoditized piece is the cross-agent dedup-and-resume, which is a feature of the triage core, not a reason for a three-part product.

Conclusion of the AGAINST case: ship plan-001 triage (dedup + resume on INFORMATION_REQUEST), let write-back be a manual habit until the answers-worth-persisting number justifies automating it, and never build the comms or documentation thirds. Atlas-the-expansion is a name looking for a product.

3.3 Independent advisory opinion (not an average of the two)

The FOR and AGAINST cases are not equally right, and splitting the difference would produce the worst outcome (a half-built platform). Here is the independent read.

The AGAINST case wins on scope and framing. The FOR case wins on the core mechanism. They are arguing about different objects, and the resolution is to accept both by refusing the bundle-as-named.

Precisely:

The answer loop should be built. The FOR case’s point 1 is decisive and triple-confirmed: the dedup → resume → persist loop is a genuine, empty gap, and the substrate makes it cheap. The AGAINST case never actually disputes this; its point 6 concedes the dedup-and-resume is “genuinely uncommoditized.” So build it. But build it as what it is: a sustaining enhancement to the tasks service (Christensen), thin, per the plan-001 zero-PR frame.
The write-back must exist but must be human/PR-gated, not autonomous. The AGAINST case’s point 3 is the most important finding in this entire document and it is correct: Atlas’s flagship benefit and worst failure mode are the same mechanism. The resolution is not to skip write-back (that is what makes answers evaporate) and not to automate it (that is what poisons the corpus). It is to gate it: an answer produces a proposed diff, executed by a cheap agent, merged only behind a human/PR review, carrying a provenance stamp, a scope, and an expiry (the Guru + Inkeep pattern from R6). This is slower, and it is the correct speed. RA-4 (review-as-new-bottleneck) is real but bounded: you only review the answers-worth-persisting (a Tier-5 number to measure), not every question. If that number is small, review is cheap; if it is large, the loop is paying for itself and the review is the highest-value work the two humans do.
The comms/status third should not be built as a product, but a generated digest line is nearly free and worth keeping. The AGAINST case is right that a status product is a graveyard and the audience is one reader. But the FOR case’s point 3 is also right that a digest generated from the loop’s own ledger is a rendering, not a maintained system, so it cannot rot on its own schedule. The resolution: no portal, no status page, no maintained wiki; a generated daily digest line to the existing GChat, produced from closed questions and ledger rows, costing almost nothing. If Tomas ignores it (the R5 single-reader risk), delete it at zero loss. Do not staff it, design it, or call it a “communication layer.”
The documentation/glossary third should be renderings in git, never a wiki, and never LLM-generated ground truth. R4 is unambiguous: the industry converged on markdown-in-git, and LLM-generated docs of a legacy estate hallucinate confidently. So the glossary is a GLOSSARY.md grown by the write-back loop (each ruling that defines a term appends an entry), reviewed in PR, surfaced to agents by grep and to humans by git. It is not a separate documentation system, and it does not duplicate the audit extractor’s legacy evidence (that boundary is already set in plan 001).
Everything is sequenced behind one measured number, per Cagan and Torres. None of the expansion is justified until the plan-001 triage core runs on one real fleet wave and produces the four numbers, above all the duplicate rate (RA-1) and answers-worth-persisting per week. If duplicate rate is low, the dedup brain has little to do and Atlas collapses to capture+resume. If answers-worth-persisting is under ~5/week, the glossary and digest are a human habit, not a product. The kill criterion is already set: questions-per-unit flat after 4 weeks means the loop is not compounding and Atlas has failed (R2).

Independent verdict: BUILD THE LOOP, GATE THE WRITE-BACK, GENERATE (do not build) THE RENDERINGS, SEQUENCE EVERYTHING BEHIND THE DUPLICATE-RATE MEASUREMENT, AND DROP THE “INTELLIGENCE AND COMMUNICATION LAYER” NAME. This is neither “build Atlas as pitched” nor “ship triage and stop.” It is: the loop is a product, the renderings are outputs of it, the comms platform is not a thing, and the whole expansion is conditional on one number nobody has measured yet.

3.4 The bundling question, judged explicitly

Should comms + docs + glossary + triage be one product? No, not as four co-equal parts. Yes, as one system with one engine and three generated outputs, only if the outputs are strictly renderings of the engine.

The distinction is not semantic, it is the difference between a tool that compounds and a tool that rots:

Framing	What it is	Fate
Four co-equal products under one “layer” name (the concept as written)	A triage inbox + a maintained wiki + a maintained glossary + a status platform	Rots and dies. The wiki rots (R8), the status product has no audience (R5), the glossary drifts, scope creep drags it toward the portal every sibling plan already rejected.
One engine (the answer loop) + three generated renderings (glossary entry, doc diff, digest line), each produced as a byproduct of closing a question, human/PR-gated	A sustaining enhancement to the tasks service that happens to emit markdown and a digest	Compounds. Nothing is separately maintained, so nothing rots on its own schedule; renderings that no one uses (the digest, if Tomas ignores it) are deleted at zero cost.

The evidence forces the second framing:

The loop is a single system with no off-the-shelf substitute (R3, R6, R7): keep it whole.
The renderings, as separate maintained systems, are each independently dead or dying (status products R5; LLM-wikis R4; ADR/wiki rot R6/R8): they must not be built as such.
The only way renderings survive is by being coupled to the engine so tightly they cannot drift (generate-from-ledger, gate-through-PR): that coupling is exactly what makes it “one product.”

So the bundle is defensible in exactly one shape and indefensible in the shape the name implies. The name “intelligence and communication layer” points at the indefensible shape and should be dropped, because a name that invites scope creep into three graveyards is itself a product risk (Jobs, Cagan RA-5). Call it the answer loop; let the renderings be quiet byproducts; measure the duplicate rate before spending another hour on the expansion.

Appendix: open questions carried forward to the rest of the plan

Duplicate rate and answers-worth-persisting on one real fleet wave (the number the entire expansion is conditioned on). → validation plan (14).
Safe dedup threshold and false-merge rate on real questions. → architecture (10) + validation (14).
Does human/PR-gated write-back review scale or bottleneck (RA-4)? → PRD (12) + pre-mortem (13).
Does the custom MCP ask_human tool + dedup + Temporal resume work end-to-end (subagents cannot ask natively, R3)? → architecture (10).
Will Tomas grant the internal-plane lane, and does the A-lite fallback change the design (A1)? → build-vs-buy (11).
Should the digest exist at all, or is one reader below the threshold for even a generated line? → north star (09) + made-to-stick (08).