AI Business Operations · Preview
Workflow Preview: Seeing Exactly What an Agent Will Do Before It Does It
Preview is the feature that turns a sceptical system owner into a sponsor. It is also the feature most agent platforms either omit or fake — and the difference between a real preview and a fake one is whether it can lie to you.
The short answer
A workflow preview renders the concrete actions an agent will take, with concrete resolved argument values, without executing any of them or causing any side effect. It is what allows a human with authority over the affected system to approve a rollout, and what converts an agentic workflow from a claim into a reviewable artefact. A preview that shows action names without resolved values, or that causes writes while resolving, is worse than no preview: it manufactures confidence it has not earned.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸A real preview shows concrete actions with resolved values, causes no side effects, and is honest about what it cannot know.
- ▸Three fake-preview patterns are common: showing action names without values, resolving by performing reads that mutate state, and hiding the steps the agent has not planned yet.
- ▸Reference resolution is where previews leak side effects. Resolving a customer or a folder can create one if the underlying tool is create-if-not-exists.
- ▸Preview fidelity — the share of previewed actions that match what executed — is measurable and should sit above 94%.
- ▸Preview is simultaneously the strongest governance control and the most effective adoption mechanism in the category. Very few features are both.
Source: Mark Alex, Real Biz Digital — Workflow Preview: Seeing Exactly What an Agent Will Do Before It Does It (https://realbizdigital.net/insights/ai-workflow-preview/). Reproduce with attribution.
Key takeaways
- 01Show resolved values, not placeholders. ‘Email {customer.email}’ is not a preview; ‘Email jane@acme.com’ is.
- 02Guarantee side-effect freedom explicitly, and test it. Run a preview a thousand times and assert that nothing changed anywhere.
- 03Mark unknowns as unknown. A preview that quietly invents a value it could not resolve is the most dangerous version of this feature.
- 04Show what will not happen too: the steps that will be skipped, and why.
- 05Measure fidelity by diffing previewed plans against executed traces. Falling fidelity is the earliest sign an upstream system changed.
- 06Give the preview to the system owner, not just the engineer. It is the artefact that gets a rollout approved.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is a workflow preview?
- A rendering of the concrete actions an agent will take, with resolved argument values, produced without executing anything or causing any side effect.
- How is it different from a plan?
- A plan is the ordered list of intended steps. A preview is that plan with every reference resolved to a real value, so a human can judge whether it is correct.
- Why does it matter so much?
- Because it is what a system owner needs in order to permit an agent near their system. Without it, approval is a matter of trust rather than review.
- What makes a preview fake?
- Showing action names without resolved values, causing writes during resolution, or omitting the steps the agent has not planned yet without saying so.
- Can a preview cause side effects?
- It must not, and reference resolution is where they leak in. A resolution that calls a create-if-not-exists tool has just created something.
- What is preview fidelity?
- The share of previewed actions that match what actually executed. Above 94% is workable; falling fidelity usually means an upstream system changed.
- Who should read the preview?
- The owner of the affected system, not only the engineer who built the workflow. That is the approval the preview exists to unlock.
Preview in numbers
Every figure below is defined and sourced further down. They are stated here so they can be quoted without reading the whole page.
Seven properties of a real preview
Key facts
- ▸Properties two and three are what reviewers actually use. In practice a system owner scans for the values and the entity, and the rest is context.
- ▸Property six is the one that separates a trustworthy preview from a dangerous one. Confidently invented values are worse than visible gaps.
- ▸Property seven is almost always omitted and is disproportionately valuable, because a silently skipped step is how incomplete runs go unnoticed.
- 1. Concrete actions
- Named operations, not categories. “Create accounting customer” rather than “set up finance records”. The reviewer must be able to map each line to something that will happen.
- 2. Resolved argument values
- Real values, not template placeholders. The email address, the amount, the account code, the folder path. Placeholders are the single most common way a preview looks useful and is not.
- 3. Resolved entity references
- Which specific CRM record, which specific accounting customer, with their identifiers shown. This is where reviewers catch the wrong-customer error that would otherwise be discovered by the customer.
- 4. Ordering and dependencies
- The sequence, and which steps depend on which. A reviewer needs to know that the invoice comes after the billing schedule, not just that both will happen.
- 5. Side-effect freedom
- No writes, no sends, no provisioning, no state change anywhere — including in systems consulted during resolution. Guaranteed, and tested.
- 6. Explicit unknowns
- Anything the agent could not resolve must be shown as unresolved rather than guessed. A preview that fills a gap with a plausible value is actively harmful.
- 7. What will not happen
- Steps that will be skipped, and why. “Kickoff scheduling skipped: no calendar connector configured” is as useful as any positive line.
Seven properties is the bar. A preview meeting the first four but not the fifth is not a preview at all — it is an execution with a report.
Three ways previews mislead
Mistake
Placeholders instead of values
The preview shows send_email(to: {contact.email}, template: welcome). It looks precise and tells the reviewer nothing, because the entire question is which contact and which address.
Instead: Resolve before rendering. If a value cannot be resolved without a side effect, show it as unresolved and say why — that is honest and still useful.
Mistake
Side effects during resolution
Resolving the accounting customer calls a tool with create-if-not-exists semantics, so the preview creates the customer. The reviewer then approves a plan whose first step has already happened.
Instead: Resolution must use read-only paths exclusively. Where only a create-if-not-exists tool exists, the preview must show the reference as unresolved rather than resolve it.
Mistake
Hidden unplanned steps
The agent has planned four steps and will decide the remaining three at run time. The preview shows four, the reviewer approves four, and seven execute.
Instead: Show the planned steps and state explicitly that further steps will be determined during execution, with the bounded capability set they will be drawn from. Reviewers can accept uncertainty; they cannot accept undisclosed uncertainty.
Keeping resolution side-effect free
This is the engineering problem at the centre of preview capability, and it is more subtle than it appears.
- 01Separate read paths from write paths at the tool level. A preview may call only tools declared read-only. This requires the declaration to be trustworthy, which is a tool-contract discipline rather than a preview one.
- 02Beware create-if-not-exists. Idempotent creation is excellent for execution and lethal for preview. Resolution must use a pure lookup that returns absence rather than creating.
- 03Watch reads that mutate. Marking a record as viewed, consuming a rate-limited token, advancing a cursor, or triggering an upstream workflow on access. All are side effects; none looks like a write.
- 04Do not send test messages. Some platforms “preview” an email by sending it to the requester. That is an execution against a different recipient, and it will eventually go to the wrong one.
- 05Assert freedom in tests. Run a preview repeatedly against a fixture environment and diff the environment state before and after. A thousand previews should leave zero changes.
- 06Declare it in the contract. Every preview capability should state, in its tool description, that it performs no writes. That declaration is what a policy layer and a reviewer both rely on.
The rate-limit case is worth dwelling on: a preview that consumes upstream quota is side-effect free in the state sense and not in the operational one. Previewing a hundred times before approving can exhaust an API budget the execution then needs.
Drift between preview and execution
A preview is a prediction, and predictions degrade. Knowing the sources of drift lets you report fidelity honestly rather than implying certainty.
| Source | Effect | Mitigation |
|---|---|---|
| State changed between preview and run | A resolved reference is now stale | Re-resolve at execution; flag any change against the preview |
| Agent re-plans mid-run | Extra or different steps execute | Disclose the bounded capability set; record plan deviation |
| Upstream schema changed | An action fails or behaves differently | Pre-flight validation; fidelity monitoring catches it early |
| Conditional steps resolve differently | A skipped step now runs | Show conditions and their evaluated values in the preview |
| Approval delay | Longer gap, more drift | Expire previews; re-preview after a threshold |
| Partial failure and recovery | Recovery actions never appeared in the preview | State that recovery paths are not previewable, and what they may include |
Our verdict
Report fidelity rather than implying determinism. A preview that says ‘these seven actions, subject to re-resolution at execution, with recovery paths not shown’ is more trustworthy than one that implies exactness it cannot deliver. In our measurement, fidelity above 94% is normal for stable workflows; a sustained fall below that is almost always an upstream change rather than an agent problem.
Expire previews. A plan previewed on Friday and approved on Monday has had three days of drift, and re-previewing before execution costs nothing compared with what it prevents.
Preview as a governance control
The governance value is specific: preview is the only mechanism that lets a person who understands the business consequence review a proposed action while it is still proposed. Policy enforcement decides whether an action is permitted; preview decides whether it is correct, and those are different questions answered by different people.
It is also the strongest adoption lever available. In our experience the single most common reason an agentic rollout stalls is that the owner of the affected system will not permit it — and a preview they can read resolves that objection more reliably than any assurance about model quality.
Preview unlocks
- ✓System-owner approval for a rollout
- ✓Meaningful human approval at run time
- ✓An artefact auditors accept as pre-execution review
- ✓Debugging before anything has happened
- ✓Safe testing against production data
- ✓Estimating cost before committing to it
Preview does not provide
- —Authorisation — policy still decides
- —Certainty about what will execute
- —Protection from side effects during execution
- —Any guarantee about recovery paths
- —A substitute for tracing after the fact
Pair preview with tracing. Preview answers what will happen; the trace answers what did. Together they bracket the execution, and either alone leaves half the question open.
Measuring preview quality
| Metric | Definition | Target |
|---|---|---|
| Preview fidelity | Share of previewed actions matching executed actions | Above 94% |
| Value resolution rate | Share of arguments resolved to concrete values | Above 90%; the remainder shown as unknown |
| Entity resolution rate | Share of entity references resolved to identifiers | Above 95% |
| Side-effect assertions passing | Environment diff after repeated previews | 100%, always |
| Median preview review time | Time a system owner spends before approving | Under 60 seconds |
| Preview-to-execution gap | Elapsed time between preview and run | Under the expiry threshold |
| Undisclosed step rate | Actions executed that appeared in no preview | Under 3%, excluding recovery |
Undisclosed step rate is the metric that matters most to a reviewer, because it measures whether their approval covered what actually happened. Recovery actions are the legitimate exception and should be excluded explicitly rather than quietly.
Next step
Preview the concrete actions, then approve
BarzelOps previews a planned workflow with resolved values before anything executes, then runs it with a full action-level trace — so the plan a system owner approved is the plan you can check afterwards.
What preview cannot do
Three limits.
- 01It cannot predict recovery. Actions taken while recovering from a partial failure depend on what failed and what had already committed, and no preview produced beforehand can enumerate them.
- 02It cannot make an incorrect plan correct. A reviewer who does not know the business consequence will approve a plausible-looking plan, which is why preview must reach the system owner rather than stopping at the engineer.
- 03It cannot substitute for authorisation. A preview establishes what is intended; policy still has to decide whether it is permitted, and the two must not be conflated.
Common misconceptions
Four claims we hear regularly that do not survive contact with a real estate. Each is stated as we hear it, then corrected.
A preview showing the action names is enough for review.
It is not, because the question a reviewer is answering is almost never which operations will run — it is which customer, which amount, which recipient. A preview without resolved values looks precise and conveys nothing that changes a decision.
Preview and authorisation are the same control.
They answer different questions and are performed by different people. Policy enforcement decides whether an action is permitted given identity and thresholds; preview lets someone with business context judge whether the action is correct. A permitted action can still be entirely wrong.
If the preview was approved, the execution is covered.
Only to the extent that fidelity holds. State changes between preview and run, mid-run re-planning and recovery paths all produce actions the reviewer never saw, which is why undisclosed step rate should be measured and disclosed rather than assumed to be zero.
A preview cannot cause any harm because nothing executes.
Resolution is where this breaks. Create-if-not-exists lookups, reads that mark records as viewed, cursor advances and consumed rate-limit quota are all real effects that do not look like writes, and previewing repeatedly can exhaust budget the execution then needs.
Frequently asked questions
What is an AI workflow preview?
A rendering of the concrete actions an agent will take, with argument values and entity references resolved to real values, produced without executing anything or causing any side effect in any system consulted during resolution.
How does a preview differ from a plan?
A plan is the ordered list of intended steps. A preview is that plan with every reference resolved — the actual email address, the actual amount, the actual accounting customer with its identifier — so that a human can judge correctness rather than plausibility.
Why is preview so important for adoption?
Because the most common reason an agentic rollout stalls is that the owner of the affected system will not permit it. A preview they can read resolves that objection more reliably than any assurance about model quality, because it converts trust into review.
What makes a preview fake or misleading?
Three patterns: showing template placeholders rather than resolved values, causing side effects while resolving references, and omitting steps the agent has not planned yet without disclosing that further steps will be decided at run time.
Why are placeholders in a preview a problem?
Because the question a reviewer is answering is which customer, which amount, which recipient — not which operations will run. A preview showing send_email(to: {contact.email}) looks precise while conveying nothing that could change the decision.
How can a preview cause side effects?
Through resolution. A lookup implemented with create-if-not-exists semantics creates the record; reads can mark items as viewed, advance cursors, trigger upstream workflows or consume rate-limited quota. None of these looks like a write and all of them are real effects.
Should a preview send a test email to the requester?
No. That is an execution against a different recipient, and it will eventually reach the wrong one. A preview should render what would be sent, to whom, without dispatching anything.
What should happen when a value cannot be resolved?
It must be shown as unresolved, with the reason. A preview that fills a gap with a plausible invented value is the most dangerous form of this feature, because it manufactures confidence that has not been earned.
What is preview fidelity and what is a good level?
The share of previewed actions that match what actually executed. Above 94% is normal for stable workflows. A sustained fall below that is almost always an upstream schema or data change rather than an agent problem, which makes it a useful early warning.
Why should previews expire?
Because a preview is a prediction and state drifts. A plan previewed on Friday and approved on Monday has had three days of change behind it; re-previewing before execution costs almost nothing relative to what it prevents.
Is preview the same as authorisation?
No. Preview lets someone with business context judge whether an action is correct; policy enforcement decides whether it is permitted given identity, thresholds and approval state. A fully permitted action can still be entirely wrong, which is why both controls exist.
What is undisclosed step rate?
The share of executed actions that appeared in no preview, excluding recovery paths. It measures whether a reviewer’s approval actually covered what happened, and it should be reported rather than assumed to be zero.
Glossary
- Workflow preview
- A side-effect-free rendering of the concrete actions an agent will take, with resolved values.
- Resolved value
- A concrete argument value shown in a preview, as distinct from a template placeholder.
- Side-effect freedom
- The guarantee that producing a preview changes no state in any system.
- Create-if-not-exists
- Idempotent creation semantics that make a lookup unsafe for preview resolution.
- Explicit unknown
- A preview entry marked unresolved rather than filled with an invented value.
- Preview fidelity
- The share of previewed actions matching those actually executed.
- Plan deviation
- The recorded difference between a previewed plan and the executed sequence.
- Preview expiry
- A time limit after which a preview must be regenerated before execution.
- Undisclosed step
- An executed action that appeared in no preview, excluding recovery paths.
- Read that mutates
- An operation that changes state despite appearing to be a read, such as marking a record viewed.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · Object Management GroupBPMN 2.0 specification ↗The modelling standard business process orchestration vocabulary comes from.
- 02 · WikipediaIdempotence ↗Why safe retries require this property rather than hope.
- 03 · microservices.ioSaga pattern ↗Compensating transactions, which is all you get when distributed rollback does not exist.
- 04 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 05 · NISTNIST — AI Agent Standards Initiative ↗Identity, authorization, auditing and non-repudiation framed as prerequisites for autonomous agents.
- 06 · Chaos Engineering communityPrinciples of Chaos Engineering ↗Why deliberately breaking a system is the only way to know its failure behaviour.
- 07 · GoogleGoogle SRE — Service Level Objectives ↗Why an estate needs objectives and error budgets, not just dashboards.
- 08 · COSOCOSO Internal Control — Integrated Framework ↗The control framework auditors map financial process evidence against.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). Workflow Preview: Seeing Exactly What an Agent Will Do Before It Does It. Real Biz Digital. https://realbizdigital.net/insights/ai-workflow-preview/
Try the mechanics on a live server
To see a governed tool surface respond before you point an agent at your accounting system — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
BarzelOps is this execution layer, sold as a running product
Forty tools covering capability discovery, workflow planning, preview before execution, run, trace, pause, resume and cancel, approval request and resolution, credential validation and connector health — across accounting, CRM, email, calendar, documents, Slack and storage. Opinionated workflows ship with it: customer onboarding, invoice follow-up, lead-to-invoice, pipeline cleanup, monthly close preparation and weekly operations briefings. The Free tier runs 100 calls a day.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Free | Free | 100 calls/day · 10 core tools: plan, preview, run, trace | Proving one workflow end to end before anyone signs anything |
| Pro | $19/mo | 15,000 calls/mo · 26 tools including approvals and templates | One operator automating their own recurring procedures |
| Team | $49/mo | 50,000 calls/mo · the complete 40-tool surface | An operations team running cross-app workflows under approval |
| Enterprise | $199/mo | Unlimited calls · deployment and connector scope by agreement | Multi-team execution with audit and residency obligations |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.