Skip to content
GRPNR.

08 - Made to Stick: Atlas SUCCESs Analysis

Method: Heath brothers’ SUCCESs framework (Simple, Unexpected, Concrete, Credible, Emotional, Stories), applied to the concept as stated, not to a friendlier version of it. Audience for stickiness: Tomas (must trust it enough to answer into it), Robert (must operate it), future Groupon engineers (must inherit the corpus and believe it). Inherits 01-initial-recommendation.md’s core finding (three products bundled under one name; only the answer loop is a system, docs/glossary/ digest are renderings of it) and the evidence in evidence/r1 through r8.

Ground rule for this pass: SUCCESs is a persuasion framework, and persuasion is not the goal here, accuracy is. Most of what would make Atlas stick is not yet earned. It can be designed for, but it cannot be claimed, until the week-one live wave produces MEASURED numbers. Every place below where a SUCCESs quality rests on ASSUMPTION or DESIGN intent rather than evidence is marked as such, and the final section collects every place the concept currently stays abstract or weak.

1. Simple

01’s one-sentence core: “Every question the program answers gets answered exactly once, everything downstream (docs, glossary, status updates) is a rendering of that ledger of answers and decisions, generated, never hand-maintained.” That is a defensible compression of the design, but it is not yet Tomas-plain. A version that meets the comm standard (plain, no adjectives, receipts not adjectives):

Tomas-facing: “You answer each question once. Every agent who asked it gets unblocked, and the answer is saved so nobody asks you again.”

Commander’s intent, the one line a future engineer should be able to test a novel decision against without asking anyone: “If it does not remove a duplicate ask or restore a decision-hour, it is not Atlas.” Applied: a searchable UI for browsing past answers fails this test (not requested, does not remove an ask or restore an hour, it is the portal 01 already rejected). A reversible, logged auto-close on a 0.95-similarity duplicate match passes.

Flag: the concept’s own name fails its own Simple test. “The intelligence and communication layer for large-scale legacy refactoring” describes three products (triage, docs/glossary, comms), not the one mechanism that is actually a system. A name that promises more than week-one ships is a stickiness liability, not a strength, because the first real experience of it (a thin triage queue and a generated digest) will underperform the name. The Tomas-facing copy in this document never uses the “intelligence and communication layer” phrase for that reason.

2. Unexpected

Two claims in the concept genuinely violate normal internal-tool intuition, and both are worth naming on purpose because a reader’s first instinct will fight them.

(a) Success is invisible. The normal pitch for an internal tool is “look how much it gets used.” Atlas’s actual win condition is the opposite: fewer interrupts reaching Tomas, a question rate that goes flat or falls as the corpus compounds. 01 already turns this into a kill test: “questions/unit flat after 4 weeks” counts as failure (R2). Leading the internal announcement with this inversion pre-empts the wrong success theater (usage graphs, dashboards) that 01 and both sibling plans (work-ledger, fleet monitor) already independently rejected.

(b) Documentation nobody maintains, that nobody distrusts. This is the load-bearing surprise underneath “documents legacy systems, maintains a glossary,” and it is the one place the evidence in hand cuts hardest against the pitch as written. Every wiki/KM-failure source found, plus the Backstage adoption data, says the opposite happens by default: unmaintained or optionally-maintained documentation drifts, and once a reader hits one stale page they distrust the whole corpus, not just that page (dev.to, “why your engineering wiki is a graveyard,” via R8: “once you encounter one outdated doc, you stop trusting all docs”). Atlas’s bet is that write-back is compulsory, enforced by the loop itself rather than left as optional hygiene, and every fact carries a provenance stamp. That is a different mechanism than the wikis that failed, and a genuinely different bet worth testing, but it is a hypothesis, not a fact, and should be announced as one.

3. Concrete

