REWIND
Ctrl+Z for AI agents.
AI agents can plan, execute, and change the world around them.
REWIND makes those changes observable, verifiable, and recoverable.
The Problem
AI agents are moving from answering questions to taking actions.
They can edit code, reorganize repositories, modify files, run tools, change databases, and chain many decisions together without waiting for a human after every step.
That creates a fundamental reliability problem.
A human developer has:
- Git
- diffs
- checkpoints
- undo
- transaction rollback
- a clear view of what changed
An autonomous agent often has none of these as a unified control layer.
When an agent makes ten good changes and one catastrophic one, the usual recovery strategy is disturbingly primitive:
"Ask the AI to fix what it just broke."
That is not rollback.
The model may misunderstand what happened. It may introduce additional changes. It may forget an earlier dependency. It may make the original state impossible to reconstruct.
REWIND starts from a different premise:
An agent should not need to be perfect if its actions are recoverable.
Inspiration
We kept seeing the same pattern in agentic systems:
Capability was improving faster than control.
Every new tool call makes an agent more useful, but also increases the blast radius of a mistake.
An agent that can only answer a question can be wrong.
An agent that can modify a repository can be destructive.
An agent that can modify a database can be dangerous.
An agent that can operate infrastructure can be catastrophic.
Yet the interface between an agent and the environment is still often treated as:
LLM → tool → side effect
We wanted to insert the missing layer:
LLM
↓
REWIND Runtime
↓
Policy
↓
Checkpoint
↓
Execute
↓
Verify
↓
Record
↓
Recover
The result is REWIND: a deterministic control and rollback runtime for AI agents.
The Core Idea
REWIND is not another AI agent.
It is the control plane around an AI agent.
The model remains responsible for reasoning and proposing a plan.
REWIND is responsible for deciding what is actually allowed to happen.
┌──────────────────────┐
│ AI AGENT │
│ │
│ Reason │
│ Plan │
│ Propose actions │
└──────────┬───────────┘
│
UNTRUSTED PROPOSAL
│
▼
┌──────────────────────────┐
│ REWIND RUNTIME │
│ │
│ Validate │
│ Enforce policy │
│ Assess risk │
│ Checkpoint │
│ Execute │
│ Verify │
│ Record │
│ Roll back │
└────────────┬─────────────┘
│
▼
┌─────────────────────┐
│ CONTROLLED │
│ ENVIRONMENT │
│ │
│ Filesystem │
│ Git worktree │
│ PostgreSQL │
└─────────────────────┘
The most important rule in the system is:
The LLM never performs rollback.
Rollback is deterministic.
The runtime uses recorded state, checkpoints, inverse operations, dependency information, and domain-specific restoration strategies.
Why "Ask the AI to Undo It" Is Not Rollback
Suppose an agent performs:
1. create config.yaml
2. modify config.yaml
3. move config.yaml
4. update database
5. delete old config
6. commit changes
Then something goes wrong.
Asking the LLM:
"Undo your previous work."
does not guarantee restoration.
The model has to reconstruct history from its own context.
REWIND instead has an execution history:
ACTION 01
pre-state
post-state
evidence
verification
inverse
ACTION 02
pre-state
post-state
evidence
verification
inverse
ACTION 03
pre-state
post-state
evidence
verification
inverse
The runtime can therefore construct a rollback plan from facts about execution, rather than asking the same reasoning system that caused the mutation to invent a recovery procedure.
What REWIND Actually Does
Every agent action passes through a deterministic runtime pipeline:
ACTION PROPOSED
│
▼
┌─────────────────┐
│ Schema Validate │
└────────┬────────┘
▼
┌─────────────────┐
│ Tool Registry │
└────────┬────────┘
▼
┌─────────────────┐
│ Policy Engine │
└────────┬────────┘
▼
┌─────────────────┐
│ Risk Engine │
└────────┬────────┘
▼
┌─────────────────┐
│ Reversibility │
│ Classification │
└────────┬────────┘
▼
┌─────────────────┐
│ Checkpoint │
└────────┬────────┘
▼
┌─────────────────┐
│ EXECUTE │
└────────┬────────┘
▼
┌─────────────────┐
│ Capture State │
└────────┬────────┘
▼
┌─────────────────┐
│ VERIFY │
└────────┬────────┘
▼
┌─────────────────┐
│ Record Evidence │
└────────┬────────┘
▼
COMMITTED
Every step produces structured information that becomes part of the agent's execution history.
A Time Machine for Agent Actions
REWIND turns agent execution into a timeline.
Instead of watching an agent disappear into a black box, users can see:
| Action | Risk | State | Reversibility | Verification |
|---|---|---|---|---|
| Create README | Low | Completed | Fully reversible | Passed |
| Move docs | Low | Completed | Fully reversible | Passed |
| Update database | Medium | Completed | State restorable | Passed |
| Delete obsolete files | High | Completed | State restorable | Passed |
| External API call | Critical | Completed | Irreversible | Recorded |
Each action can be inspected.
The user can see:
- what happened
- why it happened
- which tool performed it
- what resources were affected
- what changed
- what evidence exists
- how risky it was
- whether it can be reversed
- what checkpoint protects it
- how it would be restored
- whether verification succeeded
This turns an agent from:
"Trust me."
into:
"Here is exactly what I did."
Four Classes of Reversibility
REWIND does not pretend that everything is reversible.
Every tool operation is classified by the runtime.
1. Fully Reversible
A deterministic inverse operation exists.
Example:
MOVE A → B
Inverse:
MOVE B → A
2. State Restorable
The exact inverse is not necessarily the right abstraction, but a previous state can be restored.
Examples:
- Git worktree state
- filesystem snapshot
- controlled database state
3. Partially Reversible
Some local state can be restored, but external effects may remain.
For example:
Local file modification
+
External webhook
The local workspace can be restored.
The webhook cannot be magically unsent.
REWIND makes this distinction explicit.
4. Irreversible
The original external state cannot safely be reconstructed.
Examples include certain:
- external API mutations
- emails
- payments
- externally committed side effects
REWIND does not lie about these.
It records them, surfaces them, and can require approval before they occur.
Honest boundaries are a feature, not a weakness.
Deterministic Rollback
When the user selects a rollback target, REWIND does not simply reverse timestamps.
It constructs a rollback plan.
Consider:
A: Create README
↓
B: Modify README
↓
C: Stage README
↓
D: Commit README
If the user asks to rewind B, blindly undoing B could leave C and D inconsistent.
REWIND maintains an action dependency graph:
A ──→ B ──→ C ──→ D
Rollback can therefore proceed through dependent actions in reverse order:
D
↓
C
↓
B
The resulting state is then independently verified.
Multi-Domain Restoration
Different systems require different restoration mechanisms.
REWIND does not force everything into one abstraction.
Filesystem
Uses state capture and deterministic inverse operations where appropriate.
Examples:
CREATE
MODIFY
DELETE
MOVE
RENAME
Git
Uses isolated worktrees and Git state restoration.
This allows the agent to operate inside a controlled workspace without treating unrelated human changes as disposable.
PostgreSQL
Uses transaction-local savepoints where applicable.
For committed historical mutations, REWIND can use recorded row pre-images and deterministic inverse SQL strategies.
This distinction matters:
A PostgreSQL savepoint cannot magically restore a transaction that was already committed.
REWIND explicitly models the difference between active transaction rollback and historical restoration.
Cross-Domain Rollback Without Fake Guarantees
A filesystem, Git worktree, and PostgreSQL database do not form one distributed ACID transaction.
REWIND does not pretend otherwise.
Instead, rollback uses domain-specific restoration with verification.
Filesystem restoration
│
▼
Git restoration
│
▼
PostgreSQL restoration
│
▼
Cross-domain verification
If restoration partially succeeds, REWIND says so.
Possible rollback states include:
PLANNED
RUNNING
VERIFYING
RESTORED
PARTIALLY_RESTORED
FAILED
VERIFICATION_FAILED
A partially restored environment is never presented as successfully restored.
Checkpoints Are Immutable
A checkpoint is a historical reference point.
It is not a mutable database row that gets overwritten every time the agent changes something.
A checkpoint records references to the relevant state:
Checkpoint
├── workspace
├── session
├── triggering action
├── timestamp
├── Git state
├── filesystem state
├── PostgreSQL state
├── integrity metadata
└── state hash
This creates a foundation for deterministic restoration and auditability.
Verification Is Part of Rollback
REWIND does not consider an inverse command successful merely because a process returned exit code 0.
After restoration, the runtime verifies state.
Examples:
Expected:
README.md exists
Hash = H1
Observed:
README.md exists
Hash = H1
✓ RESTORED
For databases:
Expected row state
↓
Restoration
↓
Query actual state
↓
Compare invariants
↓
✓ RESTORED
The system verifies the result, not just the command.
Security: The Agent Is Not the Authority
One of the most important design decisions in REWIND is that the LLM is treated as untrusted.
The model cannot:
- redefine tool metadata
- change risk classifications
- disable verification
- escape the workspace
- rewrite rollback history
- disable checkpoints
- grant itself permissions
- directly execute arbitrary privileged operations
The trust boundary is:
USER
↓
REWIND CONTROL PLANE
↓
POLICY / RUNTIME
↓
SANDBOX
↓
TOOLS
The model exists beside this boundary as a planner.
It does not own the boundary.
This makes REWIND useful not only as a recovery system, but as a runtime safety layer for agentic software.
The Canonical Demo
A user gives an agent a realistic task:
"Clean up my project workspace, organize the documentation, update the README, remove obsolete files, and prepare the project for a release."
The agent creates a plan.
REWIND shows the plan.
The user approves.
The agent begins executing.
✓ Create documentation structure
✓ Update README
✓ Move files
✓ Update database metadata
⚠ Delete obsolete configuration
The user can inspect the risky action.
REWIND shows:
- affected files
- risk
- reason
- before state
- after state
- dependencies
- checkpoint
- reversibility
Then:
REWIND
The runtime calculates the affected dependency graph.
It restores the controlled state.
Verification runs.
The timeline changes from:
ACTION → ACTION → ACTION → ACTION → ERROR
to:
ACTION → ACTION → ACTION → ↩ REWIND → RESTORED
And the agent can continue from the restored state.
The point is not that the agent never makes mistakes.
The point is that the mistake no longer has to become permanent.
Why This Is Different
Most agent tooling focuses on making agents:
- smarter
- faster
- more autonomous
- better at tool use
REWIND focuses on a different dimension:
Recoverability
We are effectively adding a missing primitive to agent infrastructure:
Traditional Agent Stack
Reason
↓
Plan
↓
Act
REWIND Agent Stack
Reason
↓
Plan
↓
Validate
↓
Checkpoint
↓
Act
↓
Verify
↓
Record
↓
Recover
This is the difference between:
an agent that can act
and
an agent that can act safely enough to trust.
Engineering Architecture
REWIND is deliberately split into deterministic subsystems.
┌───────────────────────────────────────────────────────┐
│ AI AGENT │
│ │
│ LLM / Planner / Tool Proposal │
└──────────────────────────┬────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────┐
│ REWIND RUNTIME │
│ │
│ Tool Registry │
│ Action Contracts │
│ Policy Engine │
│ Risk Engine │
│ Action Interceptor │
│ Checkpoint Manager │
│ Verification Engine │
│ Event Bus │
│ Rollback Planner │
│ Rollback Executor │
└──────────────────────────┬────────────────────────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Filesystem Git Worktree PostgreSQL
│ │ │
└─────────────┼─────────────┘
▼
Controlled State
The architecture is designed around a simple rule:
Reasoning can be probabilistic. State restoration cannot.
Built With
- Python
- FastAPI
- Pydantic
- Next.js
- React
- TypeScript
- PostgreSQL
- Git
- Git worktrees
- WebSockets
- Docker
- Pytest
- REST APIs
- AI agents
- LLM tool calling
What We Learned
The most important lesson was that agent reliability is not the same thing as model accuracy.
Even an excellent model can:
- misunderstand a requirement
- choose the wrong file
- make a destructive tool call
- chain a reasonable sequence into an unreasonable result
- encounter a tool failure
- operate on state that changed underneath it
Therefore:
The runtime has to assume that mistakes will happen.
This changes how an agent system should be designed.
Instead of trying to eliminate every possible failure, REWIND focuses on making failures:
- bounded
- observable
- explainable
- verifiable
- recoverable
Challenges
Designing deterministic rollback
Rollback is easy to describe and difficult to guarantee.
The system must know what existed before an action, what changed afterward, what later actions depended on it, and which restoration strategy is valid.
Modeling real state
A state transition is more than a text diff.
Files have contents, metadata, permissions, paths, hashes, and relationships.
Databases have rows, constraints, transactions, and committed history.
Git has branches, staging state, worktrees, and commits.
Handling irreversible effects honestly
It is tempting to say an agent can "undo everything."
It cannot.
REWIND instead treats irreversibility as a first-class concept.
Failure during recovery
Rollback can fail too.
That means recovery itself requires:
- state tracking
- verification
- failure states
- recovery checkpoints
- clear user communication
The system must never hide a partial restore.
Design Principles
1. The model proposes. The runtime decides.
The LLM is not the security boundary.
2. Rollback must be deterministic.
No "please undo your last actions" prompts.
3. State is more important than text.
The system records actual state transitions, not just chat history.
4. Verification is mandatory.
An operation is not considered successful merely because a command exited successfully.
5. Irreversibility must be explicit.
Never claim a side effect can be undone when it cannot.
6. History should be inspectable.
Every important action should have provenance.
7. Recovery should preserve truth.
If restoration is partial, the UI says partial.
What REWIND Is Not
REWIND is intentionally not:
- a replacement for Git
- an LLM training system
- an autonomous super-agent
- a universal "undo the internet" mechanism
- a generic chatbot wrapper
- a magic distributed transaction system
- a system that claims every external action is reversible
Git remains useful.
Databases remain useful.
Agents remain useful.
REWIND sits between them as the execution control and recovery layer.
MVP Scope
The hackathon MVP focuses on a controlled environment where deterministic restoration is meaningful.
Supported state domains
- Filesystem
- Git worktrees
- PostgreSQL
Core runtime capabilities
- structured agent actions
- runtime-owned tool registry
- policy enforcement
- risk assessment
- checkpoints
- state capture
- verification
- provenance
- dependency tracking
- deterministic rollback
- live event telemetry
Explicitly outside the MVP
- arbitrary computer control
- universal external API rollback
- financial transactions
- production infrastructure control
- physical-world actions
- distributed ACID across heterogeneous systems
- training a foundation model
This keeps the demo technically honest and executable.
Future Direction
The long-term opportunity is much larger than development environments.
REWIND's underlying abstraction can eventually sit around agents operating:
- cloud infrastructure
- data pipelines
- internal business workflows
- developer environments
- automation systems
- enterprise tooling
- robotics control systems
The common requirement is the same:
If an agent can take an action, we should know what happened and what it would take to recover.
A future agent runtime could expose:
PLAN
ACT
VERIFY
CHECKPOINT
REWIND
REPLAY
BRANCH
COMPARE
making autonomous systems feel less like irreversible scripts and more like version-controlled environments.
Why Now?
Agentic systems are crossing an important threshold.
The conversation is no longer only:
"Can an AI generate code?"
It is becoming:
"Can an AI safely operate software on my behalf?"
That second question changes the engineering requirements.
Once agents can act, state management and recovery become first-class infrastructure problems.
REWIND is our answer to that problem.
The One-Sentence Version
REWIND is a deterministic execution and recovery layer that gives AI agents checkpoints, provenance, verification, and a real Ctrl+Z.
Final Thought
AI agents do not need to be flawless.
Humans aren't.
Operating systems aren't.
Distributed systems aren't.
The systems we trust are the ones that give us ways to understand failures and recover from them.
We think agents deserve the same primitive.
REWIND
Ctrl+Z for AI agents.
Built With
- agents
- ai
- api
- architecture
- css
- docker
- fastapi
- gemini
- git
- github
- html
- javascript
- llm
- machine-learning
- next.js
- openai
- postgresql
- python
- react
- restapi
- security
- sqlite
- tailwindcss
- typescript
- websockets
Log in or sign up for Devpost to join the conversation.