Anchor

Transactional memory for AI agents, built on CockroachDB.

Inspiration

An agent that processes refunds claims a task, calls the payment API, and the call succeeds. The worker crashes before it records that the refund happened. Nothing remembers the call went out, so the task gets claimed again, and the same customer is refunded twice.

That is not a reasoning failure. The agent decided correctly. The plumbing underneath it let one decision turn into two side effects. Agent frameworks give you a loop, not a database, so this kind of bug is not rare. It is the default.

We built Anchor so that does not happen. A crashed task cannot fire twice. Two workers cannot claim the same task. A worker that dies does not take its task down with it. An agent does not act on a memory the real world has already moved past.

What it does

Anchor is a reliability layer for agent memory and task state, built on CockroachDB.

A crashed task cannot cause a duplicate side effect. Two workers cannot claim the same task. A stalled claim cannot orphan a task forever. A recalled memory is checked against live state before it is returned, so an agent never acts on stale data with confidence.

It speaks plain HTTP, so it works with LangGraph, CrewAI, or a hand rolled orchestration loop, whatever an engineer already runs.

How we built it

The Engine is a Go service. It is the only thing that holds a CockroachDB connection. Every client, including the Python client we shipped, talks to it over HTTP with a bearer API key.

CockroachDB backs everything: organizations, agents, tasks, an idempotency ledger, and a memories table with a VECTOR column and a VECTOR INDEX for the recall path.

We proved the guarantees under real conditions with OrderDesk, a three agent LangGraph demo, plus four scripted chaos scenarios that each print their own pass or fail assertion.

We also built an MCP observability agent that talks to CockroachDB Cloud's own Managed MCP Server to answer real operational questions, like flagged task count, pending effect count, and queue depth per pool, without touching the Engine's read write database credential.

For deployment, the Engine runs on ECS Fargate behind CloudFront. The database credential lives in Secrets Manager. Nothing else touches the database directly.

Challenges we ran into

Time lol. I submitted this a few minutes to the deadline

Fargate over Lambda was not a style choice. The reclaim sweep that frees abandoned tasks is a background goroutine ticker, and Lambda freezes execution environments between invocations, so a frozen sweep is a broken guarantee.

Secrets Manager held the database credential as a JSON blob. Pulling it into the task definition without the key extraction suffix on the ARN handed pgx an unparseable value, and it silently fell back to a local socket path instead of failing loudly.

CloudFront strips the Authorization header by default, which would have quietly broken every authenticated call if we had not caught it before launch.

Docker Desktop also dropped its daemon on us more than once mid session, unrelated to the code, just something to restart and move past.

Accomplishments that we're proud of

Anchor is live at a real public HTTPS URL, backed by a real CockroachDB Cloud cluster, not a local demo. All four chaos scenarios pass against it. The observability agent is proven end to end against CockroachDB's actual Managed MCP Server, not a stand in. Nothing here is "should work," it is curled, tested, and running.

What we learned

A lot of what people call agent reliability is really missing database guarantees: exactly once semantics, race free claiming, a source of truth for what is live versus what an embedding remembers.

Infrastructure gotchas rarely announce themselves. A stripped header or a JSON shaped secret fails quietly. Proving something end to end over the real network beats trusting that it should work.

What's next for Anchor

Make this big.

Built With

• amazon-web-services
• cockroachdb
• golang
• python