Ghost does the clicking. You approve anything that can’t be undone.
Show it a task once and it runs on its own — opening pages, filling forms, moving data between systems that don’t talk to each other. What makes it different from a script: it stops before anything irreversible, proves each step actually worked, and leaves a record nobody can quietly edit.
Early stage and openly so — the execution engine works end to end. Screen recording is still being built. Nothing below claims otherwise.
- 01Open order formnavigate0.8s
Opened the order page in a real Chrome browser.
- 02Enter customer namefill0.2s
Typed "Ada Lovelace" into the Full name box — found by its label, not its position on screen.
- 03Submit orderclick
Clicking this actually places the order, so Ghost stopped. It will not click until a person approves.
ApproveRejectexecution is blocked until someone decides - 04Confirm submissionverify
Will check the page really says "Order submitted". If it doesn't, the run is marked failed.
The work this replaces
A purchase order arrives as a PDF. Someone opens it, retypes twelve line items into the ERP, checks the total matches, saves it, and files the PDF in the right folder.
Then does it again. Forty times a day.
What Ghost does with it
Ghost does the retyping. It stops before saving, shows you the twelve lines it is about to write and the screenshot of where it will write them, and waits.
You click Approve. It saves, confirms the total on screen matches, files the PDF, and writes down everything it touched.
So is this just browser automation?
Driving a browser is the easy part — Playwright and Selenium have done it for years, and a dozen no-code tools wrap them. The browser is how Ghost reaches a system, not what Ghost is.
Being exact about it: today every step runs through a browser. Calling a system’s API directly is the better path where one exists, and the pieces for it are designed in — an apiCall step type, the connector model, and the rules that decide an API action is sensitive all exist already. The executor behind them is not written yet, so Ghost does not call external APIs on your behalf. The step is deliberately not offered in the editor until it does, because a step that silently does nothing while the run reports success is worse than no step at all.
Which matters less than it sounds, because the systems this work actually lives in — supplier portals, ERPs, insurer sites, internal admin panels — mostly have no API, or have one nobody has integrated. The browser is what reaches them all.
What Ghost is, is the layer between something wanting to act and the action landing in a real business system.
A person
Clicks Run in the UI, or puts the workflow on a schedule.
Another system
A script, a cron job, or a webhook, over the HTTP API with a scoped, revocable credential.
An AI agent
Over HTTP or MCP. It can propose a run and read what happened. It cannot approve one — there is no endpoint for it, and the attempt returns 403. That is how an agent gets real reach into a business system without unchecked authority over it.
All three come in through the same gates. Proposing a run and approving one are separate powers, and only a human holds the second.
Built like a workflow engine, not a script runner
A script that crashes halfway leaves you guessing whether it half-worked. That is tolerable for a data pipeline and not tolerable for something that moves money and places orders, so the parts below are the actual substrate rather than features layered on later.
Versioned, immutable definitions
A run executes the exact version it started with. Editing a workflow never rewrites what a past run did, so the audit trail keeps meaning something a year later.
Resumes without re-acting
Every run keeps an append-only, hash-chained journal of what completed. A worker that dies is replaced by one that reads the journal and continues after the last finished step — it does not re-submit an order that already went through.
Undo is a phase, not a cleanup script
Reversing a completed run is modelled as its own direction of travel, with its own approval gate and its own events. A reversed step reads as reversed, not as one that never happened.
Ambiguity becomes an incident
When a step's effect genuinely cannot be known — the worker died mid-payment — the step is marked unknown and the run raises an incident. Retry risks double-charging, skipping risks a silent no-op, and neither is Ghost's call to make.
Concurrency caps
Limit how many runs of a workflow may touch a system at once. A workflow triggered by every inbound email should not put ten browser sessions into the same ERP.
Separation of duties
Per workflow, the person who triggered a run can be barred from approving it. Rejecting is never restricted — anyone watching a runaway run must be able to stop it.
How it works
Seven things happen to every workflow, in this order.
- 01You do the task oncebeing builtClick through it in your browser while Ghost watches — every click, keystroke, and page it lands on.
- 02It becomes a list of stepsNot a video. A readable list: "open this page", "type this in the Full name box", "click Submit". You can edit any line.
- 03Ghost runs the stepsA real Chrome browser on a server does the clicking and typing, finding buttons by their label rather than screen position.
- 04It stops before anything irreversibleSubmit, send, pay, delete — Ghost pauses and waits for you to click Approve. It cannot proceed on its own.
- 05It checks the resultAfter a step, Ghost confirms what it expected actually happened — "the page now says Order submitted" — or the run fails.
- 06It writes down what it didEvery step, screenshot, and approval goes into a log that is chained so an edited or deleted entry shows up as tampering.
- 07It can walk changes backUndoable actions get undone on request. When Ghost can't tell whether something landed, it stops and asks instead of guessing.
What it will never do on its own
Ghost runs unattended right up until an action it can’t take back. Then it stops. The list of actions that stop it is written in code as a fixed rule — an AI model never decides whether something is safe enough to skip asking you.
- Submit
- Send
- Pay
- Delete
- Overwrite
A run that’s waiting stays waiting. It doesn’t time out into proceeding, and an approval that sits too long expires rather than firing a payment days later.
What if it clicks the wrong thing?
It finds buttons by their visible label, not by screen position, so a moved button is still found and a renamed one fails loudly instead of clicking whatever is now in that spot.
What if the server dies mid-run?
Each run keeps a journal of completed steps. The next worker reads it and resumes after the last one that finished. Where it genuinely can't tell whether an action landed, it stops and asks rather than risking a double-submit.
Can someone edit the history?
Each log entry is hashed together with the previous one. Editing or deleting an old entry breaks the chain, and the Audit page recomputes it and points at where it broke.
Can it be undone?
Reversible steps can be walked back on request, and the log records the reversal as its own event rather than pretending the original never happened.
What’s actually built
Working today, and what isn’t yet. Listed plainly so nothing here has to be walked back later.
Runs steps in a real browser
A server-side Chrome opens pages, fills fields, and clicks buttons — finding them by their visible label, so a redesigned page doesn't silently break the run.
Stops for approval
Anything that submits, sends, pays, or deletes halts the run. A person clicks Approve or Reject. Which actions count is a fixed rule in code — no model decides it.
Checks its own work
A step can assert what should be true afterwards. If the page doesn't say what it should, the run fails instead of reporting success.
Screenshots every step
You can see exactly what the browser was looking at when it did each thing, and what it looked like after.
Keeps a log you can't quietly edit
Each entry is hashed together with the one before it. Change or delete an old entry and the chain stops matching — the Audit page checks this and tells you where it broke.
Survives crashes without redoing work
Each run keeps a journal of what already finished. If a worker dies mid-run, the next one reads the journal and picks up after the last completed step — it won't re-submit an order that already went through.
Takes work from other programs
An HTTP and MCP surface lets an agent or script propose a run. It still can't skip the approval step — proposing and executing are separate.
Recording your screen — not yet
The browser extension that captures a session exists; turning a raw capture into a clean step list is the piece still being built. Today you write or edit the steps directly.
Direct connections to other apps — not yet
Gmail, Salesforce, QuickBooks and the like, so Ghost can use their APIs instead of clicking through their websites. The database schema is in place; none are wired up yet.
Next.js · Node worker · Postgres · Redis · Playwright · AGPL-3.0
Watch a run stop at its approval
The walkthrough follows the bundled demo workflow one step at a time — including the moment it refuses to click Submit.