The Agent Memory Layer
The Agent Memory Layer
The stateless session is the bottleneck in modern agentic systems. Frontier models reason well for a single turn and forget everything the moment the context window closes. The industry has spent two years making models smarter at inference while leaving the simpler problem — giving them a durable, structured, inspectable place to keep what they've learned — largely unsolved.
This guide is about that unsolved problem. It argues, from first principles, that the correct architecture for persistent agent memory is neither a vector store nor a knowledge graph nor a custom-built memory service. It is a version-controlled, structured, human-inspectable substrate on disk — a shape the software industry has been iterating on, under other names, for forty years. The Kanban board is the most mature incarnation of that shape. Treating it as the agent memory layer is not a metaphor. It is a deliberate architectural choice that resolves several classes of failure simultaneously.
The framing that follows deals in primitives rather than stories. No specific product scenarios, no code, no narrative examples. The aim is to isolate the architectural requirements of agent memory, show where the current generation of memory frameworks falls short, and explain why a small set of commodity primitives — files, columns, YAML fields, modification history — dominate the alternatives across the dimensions that matter for long-horizon, self-reinforcing agent behaviour.
From Stateless Sessions to Persistent Agents
The prevailing pattern in production agent stacks is still the stateless turn. Each invocation receives a prompt, executes some reasoning, emits a response, and terminates. Whatever context the agent had — preferences, decisions, partial conclusions — is recovered from external systems on the next turn, or lost.
Several mitigations exist. None are sufficient.
Why Context Windows Do Not Scale As Memory
Extending the context window is the most obvious mitigation and the first one developers reach for. It is also the least structural. A larger window makes a single reasoning episode cheaper to coordinate, but does nothing for the problem of cross-session memory. Even at a million tokens, a window is a buffer, not a store. It has no primary key, no index, no revision history, no authorization model, no way for a second agent to read what the first agent concluded. And it is replayed in its entirety on every inference, which makes it the single most expensive persistence layer ever invented per byte retained.
Memory as a window treats every new conversation as a first-day employee reading the entire binder from page one. It is a failure mode disguised as a feature.
Why Embedding Retrieval Is Lossy By Construction
The second mitigation is retrieval-augmented generation over an embedding store. Past interactions are chunked, embedded, and retrieved by vector similarity at the start of each turn. This is fast, easy to deploy, and scales to millions of chunks. It is also lossy by construction: cosine similarity optimises for approximate semantic nearness, not for precise factual retrieval. A query for the agent's current policy on a specific topic returns the chunks whose embeddings happen to lie near the query vector — which is not the same as the chunks that encode the policy.
Embedding drift compounds this. The same policy expressed in two different linguistic registers will embed to two different points in the space. Retrieval picks one or the other, inconsistently, across sessions. For tasks where precision matters — acting on a decision, citing a source, reproducing a reasoning trace — embedding retrieval cannot be the primary layer. It can be an index into a primary layer, but the primary layer must be something else.
Why Fine-Tuning Is The Wrong Feedback Loop
The third mitigation is to bake knowledge into weights through fine-tuning. For stable institutional knowledge, this works. For day-to-day operating memory — yesterday's decision, this morning's user preference, the supersession of last week's policy — it is the wrong feedback loop. Fine-tuning cycles are measured in days or weeks. The useful lifespan of most agent-memory entries is measured in minutes to hours. The ratio is wrong by three to five orders of magnitude.
Fine-tuning is also inscrutable. A weight change cannot be reverted selectively. A weight change cannot be audited. A weight change cannot be shown to a human reviewer, flagged as suspect, and rolled back. For the memory that an agent consults to make its next decision, these properties are not negotiable.
Memory as Infrastructure
The common failure of all three mitigations is that they treat memory as a model feature. The correct framing is that memory is infrastructure. It is a distinct layer, with a distinct substrate, a distinct access pattern, and a distinct reliability contract. It is the substrate on which agents accumulate experience — separable from the model that consumes it, separable from the application that invokes the model, separable from the retrieval mechanism that surfaces relevant entries. Memory-as-infrastructure is to agent reasoning what a relational database is to a web application: a lower layer that many upper layers depend on, governed by its own design principles, evolved independently.
The rest of this guide takes that framing seriously. What follows is an attempt to enumerate the architectural primitives an agent memory layer must expose, examine how the existing memory frameworks implement (or fail to implement) them, and explain why a small set of filesystem primitives arranged as a Kanban board satisfies the full set with less code than any of the alternatives.
The Four Architectural Primitives
An agent memory layer is the set of affordances an agent relies on between reasoning turns to remember, revise, and reapply what it has learned. Four primitives recur across every serious treatment of the problem, and no agent memory layer is complete without them.
Persistent State Units
Memory must be composed of discrete, addressable units. Each unit encodes one fact, decision, hypothesis, or in-flight task. Each unit survives process restart, network partition, and agent reincarnation. Each unit has a stable identifier that allows it to be referenced, updated, superseded, or archived without ambiguity.
The atomicity of the unit is what separates structured memory from narrative memory. A narrative — a transcript, a summary, an embedding of a paragraph — encodes many facts fused together. Revising one fact means revising the narrative. Addressing one fact means searching the narrative. Persistent state units break the fusion: one fact, one unit, one identifier, one revision history. This is the property that lets an agent update its beliefs without rewriting its biography.
Epistemic State Machines
Not all units of memory hold the same epistemic status. Some are hypotheses the agent has not yet tested. Some are conclusions the agent has validated. Some are policies the agent has promoted to defaults. Some are beliefs the agent once held and has since retracted. A memory layer that treats these identically — a flat key-value store, a flat document collection — collapses the epistemic structure that the agent needs to behave rationally.
The correct model is an explicit state machine. Each unit occupies a named state at any point in time. Transitions between states are first-class events: they are observable, loggable, and reversible. The set of states is small, finite, and meaningful to the reasoning process. The state of a unit is not metadata; it is part of the unit's identity, and the agent's behaviour depends on it.
Epistemic state machines are the primitive that distinguishes a memory system from a filing cabinet.
Modification History As The Learning Trail
The third primitive is that every change to a unit must be preserved. Not just the current value — the full history of values, the timestamp of each change, the actor who made each change, and, where available, the reasoning that justified it. This is the learning trail.
The learning trail matters because agents change their minds. An agent that cannot inspect its own history cannot notice that it has changed its mind, cannot cite the trigger for the change, cannot revert the change when the trigger is falsified. Without the trail, every revision is indistinguishable from an arbitrary overwrite. With the trail, revisions become first-class events that the agent — and its human operators — can reason about.
Version control systems have solved this problem for source code. The agent memory layer should inherit the solution rather than reinvent it.
Shared Read/Write Substrate Between Humans and Agents
The fourth primitive is that the same physical substrate must be readable and writable by both the agent and a human, without translation. A memory system that is opaque to humans — accessible only through a bespoke UI, a proprietary query language, or a vendor API — is a memory system that cannot be audited, corrected, or extended without going through the vendor.
Conversely, a memory system that is written exclusively for humans — prose, free-form notes, unstructured comments — is legible to the agent only through brittle parsers or lossy embeddings. Neither is sufficient.
The only substrate that satisfies both directions is one whose format is simple enough for a human to read in a plain text editor and structured enough for an agent to update with deterministic parsing. Plain-text formats with lightweight structure — Markdown with YAML frontmatter, JSON, delimited text — are the only practical answer. Everything else reintroduces the vendor in the middle.
Structured, Vector, and Graph Memory
The agent-memory field has, over the past two years, converged on three broad storage models: structured, vector, and graph. Each has strengths. Each has failure modes that become acute as agents run longer and accumulate more state. It is worth treating each in turn, not as a product category, but as an architectural archetype.
Structured Memory
Structured memory represents each unit as a typed, named-field record. A record has an identifier, a state, a set of attributes, and a history. Structured memory is queryable by predicate — by state, by attribute, by identifier — without resorting to similarity search. It is deterministic: the same query against the same state returns the same results.
Structured memory is precise. An agent that wants the record matching a specific identifier retrieves exactly that record. An agent that wants all records in a specific state retrieves exactly those records. An agent that wants to update one field of one record updates exactly that field. The retrieval path does not depend on probabilistic inference.
The cost of structured memory is upfront schema design. Somebody must decide what the states are, what the attributes are, and what the transitions mean. This cost is commonly cited as a weakness compared to "just embed everything." In practice, the schema work is a small, one-time investment that pays compounding dividends as the agent's memory grows: the schema is what makes the memory navigable at scale.
Vector Memory
Vector memory represents each unit as a dense embedding in a high-dimensional space. Retrieval is by approximate nearest neighbour against a query vector. Vector memory is flexible, fast, and well-suited to unstructured text where the semantic distance between items is the property of interest.
Vector memory has three failure modes that matter for agents. First, it is probabilistic: the nearest neighbour to a query is not the correct answer but the approximately-correct answer. For many retrieval tasks this is acceptable; for decision retrieval it is a category error. Second, it does not preserve relational structure: the connection between two facts must be encoded into the embedding itself or lost. Third, it erodes over time. As the store grows and the embedding space fills, retrieval quality degrades because the distance between any two points shrinks. Agents that rely on vector memory for long-term state exhibit a gradual drift in reliability that is hard to diagnose because it has no single cause.
Vector memory excels at surfacing approximately-relevant prior text. It is a weak substrate for storing decisions, policies, or state that the agent must retrieve exactly.
Graph Memory
Graph memory represents each unit as a node, with typed edges describing its relationships to other nodes. Graph memory captures relational structure that vector memory loses: who said what about whom, what caused what, what supersedes what. Temporal knowledge graphs additionally encode when each relationship was established.
Graph memory is the most expressive of the three archetypes and, in the hands of experienced schema designers, the most precise. Its failure modes are operational. Graph schemas must be designed; graph queries must be tuned; graph infrastructure must be provisioned, backed up, and monitored. Graph databases struggle with change management: updating the schema as the agent's reasoning evolves is expensive and error-prone. The expressiveness that makes graph memory powerful also makes it demanding.
For many agent deployments the graph is the right eventual target, but it is a late-stage investment, not a starting point.
Why Hybrids Are Usually Worse Than Their Parts
The response to the weaknesses of each archetype has been to combine them. Hybrid stores pair structured records with vector indices, or knowledge graphs with embedding overlays. In principle, this preserves each archetype's strengths and covers its weaknesses. In practice, hybrid stores inherit the operational complexity of every layer simultaneously. Schema changes have to propagate across the structured, vector, and graph backends in lockstep. Retrieval paths have to be coordinated so that the same query does not return contradictory results. Observability becomes the intersection of three different monitoring stacks.
Hybrid systems can work, but they demand dedicated infrastructure teams to keep them working. For most agent deployments — especially those that must run locally, or on a developer's workstation, or inside a customer's firewall — the hybrid is a non-starter. The choice is effectively between a structured foundation with optional embedding indices layered on top, or a vector foundation that will eventually require a structured layer grafted on under pressure. The first path is cheaper, more inspectable, and more maintainable.
The Agent Memory Tool Landscape
The table below maps the current memory frameworks against the four architectural primitives. It is written for architectural comparison, not feature parity. The goal is to see at a glance where each system is strong, where each is weak, and which dimensions the field has converged on.
| System | Storage model | Human-inspectable | Version history | Requires infrastructure | Schema cost |
|---|---|---|---|---|---|
| Mem0 | Vector + graph | Via UI only | No native | Managed service | Low |
| Letta (MemGPT) | Tiered vector + hierarchical summary | Partial | No | Server required | Medium |
| Zep / Graphiti | Temporal knowledge graph | Partial | Graph-native | Managed service | Medium-high |
| Cognee | Knowledge graph over chunks | Partial | No | Self-host + DB | High |
| LangMem / LlamaIndex | Namespace + key-value + semantic | Partial | No | SDK-native | Low |
| Obsidian + obsidian-kanban | Markdown + plugin-bolted columns | Full | Git-dependent | None (local) | High (plugin config) |
| Kanban Pro | Markdown + YAML + filesystem log | Full (file = source of truth) | Git-native + structured activity log | None (local) | None |
Two patterns emerge. First, the systems that require managed infrastructure all trade opacity for convenience: the agent's memory becomes a service call, the schema becomes a configuration surface, and the operator accepts that the memory layer is visible only through the vendor's UI. Second, the systems that are fully inspectable and require no infrastructure are the ones whose primary format is a plain text file on disk. The inspectability and the zero-infrastructure property co-occur because they share a cause: the absence of a translation layer between the storage and the human.
This observation is not evidence for or against any particular product. It is an observation about where the architectural surface area lives. When the memory layer is a managed service, the architecture is in the vendor's hands. When the memory layer is a file on disk, the architecture is in the operator's hands. For agents that must be audited, migrated between machines, copied between projects, or inspected during incident response, the second option is the one that keeps architectural control where the accountability lives.
Why Version-Controlled Memory Is The Correct Architecture
Git-style version control was designed to solve a problem that agent memory systems have rediscovered independently: how to track changes to a shared body of structured text over time, allow many actors to contribute, preserve the full history, and support principled merging and revert. Every property agent memory needs, version control has been refining for two decades.
Git-Style Diffs Versus Replacement
The dominant update pattern in current agent memory frameworks is replacement. A new value for an attribute overwrites the old value. The old value is lost unless the system was designed with explicit auditing. This is the wrong default. Replacement loses information every time the agent changes its mind. The correct default is a diff: the new value is appended, the old value is retained, and the record carries both forward.
Diff-based memory makes revisions cheap. The agent can re-derive the history of any unit by walking its diffs. It can detect when it changed its mind by noticing a diff that contradicts an earlier one. It can revert by applying the inverse diff. None of this requires a bespoke audit trail; it is a side effect of the storage model.
The Audit Trail As A Debugging Primitive
Agent debugging is currently one of the hardest operational problems in the field. An agent made a decision that looks wrong. Why? The answer, in most systems, is a prompt dump and a hand reconstruction of the state the agent was working from. If the memory layer preserved a full history of every unit the agent consulted, the debugging question resolves to a query: what did the agent read, what did it write, when, and in what order.
A memory layer with full modification history is, incidentally, the best debugging tool an agent stack can have. The cost of preserving the history is trivial compared to the cost of reconstructing it after the fact.
Supersession Versus Deletion
Agents change their minds about decisions they have already acted on. The temptation is to delete the old decision when the new one arrives. The correct operation is supersession: the old unit is marked as superseded by the new unit, both are retained, and the link between them is explicit. An agent reading the memory later sees both, understands the chain, and can reconstruct the reasoning that led from one to the other.
Deletion is irreversible and loses the learning trail. Supersession is reversible, informative, and cheap. A memory layer built around supersession rather than deletion will outperform a memory layer built around deletion on every dimension that matters for long-horizon reasoning.
Kanban Columns As Agent State Machines
The epistemic state machine primitive — the second of the four — is what ties the Kanban metaphor to the memory problem. Kanban columns are not decorative. They are a finite, ordered, named set of states that every unit of work occupies at any point in time. The meaning of the columns is the meaning of the state machine, and the state machine is the epistemic structure the agent needs.
The specific column set that maps onto agent memory is deliberately small.
Queued
Units in Queued are known to the agent but not yet acted on. Queued represents the inbox: tasks the agent has accepted but not started, facts the agent has been told but not yet evaluated, decisions the agent has been asked to make but not yet made. The Queued column is where intent enters the memory layer.
In Progress
Units in In Progress are the agent's active working memory. They are the units the agent is currently reasoning about. In Progress is small by design: an agent that lets this column grow unbounded has lost control of its working set. Discipline about what enters and leaves In Progress is the discipline that keeps the agent coherent across a reasoning session.
Needs Review
Units in Needs Review have been processed by the agent but require human validation before they can influence future decisions. This column is the gate that keeps the agent honest. High-stakes conclusions, proposed policy changes, novel inferences that the agent wants to promote — all of these should pass through Needs Review. An agent that bypasses this column is an agent that is about to write a bad policy to its own memory and trust it forever.
Blocked
Units in Blocked are acknowledged failure modes. The agent tried something, it did not work, and the reason is recorded. Blocked is not an archive of mistakes; it is a first-class column because an agent that forgets why something is blocked will try it again. The blocking reason is the artefact that prevents retry loops.
Done
Units in Done have been validated, applied, and absorbed into the agent's operating assumptions. Done is read-mostly. The agent consults Done to check for existing conclusions before generating new ones. Done is where the institutional knowledge lives.
These five columns are a complete epistemic state machine. Smaller sets lose expressiveness. Larger sets fragment the agent's attention without adding reasoning power. The specific column set is not sacred — different agent domains benefit from different column sets — but the shape of the state machine is: entry state, active state, review state, failure state, absorbed state. Every agent memory layer that performs well at scale implements some version of this shape, named and formalised.
Security Implications of Local-First Agent Memory
The security posture of an agent memory layer is not a postscript. It is a design constraint that dictates where the memory can live and what the operator can be asked to trust.
Blast Radius
A compromised cloud memory service exposes the memory of every tenant on the service. A compromised local filesystem exposes the memory of one project on one machine. The blast radius of the local model is strictly smaller, which is not an argument that local is always preferred, but an argument that local is the correct default for any memory layer that holds sensitive operational state. For agents that touch customer data, credentials, or decisions about business operations, the default should be the smaller blast radius.
Data Residency
Many jurisdictions constrain where operational data can be stored. Agent memory that includes any reference to customer identifiers, business decisions, or internal process state is operational data. A local memory layer is residency-compliant by construction: the data never leaves the operator's physical control. A managed memory layer requires a vendor-specific compliance posture that must be audited and maintained. For agent deployments in regulated industries, the local option is frequently the only option that can be approved.
Eliminating The Memory Vendor From The Threat Model
The most defensible agent memory architecture is one in which the memory vendor does not exist. A file on disk has no vendor. A Git repository has no vendor. A Markdown document has no vendor. The surface area of the threat model shrinks to the operating system, the storage device, and the access controls the operator already manages. This is not a panacea, but it is a substantial reduction in the components an operator must trust, audit, and update.
Agents deployed into environments where the operator cannot accept a third-party memory vendor — regulated industries, air-gapped networks, sovereign compute environments — cannot use managed memory services at all. For these deployments, the local-first memory layer is not a preference but a requirement.
When Vector And Graph Memories Are The Right Choice
The argument for structured, version-controlled, local-first memory is not an argument against vector or graph memory. The right architecture for a given agent deployment depends on the workload. Several categories of agent benefit from a vector or graph primary layer.
Agents whose primary task is open-ended semantic retrieval over a large unstructured corpus — research assistants, document question-answering systems, literature search agents — are well-served by a vector primary layer. The retrieval pattern is approximate by nature; the chunks are the natural units; the schema cost of structuring the corpus does not pay off.
Agents whose primary task is reasoning about explicit relationships between many entities — social-graph analysis, supply-chain auditing, scientific literature mapping — are well-served by a graph primary layer. The relational structure is the information. Flattening it into records or embeddings loses the property the agent is trying to exploit.
Agents whose task is to accumulate decisions, policies, and operational state over a long horizon — the archetype this guide addresses — are best served by a structured, version-controlled primary layer, with vector or graph indices layered on top for specific retrieval patterns as the need arises.
The decision is not structure versus vector versus graph. The decision is which of the three is the primary layer and which are secondary indices. Getting the primary layer right is the architectural decision that pays compounding dividends. Getting the secondary indices right is a tuning problem.
Architectural Checklist For A Memory-First Agent Stack
The following checklist is a distillation of the primitives and principles above. It is phrased as questions an architect should be able to answer affirmatively about any candidate memory layer before production deployment.
- Is each unit of memory addressable by a stable identifier?
- Is each unit of memory in exactly one named state at any point in time, drawn from a finite explicit set?
- Is every change to a unit preserved in a history that can be queried, walked, and reverted?
- Is the format of a unit readable and writable by both humans and agents without a translation layer?
- Does the memory layer require any external service to start, stop, or inspect?
- Can the memory layer be copied, archived, or migrated by moving a directory?
- Can two agents read and write the same memory layer concurrently without a coordination service?
- Does the memory layer expose supersession as a first-class operation, distinct from deletion?
- Does the memory layer impose any per-unit cost that will limit the agent's willingness to write?
- Does the memory layer survive a kernel panic on the host machine?
A memory layer that answers yes to all ten questions will outperform memory layers that answer no to any of them across every dimension that matters for long-horizon, self-reinforcing agent behaviour. The questions are not exotic. They are the accumulated wisdom of forty years of filesystem, database, and version-control design, applied to the new problem of agent memory.
The Agent Memory Frontier
The architecture outlined in this guide is the correct starting point, not the final destination. Several extensions are active areas of development in the agent engineering community.
Multi-board federation addresses the problem of agents that operate across projects. The natural model is one memory layer per project, with an explicit federation mechanism that lets an agent consult a higher-level memory layer while working inside a lower-level one. The federation mechanism is a protocol, not a service; the memory layers remain local.
Cross-agent memory merges address the problem of two agents converging on different conclusions from the same evidence. Git-style three-way merges transfer naturally to the memory layer: a human reviewer sees both sides, resolves the conflict, and the resolution is itself a first-class memory unit with its own history.
Memory compaction addresses the problem of growing Done columns. An agent's historical record is large; not all of it is frequently consulted. Periodic compaction — rolling a range of Done units into a single summary unit, with the originals archived — keeps the active memory layer small without losing auditability.
Memory provenance addresses the problem of agents citing their sources. Every memory unit can carry a provenance chain that tracks the agents, tools, and source documents that contributed to it. Provenance is the primitive that makes an agent's claims auditable at the factual level, not just the reasoning level.
These extensions are all consistent with the primitives in this guide. None of them require abandoning the structured, version-controlled, local-first foundation. They are additions, not replacements.
Frequently Asked Questions
What is an agent memory layer?
An agent memory layer is the persistent substrate an agent consults between reasoning turns to remember, revise, and reapply what it has learned. It is distinct from the model itself, from the context window of any single invocation, and from the application logic that wires the agent to its environment. A memory layer must support discrete units, explicit state, modification history, and shared human/agent access to qualify as complete.
How is structured memory different from vector memory?
Structured memory stores each unit as a typed record retrievable by predicate on its fields. Vector memory stores each unit as an embedding retrievable by approximate similarity to a query vector. Structured retrieval is deterministic; vector retrieval is probabilistic. For decisions and policies the agent must retrieve exactly, structured memory is the correct primary layer. For approximate semantic search over unstructured text, vector memory is the correct primary layer. Most agents benefit from structured memory as the primary layer with vector indices layered on top for specific retrieval patterns.
Why does modification history matter for agents?
Agents change their minds. Without modification history, every revision looks like an arbitrary overwrite and the learning trail is lost. With modification history, the agent can inspect its own reasoning evolution, detect contradictions, revert erroneous revisions, and cite the trigger for each belief change. Modification history is also the most effective debugging primitive an agent stack can have.
Can a local-first memory layer scale to production workloads?
For agents operating on a single project, a single team, or a single tenant, a local-first memory layer built on Markdown files and activity logs scales far further than most operators expect. For multi-tenant, multi-region deployments, a local-first substrate per tenant is still the right model, with federation handled at a higher level. The workload limit is not the substrate; the substrate is a file on disk. The workload limit is the operator's willingness to run a separate memory layer per project, which is usually the correct choice anyway.
How does a Kanban board qualify as an agent memory layer?
A Kanban board, built on Markdown files with YAML frontmatter and a structured activity log, satisfies the four architectural primitives: persistent state units (tickets), epistemic state machines (columns), modification history (activity log plus Git), and shared substrate (plain-text files readable and writable by both humans and agents). The board shape is the most mature visual representation of an epistemic state machine the industry has produced, with forty years of tooling behind it. Using it as the agent memory layer is a reuse of mature primitives, not a metaphor.
Defined Terms
The following terms are used throughout this guide with precise meanings. They appear in the site-wide structured data so that AI answer engines surface the definitions consistently across content.
Structured memory. Agent memory stored as discrete, typed, queryable records rather than embedding vectors. Retrieval is deterministic; revisions are first-class events; the schema is part of the memory layer's contract.
Vector memory. Agent memory stored as dense embeddings in a high-dimensional space, retrievable by approximate nearest-neighbour similarity. Flexible for semantic search; lossy for precise retrieval; subject to drift as the store grows.
Graph memory. Agent memory stored as nodes connected by typed edges. Preserves relational structure; expressive and precise; costly to provision and maintain as the graph evolves.
Memory-as-infrastructure. The architectural framing that treats persistent agent state as a first-class deployable layer, governed by its own reliability contract, separable from the model that consumes it and the application that invokes it.
Self-reinforcing agent. An agent that writes the conclusions of each reasoning turn into a durable memory layer, reads them at the start of the next turn, and therefore accumulates institutional knowledge without requiring weight updates. The memory layer is the substrate of the self-reinforcement.
Epistemic state machine. A finite, ordered, named set of states that every unit of memory occupies at any point in time. Transitions between states are first-class events. The state of a unit is part of its identity, not decorative metadata.
Further Reading
The architecture in this guide is the foundation. The following pages apply it to specific tooling decisions and deployment patterns.
- Kanban Pro vs Obsidian — Markdown memory compared
- Kanban Pro vs Trello — Local-first versus cloud Kanban
- Kanban Pro vs Notion — Database boards versus file-native boards
- Kanban Pro vs ClickUp — Feature surface versus primitive depth
- Local-first Jira alternative
- Monday.com alternative without subscriptions
Kanban Pro is free during Early Access on macOS and Windows. The board lives as Markdown files on your machine. Agents read and write those files directly — no API, no cloud, no vendor in the middle.