> ## 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 Workflow Configuration Change > Use Workstream MCP to propose, validate, evaluate, apply, and verify one versioned workflow configuration change.
WORK INWorkstream MCP
BRING

Brand access · Saved baseline · Representative cases

FINISH WITH

A verified saved version and evaluation evidence

**Outcome:** one justified configuration change with a saved version, evaluation evidence, and a read-back of the applied result. This walkthrough updates a Workstream workflow brand, not a Response support-agent record or an active-horizon recipe release. Choose a small observed problem, such as a response instruction that contradicts your approved policy. Avoid changing routing, review thresholds, model settings, and policy text together: you need to understand what caused the result. ## Prerequisites Connect to [Workstream MCP](/next-temporal/mcp-connector) with access to the intended brand. Have an authorized reviewer, representative cases, and the policy or evidence supporting the change. Evaluation may invoke models and consume resources even though it does not apply the candidate to the brand. If you have no existing workflow or real case yet, start with [Your First Workflow Trial](/guides/first-workflow-trial). ## 1. Read the baseline Discover the exposed tool schemas, then read `get_brand_config` and the relevant scorecard or run evidence. These configuration tools use the argument `brand`; other operational tools may use `brand_id`. Inspect the schema rather than assuming one name everywhere. Retain the full `deterministic_config`, its `config_version`, the brand identity, and the observed problem. Keep the baseline with the proposed change so a reviewer can compare them. Use `check_config_drift` where available to identify divergence before editing.
**Success:** your proposal will be based on a known saved version and a specific failure case.
## 2. Propose a patch without saving `propose_config_patch` accepts the brand and a list of operations. Its supported operations are `set`, `remove`, `append`, and `replace_text`; it is not a generic implementation of every JSON Patch operation. Use a path observed in the actual configuration and the operation's current schema. Ask your assistant: ```text theme={null} For Workstream brand [brand identifier], inspect its current config and version. The problem is [observed behavior], supported by [run/case references]. The approved policy is [policy text or source reference]. Propose one narrow patch using the actual configuration structure. Use propose_config_patch, retain proposed_config and based_on_config_version, and show the diff and explanation. Do not apply the patch, change routing, disable review, or invent configuration fields. ``` The tool returns `proposed_config`, `changes`, `validation`, and `based_on_config_version`. It does not save the candidate. Preserve that complete candidate; do not reduce it to the changed fragment for the later apply call. ## 3. Validate the candidate you intend to apply Call `validate_config` with the brand and **the returned `proposed_config` as `config`**. Inspect `valid`, `errors`, and `warnings`. Omitting `config` validates the brand's currently saved configuration. That can succeed while your proposed change remains invalid, so confirm which object was checked. Validation checks configuration structure and binding rules. It does not prove answer quality, provider readiness, or that the desired business outcome will occur.
**Success:** the exact candidate passes structural validation, and any warnings have been reviewed.
## 4. Compare behavior before applying Use `get_eval_cases` or approved hand-written cases, then call `evaluate_config` with: | Argument | What to supply | | ---------------- | ----------------------------------------------------------------- | | `brand` | The same authorized brand | | `config` | The full proposed candidate | | `cases` | Representative cases including the observed failure | | `baseline` | The saved configuration from step 1 for comparison | | `simulate_tools` | Explicitly choose whether to exercise the tool-calling simulation | With `simulate_tools: true`, recorded case context supplies reads and mutations are recorded as proposed actions rather than executed. This is not a live connector test. Inspect missing context and proposed actions as well as generated text before trusting the result. Use `evaluate_golden` to check the candidate against the brand's standing human-corrected cases. An evaluation result informs the decision; do not mistake an earlier advisory evaluation for the apply-time gate. If there are no usable cases, build and review the relevant evidence before claiming that the change passed regression checks. Keep Response's evaluation records separate from Workstream golden cases. A Response `run_eval` result does not automatically satisfy this brand's workflow gate. ## 5. Apply the authorized candidate After approval, call `apply_config` with these fields populated from the reviewed work: | Argument | Required value or decision | | ------------------------- | ---------------------------------------------------------------------------------- | | `brand` | The same brand used for reads and evaluations | | `config` | The **full** reviewed `proposed_config`, not the `ops` array or a partial fragment | | `change_note` | Why the change is needed, with useful case/review references | | `expected_config_version` | The `based_on_config_version` of the proposal | | `require_golden_pass` | Set `true` for unattended agent applies; use the configured gate for this change | | `golden_pass_threshold` | Use the approved policy; do not lower it to make a failing change pass | A brand's required golden gate still applies when the caller omits `require_golden_pass`. Omitting the flag is not a way to bypass policy. Resolve the reported prerequisite or failed result rather than removing controls. If the version conflicts, another change may have landed. Fetch the latest configuration, review the difference, and rebuild/re-evaluate the proposal. Do not simply replace the expected version number and send the old candidate, which could erase someone else's work. An authorized apply task can be explicit: ```text theme={null} Apply only the candidate reviewed at [reference] to brand [identifier], using its original based_on_config_version, the approved change note, and require_golden_pass=true. Do not change the candidate or threshold to bypass a failure. Stop and report any conflict or evaluation blocker. After success, read the saved configuration and report the returned version and whether the saved values match the reviewed candidate. Do not change routing. ``` ## 6. Verify persistence and subsequent behavior Inspect the apply result, including `applied`, `config_version`, and `config_fingerprint` when returned. Then read `get_brand_config` independently and compare the saved values. Use `list_config_versions` and `get_config_version` for the version history and snapshots exposed by your connection. Watch relevant subsequent runs. Keep the new config version, run IDs, observed replies/actions, and unresolved regressions with the change record. A successful apply proves persistence; it does not itself prove better live outcomes or change the brand's routing mode. If a response was lost, read the saved state and version history before deciding whether to repeat the write. Do not infer success solely from an HTTP connection or a tool invocation. ## If the change needs to be reversed Read the current state and the earlier snapshot. Treat restoring prior values as another reviewed, validated, evaluated change against the **current** version. An older snapshot is not automatically suitable if connectors or other policies have changed since it was captured. This process changes future configuration. It does not unsend replies, undo provider actions, or establish that in-flight runs now use the restored values. Inspect affected executions and handle their outcomes separately. ## Troubleshooting | Symptom | Check | | ------------------------------------------------- | --------------------------------------------------------------------------------- | | Validation passes but apply rejects the candidate | Whether you validated the candidate or omitted `config` and checked saved state | | Golden gate rejects the apply | Brand policy, usable golden cases, and evaluation details | | Version conflict | Current version and concurrent edits; rebase the proposal deliberately | | Candidate loses unrelated settings | You may have supplied a fragment instead of the full configuration | | Simulation works but provider operation fails | Simulation uses recorded context; inspect live connector readiness separately | | Apply succeeds but no behavior change is visible | Saved values, relevant subsequent runs, routing, and actual triggering conditions | ## Next steps Compare subsequent outcomes with the baseline you saved. Diagnose access problems or a stalled workflow. Related: [Workstream MCP reference](/next-temporal/mcp-connector).