Back to browse
GitHub Repository

Semantic side-effect tracking for AI agents.

7 starsRust

Effect-log – Semantic crash recovery for AI agent side effects

by xudong963·Mar 14, 2026·2 points·1 comment

AI Analysis

●●●BangerBig BrainWizardryZero to One

Five effect kinds drive recovery strategy — irreversible writes escalate to humans, never re-execute.

Strengths
  • EffectKind enum (ReadOnly, IdempotentWrite, Compensatable, IrreversibleWrite, ReadThenWrite) drives all recovery logic.
  • Middleware exists for LangGraph, OpenAI Agents SDK, and CrewAI — ships with runnable examples.
  • Recovery is a pure function fitting on one screen — elegant, auditable, no hidden state.
Weaknesses
  • Python bindings exist but Rust is the primary language — may limit adoption.
  • Requires agents to declare effect kinds upfront — adds friction to quick prototyping.
Category
Target Audience

Developers building AI agents that take real-world actions

Similar To

LangGraph · CrewAI · Temporal

Post Description

Your AI agent sends an email in step 3, crashes before step 4 records it, restarts, and sends the email again. This is the exactly-once side effect problem.

effect-log is an embeddable Rust library (with Python bindings) that solves this with two ideas:

1. Every tool declares an *effect kind* at registration: ReadOnly, IdempotentWrite, Compensatable, IrreversibleWrite, or ReadThenWrite.

2. A write-ahead log records intent before execution and completion after. On recovery, the effect kind drives the strategy — reads replay for fresh data, idempotent writes safely retry, irreversible writes return sealed results (never re-execute), and unknown states escalate to human review.

The entire recovery logic is a pure function that fits on one screen.

I'd love feedback on: Is five effect kinds the right number? Are there tool types that don't fit? What failure modes have you hit with agents taking real-world actions?

Similar Projects