The front page shows what Lattice does. This is the longer read — where it comes from, the bets underneath it, and the AI agent organization that builds it.
Lattice is an experiment in what application infrastructure should look like when the system is expected to change continuously, explain itself clearly, and safely include AI agents as first-class actors.
Modern applications hide their real shape behind service code, private conventions, framework-specific models and API glue. Humans can learn those conventions over time. AI agents usually cannot: they guess at schemas, call APIs without enough context, and work around state they cannot inspect or reason about directly.
Lattice takes the opposite bet: the application state itself should be the integration surface. The system should be able to describe what exists, what may be done, who may do it, and what a valid change looks like — without a hand-written SDK for every new actor, human or machine.
The original product pressure came from experience businesses — places where one person's relationship with the operator spans leases, payments, access, events, services, staff interactions, preferences, history and support.
Residential communities, coworking buildings, campuses, clubs, hospitality groups, mixed-use properties. These businesses invent new workflows constantly: a new membership bundle, lease rule, access policy, concierge service, compliance requirement, staff process. None of that should take weeks of engineering coordination — but in normal software, every new capability crosses too many seams: database schema, service code, authorization, API shape, event stream, reporting view, workflow logic, UI assumptions.
That is the broken promise Lattice is aimed at. "Just spin up a new idea" only works if the architecture makes the right path easier than the bypass. So Lattice makes platform discipline structural: a valid change goes through the same deterministic write path, the same schema validation, the same authorization model and the same projection machinery whether it was initiated by a human, a service, or an AI agent.
What if application state were structured so humans, services, and AI agents could all reason over the same model safely?
The answer Lattice is testing is a living system, not a faster deployment script: capabilities should be authorable, reviewable, reversible, observable and evolvable inside the running platform. Meetings are replaced by intent plus review — not intent alone. Human judgment stays in the loop; coordination overhead is what gets compressed.
Most platforms end up with state spread across a relational schema, a document store, an authorization engine and a search index — each with its own shape, its own migration story, and its own blind spots when anyone, human or AI, tries to reason across them.
Lattice instead models everything — business entities, their data, their relationships, their types, their operations, even authorization itself — as one graph: vertices (the entities), aspects (their data, addressable independently so each can be versioned, encrypted or migrated on its own), and links (typed, directional relationships that double as the authorization graph). That collapse buys three things a conventional stack can't:
A fourth strength appears once the platform is running: extension without fragmentation. A new capability never has to choose between bolting onto data it doesn't own and standing up its own silo. Because a vertex's data lives in independently-addressable aspects, a new package attaches its own aspects to existing vertices — an identity gains a loyalty tier the day a loyalty package installs — and links into the graph from there, inheriting everything already known about that entity without copying any of it. What's actually protected is the write path: the graph grows outward by accretion, never by replication, and every accretion passes the same gate as everything else.
The cost is real — a graph-of-everything is a less familiar shape than tables-plus-services. Closing that gap is the Refractor's whole job: it continuously projects the graph into lenses — materialized views that land in ordinary Postgres tables or NATS KV — so anything that wants a familiar relational shape gets one, kept live off the same change stream as every other reader and rebuildable from the ledger at will. You don't give up the graph to get the table. You get both, and the table is just a projection.
NATS is a lightweight, open-source messaging system — a single small Go-embeddable binary that, via JetStream, doubles as a durable event log, a key-value store and a pub/sub fabric. Lattice needed exactly that combination.
One substrate that can be a ledger, a fast KV layer and a message bus means there is no Kafka-plus-Redis-plus-broker stack to stitch together, and no three consistency models to reconcile by hand. JetStream provides all three in one dependency: ordered streams for operations and events, atomic-batch KV for the core graph, lightweight pub/sub for everything in between — all addressable through the same key and subject conventions.
The unification matters beyond convenience. The Processor's commit pipeline depends on atomic batch publish — a write lands as a whole (vertices, aspects, links, outbox event) or not at all — and NATS's atomic batch is what makes that guarantee cheap. The Refractor's lens projections depend on durable CDC consumers reading the same change stream that fed the graph, so read models can always be rebuilt from the ledger rather than drifting from it. And because NATS is a single small embeddable binary, it is also what makes Edge Lattice possible: a sovereign client node runs the same substrate locally, offline, and reconciles by revision when it reconnects — there is no separate edge stack to design.
In short: NATS isn't a queue bolted onto the side. It is the addressable, ledgered, atomically-batched foundation the rest of the architecture is built to assume.
Lattice is deliberately developed by AI agents. The agents write everything — the code, the tests, the contracts, the documentation — under a human ratification gate.
The first phases ran as a structured, human-orchestrated loop, organized with the BMAD method: analyst, architect, delivery, engineer and reviewer roles, each story implemented by a fresh agent against a self-contained brief, then hunted by independent adversarial reviewers.
Phase 3 turned that loop autonomous. A scheduled agent organization now runs the flywheel with no human starting it: surveyor roles file demand, designer roles write the designs, a steward builds behind the full gate suite, and product-owner roles exercise the shipped apps to file the next round of demand — supply and demand, self-sustaining. The human is needed for exactly two things: ratifying frozen-contract changes and settling final architectural forks. It is an active, maturing experiment — the loop still gets steered — but the trajectory is the point: the system increasingly improves itself.
The human is Andrew Solgan, and the role is architect and supervisor, not implementer: set the vision and the binding architectural decisions, freeze the data contracts, pressure-test proposals, adjudicate the agents' output, steer course. The goal is to see how far a rigorously-supervised, contract-first agentic process can carry a genuinely complex distributed system.
None of this is a marketing claim — the paper trail is versioned in the open repository: the live planning boards, 90+ design documents, and every ratification decision.