What is a spine?
The smallest unit of structure that turns a pile of agents and surfaces into a system you can govern.
The one-sentence answer
A spine is a small, stable, typed core that everything else touches only through typed operations.
That’s the whole idea. Every consequence below — audit, revert, replay, surface independence, evaluatable change — is downstream of that single commitment.
What lives inside it
Three things, and only three things:
- Typed entities. Five to fifteen nouns, drawn from how the people who use the system actually talk. Not
Item, notRecord;Project,Timeline,Asset. The names are the project’s vocabulary. - A database. Postgres, by default. Boring, well-understood, well-instrumented. We host or hand it over.
- An event log. A typed, append-only record of every command ever attempted, written in the same transaction as the state change it captures.
What it isn’t
- It is not a microservice mesh. There’s one schema, one log, one set of operations.
- It is not a god object. Most of the work lives in the operation layer above it; the entities themselves are dumb and stable.
- It is not a knowledge graph. Triples are a fine modelling tool and a bad governance primitive.
- It is not “a backend”. A backend without the operation discipline is the thing that breaks when the agent gets root.
Why this shape
The spine is engineered for one property: when an agent acts on production, every step it takes is typed, attributable, and reversible — not by post-hoc logging, but by the structure of the contracts it called through. That property is what makes agent work durable, and it doesn’t emerge accidentally. It’s the consequence of the one commitment at the top of this page.