Your app already knows why it failed. Scritch turns that into a fix your user can act on.

A live run of the real agent

A live install of the same agent your workspace runs, on a sample invoicing app. It picks up the failure, reads what the app never surfaced, asks you the one thing only you can answer, and confirms you can carry on, while you wait rather than after you have gone. It needs no error monitoring to do this. Connect yours and it reads that too.

POST /api/invoices/1043
→ 422 Unprocessable Entity
{ "error": "validation_failed" }

POST /api/contacts/import
→ 207 Multi-Status
{ "imported": 198, "failed": 42, "rows": null }

POST /api/avatar
→ 415 Unsupported Media Type
{ "error": "unsupported_format", "accept": ["image/jpeg", "image/webp"], "max_px": 64 }

How it works

1. 1

   It reads, first

   Read-only tools you register run unattended: the server's real response, the rules your form never surfaced, and whatever your Sentry, status page, auth provider or repository already knows. Each one is your own credential, scoped to reading and nothing else.

2. 2

   It asks only what it cannot find

   Ambiguous dates in a CSV could be day-first or month-first, and no tool knows which, so it asks once, in plain words.

3. 3

   It changes nothing without you

   Any tool that writes stops for approval, showing the exact effect and what can be undone.

4. 4

   It proves the fix

   Recovery is declared by a postcondition check, never by the model saying so.

5. 5

   It hands off what it cannot fix

   Repair needs a pack you wrote for that failure. For anything else it explains the failure in plain words, hands the person a reference to quote, and gives support the whole trail behind it. Connect Linear, Jira, Zendesk or Intercom and the handoff opens a ticket there automatically. It can also post the handoff to Slack or Discord, so the right people see it without anyone re-explaining the problem from scratch.

One hook where the error message used to go

The whole integration is an npm package and a hook. scritch-react reports the failure and hands back a plain sentence and a verdict; you render it in your own components. The panel is text, never a widget you have to theme around.

import { useRecoverableTask, useGuidance } from "scritch-react";

function SaveButton({ draft }: { draft: Draft }) {
  const { incident, run } = useRecoverableTask({ code: "draft.save.rejected" });
  const guidance = useGuidance(incident);

  return (
    <>
      <button onClick={() => run(() => api.saveDraft(draft))}>Save</button>

      {/* Your toast, your styling. The hook only returns text. */}
      {guidance.message && (
        <Toast tone={guidance.userCanFix ? "action" : "info"}>
          {guidance.message}
        </Toast>
      )}
    </>
  );
}

What the agent can actually do

A small set of real tools, each with one job, grouped by what it is for. You decide which run on their own and which stop for you, and the model can only propose what is on this list.

Convert & transform

It fixes the file instead of telling the user to

Your endpoint takes JPEG or WebP. The person uploaded a PNG. Instead of an error that sends them off to find a converter, the agent converts the image itself, behind hard size and pixel limits, and re-attaches a file your endpoint accepts. It always asks you first, because it is changing what gets stored.

headshot.png

PNGRejected

headshot.jpg

JPEGAccepted

The same photo, re-encoded to a format the upload accepts.

convert_upload: defineTool({
  risk: "confirm",                 // always stops for a person
  run: async ({ to }, { state }) => {
    // convertImage is fenced: byte + pixel caps, format allowlist.
    const out = await convertImage(state.upload.bytes, { to });
    state.upload = { ...state.upload, format: to, bytes: out.bytes };
    return { converted: true, format: to };
  },
})

It answers your user in their language

A blocked person in Rotterdam or Osaka reads the explanation in their own words, not in English with an apology attached. The agent takes the language from the browser (navigator.language) or a locale your app passes, as a BCP-47 tag, and writes the recovery in it. Your console, the evidence trail and every escalation stay in English, so your team reads one language while your users read theirs.

The reply-language toggle on the live demo above runs this for real. In a live install there is no toggle: the SDK reads the language off the request.

Pay only for recoveries

One flat rate for each recovery the agent actually made, with no per-seat fees and no monthly minimum. Start with a run of free recoveries, then a 14-day trial when you add a card. Set a spend cap and a bill can never surprise you.

The questions your security reviewer will ask

Who this is for

B2B software where a blocked user costs a support ticket: integrations, onboarding, imports, billing, anything with a form a server can refuse.

Not an error monitor. If you want exceptions grouped and alerted, you already have Sentry, and this reads from it rather than replacing it.

Every recovery is a ticket your team never sees

A blocked user used to mean a support email and someone waiting for a reply. Now the person gets unstuck in the moment, in your app, and your team just sees that it happened. The failures that generate the angriest tickets (a rejected upload, an expired session, a form that refused them for a rule it never showed) are the ones the agent handles first.