Save My...

See what stops when someone disappears—and repair it before it matters.

Comment

Inspiration

Small businesses often run on invisible dependencies. One founder owns the developer account. One phone receives every authentication code. One employee knows the emergency procedure. A recovery document may even live inside the system it is supposed to recover.

These dependencies usually become visible only after someone leaves, a vendor fails, or a critical device disappears.

I built SAVE MY… to answer one urgent question before that happens:

What work stops when someone or something disappears?

Traditional continuity plans are often static documents. SAVE MY… turns continuity planning into an interactive, visual rehearsal.

What it does

SAVE MY… represents a company as a connected continuity graph containing people, roles, workflows, services, vendors, accounts, devices, documents, and recovery paths.

The product follows a simple loop:

  1. MAP — Document how the organization actually operates.
  2. BREAK — Temporarily remove a person, service, device, or vendor.
  3. REPAIR — Compare practical ways to restore the blocked work.
  4. VERIFY — Let a human review, edit, and approve the final plan.

The graph engine deterministically traces each disruption and identifies the exact critical workflows that become blocked. It does not produce an opaque AI-generated resilience score.

The application remains fully usable manually. Users can create companies, add and connect operational items, design disruption scenarios, and edit recovery plans themselves.

With native WebMCP Site Tools, an agent can investigate the structured company map, focus the visible graph, run the same deterministic simulations, and stage several repair strategies. Those proposals remain separate from the authoritative baseline until a person accepts them.

The agent can propose. The engine can calculate. Only the human can decide what becomes fact.

How I built it

SAVE MY… is built with:

  • Bun and TypeScript
  • React and Vite
  • Hono
  • PostgreSQL 17
  • Zod
  • Docker
  • Playwright and axe
  • Native WebMCP Site Tools

The page registers 18 real Site Tools through document.modelContext.registerTool(...).

These tools let an agent read bounded workspace summaries, search for exact graph entities, focus the visible interface, validate continuity paths, simulate disruptions, create company workspaces, and stage connected blueprints or recovery proposals.

The deterministic graph engine handles reachability, alternate paths, failure cascades, single points of failure, missing owners, stale recovery information, cycles, isolated items, and before/after comparisons.

I also built a custom SVG graph interface instead of using a generic node editor. Motion reveals the failure cascade step by step, while structured list alternatives, keyboard navigation, visible focus, sufficient contrast, and reduced-motion support keep the workspace accessible.

PostgreSQL provides tenant isolation and versioned persistence. Optimistic concurrency and durable idempotency protect the workspace when tools retry requests or when multiple actions operate on changing state.

Challenges I faced

Keeping agent inference separate from business truth

The hardest problem was trust.

An agent can suggest a convincing recovery plan, but it cannot know whether a backup account really works, whether an employee has accepted a responsibility, or whether a vendor agreement is still valid.

I solved this with explicit trust states, provenance, immutable before/after comparisons, and visible proposal “ghosts.” Agent-authored changes remain inferred and reversible. The product intentionally provides no tool that allows an agent to verify its own work, accept its own proposal, assign final responsibility, or delete a workspace.

Combining inference with deterministic results

Agents are useful for interpreting messy business context and suggesting creative alternatives. They should not decide graph reachability or claim that a workflow has been restored.

SAVE MY… therefore separates the responsibilities:

  • The agent structures intent and proposes options.
  • The graph engine calculates impact.
  • The human verifies facts and applies changes.

Every repair is checked against the same deterministic disruption engine before it can be presented as restoring blocked work.

Keeping Site Tools synchronized with a live application

The available workspace tools depend on the currently selected company. Switching companies while a tool call is running can otherwise produce stale results.

I built the registrations around live workspace state, cancellation, version checks, and stale-result rejection. Company-creation tools also wait until the new workspace tools are ready before handing control back to the agent.

Making a dense graph understandable

A real operational map can contain dozens of entities and relationships. Displaying everything simultaneously quickly becomes overwhelming.

The interface uses focused subgraphs, causal animation, shaped node categories, grouped alternate paths, zoom controls, structured lists, and separate baseline/scenario/proposal views to keep the graph inspectable.

What I learned

I learned that agents become substantially more useful when they operate through narrow, domain-specific tools instead of manipulating a general interface.

I also learned that good agent products need visible boundaries. Confidence should not be confused with evidence. Provenance, reversibility, deterministic validation, and human approval are not secondary safety features—they are part of the core user experience.

Most importantly, I learned that AI and deterministic software are complementary. The agent explores possibilities that would be tedious to author manually, while the graph engine provides repeatable calculations that users can inspect and trust.

What I’m proud of

  • The application provides value even when no agent is available.
  • Site Tools operate on the same visible workspace rather than a separate chatbot copy.
  • Agent proposals remain reversible and human-controlled.
  • One structured company description can become a connected operational blueprint.
  • Disruption results identify concrete blocked work instead of producing a vague score.
  • The interface supports multiple industries rather than one narrow incident type.
  • The project includes automated domain, persistence, API, responsive, accessibility, and end-to-end tests.

What’s next

The next step is to test SAVE MY… with real small-business operators and refine the process for importing their existing operational knowledge.

I would also like to add guided evidence collection, scheduled continuity rehearsals, safer integrations with business systems, and collaborative verification—while preserving the same core rule:

Agents may investigate and propose, but people remain responsible for what the business trusts.

Built With

Share this project:

Updates

Submission history