This makes a lot of sense. Recording execution + replay is exactly what’s missing once you move past simple logging.
One thing I’ve found tricky in similar setups is making sure the trace is captured before side-effects happen, otherwise replay can lie to you. If you get that boundary right, the prod → replay → fix → verify loop becomes much more reliable.
I mostly worry about the gap between a correct plan and execution-time behavior — especially when tools touch the filesystem or OS APIs. Even a single malformed argument can have irreversible effects.
Totally agree these guardrails are non-trivial, but it’s great to see the project thinking in this direction.
One thing Cloudflare Workers gets right is strong execution isolation.
When self-hosting, what’s the failure model if user code misbehaves?
Is there any runtime-level guardrail or tracing for side-effects?
Asking because execution is usually where things go sideways.
How do you handle execution-time guarantees?
For example: when an MCP tool call touches the filesystem or network,
do you validate + log the side-effects before execution?
I’ve seen audits fail not at planning, but at the exact tool-call boundary.
One thing I’ve been bitten by with desktop agents is execution-time safety:
the plan is correct, but a single malformed path or OS call causes real damage.
Do you enforce any guardrails at the tool boundary
(e.g. path sandboxing, network allowlists, dry-run / replay)?
FailCore is intentionally not an agent framework, planner, or sandbox.
It sits strictly at the execution boundary and focuses on two things:
1) blocking unsafe side effects before they happen
2) recording enough execution trace to replay or audit failures later
The goal isn’t to make agents smarter, but to make their failures
observable, reproducible, and boring.
If people are curious, the DESIGN.md goes deeper into why this is done
at the Python runtime level instead of kernel-level isolation (eBPF, VMs, etc.),
and what trade-offs that implies.
Thanks, that clarifies it. The checkpoint-based cancellation and the sync-vs-async locking model differences were exactly what I was trying to understand.
That makes sense — thanks for clarifying. Framing it as “zero infra ownership, just a reviewer convenience” really helps explain where this fits compared to ArgoCD-style previews.
That makes sense. I was mostly curious about what explicit trade-offs the author chose beyond “generation only” — e.g. fonts, Unicode, images, compression, etc.
Would be interesting to see a concrete “not supported” list from the author.
For me, one signal has been whether the problems remain interesting even when progress is slow.
When working on complex systems (like anything involving long-running automation or agents),
most of the real work happens in areas that don’t show up in demos: defining “done”,
handling partial failures, and keeping behavior predictable.
If those problems are still worth thinking about after repeated failures,
I take that as a sign the work itself is worth continuing.
I'm experimenting with a local-first autonomous agent system on Windows.
The interesting part for me hasn't been the UI or demos, but the engineering problems:
how planning compares to step-by-step tool-calling, how state drifts over long tasks,
and how fragile things get once you add retries and recovery logic.
Mostly learning by breaking things and trying to make the system more predictable.
One thing I’ve found tricky in similar setups is making sure the trace is captured before side-effects happen, otherwise replay can lie to you. If you get that boundary right, the prod → replay → fix → verify loop becomes much more reliable.
Really like the direction.