Setup
Most of what Morse can tell you depends on a few facts your runs carry: an outcome, a customer, a conversation, a prompt version, a record key. Setup lists them all in one place. Each item says which screen it unlocks, how many of your runs in the last 7 days have it (30 days is one click away), and the snippet that adds it for your framework.
The same checklist appears in three other places: at the top of an agent’s Capture health panel (for that agent only), as a banner on the dashboard while items are left, and at the end of onboarding. Empty screens such as Threads, Prompts, Cost › Segments and Customer revenue link straight to the item that fills them.
The items
| Item | What it unlocks | Target |
|---|---|---|
| Outcome labels | The Quality verdict and cost per confirmed outcome | 80% |
| Customer ID | Cost › Segments and Customer revenue (margin per customer) | 80% |
| Conversation ID | Threads: every turn of a conversation together | 80% |
| Prompt versions | Prompts: which version pays off | 80% |
| Record keys | Outcomes that arrive later (a ticket resolved, a PR merged) | 80% |
| Git revision | Deploy markers and change verdicts | 80% |
| Configuration fingerprint | Change detection. Morse computes this; you do nothing. | 95% |
Item states
- Done: coverage meets the target.
- Partial: some runs carry it, fewer than the target.
- Missing: runs exist and none carry it.
- Waiting for runs: nothing ran in the window.
- Automatic: Morse derived it without code from you. Today that means prompt versions
detected from your system prompt (shown as
auto · a1b2c3). Name them withset_prompt()and your names replace the automatic ones. If your system prompt changes on every run (a date or a user’s name inside it), Morse does not guess; it asks you to declare a version. - Morse is fixing this: the configuration fingerprint is computed by Morse for every run with a model call. If it is low, the gap is ours, and it never counts as one of your items.
Outcome presets
The outcome item suggests a preset when your agents’ own activity points to one: pull-request tools suggest Pull request merged, ticket tools (Zendesk, Intercom, Freshdesk) suggest Support ticket resolved. Each suggestion shows its evidence (“seen in 34 of 40 runs”) and how many runs it would label right now. Nothing applies until you click Apply preset. A preset joins outcomes on a record key, so an agent whose runs carry none is pointed at the record-keys item first. GitHub and the record-outcomes webhook are listed as sources alongside.
Customer from user ID
If your runs carry a user_id but no customer_id, the customer item offers Treat user_id as
customer for that agent, with sample values. Confirm it only when your user IDs identify the
paying account; an end user’s ID gives margin per user, not per customer. A customer_id your app
sends always wins over the mapping.
Automatic conversations (SDK 0.7.0)
From SDK 0.7.0, OpenAI Responses calls that continue a conversation (previous_response_id or
conversation) are chained into one thread by Morse, with no code change. Framework adapters
(LangGraph, LangChain, OpenAI Agents, Claude Agent SDK) already fill the conversation ID from the
framework’s own thread.
An opt-in capture_end_user=True (Python) / captureEndUser: true (TypeScript) on init reads
the end-user field you already pass to OpenAI or Anthropic and stores a one-way hash as the run’s
user ID. The raw value never leaves your process, and it is never used as the customer.