The 50-agents-one-ambiguity scene, built from real substrate facts rather than a generic example: VIS has been frozen since roughly 2013, orders since roughly 2017 (R2), and dead/frozen code paths are the concrete, named source of the “is this even alive, who owns this” questions the fleet will generate at volume. The agent-questions group queue does not exist yet and must be created (R1). No QUESTION TaskType exists, only INFORMATION_REQUEST (R1, and the zero-PR constraint in R2 means it stays that way in v1). Claude Code subagents cannot ask a human anything today, they auto-deny by design; only a top-level or orchestrating session can surface a question, and even that path has an open, unresolved notification-hook bug as of the cited GitHub issue (R3). The scene below specifies orchestrating sessions as the asker for exactly this reason.

Before: a fleet wave rebuilding a slice of checkout/orders hits billing logic that routes through VIS. Fifty independent orchestrating sessions, none sharing memory with each other, each independently conclude they cannot tell whether this dead path is still authoritative, and each files an INFORMATION_REQUEST. Today, with no dedup layer, that is fifty separate tasks or GChat pings, some routed to Tomas directly, most blocking silently until Robert notices and manually works out which ones are actually the same question.

After: the same fifty sessions each check the corpus first (grep and a structured index, 01’s stated v1, not embedding search). All fifty still miss, because this is a new question the corpus has not seen. The dedup layer sees fifty near-identical INFORMATION_REQUEST tasks land in the agent-questions queue within minutes and merges them into one open task with fifty attached workflow stamps (TaskWorkflowStamp, a real primitive already built, R1). Tomas sees one task in the tasks UI he already uses, not fifty. He answers once: “VIS is authoritative only for orders before 2017, treat as dead after that, confidence high, scope orders domain only, expiry: revisit if VIS is ever formally decommissioned.” Completion fires _workflowSignalSend once per attached stamp, a real, already-built primitive (R1), fifty workflows resume the same afternoon. A cheap write-back agent turns the answer into a diff: one glossary line, one decision-log entry in the existing append-only format (reasons-and-decisions/07-decision-log.md, R1), one skill note. The digest carries one line: a decision was made this week. The next wave that hits the same ambiguity finds the answer in the corpus and never asks.

flowchart LR
    A["50 orchestrating sessions hit the same frozen-VIS ambiguity"] --> B["50 INFORMATION_REQUEST tasks land in agent-questions queue"]
    B --> C{"Dedup: same question?"}
    C -->|yes, merge| D["1 open task, 50 workflow stamps attached"]
    D --> E["Tomas answers once, existing tasks UI"]
    E --> F["_workflowSignalSend fires 50 times"]
    F --> G["50 workflows resume same afternoon"]
    E --> H["Write-back agent: diff to glossary + decision log"]
    H --> I["Next wave finds the answer, never asks"]

This scene is DESIGN intent illustrated with real, already-built substrate primitives (R1). None of it has actually run yet.

4. Credible

What would make it believable: the four numbers 01 already specifies from a one-week live wave, questions filed, duplicate rate, human interrupts per day before versus after, and answers-worth-persisting per week. All four are currently DARK (unmeasured). The sizing signal is already agreed: fewer than roughly five persist-worthy answers a week means the glossary and digest are a habit, not a product, and Atlas collapses back to plan-001 triage (01). The falsifiable kill criterion is the credibility mechanism itself: flat or rising question rate after four weeks equals failure (R2), a number Tomas can check without trusting Robert’s framing of it.

