EffectFence

Your swarm doesn't need more memory. It needs a causal fence around tool side effects.

⚡ effectfence — THE STORM 1,000 attempts to charge order #777 ($49.00): concurrent racers + late retries… ACTUAL EXECUTIONS : 1 ← the whole point served sealed receipt : 995 told to stand down : 4 elapsed : 22.33ms 💰 double-charges prevented this run: $48,951.00 ✅ ONE execution. Every other attempt was fenced, replayed, or refused.

The storm above is one action, many racers. The harder case isdifferentagents makingcontradictorydecisions on the same production resource — the coordination failure now reported across production multi-agent systems (~a third of 2026 multi-agent incidents). Three autonomous SRE agents react to one latency spike:

Agent A (autoscaler): scale node pool UP ADMITTED. Fence leased cluster:prod-us-east-1 — executing kubectl scale up. DONE. EffectCert minted — verify() -> true Agent B (cost-optimizer): scale the same pool DOWN REFUSED before kubectl ran: read-set for metrics:prod-us-east-1 is stale: B decided on seq 0, world is at seq 1. Agent C (deploy-bot): roll the deployment BACK C's causal view is concurrent with A's: true -> escalated to a human instead of corrupting the cluster. Actions proposed: 3 executed: 1 cluster: intended, not corrupted.

Each agent was individually correct for the state it read. Run concurrently without coordination, all threekubectlcalls fire and the cluster ends in a state none of them intended — the $100M outage. The fence lets exactly one act, refuses the other twobeforetheir side effect runs, and tells each one why.

Nothing above is mocked — every call is the real crate API.

EffectFence is a causal concurrency fence for multi-agent tool calls. When more than one agent (or retry, or re-dispatch) can end up trying to run the same side-effecting operation — charge a card, send a payout, provision a resource — EffectFence guarantees exactly one attempt ever executes it: same-instant races are decided by an atomic compare-exchange reservation, and late duplicates get the recorded outcome replayed instead of running again. Every effect that does run gets a content-addressed certificate chained to whatever it was causally built on.

It ships as a Rust library (effectfence::fence) and as a stdioMCPserver exposing three tools —fence_prepare,fence_commit,fence_abort— so agents can route side-effecting tool calls through the fence instead of racing each other directly.

┌ intent gate ──────── already done? → Replay(recorded cert) [do NOT run] │ in flight / failed? → rejected [do NOT run] EffectRequest┤ ├ read-set check ───── dependency moved? → ReadSetStale [do NOT run] │ └ domain CAS ────────── lost the race? → DomainRace [do NOT run] │ └ Fresh(ticket) → run the effect → commit_effect_cert → EffectCert ↘ abort_effect (failed; fenced until reconciled)

Every committed effect becomes anEffectCert: a SHA-256 content hash over{intent, parent, domain, seq, tool, args, result, vector_clock, read_set, agent}, chained to aparentcert hash for causal lineage. Two certs with the same hash are, by definition, records of the same effect —EffectCert::verify()recomputes the hash and confirms it hasn't been tampered with or hand-built incorrectly.

This is anin-memory, single-processfence — state lives behind anArcand is lost on restart. That's enough to close races and duplicates between concurrent threads/tasks in one gateway process. Two things it deliberately does not do (yet):

- Cross-process/cross-restart fencing.A horizontally scaled gateway needs the same intent/domain/read-set model backed by a shared store (e.g.SETNX+CAS in Redis, or an optimistic version column in Postgres) — the types here are meant to carry over directly to that backend.
- Enforcement.The fence protects agents that route their effects through it; it cannot stop an agent that bypasses it entirely. Deploy it at the one choke point your agents share (the gateway process that owns the tools).

Memory is bounded: finished outcomes expire after a configurable TTL (FenceConfig::result_ttl, swept byEffectFence::sweep), queries never create tracking state, and domain counters are tiny and manually evictable (evict_domain).

