Stakeholders & journey: Atlas
Scope: internal system, two human stakeholders (Robert, Tomas), a Claude Code fleet (64 concurrent proven ceiling), and a “future teams” audience that is confirmed not to exist yet. This document tests the expanded concept (triage + living docs/glossary + progress comms), not just the already-decided triage core (plan 001, BUILD-ON-ZARUBA, v1 zero-PR). Where the expansion’s ambition outruns what the substrate actually supports, that gap is named plainly, not smoothed over.
Confidence key used throughout: FACT (grounded in code/docs/cited source), INTERPRETATION (a supported reading of grounded facts), ASSUMPTION (stated as true by a prior doc but not independently verified here), HYPOTHESIS (plausible, not yet evidenced). Evidence citations: R1 = evidence/r1-substrate.md, R2 = evidence/r2-prior-decisions.md, R3/R5/R6/R8 = the correspondingly numbered evidence dumps in the same directory, read directly for this document. External sources carry their own URL and date.
1. Stakeholders
Eight stakeholders. Only two hold real decision authority (Robert over build/ship/kill, Tomas over the lane grant and his own code); the rest are consumers, gates, or dependencies.
Robert (operator, router, admin)
- Goals: keep the fleet moving without Tomas’s attention becoming the ceiling; ship the triage core cheaply (zero PRs, R2) and prove or kill the expansion with real numbers, not adjectives.
- Current behavior: is the router today, by hand. Whatever ambiguity exists gets relayed to Tomas directly (chat, DM thread); no group queue, no dedup, no corpus exists yet.
- Frustrations: every duplicate question he relays is pure overhead; verbal answers evaporate and get re-asked; the scope-creep risk is partly self-inflicted, he is both the one deciding what Atlas is and the one who has to build it thin.
- Fears / objections: the “much bigger product” framing in the concept sentence is exactly the failure pattern the initial recommendation warns against: three products under one name when only the answer loop is load-bearing.
- Decision criteria: does the triage core measurably cut duplicate/interrupt volume within 4 weeks (the falsifiable metric already set in
01-initial-recommendation.md); does expansion add queues, not subsystems. - Definition of success: fewer interrupts to Tomas over time, a corpus that answers question two before it is asked, zero PRs into Tomas’s core-plane code.
- Influence over adoption: total. He decides to build, ship, or kill Atlas.
Tomas Zaruba (scarce answerer, digest reader, economic decision-maker for the factory lane)
- Goals: not be slowed down (“víc agentů mi nepomůže” is his own stated constraint, program ground truth); answer once and have it stick; keep the greenfield monorepo’s core plane clean of factory-app process.
- Current behavior: answers whatever reaches him directly, ad hoc, no queue, no dedup, no write-back. Per root CLAUDE.md’s description, his decision log is the only durable record of decisions he makes today, a flat file, appended by hand (path known from CLAUDE.md;
reasons-and-decisions/07-decision-log.mditself is confidential and was not read). - Frustrations: any factory service that leaks process into his domain; a question that turns out to be a duplicate of one he already answered, meaning his time was spent twice; an answer he gave that does not stay answered.
- Fears / objections: Atlas becomes a second, competing knowledge system next to the decision-log discipline he already trusts (R2 overlap risk, item d); a wrong dedup match makes his one answer wrong for agents it was never meant to cover, and he finds out only when something breaks downstream; the zero-PR promise erodes quietly as “expansion” needs grow.
- Decision criteria: zero PRs to his code, kept; the lane stays inside the internal-plane CODEOWNERS partition (R2); answers he gives are read once and respected, never re-litigated or silently misapplied.
- Definition of success: fewer, better-formed questions reach him over time; nothing in the corpus contradicts a decision he actually made; most days he can ignore Atlas and it still works.
- Influence over adoption: veto power over the lane grant and anything touching his code; no direct authority over the internal-plane build once granted.
Asker agents
- Goals: get unblocked fast, with the smallest possible interruption to the one human who can answer.
- Current behavior: pre-Atlas, would stall or have the ambiguity relayed by Robert; no structured question format, no dedup, no group queue exists today (R1: “agent-questions” slug ASSUMED absent).
- Frustrations: waiting on a human who may not see the question for hours; no way to know whether the exact same question was already asked and answered by another agent instance.
- Fears / objections: not applicable in a human sense. The functional analog is a stalled workflow burning wall-clock time waiting on a signal that never arrives if routing or dedup fails silently.
- Decision criteria: none, no choice, whatever tool/API is wired into the workflow is what gets used.
- Definition of success: a signal-resume that actually arrives, carrying an answer that actually resolves the blocking ambiguity.
- Influence over adoption: none directly, but their aggregate behavior (do they actually check the corpus first, see reader agents below) determines whether the whole premise holds.
Reader agents (the “check corpus first” behavior)
May be the same running instance as an asker agent; listed separately because it is a distinct behavior the concept depends on.
- Goals: resolve ambiguity from the existing corpus before ever filing a question, so the interrupt never happens.
- Current behavior: today, in-memory substring search over 23 bundled docs only (
docsContentService.search(), R1 FACT); does not cover code, does not cover a Q&A corpus because none exists yet. - Frustrations: a corpus that is thin (cold-start) or stale (an expired answer still served as current) gives false confidence either way, a miss it should not have had, or a hit it should not trust.
- Fears / objections: none in a human sense. The functional risk is trusting a stale or wrongly-merged answer with the same confidence as a correct one, the exact pattern documented in comparable memory systems (ChatGPT memory “treating stored wrong facts with the same confidence it applies to factual knowledge, without flagging uncertainty,” techbuzz.ai, undated, R8).
- Decision criteria: none, behavior is whatever skill/prompt wiring instructs; whether “check first” is actually enforced rather than aspirational is an open question (see Repeated core usage, stage 9 below).
- Definition of success: a corpus hit that is both correct and current, resolving ambiguity with zero human interrupt.
- Influence over adoption: decisive. This persona’s behavior single-handedly determines whether Atlas’s core premise (invisible success, fewer interrupts) is real or theoretical.
Write-back agent (machine persona)
- Goals: turn a completed answer into a permanent, provenance-stamped artifact (doc section, glossary entry, skill edit, decision-log row) that a future reader agent’s corpus check will actually hit.
- Current behavior: does not exist yet. This is entirely new build (initial recommendation’s judgment #2); no code path in the substrate couples task completion to any documentation write today (R1).
- Frustrations: not applicable as a feeling; the functional risk is producing a diff that fails lint/CI, or one that is technically correct but poorly scoped, at machine speed and volume, the initial recommendation’s own named biggest usability risk.
- Fears / objections: none as stated preference; the open question (initial recommendation’s #6) is who reviews these diffs and whether that review becomes the new bottleneck Atlas exists to remove.
- Decision criteria: whatever quality gate is wired in (lint, a cheap reviewing agent, a human spot-check); none is specified anywhere yet.
- Definition of success: every answered question eventually lands as a diff a future reader agent’s corpus check surfaces; zero silent write-back failures (variant E below).
- Influence over adoption: none directly, but its failure rate determines whether “answered once” means “answered forever” or just “answered for today’s askers.”
Future Groupon eng teams (deferred audience)
- Goals: HYPOTHESIS only, not confirmed to exist (ground truth: “teams to keep updated do NOT exist yet”). If/when real, presumably want searchable docs, a trustworthy glossary, and status without asking Robert or Tomas directly.
- Current behavior: none. This stakeholder does not exist today.
- Frustrations / fears / objections: genuinely unknown, not fabricated here.
- Decision criteria: unknown.
- Definition of success: provisionally, the same test any future reader would apply: can they find a trustworthy answer without the two people who built the corpus.
- Influence over adoption: zero today; potentially large later. Building for this audience now is exactly the speculative-audience risk this analysis must flag, not indulge.
Security / compliance
- Goals: no PII/PCI from the legacy estate ever lands in a permanent, widely-read artifact (git-versioned doc, GChat digest) without proper handling.
- Current behavior: consulted, not embedded. No field-level content scanning exists anywhere in the tasks or notifications services today (R1).
- Frustrations: asked to sign off after the fact, if at all, rather than gating content before it is written back or distributed.
- Fears / objections: a question or answer that quotes real legacy data (a customer record, a token-shaped field) becomes MORE exposed under Atlas than it would have been in a transient chat message, because write-back makes it permanent and searchable (variant G below).
- Decision criteria: a pre-write-back and pre-digest content check exists and is enforced, not optional.
- Definition of success: zero incidents of sensitive data reaching a permanent artifact or a broadcast channel.
- Influence over adoption: gate-keeper on specific content classes, not a general veto over Atlas’s existence, the same posture as the analogous stakeholder in the work-ledger sibling doc (
002-work-ledger-product/03-journey.md).
Anthropic (platform dependency)
- Goals: INTERPRETATION, not sourced from any direct communication: presumably, safe and reliable agentic tool use on their platform.
- Current behavior: provides the Claude Code / API / MCP substrate Atlas’s agents run on, with no Atlas-specific hooks or visibility into Atlas.
- Frustrations: not applicable, no direct interaction.
- Fears / objections: not applicable as a stated preference, but the underlying risk mechanism is real and documented at the platform level: a wrong answer served with full confidence and no uncertainty flag is the memory-poisoning / context-rot failure pattern named as a top 2026 agentic-AI risk (OWASP ASI06, per WorkOS summary, R8; Chroma Research, “Context Rot: How Increasing Input Tokens Impacts LLM Performance,” 2025, https://www.trychroma.com/research/context-rot, found every tested frontier model, including Claude Opus 4, degrades non-uniformly as retrieved context grows, “sometimes by 30 to 50 percent well before the documented limit”). Atlas would feed exactly this kind of retrieved context back into the fleet.
- Decision criteria: none over Atlas’s adoption; only exogenous ones (API pricing, context-window limits, tool-calling reliability, rate limits) that could change unilaterally.
- Definition of success: not applicable to Atlas specifically; platform-level correct and safe usage.
- Influence over adoption: no direct decision authority, but high dependency risk. A platform change is exogenous and could silently invalidate assumptions the loop is built on.
2. Journey: the standard 19 stages, adapted
Baseline framework (a standard extended SaaS adoption journey: recognition through offboarding/churn), adapted for a 2-human, agent-fleet, no-purchase-funnel internal product. Per the brief: commercial stages (purchase, renewal, churn) collapse to one N/A line each; nine stages get full treatment; the remaining seven get compact treatment.
| # | Stage | Treatment |
|---|---|---|
| 1 | Problem recognition | Full |
| 2 | Awareness of the solution | Compact |
| 3 | Research / evaluation of alternatives | Compact |
| 4 | Trial / pilot | Compact |
| 5 | Purchase / procurement / billing | N/A |
| 6 | Setup / implementation | Full |
| 7 | Onboarding (first use) | Compact |
| 8 | First successful outcome (activation) | Full |
| 9 | Repeated core usage | Full |
| 10 | Collaboration (Tomas answering) | Full |
| 11 | Integration (adjacent tools) | Compact |
| 12 | Feedback loop | Compact |
| 13 | Administration (routing, expiry) | Full |
| 14 | Support / troubleshooting | Full |
| 15 | Expansion (more queues/teams) | Full |
| 16 | Advocacy / referral | Compact |
| 17 | Renewal | N/A |
| 18 | Offboarding (program end) | Full |
| 19 | Churn | N/A |
flowchart TD
S1[1. Problem recognition] --> S234[2-4. Awareness, research, trial]
S234 --> S5{5. Purchase/procurement}
S5 -.->|N/A internal, folded into lane grant| S6[6. Setup / implementation]
S6 --> S7[7. Onboarding, first use]
S7 --> S8[8. First successful outcome]
S8 --> S9[9. Repeated core usage]
S9 --> S10[10. Collaboration - Tomas answers]
S9 --> S11[11. Integration]
S10 --> S12[12. Feedback loop]
S9 --> S13[13. Administration]
S13 --> S14[14. Support / troubleshooting]
S9 --> S15[15. Expansion]
S15 --> S16[16. Advocacy]
S9 -.-> S17{17. Renewal}
S17 -.->|N/A, no contract| S18[18. Offboarding - program end]
S9 -.-> S19{19. Churn}
S19 -.->|N/A - see kill-metric, stage 9| S18
S14 -- wrong dedup / stale answer --> F1[Failure: trust breaks, reverts to manual]
F1 -.-> S9
2.1 Full-treatment stages
Stage 1: Problem recognition
| Attribute | Detail |
|---|---|
| Goal | Robert and Tomas recognize that duplicate and un-routed interrupts burn Tomas’s decision-hours, and that answers given in chat evaporate instead of compounding. |
| Action | Robert names the pattern from available evidence; Tomas’s own words state the constraint directly (“víc agentů mi nepomůže,” program ground truth). A concrete generator is identified: EOL/dead-owner code (VIS frozen since roughly 2013, orders frozen since roughly 2017, R2) will spawn “is this even alive, who owns this” questions at volume. |
| Questions | Is this a current pain or an anticipated one? The triage core has not been built yet either, so recognition here is anticipatory, an honesty check worth stating plainly. No measured fleet-scale question-volume data exists anywhere, “hundreds of questions/day vs roughly 101 contributors” is MODELED, not measured (R2). |
| Emotions | Tomas: mild dread (more surface area asking him things). Robert: urgency, this is the resource he must protect to keep the fleet productive. Agents: none, functionally the same trigger is an inability to proceed. |
| Friction | The failure mode is invisible until tokens and hours are already spent, recognized reactively unless named ahead of time. |
| Required capability | None yet, this stage is diagnosis, not build. |
| Failure state | Atlas gets built against a problem that never materializes at the modeled scale, since no industry data exists for the interrupt-volume claim (R2), the single largest evidentiary hole in the concept. |
| Differentiation opportunity | None at recognition, but naming the problem precisely (dedup plus routing plus write-back, not “an AI knowledge base”) already narrows scope in a way nothing surveyed does (R3: zero products found doing cross-agent-instance dedup). |
| Metric | None producible yet, qualitative only. |
| Owner | Robert. |
Stage 6: Setup / implementation
| Attribute | Detail |
|---|---|
| Goal | Stand up the triage core with zero PRs to Tomas’s code, inside whatever lane the internal plane grants. |
| Action | Create the “agent-questions” assigneeGroupSlug queue; file INFORMATION_REQUEST tasks; build a dedup layer entirely in the internal plane, since the tasks service has no payload schema validation and no fan-out consumer today, and R3 confirms zero surveyed products do cross-agent-instance dedup, this has to be built from scratch, not adopted. |
| Questions | Does an “agent-questions” group and its membership already exist in the user service, or must Robert create it (R1 marks this ASSUMED absent, not confirmed)? Is Robert a member of the queue or purely its admin? |
| Emotions | Agents: none. Robert: mild anxiety about scope creep, each of the three bundled products could balloon setup. Tomas: likely indifferent if genuinely zero-PR, his code does not change. |
| Friction | No task-events fan-out topic exists (“add when a consumer exists,” R1, Atlas is that consumer and it does not exist), so the dedup layer cannot subscribe to new-task events natively; it likely has to poll GET /tasks?assigneeGroupSlug=... (R1, the doc comment literally shows this pattern) rather than react to a push signal, a real latency and complexity cost the initial recommendation does not price in. |
| Required capability | Dedup/matching logic (no OSS or product precedent, R3), the polling or event-consumer wiring, provenance stamps on questions. |
| Failure state | Setup stalls on a small, boring, blocking gap (the group/membership does not exist and nobody owns creating it); or setup over-builds immediately toward the full three-product vision instead of the v1 zero-PR core, reopening the exact scope objection this research pass exists to test. |
| Differentiation opportunity | None, this stage is plumbing; the risk here is doing more than needed, not less. |
| Metric | Time from decision to first live INFORMATION_REQUEST task filed by a real agent; zero PRs merged into Tomas’s core-plane code (a compliance metric, not a vanity one). |
| Owner | Robert, plus a cheap agent for the build itself. |
Stage 8: First successful outcome (“first deduped question answered once”)
| Attribute | Detail |
|---|---|
| Goal | Prove the actual mechanism: two or more agents hit the same ambiguity, dedup merges them into one open question, Tomas answers once, both agents resume. |
| Action | Fleet runs against a real EOL-code ambiguity; dedup matches question B to already-open question A above a confidence threshold; Tomas completes the task once via the existing POST /tasks/:id/complete (R1 FACT); Temporal signal-resume wakes blocked workflows via the existing TaskWorkflowStamp mechanism (R1 FACT). |
| Questions | What confidence threshold counts as “the same question,” and who validates it actually was the same question afterward? Is signal-resume proven to reach a workflow blocked by a merged task it did not originally mint the stamp for, or does the merge require re-registering the second workflow’s own signal against the first task? This is a genuine integration gap: the codebase supports one-task-one-stamp idempotency (R1), it is not documented for many-workflows-one-task fan-out. |
| Emotions | Robert: high-stakes relief or panic, this is the concept’s entire premise proven or disproven in one event. Tomas: first real trust signal, sharply positive if the merge was correct, sharply negative if wrong (ties to stage 14 and variant F). Agents: neutral, mechanical resume. |
| Friction | The fan-out gap above (no task-events consumer built) means “attach a second asker to an already-open question” is not a proven, existing code path, it is new build the initial recommendation’s ten judgments imply but do not specify. This is the single largest unverified technical assumption in the whole concept. |
| Required capability | Signal-resume-fan-out proven for N greater than 1 waiting workflows on one task, unconfirmed and unbuilt today. |
| Failure state | Dedup fires but only the original asker actually resumes, silent partial failure that looks like success in the tasks UI but leaves a second agent stuck, discovered only when it times out or a human notices. |
| Differentiation opportunity | This is the one genuinely novel moment (R3: zero found products do cross-agent-instance dedup-to-one-answer); if it works, it is Atlas’s actual differentiation, not the docs/glossary/digest wrapper around it. |
| Metric | The falsifiable metrics already set in 01-initial-recommendation.md: questions filed, duplicate rate, interrupts/day before and after, answers-worth-persisting/week. First data point on all four. |
| Owner | Robert (build and watch), Tomas (answer). |
Stage 9: Repeated core usage
| Attribute | Detail |
|---|---|
| Goal | The loop runs unattended at fleet scale (tens up to roughly 64 concurrent agents) without Robert manually reconciling each question. |
| Action | Reader agents check corpus first, miss, file, dedup, route, Tomas answers on his own cadence in the existing tasks UI, write-back, digest line. |
| Questions | Does “check corpus first” actually happen, or do agents ask anyway because searching costs tokens/turns while asking is cheap for the agent even though it is expensive for Tomas, a misaligned-incentive risk not addressed anywhere in the research? Is there any enforcement (a skill, a system-prompt rule) making the check-first step real rather than aspirational? |
| Emotions | Tomas: calm if volume stays low and answers stick; rising frustration if the already-defined failure metric (“questions/unit flat after 4 weeks,” R2) starts trending that way, meaning dedup is not actually suppressing repeat asks. |
| Friction | The notifications service has zero rate-limiting or group-broadcast code today (R1 FACT), “rate-limiting noise” is a named promise in the concept-under-test sentence but is unbuilt infrastructure, not an existing capability being reused. |
| Required capability | Rate-limiting logic (new build); the check-corpus-first habit actually holding under agents’ own economic incentives (unverified assumption). |
| Failure state | Exactly the pre-defined failure line: flat questions/unit after 4 weeks means agents ask as much as ever, the loop exists but is not suppressing interrupts, costing build effort without buying back Tomas’s attention. |
| Differentiation opportunity | If check-first genuinely reduces repeat asks, this is the compounding-value moment the “much bigger product” pitch depends on; if not, Atlas is a nicer queue, nothing more. |
| Metric | Questions/unit trend over 4 weeks (the explicit go/no-go signal); percent of questions that hit an existing corpus answer before filing (the silent-success rate, the product’s best-case invisible outcome, and currently unmeasurable, see variant C). |
| Owner | Robert (metric-watching), fleet agents (the behavior itself). |
Stage 10: Collaboration (Tomas answering)
| Attribute | Detail |
|---|---|
| Goal | Tomas’s single answer is enough, both to unblock every attached agent and to be trusted as durable, scoped, and permanent by whoever reads it later. |
| Action | Tomas opens his existing tasks UI (no new UI, per the initial recommendation’s own mandate), fills the answer (decision, rationale, scope, expiry/confidence), completes the task once. |
| Questions | Is “the answer form forces scope and expiry” actually enforceable through the existing formPayload mechanism, or does it require the formSchema validation R1 confirms is explicitly NOT built yet? If schema validation does not exist, nothing stops a one-line answer with no scope or expiry, and the whole write-back/trust design degrades to “hope he’s thorough.” |
| Emotions | Tomas: the target feeling is “my answer settles this permanently” (Norman lens, initial recommendation); the actual feeling depends entirely on whether his unmodified existing UI surfaces the structured fields Atlas needs, which today it does not enforce. |
| Friction | This is the highest-leverage gap in the zero-PR premise: zero-PR protects Tomas’s code from Atlas, but it also means Atlas cannot add the one enforcement mechanism (schema validation) that would make his answers structured by construction instead of by discipline. |
| Required capability | Either a schema-validation PR (which the zero-PR mandate defers) or a convention-only form Tomas fills by habit, unenforced, the same “adoption is organizational discipline, not tooling quality” risk named as the primary wiki/KM failure driver (R8, citing a study on wiki-system adoption). |
| Failure state | Tomas answers tersely, without scope or expiry, under time pressure (most likely during an overload week, variant D); the write-back agent then has to guess the scope or block, either of which erodes the “one answer settles this” premise. |
| Differentiation opportunity | None technical, the opportunity is process discipline: shaping how the question is asked (a skill/prompt) so Tomas’s free-text answer naturally contains scope and expiry even without schema enforcement. |
| Metric | Percent of completed INFORMATION_REQUEST tasks whose answer contains an inferable scope statement (a proxy metric, since true enforcement is not built). |
| Owner | Tomas (answering), Robert (designing the ask so the answer comes out usable). |
Stage 13: Administration (routing rules, expiry)
| Attribute | Detail |
|---|---|
| Goal | Routing rules (which queue, which fallback if Tomas is unavailable) and answer expiry stay correct as the program evolves. |
| Action | Robert, as admin, adjusts assigneeGroupSlug routing, sets or adjusts expiry conventions on answers, retires stale queues as domains finish. |
| Questions | Is a second human ever available as a routing fallback, or does every path terminate at Tomas by design (a single point of failure, confirmed ground truth: two humans total)? What happens to an expired answer, does it get flagged for re-confirmation, or silently keep serving as if fresh? |
| Emotions | Robert: administrative fatigue risk if routing rules need frequent hand-editing. Tomas: none, if genuinely zero-attention required of him for admin. |
| Friction | The tasks service has no SLA, escalation, or expiry machinery built today (R1 FACT, “explicitly NOT built yet”), “expiry” as the answer-form design requires is entirely new build, not a first-class field Zaruba’s schema already supports. |
| Required capability | An expiry-tracking layer external to the tasks service, and a way to demote or flag an expired answer before it is served again by the corpus-check step. |
| Failure state | An expired answer keeps serving as current (the exact failure state named for stage 14) because nothing enforces expiry; routing rules rot as domains retire and nobody prunes dead queues. |
| Differentiation opportunity | Expiry-aware serving (never surface an answer past its stated confidence window without flagging it) is a real, buildable differentiator against the static-FAQ failure pattern documented in every comparable product surveyed (R6, R8). |
| Metric | Count of answers past expiry still served unflagged (target zero); queue-routing changes per month (a proxy for administrative overhead). |
| Owner | Robert. |
Stage 14: Support / troubleshooting (wrong dedup, stale answer)
| Attribute | Detail |
|---|---|
| Goal | When the loop gets something wrong, it fails visibly and correctably, not silently. |
| Action | Robert, an agent, or Tomas notices a wrong dedup match or a stale-but-still-served answer and corrects it. |
| Questions | How is a wrong match even discovered, is there any log or audit trail of which questions got merged into which, or does a wrong merge simply look like a normal answer with no visible seam? Cross-vendor guidance (Jira/Zendesk/HubSpot merge tooling, R8) converges independently: “merges are effectively irreversible in most systems.” Who has authority to un-merge or supersede a bad answer once N agents have already acted on it? |
| Emotions | Tomas: this is the trust-breaking moment the initial recommendation names as its biggest usability risk. Once burned, the documented reaction pattern (R8, citing Backstage adoption-failure reports: failures are “adoption failures, not technical failures”) is to stop trusting the corpus and revert to answering everything from scratch, the exact regression Atlas exists to prevent. |
| Friction | Best practice across every vendor surveyed is surface-for-confirmation, never auto-merge, even at conservative similarity thresholds around 0.90 (R8), directly cautioning against any temptation to ship auto-resolve-on-high-confidence in v1 without an undo/supersede path. |
| Required capability | Append-only, supersede-never-edit correction (reusing the existing decision-log convention already trusted in the codebase, R1/R2, rather than inventing a new one), and a way to notify every agent who already consumed the bad answer, not just future askers, a genuinely hard, unaddressed requirement: the existing signal-resume mechanism wakes blocked agents once, it has no mechanism to reach agents who already resumed and moved on with wrong information. |
| Failure state | N agents already acted on a wrong dedup match by the time it is caught (variant F below); worse, nobody catches it at all because there is no review step over machine-merged questions, echoing the initial recommendation’s own open question: who reviews write-back diffs, and does that review become the new bottleneck. |
| Differentiation opportunity | A visible, cheap “supersede” action that fans back out to everyone who touched the wrong answer would be genuinely unsolved elsewhere (R3: zero products found with any fleet-wide correction/retraction mechanism), but it is unbuilt and nontrivial, not a checkbox. |
| Metric | Time from wrong-match discovery to correction fanned out; number of agents that acted on a since-superseded answer (a blast-radius metric, the same one the initial recommendation’s answer-form field asks askers to estimate). |
| Owner | Robert (triage), Tomas (final call on correctness). |
Stage 15: Expansion (more queues, more teams)
| Attribute | Detail |
|---|---|
| Goal | The pattern (one queue, one answerer, dedup, write-back) extends to more domains or queues as the fleet grows, and eventually to more human answerers if a second one materializes. |
| Action | Robert adds a queue per domain or team as needed; if a second answerer joins, routing splits correctly instead of defaulting everything to Tomas. |
| Questions | Does “more teams” mean more human answerer capacity, currently exactly one, a hard ceiling expansion cannot route around, only distribute within, or more agent askers hitting the same queue, which is a volume increase, not an expansion of who answers? Fleet monitor already owns “keeps teams updated on progress” and work-ledger already owns disposition/evidence records (R2), does Atlas’s “expansion” mean re-annexing sibling scope, or strictly adding queues/domains within the triage-plus-write-back frame? |
| Emotions | Robert: the tempting direction (more UI, more dashboards) is precisely the anti-pattern both sibling plans already explicitly rejected (“custom UI/kanban/control-room explicitly removed from concept in both work-ledger and fleet-monitor docs,” R2). |
| Friction | “Teams to keep updated don’t exist yet” is confirmed ground truth across every plan in the program (R2), expansion of the comms/glossary ambition has no real audience today, the single biggest scope-creep risk in the concept sentence. |
| Required capability | None beyond what setup and administration already need, expansion should be “add a row,” not “add a subsystem,” if the loop is genuinely thin. |
| Failure state | Expansion becomes an excuse to build the standalone glossary/docs portal/status page the initial recommendation explicitly says Atlas must NOT be, duplicating an ADR/knowledge system that already exists (MADR-style decision log, R2) instead of rendering from it. |
| Differentiation opportunity | None new, the only honest differentiation left is restraint: prove the loop scales by adding queues, not by adding surface area. |
| Metric | Queues added versus new subsystems built (target: near-all-queues, near-zero-subsystems); overlap incidents with work-ledger/fleet-monitor scope (target zero). |
| Owner | Robert. |
Stage 18: Offboarding (program end: the corpus IS the deliverable)
| Attribute | Detail |
|---|---|
| Goal | When the refactor program ends, or a domain retires, the accumulated corpus of answered questions, glossary entries, and decision records outlives Atlas-the-service and remains usable by whoever inherits the monorepo. |
| Action | The loop stops running live for a retired domain; its questions, answers, and write-back diffs stay in git (markdown-in-git is explicitly durability-by-design, initial recommendation’s Rams lens) and in the existing decision log, not deleted. |
| Questions | Is there any procedure anywhere in this plan or its siblings for what “done” looks like, or is this as undefined for Atlas as work-ledger’s own sibling doc found for its own equivalent stage (“largely undefined, flagged, not designed here,” 002-work-ledger-product/03-journey.md)? Who owns the corpus once Robert’s fleet and Tomas’s direct involvement end, does it fold into the existing docs-sync pipeline (pnpm docs:sync, R1), or become an orphaned second archive? |
| Emotions | Whoever inherits it: trust or distrust depending entirely on whether every entry still carries its provenance and expiry passport (Rams “honesty” lens) rather than reading as an unlabeled pile of old chat answers. |
| Friction | Because markdown-in-git was the explicit no-new-infrastructure choice, offboarding has no dedicated export/migration step to design, a feature (nothing to build), but it also means nobody has validated that a future reader (the deferred Groupon eng team stakeholder) can actually navigate it without the two people who built it. |
| Required capability | None beyond what setup already built, if the write-back contract genuinely produced git-native, provenance-stamped artifacts throughout. This stage’s success is entirely inherited from whether earlier stages did their job honestly. |
| Failure state | The corpus exists but is undiscoverable or untrusted by its eventual real audience, because provenance stamps were skipped under time pressure somewhere in the middle stages, or because it never merged with the existing decision-log/docs-sync pipeline and became a second, competing knowledge store (the same risk named in R2). |
| Differentiation opportunity | “The corpus is the deliverable, not the app” is Atlas’s most honest possible pitch, if true, it is also the cheapest possible offboarding (delete the service, keep the git history) and the strongest argument for keeping Atlas thin throughout. |
| Metric | Percent of corpus entries with intact provenance, scope, and expiry at program end; whether the corpus is reachable via the existing docs-sync/search path rather than a bespoke export. |
| Owner | Robert at handover; ultimately unowned per current ground truth, no “future Groupon eng teams” contact exists yet to formally own it, the same gap the sibling doc flagged for work-ledger. |
2.2 Compact stages
| Stage | Goal | Action | Friction | Failure state | Metric | Owner |
|---|---|---|---|---|---|---|
| 2. Awareness of the solution | Robert and Tomas both know the triage-core pattern is available. | Named in the same decision thread as the other factory apps (plan 001). | Internal, two-person, no real “awareness” gap exists separate from problem recognition. | N/A, folded into stage 1. | None. | Robert. |
| 3. Research / evaluation of alternatives | Confirm nothing already solves this before building. | This plan’s own research pass (R1-R8): HumanLayer dead (founder-confirmed deprecated, R3), agent-inbox LangGraph-coupled, zero cross-agent-instance dedup products found anywhere (R3). |
None, this step already happened, it is this document’s evidence base. | Skipping this and building blind (avoided here). | None. | Robert, research-agent-assisted. |
| 4. Trial / pilot | Cheapest disproving test before full build. | The initial recommendation’s own “fastest concept test”: run the triage core live on the next real fleet wave for one week, count four numbers. | Needs a real fleet wave to exist on the research pass’s own timeline, may not land before a build decision is needed. | Skipped, Atlas ships on faith instead of the one-week trial. | The four numbers: questions filed, duplicate rate, interrupts/day before and after, write-back-worthy answers/week. | Robert. |
| 7. Onboarding (first use) | A new agent, or Robert, uses the loop for the very first time with no prior corpus. | Agent hits ambiguity, searches an empty or thin corpus (a miss by default, variant B), files the first-ever question. | Cold-start problem, value compounds only after weeks of write-back; first users get none of the benefit yet. | First agents conclude “asking is faster than checking,” entrenching the ask-first habit the whole concept depends on breaking. | Time-to-first-question-filed; corpus size at week 1 versus week 4. | Fleet agents, Robert. |
| 11. Integration (adjacent tools) | The loop rides existing substrate (tasks UI, GChat digest, git, MCP tool) with no new integration surface. | Dedup layer reads/writes the tasks API; write-back agent commits to git; digest posts to GChat. | “Digest to GChat” in the initial recommendation’s own platform judgment has zero supporting code today: R1 confirms no Slack/Chat client code anywhere in the repo, and the legacy Sherlock GChat triage gateway was deliberately not ported when this codebase was built (“migrated from the legacy notification service minus its Google-Chat/Sherlock triage gateway… deliberately not ported,” R1 quote). This is new build presented as if it rides existing rails. | Digest never ships because nobody budgeted the GChat webhook/bot integration as net-new work. | Whether a GChat message ever actually posts outside a manual copy-paste. | Robert. |
| 12. Feedback loop | Frustration signals (wrong routing, noisy queue) actually change routing/rate-limit rules. | Informal, the same decision thread used elsewhere in the program, no dedicated feedback mechanism designed. | No structured feedback intake exists, fine at N=2, breaks silently if “future teams” ever arrive with no formal channel built. | Feedback happens but never gets written back into routing-rule changes, config drifts from what people actually want. | None currently, qualitative. | Robert. |
| 16. Advocacy / referral | If the pattern works, Robert or Tomas describes it as worth reusing for a future team or program. | Verbal or decision-log mention, no formal referral mechanism at N=2. | None, there is no one else to refer to yet. | N/A, no audience to fail to reach. | None. | N/A. |
2.3 Collapsed commercial stages (N/A)
| Stage | Reason N/A |
|---|---|
| 5. Purchase / procurement / billing | Internal system, no transaction, no budget line separate from the factory lane’s existing internal-plane lane grant (covered under stage 6, Setup). |
| 17. Renewal | No subscription or contract to renew; the closest real analog is a go/no-go decision, already owned by the falsifiable 4-week metric (stage 9), not a separate stage. |
| 19. Churn | No paying customer to lose. The real analog is the concept’s own stated collapse condition: fewer than roughly 5 write-back-worthy answers per week means Atlas contracts back to plan-001 triage-only (01-initial-recommendation.md), a kill criterion covered under Offboarding and the variant journeys below, not a distinct funnel stage. |
3. Core loop, happy path (sequence diagram)
sequenceDiagram
participant Ask as Asker agent
participant Read as Reader agent (corpus check)
participant D as Dedup layer
participant T as Tomas
participant WB as Write-back agent
participant G as Digest (GChat)
Read->>Read: search corpus first (docs, glossary, past answers)
alt corpus hit, current and correct
Read-->>Ask: resolved, no interrupt (invisible success)
else miss
Ask->>D: file structured question (INFORMATION_REQUEST, agent-questions queue)
alt matches an already-open question
D->>D: merge, attach this asker to the existing task
else no match
D->>T: route as a new task
end
T->>T: answer once (decision, rationale, scope, expiry)
T->>D: POST /tasks/:id/complete
D->>Ask: signal-resume (all attached agents)
D->>WB: hand off completed answer
WB->>WB: write diff (docs/glossary/decision-log)
WB->>G: digest line (decisions made, questions open)
end
4. Variant journeys
A. Happy path
Agent hits ambiguity on EOL code, searches the corpus, misses, files a structured question as INFORMATION_REQUEST with assigneeGroupSlug=agent-questions, no existing open duplicate, routes to Tomas’s queue, Tomas answers within his own cadence via the existing tasks UI, signal-resume wakes the one blocked workflow (the proven single-task path, R1), write-back turns the answer into a docs/glossary diff plus a decision-log row, a digest line is generated. The next agent with the same question hits the corpus and never asks. This is the only path where the concept pays for itself; every other path below is a cost the design must bound, not eliminate.
B. Cold-start agent (empty corpus)
First agents in week 1 hit only an empty or thin corpus, a guaranteed miss regardless of question quality, there is nothing to find yet. This is structural, not incidental: the value proposition (“check corpus first, most ambiguity resolves invisibly”) is literally false for the first several weeks by construction, and interrupts-per-day will look identical to a no-Atlas baseline until the corpus has depth. Risk: Tomas forms a judgment in week 1-2, exactly when the product looks worst, rather than waiting the full 4 weeks the go/no-go metric assumes.
C. Expert agent
An agent running long enough (or seeded with the corpus at start) checks first, finds a fresh, non-expired match, and never files a question at all, the fully invisible success case (Ive lens: success is invisible, fewer interrupts, not more screens). The risk is measurement, not behavior: a fully successful run produces zero rows in any dedup/task log, so the loop’s best-case outcome is undercounted unless corpus-hit events are deliberately instrumented, which nothing in the substrate does today (R1: no logging found for docsContentService.search() hits). The metric that would prove the product works (silent-success rate) may not exist without new instrumentation.
D. Answerer overload week
The EOL-code question generator spikes volume beyond Tomas’s daily answering cadence in a single week, for example when a new domain onboards. The tasks service has no reminder, escalation, or SLA reassignment (R1, explicitly not built) and notifications has no rate-limiting (R1), so nothing structurally protects Tomas from a queue-depth spike; the only real relief mechanism is dedup collapsing duplicates before they reach his queue at all, meaning dedup precision under load is the entire buffer, with zero fallback if it saturates. Failure mode: Tomas starts answering tersely, skipping scope and expiry under pressure (feeding directly into stage 10’s failure state), or the queue backs up silently since no escalation path exists.
E. Failed write-back
An answer completes the task and resumes agents, but the write-back step (doc diff, glossary entry, decision-log row) never lands, it crashes, sits in an unstaffed review queue, or the diff fails lint/CI and stalls. The answer unblocked today’s agents, but the next agent asking the same question gets no corpus hit, the loop silently degrades back to plan-001 triage-only (answered once per instance, not answered once forever), and nobody notices because “task completed” looks identical whether or not write-back succeeded (R1: task completion and write-back are two separate, uncoupled steps in the substrate). This is the initial recommendation’s own open question made concrete: who reviews the machine-written diff, and what happens when that review does not happen.
F. WRONG dedup match feeding N agents a bad answer
Dedup falsely matches question B (subtly different from question A) to an already-answered question A; every agent attached to B gets resumed with A’s answer, wrong for their case. Grounded directly in the evidence: false-positive auto-merges are “effectively irreversible in most systems” and corrupt audit trails, a finding that converges independently across Zendesk-, Jira-, and generic support-tooling vendor guidance (R8); and memory-poisoning research (MINJA, Dong et al., NeurIPS 2025 poster, https://arxiv.org/html/2503.03704v4, reporting 95%+ injection success in adversarial settings) shows agent memory systems accept and propagate incorrect records with the same confidence as correct ones, without flagging uncertainty, directly analogous to what a wrongly-merged answer would do once written back and served to future agents as verified fact. Worst case: the wrong answer gets written back into the permanent corpus, poisoning the well for every future agent that matches against it, not just the N originally-attached agents, the single most severe failure mode in the concept, and the one the initial recommendation names first as its biggest usability risk. No product surveyed (R3) has a fleet-wide retraction or fan-out-correction mechanism, so recovery is entirely bespoke: a supersede action that reaches every agent who already consumed the bad answer, not just future askers, unbuilt, and nontrivial (stage 14).
flowchart LR Q1[Question A - answered correctly] -->|false-positive merge| Q2[Question B - subtly different] Q2 --> A1[Agent 1] & A2[Agent 2] & A3[Agent N] A1 & A2 & A3 -->|resumed with wrong answer| Work[Wrong work proceeds] Q1 -->|write-back| Corpus[(Corpus)] Corpus -.->|future agents match against it too| MoreAgents[Future agents] style Q2 fill:#622,stroke:#f66 style Corpus fill:#622,stroke:#f66
G. Permission problem (question quotes confidential data)
An agent’s question, describing what it is blocked on, quotes real legacy data as an example, a customer record, an SSN-shaped field, a payment token. Under the write-back contract, that question and its answer are destined to become a permanent, git-versioned artifact (docs/glossary/decision-log), and possibly a GChat digest line, meaning a PII/PCI exposure that would have been transient in a chat message becomes permanent and searchable the moment write-back succeeds, the literal opposite of what write-back is supposed to make safer. Nothing in the substrate today screens question or answer text for sensitive content before it is attached, routed, or written back (R1: no field-level ACL or content-scanning found in tasks or notifications services). The security/compliance stakeholder’s required gate here is a pre-write-back content check, which is out of scope for the zero-PR v1 as currently framed, a genuine fourth ask the research pass surfaces even though the ask surface was explicitly capped at three (R2). This needs to be folded under one of the existing asks or named as an unaddressed gap in the synthesis doc, not silently absorbed.
H. Program handover to Groupon staff
The deferred “future Groupon eng teams” stakeholder finally materializes, the refactor program transitions from Robert’s fleet plus Tomas to a real Groupon engineering org reading the corpus for the first time with no context on how it was built. This is offboarding’s real test: does the corpus read as trustworthy, current, and navigable to someone who never watched it accumulate, or as an unlabeled pile requiring archaeology? Grounded risk: Backstage-adoption literature found failures are “adoption failures, not technical failures,” the tool works, but a team a year later either abandons it (“install and forget”) or discovers a year-plus in that ownership was never assigned (R8), directly on point for a corpus whose only two committed readers are the ones handing it off. No procedure for this exists in any doc in this plan or its siblings (the same gap flagged in 002-work-ledger-product/03-journey.md’s own stage 8), carried forward here as an open question, not invented.
5. Cross-cutting risks this analysis surfaces
Not re-litigated in full, flagged so later docs (PRD, pre-mortem) inherit them rather than rediscovering them:
- The fan-out gap (stage 6, stage 8). No code path exists today for “attach a second asker to an already-open question” and get both resumed. This is the single largest unverified technical assumption underneath the entire concept and should be the first thing prototyped, before any docs/glossary/digest work, since the whole expansion is worthless if this does not actually work.
- Schema validation the zero-PR mandate cannot add (stage 10). The answer form’s scope/expiry structure, load-bearing for dedup and write-back trust, has no enforcement path without a PR the v1 mandate defers. This is a real tension between two of the program’s own binding constraints, not a gap in this analysis.
- The wrong-dedup blast radius (stage 14, variant F). This is the concept’s own named biggest usability risk, and the evidence base (R8) confirms the industry consensus is surface-for-confirmation, never auto-merge, plus no product anywhere has a fleet-wide retraction mechanism. Any v1 that ships auto-resolve without a supersede-and-notify path is shipping against documented best practice.
- Silent write-back failure (stage 14, variant E). Task completion and write-back are uncoupled today; a failure here degrades the product invisibly, back to plan-001 triage, without anyone noticing until a repeat question surfaces it.
- Content screening before permanence (variant G). Write-back converts transient exposure into permanent, searchable exposure. This needs an explicit answer, not a silent absorption into the existing three-ask cap.
- Measuring the invisible success case (variant C). The product’s best outcome (a corpus hit that prevents an interrupt entirely) produces no log entry anywhere in the current substrate. Without instrumenting this, the go/no-go metric can only ever see the worst half of the picture.
6. Open questions handed to later docs
- Does the fan-out/many-to-one signal-resume mechanism actually work as designed, or does it need new Temporal-workflow-signal plumbing beyond what R1 confirms exists? (feeds
10-architecture.md) - How does the zero-PR mandate coexist with the need for structured (schema-validated) answers? Is a convention-only approach acceptable for v1, or does this force a renegotiation of the ask cap? (feeds
12-prd.md) - Who reviews write-back diffs, and at what volume does that review itself become a bottleneck? (initial recommendation’s own open question #6, unresolved here)
- Is there a fourth ask (a pre-write-back/pre-digest content screen) that the three-ask cap needs to absorb or explicitly decline? (feeds
12-prd.md,13-pre-mortem.md) - What does program offboarding actually look like, concretely, for either Atlas or work-ledger? Both docs independently flag this as undefined. (feeds
13-pre-mortem.md) - Does “expansion” have any real content beyond adding queues, given “teams to keep updated” remains a hypothesis throughout this entire analysis? (feeds
09-north-star.md)