What currently lacks any proof, checked against the evidence directly:

  • Auto-generated, trusted docs. Contradicted by Backstage’s real-world adoption numbers (roughly 10 percent external adoption versus 99 percent internal at Spotify, 5 percent in the ShiftMag case study, Port.io newsletter 2026-03-31, numbers independently corroborated by a second Medium source, R8) and by the peer-reviewed ICSE 2019 documentation-issues taxonomy. The named mechanism in the literature is that manually- or loosely-maintained catalogs drift from reality and trust collapses once it starts. Atlas’s mitigation, compulsory write-back plus provenance stamps rather than optional curation, is a different mechanism and untested.
  • Safe auto-dedupe and auto-merge. Contradicted by MINJA (NeurIPS 2025 poster, 95 percent-plus memory-injection success via query-only interaction, R8) and by consistent vendor guidance that merges are effectively irreversible and should require human confirmation even above a 0.90 similarity score (Jira and Zendesk merge-tooling guidance, R8). Stack Overflow’s own aggressive duplicate-closing culture is independently blamed for driving experienced users off the platform (R8), the exact failure mode, being too quick to call something a duplicate, that would make Tomas stop trusting the queue. 01 already designed for this with a confidence threshold splitting attach from auto-resolve; the credible public claim is that a high bar exists and every merge is logged, not that dedup is solved.
  • Write-back safety generally. The “Always-On Agents” survey (arXiv 2606.30306, R8) names write-back integrity as one of four core failure families for persistent agent memory. A Claude Code anecdote in the same bucket (MindStudio, R8) shows even a simple memory file goes stale for months unless someone prunes it by hand. Atlas’s write-back needs the expiry field 01 already specifies to actually be enforced, or it inherits this exact failure mode.
  • Fleet-scale volume and dedup-rate data. None exists anywhere in public literature (R2, checked twice, same conclusion both times). Every “hundreds of questions a day” estimate anywhere in this program is MODELED or analogy, not a citation.

Recommended credibility mechanism for anything Tomas sees: passport every number and claim (MEASURED, MODELED, DARK, or DESIGN), stamp every persisted answer with who, when, scope, and expiry, log every above-threshold merge as reversible and visible rather than silent, and open with the kill test itself rather than a promise. Credibility here comes from stating the test that could prove the concept wrong, not from adjectives about intelligence.

5. Emotional

Tomas. The whole appeal has to reduce to protecting his decision-hours, because his own words already frame the problem this way: more agents will not help him. His judgment is a fixed, non-parallelizable resource, and every duplicate question that reaches him personally taxes the one thing the 64-agent fleet cannot scale around. The fear worth naming directly, not softened: an answer he gives once in a chat thread today evaporates, and next week six more agents ask the identical thing, and if that keeps happening the arc is not neutral inconvenience, it is Tomas starting to disengage from the queue the same way an engineer stops trusting a wiki after the first stale page. Trust does not degrade gracefully in either case, it cascades toward zero (R8). That is the actual stake behind “protect Tomas’s attention”: not that he is annoyed, but that he stops answering carefully, which would break the loop from the top.

Robert. The stake is operability, not delight. A system that still requires Robert to manually re-triage chat noise is not less work, it has just moved. The win condition is boring on purpose: nothing new to babysit day to day, the loop runs on primitives that already exist and work (tasks, Temporal signal-resume, git), and only two pieces are genuinely new to operate, the dedup layer and the write-back enforcement step, which 01 already scoped to the minimum.

Future Groupon engineers. The risk is inheriting one more entry in the well-documented wiki and developer-portal graveyard (R8) instead of a decision log they can trust on sight. The difference is not sentiment, it is the provenance stamp: a future engineer trusts a fact because it names who decided it, when, and under what scope, not because a tool markets itself as a source of truth. The “single source of truth is a governance claim, not a technical one” critique (R8, section 5) applies directly here: Atlas should never claim to be the source of truth, only to render one honestly from ledger data that already exists.

6. Stories

Retellable in one breath: “Fifty agents hit the same frozen 2017 billing code the same week. Before Atlas, that was fifty pings landing on Tomas. After Atlas, it was one answer, forty-nine resumes, and a glossary entry nobody will ever have to ask about again.”

