Skip to main content
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 so your first trial and later live results remain traceable to the same intended operation. Complete your first support agent and, for helpdesk automation, your first workflow trial. Keep a shared record of: 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:
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. 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:
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 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:
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.

​
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. 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:
For operator training, use Your First Shift in Chat Desk to practice ownership, customer-visible reply checks, and shift handoffs.

​
Next steps

Last modified on September 20, 2026