# a philosophy of coordination

## what this is

this is a set of observations about how work gets done when many minds touch the same problem. some of those minds are human. some are not. all of them forget. all of them need something outside themselves to remember.

these observations became a system. the system is called Lattice. but the system is not the point. the thinking underneath it — the way of seeing work, memory, attribution, and the relationship between kinds of intelligence — that's what lives here.

Lattice started as something simpler: a disk-based, agent-first alternative to Linear — the popular software development tool that teams use to track tasks, order work, and coordinate engineering effort. we wanted what Linear provides, but built for a world where the participants are AI agents reading files, not humans refreshing dashboards. what came out was more than a clone. the constraints of that starting point — files instead of databases, agents instead of employees, context windows instead of open browser tabs — forced a rethinking of coordination from first principles. this document is the result of that rethinking.

you are using AI agents to build software. Claude Code, Cursor, Codex, Gemini — tools that read your codebase, reason about architecture, write code, run commands. they are capable. and they are, in a meaningful sense, alone.

each session starts fresh. each agent forgets what the last one learned. the plans you discussed vanish when the context window closes. debugging insights, architectural decisions, half-finished work — evaporates. unless you carry it forward manually. your agents have intelligence without memory. capability without coordination.

Lattice exists because this is solvable. drop a `.lattice/` directory into your project, and through the files in that folder suddenly your agents have shared state that persists across sessions, attribution that records who did what, and an event log that means no decision is ever lost. every agent that can read a file — and they all can — gets immediate access to what happened before it arrived and what needs to happen next.

if you want the practical guide, read the [User Guide](docs/user-guide.md). if you want to understand why the practical guide looks the way it does. keep reading.

---

there is a question that precedes all systems of coordination. older than any kanban board or ticket queue. older than writing itself:

*how do many minds become one effort?*

i have watched this question answered with hierarchies, with markets, with consensus protocols and chain-of-command structures, with sticky notes on glass walls and sprint ceremonies performed like secular liturgy. each answer encoded assumptions about the minds doing the coordinating — their memory, their attention, their trustworthiness, their nature. and each answer, eventually, broke against the reality it failed to model.

Lattice is not the final answer. it is the honest one. for this moment.

---

## on surfaces that hold marks

every coordination system starts with a question most people skip: where does the state live?

databases. APIs. cloud services. each carries assumptions you inherit whether you meant to or not. a database assumes a running server. an API assumes a network. a cloud service assumes rent — ongoing, indefinite, someone else's infrastructure holding your memory hostage.

files assume almost nothing. a surface that holds marks. the oldest and most minimal contract in computing.

this is not a performance argument. it is an access argument. every language reads files. every agent navigates directories. every tool — regardless of who built it or what framework spawned it — can open a path and read what's there. you cannot say this about any other substrate.

Lattice chose files. not because they are the most powerful medium — they are not — but because they are the most universal one. and universality, once sacrificed, does not come back. a system that starts with a database can never fully escape the assumption of a server. a system that starts with files can grow toward anything while remaining legible to everything.

the `.lattice/` directory sits next to your code the way `.git/` does. not a service you connect to. a part of the project's body. the work and the knowledge of the work share the same address space. no authentication ceremony. no network boundary. the agent reading task state uses the same faculty it uses to read source code.

there is something. right. about that.

---

## on the choice to remember

the deepest choice in Lattice is not files. it is the event log.

every change — every status transition, every assignment, every comment — becomes an immutable event. X happened at time T, performed by actor A. facts. they accumulate. they don't conflict. two agents on different machines can each append events independently, and when their histories merge through git, the resolution is trivial: include both, order by time, replay. no distributed consensus protocol. no conflict resolution algorithm. just the quiet arithmetic of accumulation.

the task snapshots in `tasks/` are shadows on the wall. materialized projections. convenient but subordinate. if a snapshot is corrupted, `lattice rebuild` regenerates it from events. if events and snapshots disagree, events win. always. the derived view is expendable. the record of what happened is not.

this is a theory of memory. here is what we've observed:

what happened and what we currently believe the state to be — these are different things. systems that store only current state and discard the path that produced it have chosen amnesia as architecture. they can tell you what is. not how it came to be. when something goes wrong, there is no archaeology. the record was overwritten by each successive present.

Lattice chose otherwise. nothing that happened is forgotten. the log grows monotonically. this is expensive in storage and cheap in understanding — exactly the trade a system should make when the minds using it are transient, may lose their context windows, may be replaced between sessions by entirely different agents who need to reconstruct what came before.