Flag, adversarial, partially resolved. Groupon already built a chat-triage layer once. The legacy notification service had a Google Chat triage gateway, internally named “Sherlock,” and it was deliberately not carried into this monorepo when the notifications service was rebuilt: services/notifications/README.md:3-6 documents it plainly, “migrated from the legacy notification service minus its Google-Chat/Sherlock triage gateway, a different domain, deliberately not ported” (R1). The reason Sherlock was cut is therefore already on the record: a different domain, not a quality or scaling failure. What is not resolved is narrower: whether that same “different domain” reasoning also excludes Atlas’s digest rows from riding the notifications service (as opposed to fleet monitor’s own GChat channel, per plan 004), or whether Atlas repeats a mistake made for some other, undocumented reason. This is a single, low-cost question to confirm with Tomas directly before any internal announcement goes out, not an open mystery.

Deliverables

One-sentence description, two versions:

  • Internal/design use: “Every question the program answers gets answered exactly once; docs, glossary, and status updates are generated renderings of that ledger of answers, never hand-maintained separately.” (01’s original.)
  • Tomas-facing, plain: “You answer each question once. Every agent who asked it gets unblocked, and the answer is saved so nobody asks you again.”

Memorable value proposition: “Answer it once. It stays answered.” Rejected alternatives and why: “the intelligence and communication layer for the refactor” overclaims against v1 scope and fails the Simple test above; “your AI assistant for the monorepo” implies a chat-with-docs interface, explicitly removed from the concept in 01; “never get asked twice” is close but frames the win as annoyance-avoidance, “it stays answered” centers the durable-artifact mechanic, which matters more once week-one data exists to point back to.

Internal announcement headline and subheadline. This replaces a homepage because there is no homepage, it is an internal notice, and the copy says so:

This is an internal tool for the two of us and the fleet, not a product launch.

Headline: You will not be asked the same question twice.

Subheadline: A queue in front of your existing task inbox merges duplicate agent questions into one. You answer once, in the tasks UI you already use. Every agent who asked resumes. The answer is saved so the next agent finds it before asking. No new login, no new UI, zero code changes to your services in week one.

30-second explanation: “Right now, when an agent hits something ambiguous in the legacy code, it can end up pinging you directly, and if fifty agents hit the same ambiguity in the same week, that can be fifty pings, not one. Atlas sits between the fleet and your existing task inbox. It notices when multiple agents are stuck on the same thing, merges them into one task, and when you answer it once, all fifty resume automatically, the same way task completion already resumes a workflow today. The answer also gets written down, so next month, when a different wave hits the same question, it finds your answer in the docs and never asks at all. We are going to run it for one week and count four numbers: questions filed, duplicate rate, interrupts per day before and after, and answers worth keeping. If the question rate has not dropped after four weeks, we call it a failure and fall back to the plain triage queue.”

Customer problem story: Tomas said it himself, more agents will not help him. His time is the one thing in this program that does not scale with fleet size. Every ambiguity the legacy code creates, and there will be plenty, since VIS has been frozen since roughly 2013 and orders since roughly 2017, eventually has to reach him, and today nothing stops it from reaching him more than once. An unrouted, undeduped stream of questions from a 64-agent fleet is a direct attack on the one non-parallelizable resource in the whole program.

Before-and-after story: Before: fifty agents independently stuck on the same frozen billing path, fifty tasks or chat pings, Robert manually working out which ones are actually the same question, Tomas answering some version of the same thing more than once across a week. After: the fifty tasks land in one queue, a dedup pass merges them into one open item within minutes, Tomas answers once in the tasks UI he already has, all fifty workflows resume the same afternoon, and the answer becomes a glossary line so the next wave does not ask at all.

Demonstration concept: do not pitch it, show the two queues side by side. Run the actual next real fleet wave, 01’s own fastest concept test, and put two views in front of Tomas at the end of week one: the raw list of INFORMATION_REQUEST tasks as they would have landed unfiltered, next to the deduped queue he actually saw. The demonstration is the four numbers, not a slide: questions filed, duplicate rate, interrupts per day before and after, answers worth persisting. If the deduped queue is visibly shorter and the interrupt count visibly drops, that is the whole demo. If it is not, that is the demo too, and it matters more, because it is the kill signal.

