Runs and run history

Workflow Agent run records summarize simulations, policy-blocked previews, and other local-safe outcomes. They are not production workflow executions and do not prove that an external app was contacted. Use the history surface to understand what the preview evaluated, which gate stopped progress, and what evidence was retained for the current environment.

Run lifecycle

A Workflow Agent preview record begins when a draft is simulated or when the preview logic records a blocked outcome. The record can move through local evaluation and end with a simulation summary, an error, or a policy-related stop. Retry and replay are unavailable or disabled in preview mode.

Do not apply the broader agent runtime lifecycle automatically to these records. A workflow preview run is a distinct product concept. Its lifecycle is constrained by the draft-and-simulation implementation and does not represent durable production scheduling, remote execution, or external side effects.

The run store, run types, timeline helper, and evidence store provide a structured foundation for the UI. Current data may be local-safe or fixture-backed, so the presence of a record is not evidence of production durability.

Simulation results

A simulation result should identify the draft evaluated, the steps considered, route-readiness decisions, missing credentials, approval requirements, and any policy or connector restriction that affected the outcome.

Read the result as a forecast of behavior. A passed step means the preview logic accepted that part of the definition. A blocked step can be more informative than a generic failure because it points to the exact gate that must remain unresolved.

No simulation result should be described as an external write. Bridge dry-run lines, expected outputs, and generated evidence remain preview material. If a result includes sample data, keep it separate from real business records.

History

The runs route provides a history-like view of current preview records. Seeded examples and fixture-backed entries can help explain status and evidence, but they are not a guaranteed account of every action over time.

Run-store evidence does not verify that records survive every restart, deployment, or environment change. Do not rely on this page as a production audit log. When a preview is important for review, retain the relevant definition and result through an approved external process rather than assuming indefinite product retention.

History entries should make their source and mode clear: simulation, policy block, example, or local preview. Avoid combining them with Studio jobs or agent runtime runs, which have different state and persistence contracts.

Errors

An error can arise from an invalid draft, missing route, absent credential, approval gate, policy decision, connector state, or simulation problem. Interpret it using the step and route context rather than treating every error as a system outage.

Correct only the supported cause. A policy or disabled-route result should not be retried as though it were a transient network failure.

Evidence

Evidence records explain how the preview reached its result. They can reference route readiness, simulation output, step state, or the reason a policy gate applied. Evidence should remain tied to its workflow definition and record identity.

Do not call evidence an artifact or receipt unless the source uses that exact concept. Evidence does not prove execution. A read-only JSON definition, timeline item, or dry-run line can support review without representing an external event.

When evidence is incomplete, keep the result provisional. Do not fill missing fields with assumptions about provider behavior or app responses.

Troubleshooting

If a record is missing, first determine whether the current environment loaded fixture or local data and whether the simulation created a record at all. If a record appears but has no expected step result, compare the stored draft with the current builder definition.

A disabled retry control is intentional in preview mode. Revise the draft or prerequisite, then request a new simulation rather than trying to replay a non-production run. When a record reports a policy or approval block, preserve that outcome and resolve the governance question before continuing.

For inconsistencies between the builder, approval packet, and runs page, use the least mature interpretation: the workflow remains a draft, the decision remains unresolved, and no external execution occurred.

Reading the timeline

A preview timeline should be read as an ordered explanation of local evaluation. Entries can show draft creation, validation, simulation, policy checks, and a final preview status. They should not be interpreted as remote provider timestamps unless a source explicitly identifies an external event, which the current Workflow Agent record does not.

Compare timeline entries with the workflow definition. A step that appears in the draft but not in the simulation may have been blocked by an earlier gate. A record that ends at approval or policy is complete for preview purposes even though no downstream action ran.

Record identity and correlation

Keep the record reference together with the draft and evidence it describes. If the same workflow is simulated again after an edit, treat the new result as a separate preview rather than overwriting the earlier interpretation. Preview-run sources do not guarantee a durable version graph, so record comparison may be manual.

Persistence consequences

Local-safe or fixture-backed storage is appropriate for product preview, but it changes how the history can be used. It cannot serve as the only audit source for a consequential decision. It also cannot prove that an absent record was intentionally deleted. Until durability is verified, export or note important review results through an approved process that does not expose secrets.

Distinguishing records

Workflow Agent preview records, Studio media jobs, and agent runtime runs have different state machines and meanings. Do not merge them in terminology or troubleshooting. A simulation summary is not a media result, and a policy-blocked preview is not a failed production agent run.

Simulation comparison

Two simulation records can be compared by draft shape, route status, connection state, and outcome. A later record may improve because the description was clarified or a connection state changed. It may also become more restrictive when the current source or policy differs.

Avoid comparing only the final status. A “passed” preview with a suggested-only route can be less operationally ready than a “blocked” preview that correctly exposes a required approval or missing credential.

Error preservation

Keep the original error domain and message associated with the record. Rewriting every failure as “simulation failed” removes the information needed to correct it. Do not add provider or network explanations unless the preview actually attempted that layer.

Evidence retention limits

The evidence store supports the current preview experience, but no fixed retention or export contract is verified. If evidence is important to a review, capture its references and relevant non-sensitive content through an approved process. An absent record later should not be interpreted as proof that evidence was intentionally purged.

Read-only history

Current retry and replay controls are unavailable or disabled. The safer workflow is to create a new simulation after a change. This preserves the distinction between the earlier preview and the updated result, even if the product does not provide a durable comparison interface.

Review questions for a single record

Ask which draft was evaluated, whether the loader used production or fixture data, which route was considered, which gate stopped progress, and whether the evidence is simulated. Those answers establish what the record can support without turning it into an audit log.

Preview-run completion

A preview record is complete when it explains the evaluated draft and final preview outcome, even if that outcome is blocked. It does not need a remote side effect to be useful. A policy block, missing credential, or unavailable route can close the preview cleanly.

History boundaries for reporting

Do not use the runs page to calculate production volume, success rate, or service reliability. Fixture-backed and local-safe records are not a stable operational dataset. Counts and trends would be misleading without durable storage and clear source labeling.

Evidence sensitivity

Review evidence before sharing it. Although raw credentials should not be present, a prompt or simulated payload can still contain sensitive business data. Redact unnecessary values while preserving the route and error context needed for diagnosis.

Timeline ordering limits

The timeline can order events recorded by the preview store, but it does not prove synchronized timestamps with external apps. No remote app is contacted. Use it to understand local evaluation sequence, not to measure third-party latency or establish a legal event chronology.

Counts and summaries

Totals derived from preview records can include fixtures, examples, and policy-blocked simulations. They should not be used as production metrics. A dashboard count is meaningful only after the source mode and persistence contract are known.

Record cleanup

The sources do not verify delete, archive, or retention controls for preview runs. Do not advise readers to remove records through an invented action. If a sensitive simulated value appears, stop sharing it and request product review of the current store.

Record provenance

Mark whether a record came from a user-requested simulation, a seeded example, a fixture, or a policy-blocked preview. Provenance prevents examples from being counted as user activity.

Snapshot interpretation

Each record captures the draft and environment at one point in time. Later connection or route changes do not retroactively make the earlier result live or incorrect; they create a different context for a new simulation.

Current conclusion

Use preview history to explain a simulation, not to prove service uptime, external execution, or durable retention across environments.

Record provenance should remain visible whenever preview history is shared or compared.