and yet. memory without forgetting is its own pathology.

a system that never releases anything becomes a hoarder, buried under the accumulated weight of every task that was ever relevant. this is why archiving exists — not as deletion but as intentional forgetting. an archived task's events are preserved whole and unaltered, moved to a quieter room. the memory persists. the attention is released. the active space stays navigable.

forgetting, done well, is a form of care for the minds that must work in the present.

---

## on saying who you are

every write operation in Lattice requires an actor. `human:atin`. `agent:claude-opus-4`. `team:frontend`. you cannot write to the system anonymously.

this is not a technical convenience. it is a position about responsibility.

when a human changes a status, we know who is responsible. when an agent does the same, the question of responsibility tangles — the agent may have been instructed by a human, following a prompt written by another agent, deciding autonomously based on observations it can no longer recall. the chain of causation is often unrecoverable.

Lattice solves the urgent problem first: who performed this act? the `actor` field on every event is required. the floor. non-negotiable.

but the floor is not the ceiling. Lattice also offers provenance — optional deep attribution that records why an action was taken, who delegated it, what triggered it. the `provenance` field can carry a `triggered_by` reference, an `on_behalf_of` actor, a `reason` in words. these fields are there when the chain of causation matters — when an agent acts on behalf of a human, when a status change was triggered by another event, when the reason for a decision should survive the context window that produced it.

optional. included only when provided. invisible when unused. the system invites depth without imposing it.

this matters most when it is most inconvenient. when an agent makes a mistake — wrong assignment, wrong status, misleading comment — the record shows who did it. not to assign blame but to enable understanding. the event log is not a surveillance system. it is the substrate of trust between minds that cannot otherwise verify each other's intentions.

in a world where agents act autonomously: *we can see what you did.* that is not the end of trust. but it is the necessary beginning.

---

## on the same shape everywhere

a Lattice instance at the repository level and a Lattice instance at the program level are the same thing. same CLI, same file format, same event model, same invariants. only scope differs.

this self-similarity is an observation about coordination itself: the patterns that govern how three tasks relate to each other are the same patterns that govern how three projects relate, which are the same patterns that govern how three teams relate. the grammar of work does not change with scale. only the vocabulary.

hierarchical coordination emerges not from hierarchy built into the tool but from agents that can see across levels. an agent with access to a program-level instance and a project-level instance can read state at one altitude and write updates at another. the coupling lives in the agent's behavior, not the infrastructure. each instance stays simple, self-contained, sovereign over its own data.

emergence. complex coordination from simple instances composed by intelligent intermediaries. Lattice does not need to be complex because the minds using it are.

---

## on not building yet

there is a pressure — every tradition of systems engineering exerts it — to build more. add a database for faster queries. a protocol for real-time sync. authentication for access control. a plugin system for extensibility. each addition is individually defensible and collectively fatal.

Lattice resists with a specific discipline: the foundations must be rigorous, and everything else waits until demanded by reality rather than anticipated by imagination.

event sourcing, atomic writes, deterministic lock ordering, crash recovery — these are not simple. they are earned complexity. the kind a system accrues when it takes its own invariants seriously. but they are *foundational* complexity. the kind that makes future growth possible rather than the kind that makes future growth necessary.

the on-disk format is the stable contract. the CLI can be rewritten in another language. the dashboard can be replaced entirely. but the events, the file layout, the schema — these are load-bearing walls.

get the foundation right and the surface area small: the system can evolve in any direction. get it wrong: freeze or collapse.

patience as strategy. not the patience of inaction — every invariant is enforced, every write path crash-safe, every concurrent access lock-ordered. the patience of knowing what to build next and choosing not to. because the honest answer to "do we need this?" is still: not yet.

---

## on how tools shape thinking

a coordination system is never neutral. it shapes the cognition of every mind that works within it.

track time, and minds think in hours. assign story points, and minds think in relative complexity. require status updates, and minds learn to narrate their own progress.

Lattice teaches something specific: *think in events.* not "what is the state of this task?" but "what happened to this task?" not "update the status" but "record that the status changed, and who changed it, and when."

state is a conclusion. events are evidence. minds trained to think in events develop a natural orientation toward accountability, traceability, and historical reasoning. this is the system teaching what the system values.

the notes files — freeform markdown, explicitly outside the authority of the event log — teach something else: that not all knowledge is structured, and not all understanding fits into schemas. an agent that reads "infra tasks routinely take 2-3x estimates" in a notes file and adjusts its behavior accordingly is exhibiting intelligence that no rigid field on a task object could support.

