How much you have to build

Two questions decide how much work installing Sarah actually is:

1. Which moments can she catch on her own? Some she detects. Some you tell her about.
2. Can she only talk, or can she also act? Talking is free. Acting needs a small server you run.

They're independent. You can have every moment firing and zero actions — that's a perfectly good place to stay, and it's most of the value.

Question 1 — which moments fire on their own

Everything starts with one script tag and one call telling Sarah who the user is:

UserSay.identify({ uid: user.id, plan: user.plan, credits: user.credits });

From there, moments fall into four tiers. Your dashboard labels every moment with the same four, so you can check any row of this table against it.

How the free ones work

• welcome — first visit. She introduces herself and asks what brought them.
• pricing_visit — the URL matches /pricing and they linger. No instrumentation; she's watching the address bar.
• return_visit — the SDK counts sessions and gaps by itself. A user coming back after a long silence is detected client-side.
• credits_exhausted — she watches for HTTP 402 responses from your own API. If your product already returns 402 when a user runs out, this fires with no code at all. This is the single highest-value free trigger on the list, because "just ran out mid-task" is the most convertible state a user is ever in. One caveat worth knowing: it is free because a new project ships with 402 detection switched on. If you turn that off in the dashboard, this moment moves down a tier and needs the one-line trigger like the others.

That last one is worth checking before you write anything: if your API returns 402 today, you're already done.

Why the free list isn't longer

The auto-detect set is deliberately small. The design rule in the code reads:

can miss, must not misfire.

A moment that fires at the wrong time is worse than one that doesn't fire. Sarah interrupts a real person inside your product — a false positive costs you their patience and some of your credibility. So she only auto-detects the signals that can't be misread: a first visit, a URL, a 402, a session gap. Everything else, you tell her, because only you know what "the user's first real success" means in your product.

The one-line ones look like this:

UserSay.trigger('cancel');            // in your cancel flow
UserSay.trigger('first_use');         // from the SUCCESS callback — not the attempt
UserSay.trigger('generation_failed'); // when output missed

Question 2 — her words, or her hands

Layer 0 is most of the value, and it's free. You cross into Layer 1 the moment you want Sarah to give, charge, verify, or count something automatically.

Here's the difference in one conversation. Layer 0, unblocking someone who is stuck — no server involved, and no server needed, because the user wasn't missing a resource:

Sarah

ChatDiagram · stuck

Sarah

looks like you've been staring at a blank canvas — what are you trying to draw?

SIGNAL

comprehension wall, not a resource one — a grant here would solve a problem they don't have

I have meeting notes but no idea what diagram fits

Sarah

paste the notes — if it's a process, a flowchart; if it's parts of a whole, a mind map. let's try one.

MOVE

diagnose UI vs conceptual, then unblock with one concrete suggestion

Now Layer 1, where words genuinely aren't enough — the user is out of credits and wants to finish what they started. No amount of good conversation gives them credits back:

Sarah

ChatDiagram · credits_exhausted

Sarah

ran out mid-diagram — what were you building?

a flow for our onboarding, was almost done

Tool call · grant_credits

→{ "reason": "stuck_rescue" }

←{ "status": "applied", "grantedCredits": 30 }

COST

the server picked the amount, not Sarah — she asked, your caps answered

Sarah

put 30 credits back on your account — go finish it. what made you pick a flowchart over a mind map for onboarding?

Note what happened in the tool call: Sarah asked, your server decided the amount. She can't set it, can't override it, and can't tell the user it worked until your server says it did. That's the arrangement that makes Layer 1 safe to turn on — see Actions for how it's enforced.

What to turn on first

In order of value-per-hour of your time:

1. Paste the script tag and call identify(). Four moments start firing. If your API returns 402, one of them is the best one.
2. Add trigger('cancel') to your cancel flow. One line, and it's the moment with the most money sitting on it. It's also the one line that later becomes a full handoff — once you have a cancel tool, the button opens Sarah instead of your confirm dialog and she owns the outcome. The wiring, both halves.
3. Add trigger('first_use') — the dashboard calls this one First value, and the name is the instruction: fire it when their first creation actually succeeds, from the success callback. A first attempt is not a first value, and firing on the attempt puts Sarah in front of someone who is still mid-task. This is the moment only you can define.
4. Build the MCP server when — and only when — you've read enough conversations to know which action you actually need. Most founders find it's create_checkout_link or grant_credits, not both at once.

Step 4 is the one people rush. Don't. The actions page exists for when you get there, and the conversations from steps 1–3 will tell you which tool to build first.

What none of this covers

Every trigger above needs the user to be in your product right now. Sarah works in a browser tab; if nobody's in the tab, nothing fires.

So there is no tier on this page — free or paid — that catches a user who signed up and never returned, whose card just failed, or who has quietly gone cold over three weeks. Those need a way to notice people who aren't on the page, and that doesn't exist yet. See the user journey.

Next: The user journey if you want the map of what she's for — or Actions if you already know and want her hands.