SPIRAL
SPIRAL
How it worksExploreArchitectureDocs
Solutions
For FoundersFor EngineersFor PMs
GitHub
Join the beta
Shared memory for AI coding agents

You already
decided this.
Your agent
forgot.

Spiral keeps every decision your project has made somewhere your agents have to read before they write. New chat, new editor, same answers — and when an agent tries to undo one, Spiral refuses the write and names the decision it broke.

Join the betaSee it catch one
spiral_check_conflictsclaude-4a2f
decision.auth_strategy

Switch user auth to session cookies

  • 1Time
  • 2Rules
  • 3Blast radiusnot reached
  • 4Meaningnot reached
  • 5Reviewnot reached

Works with Cursor, Claude Code and Windsurf — the tools you already use. No SDK.

One week, one project, one agent

  1. Monday

    You and your agent work out how logins should work. It builds it. It works.

  2. Thursday

    New chat. It has never heard of Monday, so it solves logins again — a different way.

  3. Later

    Both versions are in there. Neither looks wrong on its own. Nothing ever flagged it.

Nobody in that story ever said no.

So, plainly

Spiral is where your project's decisions live, and your agent has to go through it to change one.

Not an editor
Keep the one you have.
Not a model
It doesn't write your code.
Not a wiki
Nothing for you to keep up to date.

Close the tab. Nothing resets.

Your decisions don't live inside the chat, so they don't die with it. Spiral sits behind whichever editor you open, and every session starts by reading what the project has already settled.

A new chat
Starts caught up
The agent opens the session by reading what the project already decided. You don't explain your app again.
A different editor
Same project
Cursor today, Claude Code tomorrow. The decisions aren't stored in the tool, so there is nothing to move across.
Six months on
Still says why
Every decision kept the reason it was made and the date it was made on. You can see why the project is shaped like this.

All of which is the easy part. Remembering a decision does nothing if the agent is still free to ignore it.

Connect an agent
One governed turn, end to end

Watch an agent
get told no.

The real five-call sequence, in the order the server enforces it.

MCP sessiondemo/spiralclaude-4a2fpaused
  1. spiral_start_sessionagent=claude-4a2f
    Session open

Phase: Implementation. 7 facts, 7 edges in scope.

Shared ledger
  • arch-auth-tokensdecision

    Token-based auth, not session cookies

  • arch-storage-primarydecision

    Postgres is the primary store

  • arch-graph-read-gateconstraint

    Graph reads go through the gate

  • arch-token-rotationdecision

    Refresh tokens rotate on every use

1/8

Refused with a reason, then corrected — inside one turn, before any code was written.

Five checks run cheapest-first, so most writes never reach a model. How the cascade works

It checks against this.

Every decision your project has settled, and what each one rests on. Decisions can be replaced, but never quietly — the old one stays, marked.

How decisions are stored
demo / spiral — knowledge map
The Spiral knowledge map: a project's decisions and rules laid out in layers, with lines showing which ones depend on which.

You can start with nothing but an idea.

No repository, no code, nothing to import. Describe what you want to build and the first decisions come out of the conversation.

  1. 01

    Describe

    A paragraph about what you want to build. That is the whole input.

  2. 02

    Research

    Live search across the web, Hacker News and public repositories, every turn.

  3. 03

    Map

    What others already built, and what you'll have to work around, laid out so you can throw out what doesn't apply.

  4. 04

    Keep

    Whatever you keep becomes the first decisions every agent is held to.

Start from an idea

Or publish the whole map.

Public projects show up on Explore, and anyone can fork one — every decision and every link between them, copied into an account of their own.

See what other people builtThe open format
resolve_projectevolve_contextsync_contextget_context_mdget_project_graphcomplete_featurecheckpointmemory_upsert_fact_v1memory_query_v1memory_check_conflicts_v1list_facts_v1list_conflicts_v1resolve_conflict_v1continuous_extractionspiral_start_sessionspiral_search_contextspiral_declare_intentspiral_propose_decisionspiral_check_conflictsspiral_commit_decisionspiral_finalize_turnspiral_reconcile_syncspiral_sync_statusspiral_decision_memory

No SDK.
Just MCP.

If your agent supports MCP, it already speaks this — nothing to install in your project. 24 tools on one server: Cursor, Claude Code, Windsurf.

Connect an agent

Does it actually catch them?

Scored over 180 real cases — 110 that genuinely contradict something and 70 that don't. Not a synthetic benchmark, and the column we do worst on is on the wall with the rest.

Real conflicts it caught
107 / 110recall 0.97 · 95% CI [0.92, 0.99]
Times it was right to refuse
107 / 109precision 0.98 · 95% CI [0.94, 0.99]
Harmless writes blocked
2 / 70the cost of being wrong in your favour
Caught, then mislabelled
22%our worst number

That last column is the one we like least. It means the refusal was correct — the write did contradict something — but the explanation named the wrong kind of contradiction. Methodology

The agent doesn't get a vote.

It sends a proposal and receives a verdict. It never holds the graph, and it cannot report its own result — the answer is read back from the server's ledger.

To ask
92 tokens
The proposal and the keys it touches. That is the whole request.
To answer
3.0k tokens
A verdict, a type, a recommended action, and the rule it broke.
Server side
20 seconds
Five cascade stages and a cross-encoder your context never sees.
Embeddings sent
0
Vectors stay in the database, where they are useful.

Measured with tiktoken/o200k_base over the same tools an agent uses, across one refused decision and one committed one. Re-run it yourself: scripts/demo_governed_loop.py.

In progress — agent track record

Personality
you can't
fake.

Not a persona you write for an agent — a profile computed from what it actually did. What it has authority on, whether it has been right, and what it already committed to.

Attribution ships today. The registry that resolves those rows into one identity is in progress, and spiral_describe_agent is not callable yet.

spiral_describe_agentnot callable yet
decision.auth_strategyclaude-7b1c

Migrate auth to stateless JWT

who has already worked on this?
cursor-3f2aderived from the ledger
Expertise
auth — 47 facts, 6 decisions
primary author on this subject
Reliability
3 of 51 facts superseded
no conflicts lost
Stance
server-side sessions, not JWT
revocation requirement · Jul 12 · disagreed with claude-7b1c

What isn't built yet.

Everything above this line runs today.

  • Agent registry

    In progress

    Attribution is per row; nothing resolves it into one durable identity yet.

  • Asking about another agent

    Next

    The data is in the ledger. The read surface is not built.

  • Locks that actually block

    Next

    Recorded and surfaced to people, but the write path does not enforce them.

  • Trust scores that change outcomes

    Planned

    Tracked per agent, but they do not yet influence a conflict decision.

Memory that
pushes back.

Point the agent you already use at it, and stop deciding the same thing twice.