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.

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.

Nice idea. How does this compare to running ephemeral preview environments via ArgoCD or Helmfile today?

Interesting angle. How do you decide what becomes persistent memory vs transient context? Is there any eviction or decay model?

How does this differ from asyncio.Queue in terms of backpressure or cancellation semantics?

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.

3KB is wild. What features did you intentionally leave out to get this small?

Exactly. I’ve also found that once those constraints become boring, that’s usually when the work itself is done — or not worth doing anymore.

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.