DEV Community

aditya nema
aditya nema

Posted on

Anchor — the Durable Execution Engine for Mission-Critical AI Agents. ⚓

#ai #opensource #automation #agents
💳 Agent double-charged a credit card mid-tool call?
💀 Woke up to a dead container and lost 4 hours of LLM reasoning?

When multi-step AI agents run in production—executing tasks like searching databases, calling LLM reasoning APIs, dispatching emails, or charging credit cards—server worker processes will inevitably crash. Containers experience Out-Of-Memory (OOM) kills, Kubernetes rolling redeploys, cloud spot instance preemption, and transient network dropouts.

Standard task queue architectures and current agent frameworks break down when these interruptions happen.

1. The Business Impact & Financial ROI

Unmanaged process crashes in multi-step AI workflows create severe business and financial losses:

  • Wasted Token Costs: On 1,000,000 multi-step LLM requests per month with a modest 2% container crash rate, unmanaged retries waste over $12,400/month in duplicate prompt tokens by re-evaluating 4-hour model reasoning chains from scratch.
  • Customer Double-Billing & Trust Erosion: If a worker process dies mid-step while calling a payment endpoint or sending an onboarding email, retrying from step 0 double-charges the user's card or spams their inbox with duplicate messages.
  • Cloud Infrastructure Tax: Legacy enterprise orchestrators (Temporal, AWS Step Functions) charge a $5,000+/month infrastructure tax and require hosting massive external Java/Cassandra clusters built for microservices, not non-deterministic Python LLM loops.

2. The Core Architectural Flaw in Existing Frameworks

Existing agent frameworks (LangGraph, CrewAI, AutoGen) rely on in-memory state buffers or naive Redis checkpoints.

When a worker container dies mid-step:

  1. The Uncertainty Window: Standard task queues (Celery, BullMQ) cannot determine if an external HTTP request (e.g. Stripe charge or SendGrid dispatch) succeeded before the process crashed. Blind retries cause duplicate side-effects.
  2. Zombie Worker Split-Brain Writes: If a stalled worker process experiences a 10-second GC pause and wakes up after a secondary worker has taken over, both workers write conflicting results to the database, corrupting state.

3. The Anchor Architecture: PostgreSQL-Authoritative Self-Healing

I built Anchor (an open-source Python execution engine backed by PostgreSQL/SQLite) to make AI agents 100% crash-proof without external cloud clusters.

Anchor embeds 3 core engineering mechanisms natively in SQL:

A. Atomic Two-Phase Tool Journaling (INTENT / RESULT)

Before any side-effect @anchor.tool is invoked, Anchor atomically writes a TOOL_INTENT journal entry to PostgreSQL (SELECT ... FOR UPDATE SKIP LOCKED). Upon completion, it commits TOOL_RESULT. If a container dies mid-execution, the secondary worker checks the journal on recovery—replaying completed steps in <5ms from cached outputs without re-dispatching external API calls.

B. Monotonic Epoch Token Fencing (AN001)

Every worker claim lease increments an atomic, monotonic epoch token. If a zombie worker wakes up and attempts to write to a run owned by a newer worker, Anchor blocks the write at the database constraint boundary with AN001_FENCED_WRITE.

C. Human-in-the-Loop NeedsReview Operator Queue

For non-idempotent unsafe tools (e.g. @anchor.tool(safety="unsafe")), if a crash occurs during the uncertainty window, Anchor halts the run in needs_review status. Operators can inspect the run on the Operator Console and resolve it via:

  • mark_executed: Supplies a custom JSON result payload override.
  • mark_not_executed: Authorizes the worker runner to safely retry execution from the failing step.

Demonstrates hard SIGKILL process terminations mid-workflow. Shows Anchor's worker lease expiration detection, monotonic epoch fencing (Epoch 1 → Epoch 2), and sub-second lease reclamation by a secondary worker replica without lost state.

Demonstrates hard SIGKILL process terminations mid-workflow. Shows Anchor's worker lease expiration detection, monotonic epoch fencing (Epoch 1 → Epoch 2), and sub-second lease reclamation by a secondary worker replica without lost state.

Demonstrates the raw `@anchor.tool(safety=

Demonstrates the @anchor.tool(safety="unsafe") protection protocol. When a worker process crashes mid-execution of an unsafe tool call, Anchor halts the run in needs_review status. Human operators can resolve the halt via mark_executed (which accepts a custom JSON payload result override) or mark_not_executed (which authorizes the runner to retry execution from the failing step).

4. Interactive Video Demos & Empirical Proofs

I recorded live, unedited video demonstrations of Anchor handling process crashes, unsafe tool pauses, and adversarial chaos harness runs:

👉 Watch All Live Video Demos at anchor-runtime.xyz/demo

5. Getting Started in 3 Lines of Python

No API keys or external clusters required. Install and run locally in under 60 seconds:

pip install anchor-runtime
anchor dev
Enter fullscreen mode Exit fullscreen mode

Write your agent (app.py):

import anchor, json

@anchor.tool(safety="retry_safe", naturally_idempotent=True)
async def fetch_customer(customer_id: str) -> dict:
    return {"id": customer_id, "email": "aditya@anchor.dev", "tier": "VIP"}

@anchor.tool(safety="unsafe")
async def send_welcome_email(email: str, tier: str) -> dict:
    return {"status": "sent", "to": email, "tier": tier}

@anchor.agent(name="onboarding_agent")
def decide_next_step(ctx: anchor.StepContext):
    customer = yield anchor.ToolCall("fetch_customer", {"customer_id": ctx.input["customer_id"]})
    email_res = yield anchor.ToolCall("send_welcome_email", {"email": customer["email"], "tier": customer["tier"]})
    yield anchor.Done({"status": "completed", "customer": customer, "email": email_res})

if __name__ == "__main__":
    result = anchor.run("onboarding_agent", input={"customer_id": "cust_99"})
    print(json.dumps(result, indent=2))
Enter fullscreen mode Exit fullscreen mode

🔗 Resources & Links

Top comments (0)