Credibility mechanism: passport every number and claim (MEASURED, MODELED, DARK, or DESIGN), stamp every persisted answer with who, when, scope, and expiry, log every above-threshold merge as reversible and visible rather than silent, and open the announcement with the falsifiable kill test rather than a promise. Credibility comes from stating the test that could prove the whole thing wrong, not from adjectives about intelligence.

Strongest narrative: the fifty-agents-one-answer scene. It is the only part of the concept that is a system rather than a rendering (01’s own finding), it maps onto primitives that already exist and work today (TaskWorkflowStamp and _workflowSignalSend, R1), and it ties directly to Tomas’s own stated constraint rather than to a future audience of teams that does not exist yet. The comms and docs/glossary stories are weaker by comparison, not because they are false, but because no standalone version of either has survived in the market researched here (Atlassian’s own “Atlas” retired 2025-05-21, Friday.app dead 2022-06-03, R5), and the strongest surviving analogs (DailyBot, Status Hero) already auto-generate status from agent run logs as a shipped 2026 feature. If Atlas’s digest is just status-from-logs, it is not differentiated. It becomes differentiated only if it carries the decisions-and-why layer that R5 found nobody else in the market has actually built.

Flags: what stays abstract or weak

  1. The concept’s own name overclaims relative to what ships. “Intelligence and communication layer for large-scale legacy refactoring” names three products; only the answer loop is a system (01). Recommend the Tomas-facing copy never use this phrase.
  2. “Docs nobody maintains, that nobody distrusts” is the single most load-bearing Unexpected claim in the concept and currently has zero supporting evidence and a wall of contrary evidence (Backstage adoption data, the ICSE 2019 taxonomy, general wiki-rot literature, R8). It is a hypothesis the write-back contract is designed to test, not a fact to announce as already true.
  3. Every number in this document except the four to be measured in week one is MODELED, DESIGN, or DARK. No fleet-scale question-volume, dedup-rate, or interrupt-cost data exists anywhere in public literature (R2, checked twice) or inside the program yet. State this plainly in any Tomas-facing copy.
  4. The legacy “Sherlock” Google Chat triage gateway (R1) was deliberately cut when the notifications service was rebuilt for this monorepo; the reason is already documented (services/notifications/README.md:3-6: “a different domain, deliberately not ported”). The open question is narrower than “why was it cut”: whether that same reasoning also excludes Atlas’s digest rows from the notifications service. Confirm with Tomas directly before any internal announcement ships.
  5. Auto-dedupe and auto-write-back are both real, evidenced risk surfaces (MINJA’s 95 percent-plus memory-injection success rate, Stack Overflow’s duplicate-closing culture blamed for driving users away, universal vendor guidance against silent auto-merge, R8). The emotional trust story and the technical risk story are the same mechanism running in opposite directions: one bad silent merge or one wrong persisted answer believed as fact, and trust does not degrade, it collapses. This must stay a first-class design constraint, human-confirmed merge, logged, reversible, not a footnote.
  6. The concrete fifty-agent scene only holds up if it specifies who is actually asking. Claude Code subagents cannot surface a question to a human today, they auto-deny by design; only a top-level or orchestrating session can, and even that path has an open, unresolved notification-hook bug as of the cited GitHub issue (R3). Any demonstration or diagram must show orchestrating sessions, or a custom MCP proxy tool, as the asker, not raw subagents, or it will not match what the fleet can actually do.
  7. The digest and comms limb is the weakest of the three bundled products by competitive evidence (R5): standalone status products either die (Atlassian Atlas, Friday.app) or survive only as small hybrids that auto-pull from source systems, and a funded incumbent (DailyBot) already ships auto-status from Claude Code sessions as a 2026 feature. If Atlas’s digest is only status-from-logs, it reinvents a commodity. Its only defensible differentiation is the decisions-and-why layer R5 found nobody else has built; the narrative should say this explicitly rather than let the digest read as a me-too status page.