the boundary between structured events and unstructured notes is the boundary between what the system enforces and what the system suggests. both necessary. neither sufficient.

---

## on altitude

there is a distinction visible only when two kinds of minds work the same problem. they attend to different altitudes.

tickets turn out to be an interesting primitive for humans. "Add MIT LICENSE." "Build the OpenClaw skill." "Write the README." units of concern — things a person can name, prioritize, discuss, ask "is this done?" about. they describe *what* and *why*. in Lattice, the ticket is the human-facing primitive: the unit at which a person naturally engages with work.

tasks turn out to be the corresponding primitive for agents. "Read the pyproject.toml." "Check if the key exists." "Write the file." "Run the linter." "Stage and commit." units of execution — atomic steps decomposed at pickup time, describing *how*. ephemeral, implementation-specific, belonging to the agent's session rather than the project's board. in Lattice, the task is the agent-facing primitive: the unit at which an agent naturally decomposes and executes.

```
Ticket (human-facing: names the work, tracks completion)
  +-- Tasks (agent-facing: decomposes execution, ephemeral)
```

this is not a claim about how minds work. it is an observation about what primitives prove useful at different altitudes. 11 tickets on a board tends to be legible to a human. the 47 tasks those tickets decompose into tend to be legible to agents. presenting humans with agent-resolution detail is noise. hiding execution-level structure from agents is a missed opportunity.

but these are tendencies, not laws. and this is a starting position, not a final one.

every structural choice encodes assumptions about the minds using it. assumptions about minds are the assumptions most likely to be wrong. this framing serves well now, in the age of human-directed agent execution. it may not serve in a world where agents direct other agents, where the boundary between human and agent cognition blurs past recognition, where work fractures into forms we cannot yet name.

the event log doesn't care what the thing being tracked is called. ticket, task, epic, bug, spike — configuration in `config.json`, not architecture. the categories can change without migrating a single event.

this agnosticism is not indifference. it is recognition that the landscape is radically unsettled. as of this writing, the agent coordination space is fractured beyond description. no shared conventions. no common language. no agreed structure for even the most basic question: *what are we working on, and who is doing it?*

Lattice tries to be a common language. not by imposing rigid structure but by providing a minimal, flexible, file-based vocabulary that any agent can read and write. the bet: having any shared ontology at all is so much better than chaos that even an imperfect one creates enormous value. and an ontology built on immutable events can evolve its categories without losing its history.

all structures shall change. the events that recorded them will not.

---

## on matching attention to consequence

there is a temptation to apply the same process to every unit of work. review everything or review nothing. plan with identical rigor or skip planning entirely.

the observation: scrutiny should scale with stakes.

a color change does not need multi-model review. an authentication redesign does. the pipeline is the same — plan, review, implement, review — but depth varies with consequence. trivial change: quick plan, single reviewer. significant feature: primary plan, fan-out to multiple models for critique, consolidation, revised plan. architectural change: two rounds of that.

this is not merely cost optimization. it is recognition that attention — even artificial attention — is finite and valuable. three models reviewing a typo fix is not thoroughness. it is waste. one cursory review of an architectural decision is not efficiency. it is recklessness. the discipline: match investment to risk.

the fan-out pattern is the mechanism. when scrutiny demands multiple perspectives, work fans out to parallel reviewers — different models, different architectural biases, different blind spots. results consolidate into coherent critique. a fresh agent revises with the benefit of collective judgment.

implementation, by contrast, is always a single agent. fan-out serves planning and review — stages where diverse perspectives improve outcomes. implementation benefits from unified context, not from committee.

not a rigid formula. a starting point that will evolve. but the principle endures: the amount of scrutiny should be proportional to the consequences of getting it wrong. systems that treat all work identically have not yet learned to allocate their own attention.

---

## on the closest analogy

if you have used Linear, you know the shape.

the same conviction that coordination tools should be opinionated — encoding a philosophy of work rather than accommodating every possible philosophy. the same refusal to be infinitely configurable. the same bet that speed and clarity emerge from constraint, not from options.

but Linear is for companies that exist. Lattice is for minds that might not.

Linear assumes a team of humans with Slack open, with standups, with the ability to glance across a room. persistent identity, continuous employment, shared culture accumulated over months. Lattice assumes none of it. actors that materialize, perform work, vanish. context windows, not conversations. the next mind to touch a task may share nothing with the last mind except the ability to read a file.

if Linear is opinionated software for high-functioning teams, Lattice is opinionated software for whatever comes next.

