PREVIEW

The real runtime, worker, adapters, and Google certification.
GPT-5.6 receives staging tools, never commit authority.
GPT-5.6 stages a live graph while provider writes remain zero.
PREVIEW stages agent actions before anything becomes real.
Exact cross system consequences appear before approval.
Approval binds the exact graph, snapshot, policy, and order.
Approved effects are committed and independently verified.
Replay removes the risky branch from clean shadow state.
Six connected effects reveal a hidden $1.25M renewal risk.

Inspiration

The most dangerous AI agent isn't always the one that fails, sometimes it's the one that successfully does the wrong thing. An agent can have valid permissions, understand an instruction and follow it perfectly while still creating a disastrous outcome. “Move my meetings next week”, sounds safe until it moves a $1.25 million renewal beyond its deadline, emails an external buyer and shifts the connected CRM follow up.

Most agent safety systems inspect permissions, prompts or individual tool calls but the real danger often appears only after those calls combine across systems.

I kept coming back to one question: software developers can preview a deployment before it goes live, so why can’t we preview the future an agent is about to create? Worth thinking, isn't it?

The answer to that question became PREVIEW.

What it does

PREVIEW is a transactional runtime between AI agents and the tools they can change.

Instead of letting an agent immediately mutate Gmail, Calendar, CRM, files, payments or any kinda infrastructure, PREVIEW gives it an isolated copy of the world first. The agent stages its proposed actions there and then PREVIEW turns them into one immutable cross system effect graph.

The user sees the exact consequences before anything becomes real: dates, recipients, payloads, dependencies, external contacts, risk classes and what can or cannot be recovered.

The user can then:

Approve the exact staged future.
Add a constraint and replay from clean shadow state.
Abort the transaction with zero provider writes.

Replay is not presented as some sort of magical undo. It creates a new revision, applies the human correction, rebuilds the transaction and invalidates the previous approval path.

Approval is also not attached to a vague prompt. It is content bound to the exact graph, snapshot, constraints, adapter and policy versions and execution order. If that future changes, the approval is no longer valid.

After approval, deterministic adapters commit the graph, verify provider state and then produce a durable receipt reporting what succeeded, what remains and what exacxtly is unresolved.

PREVIEW does not replace human judgment. It gives human judgment a chance to happen before the damage.

How we built it

I built PREVIEW as a provider neutral TypeScript modular monolith with a separate durable worker.

The core runtime maintains shadow state with cross adapter read-your-writes. In the demo, Mail does not invent its message independently. It reads the time staged by Calendar and derives its effect from that value, making the causal relationship real rather than decorative.

Effects are immutable and sealed into a deterministic graph digest. Simulation and commit capabilities are separated, unknown mutations fail closed and commit controls are never exposed as agent tools.

GPT-5.6 is integrated through the Responses API with four strict Calendar and Mail read and stage tools. It can decide how to orchestrate the simulation and explain the result but it cannot approve, commit, classify provider semantics, verify outcomes or perform recovery. Those responsibilities remain in deterministic PREVIEW code.

The commit worker revalidates the complete observed read set before the first mutation, journals execution intent, executes in dependency aware order and then verifies each provider afterward. If the process dies after an external call, PREVIEW reconciles provider state before deciding whether a retry is safe. Ambiguous irreversible actions are never blindly repeated.

The public Judge Mode uses isolated synthetic Calendar, Mail and CRM providers so anyone can test the complete flow without credentials. Separately, I built capability scoped Google Calendar and Gmail adapters with OAuth and certified a real Calendar move, Gmail draft and Gmail send through the same prepare, approve, execute and verify boundary

Challenges we ran into

The hardest part was making the simulation truthful across systems. A UI can easily draw arrows between cards but proving that a later effect actually consumed an earlier staged value required runtime owned provenance and strict causal validation.

The second challenge was approval. Binding approval only to a prompt or graph was not enough. I had to include every part capable of changing the meaning of execution and then ensure replay invalidated the old path completely.

The third challenge was failure after external mutation. A worker can crash after a provider accepts a request but before the result is recorded. retrying blindly could duplicate an email or payment. PREVIEW therefore distinguishes safe retries from outcomes that require reconciliation.

The final challenge was honesty. “Universal undo” makes a great slogan but it is not real. Sent emails, transferred money and human reactions cannot always be reversed. PREVIEW reports reversible, compensable, residual and unresolved outcomes instead of pretending everything is atomic.

Accomplishments that we're proud of

PREVIEW is not a disconnected visual mock. Every Judge Mode action calls the actual runtime, approval authority, worker, adapters, journal and receipt path.

The final repository passes all 17 production builds, strict typechecks, zero warning linting and 91 tests covering adapter conformance, tampering, drift, replay invalidation, crashes, duplicate workers, lease expiry, reconciliation, compensation and ambiguous delivery.

The public Live Sandbox also performs a real GPT-5.6 Responses API run, creates a sealed Calendar to Mail graph and proves that provider state remains untouched.

Codex worked like my second engineer throughout Build Week. I used it across the kernel, adapters, recovery testing, UI, debugging, documentation, deployment and final verification, while continuously challenging decisions and making sure I understood what entered the repository.

What we learned

Agent safety cannot stop at asking, “Is this tool call allowed?”

The stronger question is, “What exact future will this collection of actions create and is that the future the human intended?”

Instructions can look safe. Consequences are where the danger lives.

What's next for PREVIEW

Customer operations is only the demonstration package. PREVIEW is designed to become a horizontal transaction boundary for any system where agents can create consequential change.

The next step is an SDK or MCP compatible gateway with certified adapters for communications, files, payments, infrastructure and business systems. Above that runtime, teams could build approval routing, reusable constraints, organizational policies, audit receipts and incident recovery.

PREVIEW will never promise universal undo. Its promise is narrower and more useful:

Stage, inspect, replay, commit, verify and recover what is actually recoverable.

Wherever an agent can change reality, PREVIEW should become the boundary before it does.