IntelliAvatar

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.

Really like the direction.

Makes sense, thanks for the clarification.

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.

Nice project.

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.

Really like the local-first + MCP angle.

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.

This looks great.

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)?

Curious how you’re thinking about this.

One clarification that may help set expectations:

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.

Full formal verification is rare, but partial guarantees at execution boundaries are very practical — especially for systems that act autonomously.

A runtime layer for AI agents that enforces execution boundaries: traces, replay, and a hard “no” when something unsafe is about to run.

Observability is step one. The hard part is what the system is allowed to do once you observe it.

Thanks, that clarifies it. The checkpoint-based cancellation and the sync-vs-async locking model differences were exactly what I was trying to understand.