What is a Moment?
A moment is a specific instance in a person’s day when something happens that needs handling: a job to be done. A flow is a path through a system, but a moment is a thing that happens in the world and needs a response. The moment is the unit design centers on because it’s the unit where the cognitive load question becomes answerable: in this moment, who’s doing the assembling and reasoning — pulling together the scattered sources, working out the next move — the person, or something built to do it? This matters because a role is a collection of recurring moments. Designing an AI role doesn’t mean designing “an AR agent” — it means scoping one moment at a time: the clerk’s twelve failures landing, then the next moment after that. The composition model is built for exactly this: each scoped moment becomes the Capability Plugin/Skill (Capability Plugins/Skills are technical pieces and instructions defined by the PM and engineers that enable Atlas to perform the work) that handles it, and the platform assembles the Role Plugin from all of them at runtime (runtime is the point when AI starts its processes for a specific Capability Plugin/Skill). The five parts of a moment are constant — Assemble, Reason, Decide, Act, Remember — but the UX varies significantly depending on whether the moment was triggered by a domain event, a schedule, or a person initiating it. This view makes those differences explicit, part by part.1. Assemble
Agent’s half — invisible to the person Atlas reads sources, reconciles what they say, and builds the Situation Package — the compilation of evidence Atlas references while reasoning through the Capability Plugin/Skill. This is backstage work — the person never sees the assembly directly. The assembled Situation Package is available for the person to review as part of the output guidance (the recommendation surface — a Workspace feed item, domain page alert, or chat response — where Reason’s output becomes visible to the person).When It Breaks
A source is stale or two sources conflict, creating a risk. Atlas surfaces this in the output guidance rather than guessing — noting which data is missing, flagging conflicting signals, and letting the person know the recommendation is incomplete.2. Reason
Agent’s half — the result becomes the output guidance Reason produces the output guidance content. Everything the person can read — recommendation, evidence, confidence, alternatives, and risks — is Reason’s output made visible. The details of the output guidance show Reason’s work: why this guidance was generated, what evidence it drew on, and what it’s uncertain about.When It Breaks
Confidence is low — not enough signal for a confident recommendation. Atlas surfaces this in the output guidance rather than overstating certainty: “I found three payment failures but can’t classify the third — here are the two I can recommend, and here’s the third for your review.” Naming the gap gives the person something to act on; a silent gap doesn’t.3. Decide
Person’s half — always visible, always actionable The output guidance is the main UX artifact. It carries the recommendation, evidence, confidence, alternatives, and proposed next step. The design follows a trust ramp: default view is enough to act on quickly; progressive disclosure opens fuller evidence for verification. The goal is to make the right action the easy one.When It Breaks
The person rejects the recommendation. The card must capture the reason — not just “rejected” but enough signal to learn from. “Wrong” vs “right but not now” vs “right but never for this customer” — the system can only learn differences the card can capture.4. Act
Deterministic — gated, not improvised Accepting the guidance is not the same as executing the action. Two actions in the same moment can have different trust ceilings: a reversible internal write can graduate to autonomous; a customer-facing send stays behind explicit approval permanently.When It Breaks
Action fails — payment gateway times out, downstream system rejects the write. The UX surfaces what happened (not a silent failure), names the gap, and doesn’t leave the person starting over. If a handoff to a human is needed, the Situation Package travels with it.5. Remember
Platform’s job — written before the action fires Every time Atlas (or Atlas with a person’s approval) is about to implement a decision that changes something in ServiceTitan — retry a payment, send a collections notice, reassign a technician — it records what it observed, what it concluded, and what was decided before executing. This record is the decision trace: an audit trail with reasoning attached. Remember doesn’t vary by trigger — the same write-before-action step runs whether the moment started with an event, a schedule, a person, or a policy, which is why this section has no trigger table. A decision trace captures the situation at the time of the decision (the customer’s balance, how many days overdue, any promise to pay), what Atlas recommended and why, its confidence, and what the person chose to do — accept the recommendation, reject it, modify it, or override it — including what they changed it to and why. For example, if a manager overrides a suggested retry amount, Atlas adds that override to the decision trace as evidence of how the shop wants retries handled. Atlas writes the decision trace automatically, just before the action fires. It’s what makes Atlas improve over time and what a person can audit to understand a past decision. The decision trace is available on any past output guidance: what was assembled, reasoned, recommended, decided, and what happened as a result.UX patterns for this framework are in progress.