Skip to main content

​
Review runs and approvals

Every triggered occurrence produces a persisted run. External writes never execute directly; the agent files a proposal that a human approves or rejects. Both are visible in the Studio.

​
Run history

Open the Runs view and select an agent to see its runs, newest first. Each run row shows:
  • Status. Queued, running, succeeded, or failed.
  • Started at and completed at timestamps.
  • Trigger source. Manual, schedule, Control event, or signed external event.
  • Error code and message when the run did not succeed.
Selecting a run expands two lists:
  • Events. A time-ordered stream of what the agent did during the run — tool calls, intermediate reasoning summaries, produced artifacts, and the final output.
  • Audit entries. Governance-relevant records such as tool grants exercised, external-action proposals filed, and decisions recorded on those proposals.
Use the events list to confirm which Control tools the run invoked and to verify the agent’s summary against the underlying data.

​
Rerunning a workflow

To rerun the same instructions on demand, use Run now in the Builder. To have Control rerun on a schedule or event, configure the appropriate trigger. See Trigger workflows. Occurrences and their runs are immutable. Editing the draft and publishing a new version does not change past runs; new triggers dispatch runs against the new version.

​
Approvals view

The Approvals view lists external-action proposals filed by any workflow in the tenant. Each proposal captures: Proposals inherit tenant-level access controls. Any tenant member can open the view.

​
Approve or reject a proposal

  1. Open Approvals.
  2. Select the proposal.
  3. Read the payload and confirm the fixed destination (for example, #finance-review).
  4. Choose Approve or Reject.
Effects:
  • Approve. Control atomically claims the proposal for execution, sends the exact payload to the provider through the bound connection, and records the result. If the provider fails, the proposal is marked failed with a sanitized error message and can be retried by reconciling delivery.
  • Reject. The proposal is closed as rejected. No provider call is made.
Approvals check the proposal hash, so a payload cannot be changed between review and execution.

​
Reconciling provider delivery

If the provider call is interrupted or its response is lost, Control keeps the proposal in a claimed state and surfaces reconciliation controls in the Approvals view.
  1. In the provider’s own UI (for example, Slack), confirm whether the message was actually delivered.
  2. Enter the provider’s receipt (message ID or draft ID) in the reconciliation input.
  3. Confirm Delivered or Not delivered.
Confirming delivery marks the proposal succeeded and records the provider receipt against the run’s audit trail. Confirming non-delivery marks it failed so the workflow can re-propose if needed.

​
Verify what actually happened

For every action the workflow took:
  • The originating run in the Runs view lists the tool calls and the proposal filed.
  • The proposal in the Approvals view shows the exact payload, the approver, and the provider receipt.
  • The workflow’s audit entries link the proposal to the run and to the trigger that produced the occurrence.