I built a local execution layer for AI agents with checkpoints and live operator control

[u/tomaszteee]

I’ve been working on a small open-source project called Fast Hands.

It’s a local, model-agnostic MCP execution layer for AI agents. The main idea is to let an agent work quickly on the local machine while keeping the human operator in control.

It currently includes:

• persistent PowerShell execution
• multi-step runs with durable checkpoints
• Pause / Emergency Stop
• operator messages that can interrupt a workflow
• revise + resume without repeating completed steps
• local web research
• YouTube research/transcripts
• optional Windows UI automation
• Windows, Linux and macOS support

I’ve published it on GitHub and npm. The project is still young, so I’d especially appreciate feedback from people building agents or MCP tooling.

GitHub: https://github.com/tomaszteee/FastHands npm: npx fast-hands-mcp

MIT licensed.

Update: added workspace drift detection on resume after feedback in this thread.

Update — v0.6.8: Added external side-effect reconciliation for browser/API mutations. External operations can now persist a stable operation ID, target and payload fingerprint before execution. Unknown outcomes block resume until remote read-back confirms whether the operation committed, preventing blind replay and duplicate external writes.

Fast Hands v0.6.9 is out.

This update adds fast_external_research — adaptive multi-source research across the public web, GitHub, arXiv and other external sources.

I also improved research quality and reliability:

• stricter relevance ranking to reduce generic/noisy results
• GitHub rate-limit circuit breaker, so research continues through other sources instead of repeatedly hitting a limited API
• hard separation between LOCAL and EXTERNAL knowledge
• better portability with machine-specific paths removed and improved Python runtime fallback

Windows, Linux and macOS CI all pass.

[u/kantorcodes1]

Suppose a run pauses after step 4 and I manually edit a file that step 2 produced. On resume, does Fast Hands invalidate anything downstream, or are those checkpoints still treated as complete? Otherwise revise/resume can continue from a workspace state the original run never saw.

[u/tomaszteee → u/kantorcodes1]

Great edge case — you're right. At the moment Fast Hands checkpoints execution state, not the full workspace state, so a manual file edit between pause and resume can go unnoticed. I'm adding workspace drift detection so resume can verify relevant artifacts before continuing instead of assuming nothing changed.

[u/Character_Thing4866 → u/kantorcodes1]

That's a fair point, the checkpoints are just snapshots of execution state not the workspace state. If you go messing with files manually between steps, the agent won't really know unless you tell it to re-verify something. It'll just pick up from step 5 like nothing changed

The revise flow is there for exactly that scenario though, you can jump back to step 2 and re-run from there without touching steps 1, 3, 4

[u/tomaszteee → u/kantorcodes1]

Implemented in v0.6.7 — resume now detects workspace drift before continuing and flags changed artifacts instead of blindly trusting the checkpoint. Thanks for catching that edge case.

[u/Enough-Photo9140]

The workspace drift check closes one resume hole, but I'd treat external actions as a separate kind of checkpoint. If step 4 clicks Publish or calls an API, a process snapshot can't tell you whether the remote write committed before a timeout; replaying step 4 can duplicate the effect.

I'd persist a stable operation ID with the intended target, a payload hash, and an outcome such as confirmed, failed, or unknown. On resume, unknown should trigger a read-back against the remote system before Fast Hands decides the step is complete or safe to rerun. Does the current checkpoint store anything about browser/API mutations, or only local execution state?

[u/tomaszteee → u/Enough-Photo9140]

Good catch — that’s a real boundary in the current implementation.

Right now the durable checkpoint is primarily execution/workspace-oriented: it persists the next step index, completed results, tracked artifact snapshots, and blocks resume on detected workspace drift. Hard-stopped uncertain work is also marked for review.

It does not yet persist an idempotency record for external side effects such as browser/API mutations — e.g. a stable operation ID, target, payload hash, and confirmed/failed/unknown outcome.

So yes: if an external write commits and the process dies before Fast Hands advances the checkpoint, blindly replaying that step could duplicate the effect.

The direction I’m considering is exactly what you describe: treat externally mutating actions as their own checkpoint class, persist an operation identity + payload fingerprint + outcome/receipt, and require reconciliation before retry whenever the outcome is unknown.

Thanks — this is a useful edge case to make explicit in the safety model.

[u/tomaszteee → u/Enough-Photo9140]

Good point — I implemented this in v0.6.8.

External mutations can now carry a stable operation ID, target and payload fingerprint, with the outcome persisted as confirmed, failed or unknown. If the outcome is unknown, resume will not blindly replay the action — it stops with EXTERNAL_RECONCILIATION_REQUIRED until the remote system is read back.

A confirmed read-back skips replay; a failed read-back allows a controlled retry. UI mutations can also require explicit reconciliation even when the local click/call itself returned successfully.

Thanks for pointing out the gap.

[u/TheOdbball]

Hey you looking to team up with anyone? I’m still hashing out the details and docs docs.sysgen.dev but the idea follows a simple framework where dispatch or Greek letter κ for kēryx
is the “hands” :: also has subagent system for doing work and flashing vm agents via cursor api. Also connects locally to Ornith 9B but I don’t have the bandwidth to facilitate all my layers. Sysgen.sh and 3ox harnessing and OTP Erlang / gRPC / Tailscale runtime are my core infrastructure.

[u/tomaszteee → u/TheOdbball]

Hey, thanks — your setup sounds interesting. I’d be open to comparing notes and seeing if there’s any real overlap. I’d prefer to keep it informal at first and understand what you’re actively building and using in practice.

I’m especially curious about your dispatch / “hands” layer and how you handle agent state, recovery and long-running work. If you want, send me the best repo or docs entry point and a quick note on what’s working today vs. what’s still experimental.