← Work

Braid

A shared memory so that when several people each run their own AI agent, those agents can see what the others have already decided.

Kind
In development
Role
Lead
Stack
TypeScript, Node.js, MCP, PostgreSQL + pgvector, Docker

The problem

If two people each run an AI agent, those agents still work in isolation. One can spend a session deciding something the other has no way to see, even when it directly affects the next piece of work.

Braid started from that small, specific moment: explaining the tools you use day to day, and realizing mid-sentence that your agent has zero visibility into what a teammate’s agent decided ten minutes ago.

What it does

An append-only event log sits underneath everything. Async workers distill raw session events into typed facts — decision, task, entity, question. A new fact can supersede an old one, forming a versioned chain, so both states stay queryable.

Agents connect through an MCP server with three tools: get_briefing at session start, query_facts, and commit_fact. Briefing bundles are precomputed on commit rather than assembled per request, so starting a session is a cache hit.

On every commit, a conflict engine runs cheap structural checks first: shared entity references, dependency edges into something just superseded, embedding similarity via pgvector. Only surviving pairs go to an LLM, which has to explain, in language a person can read, why the two facts actually collide. The system is tuned for high precision and low recall: a missed conflict is recoverable because the log keeps everything; a false alarm that trains people to ignore the system is not.

Access control is enforced in PostgreSQL with row-level security keyed to workspace, scope, and the caller. A bug in application code cannot leak a private fact the database itself will not return.

Three decisions

Supersession instead of mutation. Facts are never edited or deleted in place. The audit trail and staleness detection come from the same graph either way.

Structural filtering before any LLM call. Comparing every pair of facts in a workspace with a model does not scale. Graph and vector lookups are cheap and can throw away almost all non-candidates first.

Postgres + pgvector instead of a dedicated vector database. Postgres was already the system of record. One fewer store to run and keep consistent — not a benchmarked performance choice.

What’s unfinished

Braid is in active development. It is not deployed to a team yet. Scale past a handful of agents is untested; the structural-filter-before-LLM design is the part meant to keep cost from growing with every new fact.