Skip to main content
WORK INWorkstream MCP
BRING

Runtime readiness · Complete plan · Required release approval

FINISH WITH

Workflow ID, observed final state, and output evidence

Outcome: an authorized long-running task has a durable workflow ID, observable progress, and a clear completion or stop result. This walkthrough is for Workstream’s active-horizon agents, not the support-agent records created in Response. Start with a small task such as producing a report from an approved dataset. Define the output and the records that prove completion before giving the agent permission to run.

​
Prerequisites

  • A Workstream MCP connection with permission for the brand and the operations you need.
  • The deployed worker, Temporal service, and required child-workflow runtime; sandbox tasks also need their configured sandbox access.
  • A complete start payload for the intended task, prepared against the current contract.
  • For governed recipes, a validated release, verified sandbox test evidence, and release approval from the authorized operator.
If you have only signed up for Response, begin with your first support agent or workflow trial. A connection to MCP alone does not provision these runtime or release requirements.

​
1. Define a bounded task

Use this worksheet with your operator or assistant. It is a planning template, not a start request; child workflows require their own complete payloads.
The supervisor schedules child workflows; it does not interpret any arbitrary JSON task as an executable integration. Validate the selected child workflow’s input and allowlist entry. Bounded execution also does not make a task read-only: enforce that through the chosen tools, credentials, workflow types, and autonomy policy.

​
2. Complete the release process

For a recipe-backed launch, the current Rust implementation requires recipe_key, recipe_version, and an explicit autonomy_policy, then authorizes the final launch against an approved release_id and its plan hash. Follow the deployed authoring/operator flow and these contracts:
  1. Validate the active-horizon plan. This creates a validated release record; it does not start the agent and is not a read-only check.
  2. Run the required sandbox test for that release using the supported authoring flow, then verify its test evidence. Verification checks an existing test execution; it does not run a test merely because an ID was supplied.
  3. Have an authorized approver approve the release.
  4. Retain the approved plan and release ID for launch. Do not widen its task scope or budgets by editing the payload after approval.
The manual autonomy level permits validation/testing but is rejected for launch. Select the policy appropriate to the authorized task through the release process; do not change it just to bypass a rejection.
The current MCP operations expose start_agent, status, and controls. Do not infer a validate_agent or approve_release MCP tool from the REST route names. If the required authoring or approval operation is unavailable to your assistant, hand that step to the authorized operator rather than skipping it.

​
3. Start the approved plan

Inspect start_agent in tools/list. Its input is an object with a payload property containing the complete active-horizon REST start body. Use the actual approved body; a goal, brand ID, and a list of tool names are not a substitute for it. Ask your assistant:
Keep the returned workflow ID. Closing the initiating assistant conversation does not cancel the durable execution. Conversely, a returned ID is not evidence that its child tasks succeeded. If the start response is lost, reconcile the original request and visible executions before starting a new run. Do not create a fresh request ID merely to retry uncertain work.

​
4. Read progress

Call get_agent_status with these MCP arguments, replacing the placeholder:
Inspect the phase, current task, completed work, failures, available evidence, and remaining bounds exposed in the status. If you lost the ID, use Workstream’s list_agents for the actual brand_id, then inspect the matching execution. Response’s list_agents lists support-agent records and cannot substitute for this lookup. Long-running execution uses a bounded ledger across checkpoints. Store large artifacts in the configured durable destination and retain their references; do not assume the supervisor retains every transcript forever.
Success: a status read identifies the expected task and its observed progress. When it ends, check the result and output evidence rather than treating every stopped run as completed work.

​
5. Pause, steer, or cancel deliberately

control_agent accepts a workflow ID, action, and optional action-specific payload. For example, authorized steering uses:
To request cancellation:
The supported MCP actions are pause, resume, steer, enqueue, reprioritize, extend_budget, and cancel. Inspect the specific action’s schema/contract before using it. A note does not authorize a new business action, and extending a runtime budget does not grant permission to broaden the task. An accepted control means the request was accepted. Read status again to observe its effect; do not assume an in-flight child stopped instantly or that completed external effects were reversed. Emergency termination is a separate REST operation, not an action in this MCP enum; use the operator reference.

​
6. Hand off the result

Record the workflow ID, release ID, final state, completed/remaining tasks, consumed bounds, output references, and unresolved approvals or failures. A budget-exhausted run may have useful partial work, but it is not the same as achieving the goal. Have the owner verify the report or business result. For an external action, retain the provider’s outcome too: durable execution does not remove the need to reconcile an uncertain provider response.

​
Troubleshooting

​
Next steps

Inspect operator controls

Review lifecycle controls, execution bounds, and recovery.

Explore related engines

Choose the commerce, workflow, or agent capabilities for your next task.
Related: Onboarding troubleshooting.
Last modified on September 20, 2026