> ## Documentation Index > Fetch the complete documentation index at: https://docs.stateset.com/llms.txt > Use this file to discover all available pages before exploring further. # Your First Week with StateSet > Move from a successful trial to reviewed live outcomes, preserve corrected answers as evaluations, and measure whether changes help. Your first useful answer proves that setup works. The next goal is a repeatable operation: customers receive appropriate answers, exceptions reach the right person, and changes improve results you can inspect. Use this sequence at your team's pace. It is a suggested operating plan, not a promise that all integrations or approvals complete in a calendar week. ## Start with a small launch record Carry forward your [onboarding record](/guides/platform-onboarding#keep-a-record-you-can-resume) so your first trial and later live results remain traceable to the same intended operation. Complete [your first support agent](/guides/first-support-agent) and, for helpdesk automation, [your first workflow trial](/guides/first-workflow-trial). Keep a shared record of: | Item | What to record | | --------------- | ------------------------------------------------------------------ | | Scope | One support intent, channel, and intended customer group | | Identity | Response organization and agent IDs; Workstream brand ID if used | | Configuration | Current workflow config version and any relevant agent changes | | Evidence | Representative questions, observed answers, and replay/run IDs | | Review | Who checks drafts and handles escalations | | Launch decision | Who can change routing, what evidence they need, and when to pause | This is your team's worksheet, not an API request. Start with a narrow scope you can review; do not treat successful signup or activation as a customer outcome. ## First session: establish a baseline In Response, inspect recent responses and conversations alongside agent analytics. With MCP, use the exposed `list_responses`, `get_response`, `list_conversations`, and `agent_analytics` tools. The analytics tool returns per-agent results over its requested window; select the agent you are reviewing from those results. For workflows, inspect `get_brand_scorecard`, `get_brand_outcome_trend`, and representative runs. Use `get_onboarding_funnel` if there is no real traffic yet. The tools have different schemas: for example, the scorecard uses `brand` and `window_hours`, while outcome trends use `brand_id`. Discover the schema rather than reusing one argument object for every tool. Ask your assistant: ```text theme={null} Read only. Review Response agent [agent UUID] and Workstream brand [brand UUID] for [date/time window and timezone]. Confirm the actual scope and coverage returned by each tool. Separate live traffic from tests and backfill replays. Report handled volume, pending reviews, escalations, and the reasons visible in the results. Include representative response/run IDs. Mark unavailable metrics as unknown. Do not change agents, configuration, routing, or channels. ``` **Success:** you know what has actually run, what still needs review, and which gaps block a useful result. If the tools cannot distinguish a requested cohort, report that limitation instead of presenting the aggregate as a precise cohort measurement. ## Next: review the first live outcomes Before moving a workflow beyond shadow mode, confirm provider readiness, the review gate, and the reviewer who will handle incoming drafts. An authorized operator can choose a canary or live routing mode in Workflow Studio or through `set_brand_routing_mode`. Follow one real event through drafting, review, and dispatch. Confirm the resulting message in the owning channel or execution evidence. A completed dry run, an approved draft, and a sent reply are different outcomes. Workflow routing governs the workflow engine. It does not switch off a Response widget or another independently connected channel. Review and pause each active surface through its own controls when necessary. If behavior is wrong, stop expanding the rollout. Have the responsible operator return workflow routing to shadow where appropriate, inspect pending/in-flight work, and handle affected cases. Changing routing does not unsend messages or prove that already-running work was cancelled. ## Turn a correction into a regression case For exact MCP inputs and a complete before/after exercise, follow [Your First Agent Evaluation](/guides/first-agent-evaluation). In Response, a corrected reply can become an evaluation. `create_eval` accepts the original `response_id` and a `preferred_output`; the service reads the original message/reply rather than relying on your assistant to reconstruct it. Use an explicit task after a reviewer supplies the correction: ```text theme={null} For response [response UUID] from agent [agent UUID], create one evaluation using the approved corrected reply below. Preserve the response ID and explain why the original answer was wrong. Return the evaluation ID. Approved corrected reply: [reviewer's exact correction] Reason: [the policy or evidence the original response missed] I authorize creating this case and running run_eval against the same agent. Report the generated answer, grading result, and any unavailable grading. Do not edit the agent, publish it, or contact the customer. ``` Evaluation runs use real generation and consume usage. In `run_eval`, **`passed: null` means grading could not run**, not that the agent passed or failed. Resolve that gap before claiming that the change has been verified. `run_evals` is capped and can return `has_more`. If the suite is incomplete, use `list_evals` to identify remaining case IDs and `run_eval` for the cases you still need to check. Do not assume that repeating the same capped call advances a cursor. Workstream has a separate golden evaluation set, available through `get_golden_cases`. Its reviewer-corrected workflow replies are not automatically the same records as Response evals. Keep the relevant identifiers and check the evaluation set belonging to the system you change. ## Improve one behavior at a time Use [Your First Workflow Configuration Change](/guides/first-workflow-config-change) for the complete candidate-to-apply walkthrough, including conflicts and recovery. Choose a recurring issue from the baseline: missing source material, a wrong policy condition, unnecessary escalation, or an unsupported capability. High escalation is not automatically bad; inspect the cases to distinguish required review from avoidable handoffs. For Response, correct the relevant knowledge, rule, or settings with authorization, rerun the relevant evaluations, and inspect `list_changes` plus saved configuration to verify the edit. An evaluation case records expected behavior; creating one does not itself update the agent. For Workstream, ask: ```text theme={null} Inspect brand [brand UUID] with get_improvement_breakdown, get_golden_cases, check_config_drift, and representative runs. Propose one configuration change that addresses a recurring problem. Show the evidence, proposed diff, current config version, validation result, and evaluation result. Make no writes. If the problem requires a missing tool or connector rather than a config change, identify that dependency instead of inventing a configuration field. ``` After the proposal is authorized, apply through the versioned pipeline using the required `expected_config_version` and `change_note`. Unattended applies must use `require_golden_pass: true`. A conflict requires a fresh read and review; a failed evaluation requires investigating the result. Neither is a reason to bypass the check. Read back the saved configuration and inspect new executions. See the [MCP management walkthrough](/guides/manage-platform-with-mcp#improve-an-existing-workflow). ## End-of-week review: did customers and operators benefit? Use the same scope and comparable time windows for before/after review. Record sample counts and changes in traffic mix; a handful of easy questions is not evidence of broad improvement. | Question | Evidence to use | | ---------------------------- | ----------------------------------------------------------------------------------- | | Are answers correct? | Reviewed replies and evaluation results, with ungraded cases shown separately | | Is work reaching completion? | Confirmed live outcomes, run/response IDs, and remaining pending work | | Are escalations appropriate? | Sampled escalation reasons and the actual tickets behind them | | Is review effort decreasing? | Reviewer corrections and measured handling effort for comparable cases | | Did the change help? | Change/config version, evaluation results, and subsequent live evidence | | What should expand next? | A named intent/channel supported by the observed results and available integrations | Do not equate a generated draft, tool call, or activated agent with a resolution. Do not infer hours saved or financial return from response count alone. Record measured handling time or other business evidence if you want to make those claims. A useful weekly handoff is short: ```text theme={null} Scope and observation window: Live volume and verified outcomes: Pending reviews and important escalations: Corrections preserved as evals: Changes applied and their versions: Evidence of improvement or regression: Next proposed expansion or blocker, with owner: ``` For operator training, use [Your First Shift in Chat Desk](/guides/chat-desk-first-shift) to practice ownership, customer-visible reply checks, and shift handoffs. ## Next steps * [Platform onboarding](/guides/platform-onboarding): review the first-value milestones. * [MCP management](/guides/manage-platform-with-mcp): connect your assistant and authorize bounded tasks. * [Response MCP](/stateset-response/response-mcp) and [Workstream MCP](/next-temporal/mcp-connector): inspect the relevant tools.