> ## Documentation Index > Fetch the complete documentation index at: https://anvil.servicetitan.com/llms.txt > Use this file to discover all available pages before exploring further. # UX and the Five Parts of a Moment > How the five parts of a moment — Assemble, Reason, Decide, Act, Remember — shape AI UX depending on what triggers the moment. ## 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). | Trigger | What the Person Sees | UX Surfaces | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | Event | Nothing. Assembly happens at event time — payment failure, estimate expiry, job completion. By the time the person sees the output guidance, the assembly is already done. The output guidance carries a timestamp to show when it ran, signaling freshness. | Output guidance (Workspace feed item or Domain page Atlas alert) · Freshness timestamp on output guidance · Situation Package | | Scheduled | Same as event — assembly runs at the scheduled time (morning brief, nightly AR scan). | Same as Event | | Human | The Atlas thinking pattern. The person asks Atlas a question or triggers an Atlas action and waits in the conversation while Atlas assembles in real time. | Atlas thinking pattern (inside an Atlas conversation) · Situation Package | ### 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. | Trigger | What the Person Sees | UX Surfaces | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | | Event | Reasoning ran at the time the event triggered. The output guidance is pre-populated and ready on page load. The description, recommendations, evidence, and risks reflect the moment the event fired, not when the person reads it. | Output guidance headline · Evidence · Recommendations · Risks | | Scheduled | Same as Event. Reasoning ran at the scheduled time. Data in the card reflects when it ran, not when it's read. | Output guidance headline · Evidence · Recommendations · Risks | | Human | Reasoning happens live in Atlas chat. Because the person initiated it, they're invested — this is the highest-scrutiny surface. They can ask follow-up questions ("why this one?") and Atlas explains its reasoning, sources, and uncertainty interactively. | Inline reasoning in chat · Situation Package · Conversational follow-up | ### 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. | Trigger | What the Person Sees | UX Surfaces | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Event | Output guidance either in the Workspace feed or on a domain page. Workspace feed item expands details; a recommendation card on a domain page can bring the user to more details or directly into an Atlas conversation. | Output guidance (Workspace feed item or Domain page Atlas alert) · Situation Package · Recommendations | | Scheduled | Same as Event. | Output guidance (Workspace feed item or Domain page Atlas alert) · Situation Package · Recommendations | | Human | Decision surfaces inline in Atlas chat — the approval appears in the conversation thread. The person can review reasoning in the same thread and ask follow-ups before approving. | Inline reasoning in chat · Situation Package · Recommendations · Conversational follow-up | | Autonomous | If an Atlas action has graduated to an Automation (e.g. retry payments under \$200 automatically), Decide doesn't interrupt the person. The decision was made in advance by policy. A decision trace is still written, and the action surfaces in "What Atlas did" with full attribution. | What Atlas did · Decision trace logged | ### 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. | Trigger | What the Person Sees | UX Surfaces | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Event | Runs right after the person approves the action. High-consequence actions get an explicit confirm step before execution and surface in "What Atlas did" after completion. | Action confirmation toast · What Atlas did · Approval Gate with explicit confirm (high-risk) | | Scheduled | Same as Event. High-consequence actions have an explicit confirm step during setup. | Action confirmation toast · What Atlas did · Approval Gate with explicit confirm (high-risk) | | Human | Act runs in the same chat session. Atlas confirms what changed and can answer follow-up questions about the result in the same thread. The conversation becomes part of the evidence record — what was asked, what was approved, what happened. | Inline action result in chat · What Atlas did · Conversational follow-up | | Autonomous | Runs automatically, without a preceding approval step. Only reversible, low-consequence actions graduate to this ceiling (e.g. retry payments under \$200). The action still surfaces in "What Atlas did" with full attribution and a decision trace. | What Atlas did · Decision trace logged · Automate Action follow-up | ### 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.