Protecting weeks of agent setup from resets, overwrites, and machine moves

Phase 1, soft-launch gated. Solo product architecture, design, and build: web dashboard, native Mac app, local backup engine, and cloud sync.

Power users spend days tuning agents with instructions, memory, skills, principles, configs, and local files. One reset, overwrite, machine swap, or platform change can wipe out that accumulated work. Unerase exists for the recovery moment: what changed, what is safe to restore, and who is allowed to approve it.

The customer problem

Power users now run fleets of agents. They tune instructions, teach workflows, install skills, write principles, connect tools, and accumulate memory over days or weeks. That work becomes part of the agent's identity, but it lives in ordinary folders and platform-specific state.

The current fallback is either Git or a manual zip. Git is powerful, but it is not agent-aware: restores are intimidating, diffs are noisy, and agents can rewrite their own files in ways that make history hard to trust. Manual zips are worse. They are easy to forget, hard to inspect, and useless when a user needs one exact file back at 11pm.

Unerase's wedge is simple: everyone else is trying to make agents remember more. Unerase makes it safe when the agent, tool, or platform forgets everything.

The constraint

The hard part was not storing files. The hard part was designing the boundary between two users of the same system: the human who owns the agent, and the agent that wants to protect itself.

An agent should be able to create a checkpoint before risky work. It should be able to inspect backup health and request a restore candidate. But if it can apply a restore by itself, the product has handed destructive power to the thing it is supposed to protect against.

That led to the core invariant: agent-callable, not agent-autonomous. Agents can ask, observe, and create. Humans approve destructive actions on the local device, against a diff the server cannot fake.

The second challenge was product simplicity. The target buyer is technical, but the surface has to be designed for the least-technical user imaginable. A backup product cannot ask users to reason through storage classes, symlink policy, secret handling, and retention rules before their first snapshot. The first-run experience has to answer one question: "Am I safe yet?"

The third challenge was trust. Unerase backs up sensitive agent material, including configuration and credential files when the user chooses the default. The server stores metadata and encrypted snapshot pointers, never plaintext brain content. That limit has to show up in the interface as a promise the product can actually enforce.

What we built

The customer-facing product has two required halves. The web app at erase.ai handles account, billing, devices, backup history, version timelines, and settings. The native Mac app owns anything that touches local plaintext: workspace discovery, first backup, manual snapshots, scheduled backups, restore preview, local approval, restore apply, recovery-key display, and local health checks.

Underneath that surface is a local backup engine built around encrypted restic snapshots, metadata sync, and crash-safe restore with rollback. Agents interact through scoped local capabilities: backup:create, backup:list, and restore:request. There is no restore:apply scope.

What we learned

The central lesson was that an agent can be a first-class user without being an autonomous one. The design move is not to hide the boundary. It is to make the boundary the product's trust contract.

The second lesson was that information architecture should tell the truth about the data model. Unerase keys an agent instance by name and device. The same named agent on two machines is not magically one "logical agent" unless the system can enforce that relationship. Refusing that abstraction made the dashboard less clever and more honest.

The third lesson was that trust-critical products earn confidence by saying what they cannot do. The web app does not decrypt brain content. The server cannot recover the user's key. A restore requested from the cloud still waits for local approval. Those are not limitations to bury. They are reasons to trust the system.

How AI shaped the work

Unerase was built with AI as an operating partner, not as a vague productivity claim. AI helped pressure-test the product thesis, compare launch gates, review architecture decisions, generate implementation plans, and turn dogfood findings into sharper specs. The product itself also became the test case: before an agent edits its own memory, Unerase should be the safety layer that lets it checkpoint, inspect, and recover.

That loop changed the design. Using agents to build a tool that protects agents made the permission boundary feel practical, not theoretical. The same question kept coming back: if an AI collaborator can help create the product, what authority should it have over the product's state? The final answer was strict and durable: it can ask, observe, and create. It cannot destroy.

Current status

Unerase is in Phase 1 and soft-launch gated. The engine has been dogfood-validated on real agent workspaces; the web dashboard and auth boundary exist; the Mac app is the local control surface for backup and restore. The public Founding-100 launch remains gated on operational readiness, including cost-model validation, unit economics, and signed Mac distribution.

The case study headline is not "we built a backup app." It is "we designed a permission model for AI systems that need to protect themselves without being allowed to destroy themselves."