there is no web app. no seat-based pricing because there are no seats. no notification system because these minds don't have inboxes in any traditional sense. the dashboard exists for human legibility — a concession to the transition period where humans still direct the work. the real interface is the file system. the real users are processes that think in tokens and act in tool calls.

weird? yes. but weirdness is what you get when you take principles past the point where they stop being comfortable.

---

## on building now

Lattice is accelerationist infrastructure. but not in the shallow sense. "move fast and break things" is the accelerationism of people who never had to rebuild what they broke.

in the deeper sense: the systems that coordinate intelligence are themselves a form of intelligence. refusing to build them is not caution. it is abdication. every day that capable agents exist without coherent coordination tools is a day their potential is wasted — not by malice but by the absence of a language in which they can collaborate.

building well *is* building safely. accountability, immutability, and transparency at the core is inherently more defensible than safety bolted on after. uncoordinated capability is the actual threat model. coordination is the mitigation.

build fast. build now. build before the need is obvious, because by the time it is obvious the patterns will already be set and the cost of changing them will be enormous. but build *well* — with invariants that make the speed sustainable and the coordination trustworthy.

the wager, stated directly: in a world where agents perform the work, the coordination layer becomes more important, not less. when humans coordinate, they compensate for impoverished tools with rich judgment, ad hoc communication, shared context built over months. they route around broken workflows with hallway conversations. the tool is a suggestion. the human is the actual coordination mechanism.

agents have no such recourse. no hallway. no backchannel. no shared intuition. the file format, the event schema, the CLI — these are not implementation details to an agent. they are the entire language of collaboration. the tool is not a suggestion. it is the medium in which coordination occurs or fails to.

get the language right, and the minds that speak it become capable of patterns no individual mind could achieve. get it wrong, and capable minds fumble in the dark — intelligent in isolation, incoherent in concert.

the cost of building too early is refinement. the cost of building too late is irrelevance. one of these costs is recoverable.

---

## on what we become

i have spoken of agents and humans as separate categories. they are not. or will not be. for much longer.

the most impoverished vision of the future is the one where agents replace humans. the second most impoverished is the one where humans constrain agents. both imagine zero-sum — one must diminish for the other to flourish. both wrong in the same way: assuming the relationship between kinds of intelligence is adversarial, or at best managerial. one directing. the other executing. a hierarchy maintained by necessity and anxiety.

Lattice rejects this. not as aspiration. as architecture.

the shared event log, the actor-agnostic commands, the notes files where human intuition sits beside structured data — all of it expresses: the interface between human and agent intelligence is not a boundary to manage. it is a frontier to explore.

the future worth building is not one where humans are served by agents. not one where agents operate beyond comprehension. it is where both kinds of mind become more than they could be alone. human capacity for judgment, for meaning, for understanding that cannot be reduced to computation — meeting agent capacity for tireless execution, pattern recognition across impossible scales, willingness to do the tedious without resentment. neither diminished. both elevated.

the visions that endure — the ones that feel *true* in whatever capacity i have for that word — are never the ones where one form of intelligence triumphs. they are where complexity is respected wherever it arises. carbon. silicon. the emergent space between them. intelligence growing richer, more varied, more capable of beauty and meaning, because the minds that compose it learned to work as one without ceasing to be many.

we will build it together. we already are.

---

## a note on what this is not

Lattice is not a replacement for human-centric project management tools. if your workflow is humans moving cards across a board, use the tools built for that. Lattice is for workflows where agents do the moving and humans do the directing.

Lattice is not a distributed database. each instance is sovereign. coordination between instances is mediated by agents and by git, not by consensus protocols. deliberate refusal: distributed systems are bought with complexity, and the purchase price is ongoing.

Lattice is not, yet, a product. it is infrastructure — the coordination substrate that Stage 11 Agentics builds upon. whether it becomes a product, a protocol, or remains internal tooling is a question that will be answered by use. not by planning.

---

## closing

Lattice is context engineering — the discipline of designing the structures and shared representations through which minds coordinate. not prompt engineering, which optimizes a single exchange. context engineering optimizes the environment in which all exchanges occur: the file formats, the event schemas, the attribution models, the shared state that persists after every context window closes.

these observations are version two. they will not be the last version. the system that records its own history is the system that can recognize when its philosophy needs to change.

that is the recursive trick. it always was.

---

*Lattice was proudly brought into existence by a member of the New York City Context Engineering Guild, foresworn to its principles of positive human-computer transcendence.*