use effectfence::fence::{ prepare_effect_fence, commit_effect_cert, Admission, EffectFence, EffectRequest, VectorClock, }; let fence = EffectFence::new(); let req = EffectRequest { intent: "charge:order-123".into(), // same action -> same intent, always parent: None, // hash of the cert this follows, if any domain: "order:123".into(), // contention scope tool: "charge_card".into(), args: serde_json::json!({"amount_cents": 1999}), read_set: vec![], // other domains this decision cross-checked agent: "agent-a".into(), known_clock: VectorClock::new(), }; match prepare_effect_fence(&fence, req)? { Admission::Fresh(prepared) => { // This attempt won. Actually run the charge... let cert = commit_effect_cert( &fence, prepared, serde_json::json!({"charge_id": "ch_123"}), )?; assert!(cert.verify()); // (on failure: abort_effect(&fence, prepared, "why") instead) } Admission::Replay(cert) => { // This exact action already ran -- use cert.result, charge nothing. } }

A concurrent duplicate of the same intent getsErr(FenceError::IntentInFlight); a same-instant race on the domain getsErr(FenceError::DomainRace); either way it must not run the effect.

Try it in 10 seconds (nothing installs, nothing real fires)

cargo install effectfence # or: npx -y effectfence demo effectfence demo

Twelve agents reach for one $49 charge at the same instant. You'll see it hit a built-in serverraw— 12 duplicate charges — then thesame twelve calls behind the fence: exactly 1. This binary is talking to itself, so no real call fires and you need no server of your own to see the point.

── Act 1: the raw server, no fence ── DISTINCT effects : 12 PROVEN DOUBLE-FIRE ── Act 2: the SAME twelve calls, behind the fence ── DISTINCT effects : 1 12 callers, 12 clean answers, one execution

First: does YOUR stack actually double-fire? (probe it)

Before you install a fence, prove you need one — on your own server, not our demo.probeis a bare MCP client. Point it at any MCP server, and it fires N byte-identical calls at one toolconcurrently— the twin-caller race that happens the instant two agents reach for the same action — then reports how manydistincteffects actually landed:

effectfence probe --tool charge_card --args '{"amount":4900}' --calls 12 -- npx -y @your-org/your-mcp-server

EffectFence probe — twin-caller race report -------------------------------------------- identical calls : 12 DISTINCT effects : 12 PROVEN DOUBLE-FIRE. 12 byte-identical calls produced 12 DIFFERENT results. Each distinct result is a separate real execution of one intended action — the duplicate side effect you cannot take back.

It firesonlythe one tool you name, with the exact arguments you supply — it never enumerates and hammers a server blindly. And it is honest about what it can see: distinct results are undeniable proof of double-execution; identical results are reported asinconclusive from the response, never as a zero it can't prove.

Then re-run the same probethrough the fenceand watchDISTINCT effectsdrop to1:

effectfence probe --tool charge_card --args '{"amount":4900}' --calls 12 -- effectfence wrap -- npx -y @your-org/your-mcp-server

That is the whole pitch in two commands: the footprints, then the lock.

Quickstart: wrap an existing MCP server (start here)

The fastest way to use EffectFence is to put itin front of a tool server you already run. Agents don't have to remember to call anything — every tool call is fenced automatically:

agent/client ──MCP──> effectfence wrap ──MCP──> your real tool server

Then wrap whatever server owns your dangerous tools:

effectfence wrap -- npx -y @your-org/your-mcp-server

The tool list is mirrored 1:1 from the child (same names, schemas, docs), so nothing in your agent changes. What changes: identical duplicate calls — same tool, same arguments — execute the childonce; later duplicates get the recorded result replayed, and concurrent identical calls are refused rather than double-firing.

One-paste recipe: fence a cluster-mutating server

The case this exists for — several agents withkubectlon the same cluster.

claude mcp add k8s-fenced -- effectfence wrap -- npx -y kubernetes-mcp-server

Cursor(~/.cursor/mcp.json)or Claude Desktop(claude_desktop_config.json):

{ "mcpServers": { "k8s-fenced": { "command": "effectfence", "args": ["wrap", "--", "npx", "-y", "kubernetes-mcp-server"] } } }

Swapkubernetes-mcp-serverfor whichever server holds your write-bearing tools — cloud APIs, deploy tooling, a payments server. Point every agent at the fenced name and remove their access to the raw one; the fence is only a fence if it is the only door.

Watch it work withfence_stats(see below) —replayedandrefusedare the duplicate executions that did not happen.

Tools only for now (no resource/prompt passthrough). Intent is derived fromhash(tool + canonical args), sobyte-identicalarguments are treated as the same action — an agent that varies a timestamp in its arguments defeats dedup, and that direction failssafe: the call runs, nothing is corrupted. State is in-memory per wrap process; run one fenced gateway per set of production-mutating tools.

Quickstart: MCP server (explicit fencing)

Use this when you want agents to fence deliberately — richer control (read_set,parent,known_clock) thanwrapderives automatically.

Listed in theofficial MCP Registryasmcp-name: io.github.aurumflux20/effectfence

cargo build --release # binary at ./target/release/effectfence

claude mcp add effectfence -- effectfence

{ "mcpServers": { "effectfence": { "command": "effectfence" } } }

{ "mcpServers": { "effectfence": { "command": "effectfence" } } }

effectfence since boot: admitted=1 replayed=995 refused(stale=0 race=4 in-flight=0 failed=0) total=1000 prevented=999

cargo test # unit tests + chaos tests cargo clippy --all-targets

python3 tools/fencescan.py /path/to/your-mcp-server

Same problem, other runtime.once(pip install once-kernel) is the Python idempotency kernel built on the same idea: a side effect runs exactly once under retries, webhook redelivery, and concurrent workers. It goes further on durability — a Postgres store, heartbeat leases with fence tokens so a stale worker can't resurrect after its lease is reclaimed, and RFC 8785 canonical payload fingerprints.

The libraries are free and stay free. If you want help applying them to a codebase that already moves money — a fixed-scope audit of every side-effecting path, storm-tested, with a CI test that keeps it fenced — seeSUPPORT.mdor emailhello@aurumflux.co.

Create crafted UI components inspired by the best 21st.dev design engineers.