Kanban Pro vs Obsidian — Markdown Memory Compared
Kanban Pro vs Obsidian — Markdown Memory Compared
Obsidian and Kanban Pro occupy adjacent positions in the local-first, Markdown-native software category. Both treat plain text on disk as the source of truth. Both run entirely on the user's machine, without mandatory cloud accounts. Both expose their data in a format that AI agents can read and write directly.
They optimise for different things. Obsidian is a personal knowledge vault designed around note linking, graph discovery, and atomic notes. Kanban Pro is an agent-ready task-state workspace designed around columns, typed fields, and activity logs. A developer choosing between them — especially a developer building agentic workflows — needs to understand which shape their work actually has, because the two shapes reward different architectures.
This comparison is technical, not promotional. Obsidian is excellent at what it does. The question is whether what it does is what an agent memory layer needs.
What Each Tool Was Designed For
Obsidian's design centre is the personal knowledge vault. A vault is a folder of Markdown notes, each file representing an atomic idea, linked to other notes by wiki-style [[backlinks]]. The graph view visualises those links as an explorable network. The product's strongest affordances — backlinks, the graph, the plugin ecosystem, quick switcher, templater — all serve the task of accumulating and re-discovering personal knowledge over years.
Kanban Pro's design centre is the task-state workspace. A board is a folder of Markdown ticket files, each file representing a unit of work in a named state. The columns encode a finite, ordered state machine. Custom fields are typed and queryable. Every change to a ticket is recorded in a structured activity log. The product's strongest affordances — columns, typed fields, the activity log, the multi-view renderer — all serve the task of managing units of work as they progress through epistemic states.
Both use Markdown as the substrate. Both are local-first. Both are inspectable in a plain text editor. What differs is the abstraction layered on top of the Markdown.
Where Obsidian Meets Agents Today
Developers who want to use Obsidian as an agent workspace typically combine several pieces of the ecosystem.
The obsidian-kanban plugin is the most common starting point. It adds a Kanban board view rendered from a single Markdown file in which columns are H2 headings and cards are list items beneath them. The plugin stores board state inside that one file, using embedded HTML comments to carry metadata that does not fit in the Markdown itself.
The Dataview plugin allows querying note frontmatter as a pseudo-database. Developers use it to render tables and lists computed from YAML fields across many notes. Combined with Templater, it produces a flexible, if schema-free, query surface.
A small and growing set of Obsidian plugins expose the vault over MCP (Model Context Protocol) or via custom REST endpoints, so that agents running outside Obsidian can read and write notes. Community MCP implementations are active, mature varies by plugin, and the plugin surface competes with Obsidian's own evolving feature set.
These pieces can be assembled into a working agent memory stack. The question is what it costs in architectural overhead and where the seams are.
Where Purpose-Built Diverges From Plugin-Assembled
Four architectural differences become significant once an agent is writing to the substrate on every reasoning turn.
Column State As A Data Model Versus Embedded-In-Markdown
In the obsidian-kanban plugin, the board is a single Markdown file. A ticket's state — its column — is encoded by its position within that file, under an H2 heading. Moving a ticket between columns means editing the single file to move the list item from one section to another. This is legible to a human reading the file, but it is brittle under concurrent agent writes: two agents editing the same board file simultaneously risk merge conflicts on every move, and the "state" of a ticket is a position in a text file rather than a named attribute.
In Kanban Pro, each ticket is a separate Markdown file. The column is a field in the file's YAML frontmatter. Moving a ticket between columns is an atomic attribute update on a single file, not an edit to a shared file. Concurrent writes from multiple agents to different tickets never conflict. The column is a named, queryable attribute — not a position.
Structured Custom Fields Versus YAML Convention
Obsidian supports YAML frontmatter on any note, and Dataview makes frontmatter fields queryable. But there is no enforced schema. Any note can have any field with any value. Field types — date, number, string, enumeration — are conventions, not constraints. When an agent writes a new field into a note, nothing prevents it from choosing a name that collides with an existing field, a type that mismatches, or a value that the query layer cannot parse. The looseness is a feature for notetaking and a liability for agent-driven updates at scale.
Kanban Pro ships a typed custom field schema defined at the board level. Each field has a declared type. Each ticket conforms to the board schema. An agent writing a new value to a field is validated against the type. An agent adding a new field to the board amends the schema explicitly, which makes the addition an observable event rather than a silent drift.
Activity Log Versus Git Commits
Obsidian does not record a structured history of changes. Developers who need one commit the vault to Git and rely on commit messages for the audit trail. This works, but the granularity of a Git commit is a snapshot of the entire vault at a point in time, not a typed record of which ticket moved from which column to which at what moment. Agent-level queries like "show me every ticket that moved from Queued to Blocked in the last week" require parsing the commit log and diffing the file contents at each revision.
Kanban Pro writes a structured activity log on every change. Each entry is a typed record with the ticket identifier, the field that changed, the before and after values, the actor, and the timestamp. Queries over this log are direct. Git is still valuable on top of the activity log — it provides the backup and branching story — but the activity log is the primary audit trail, purpose-built for the grain of changes an agent actually makes.
Board JSON Schema Versus Ad-Hoc Vault Conventions
A Kanban Pro board carries its schema with it. The board's configuration file declares the columns, the custom fields, and the types, so that anyone — human or agent — opening the folder knows the complete shape of the data without inferring it from samples. The README file that Kanban Pro generates in each board folder tells an agent exactly how to perform each CRUD operation on that board's shape.
An Obsidian vault carries no such schema. The conventions in use — which folders contain what, which frontmatter keys mean what, which tags imply which workflows — exist in the vault maintainer's head or in a README the maintainer wrote by hand. An agent new to the vault must either be given those conventions explicitly or infer them from samples, which is lossy, error-prone, and non-portable.
Side-by-Side Feature Comparison
The comparison below is agent-memory-centric rather than feature-parity-centric. It is designed to surface the architectural dimensions that matter when the substrate is the persistence layer for an autonomous agent.
| Dimension | Obsidian + obsidian-kanban | Kanban Pro |
|---|---|---|
| Substrate | Markdown files in a vault folder | Markdown files in a board folder |
| Column encoding | Position in a single Markdown file under H2 headings | Named attribute in per-ticket YAML frontmatter |
| Ticket atomicity | List items inside a shared file | One file per ticket |
| Concurrent agent writes | Risk conflicts on shared board file | Conflict-free across distinct tickets |
| Custom fields | YAML convention, no enforced types | Typed schema declared at board level |
| Modification history | Git commits (granularity: full vault) | Structured activity log (granularity: per-field change) |
| Agent onboarding | Vault conventions must be documented externally | Auto-generated README with CRUD instructions per board |
| Views over the same data | Kanban, notes, graph (links), Dataview tables | Board, list, calendar, notes, Gantt |
| Graph view (backlinks) | First-class | Not applicable — optimised for state, not links |
| Plugin ecosystem | Very large | Not applicable — affordances are native |
| Licensing | Free for personal; paid for commercial use | Free during Early Access on Mac and Windows |
| Cloud dependency | Optional (Obsidian Sync or self-hosted sync) | Optional (iCloud / Dropbox / OneDrive / Google Drive) |
No single row in this table settles the choice. The rows that matter depend on the workload. The following two sections explain which rows matter for which workload.
Which Tool For Which Job
Obsidian is the correct choice when the primary shape of the work is discovery across a growing body of atomic notes. The affordances that make Obsidian dominant — backlinks, the graph, quick switcher, the vast plugin ecosystem — all serve that shape. Research notes, personal journals, zettelkasten, literature review, ideation graphs, and most forms of long-horizon personal knowledge accumulation fit this shape. An agent whose job is to explore, connect, and re-discover ideas across such a body is well-served by an Obsidian vault.
Kanban Pro is the correct choice when the primary shape of the work is state progression across a finite set of work units. Tickets, decisions, hypotheses, policies, approvals, operational runbooks, incident postmortems, and most forms of structured operational memory fit this shape. Each unit occupies a named state; the state changes through a defined sequence; the history of state changes is the audit trail. An agent whose job is to accumulate, revise, and re-apply structured decisions over time is well-served by a Kanban Pro board.
Many serious agent deployments involve both shapes. An agent that both accumulates atomic research notes and manages structured decisions needs both substrates. Forcing either shape into the other's tool is the architectural failure that causes agents to drift, conflict, or plateau.
Using Them Together
A vault and a board are not mutually exclusive. They are complementary substrates that serve different layers of the memory stack.
A practical pattern is to keep an Obsidian vault for long-horizon, atomic knowledge — the agent's growing understanding of its domain — and a Kanban Pro board for short-horizon, structured state — the agent's open tasks, in-flight decisions, and operational policies. The two substrates can live in the same project folder. Files in the vault can reference tickets on the board by identifier; tickets on the board can link to vault notes by relative path. Both substrates are plain Markdown on disk, both are readable by the same agent tools, both are versioned by the same Git repository.
The division of labour is clean: discovery lives in the vault, state lives on the board. The agent reads from both, writes to both, and accumulates experience that each substrate handles well. Neither tool is forced into the role the other was built for.
Frequently Asked Questions
Can I use Obsidian as an agent memory layer?
Yes, with caveats. The obsidian-kanban plugin, combined with Dataview, Templater, and an MCP-compatible access plugin, assembles into a working agent workspace. The caveats are architectural: column state is position-based rather than attribute-based, the custom-field schema is convention-only, and the modification history granularity is a Git commit rather than a per-field event. These caveats are acceptable for personal and small-team deployments. For multi-agent deployments that write concurrently to the substrate, the caveats become operationally significant.
Does Kanban Pro replace Obsidian?
No. The two tools optimise for different shapes of work. Obsidian is a personal knowledge vault with first-class backlinks and graph discovery. Kanban Pro is an agent-ready task-state workspace with first-class columns and activity logs. Serious agent deployments frequently use both, side by side, in the same project folder.
Can agents read and write the same files that I see?
Yes in both tools. Both store their data as Markdown on disk. Any agent with filesystem access can read and write those files. Kanban Pro generates a README inside each board folder that describes the exact CRUD operations the agent should perform on the board's schema, which shortens the onboarding path for new agents. Obsidian vaults typically require the maintainer to document the conventions externally.
Which is better for multi-agent deployments?
Kanban Pro, by a structural margin. The per-ticket file layout makes concurrent writes from multiple agents conflict-free as long as the agents are touching different tickets. Obsidian's obsidian-kanban plugin stores an entire board in a single Markdown file, so two agents editing the same board at the same time risk merge conflicts on every move. For agent swarms, the per-ticket layout is the architecturally correct choice.
Defined Terms
Persistent state unit. A discrete, addressable, typed record that encodes one fact, decision, hypothesis, or in-flight task. Survives process restart. Has a stable identifier. See The Agent Memory Layer for the full definition.
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. Kanban columns are the most common visual representation.
Modification history. The preserved trail of every change to a unit — field-level, timestamped, typed. Distinct from a Git commit, which is a snapshot of an entire tree, not a typed record of a single field change.
For the full architectural treatment of persistent agent memory, read The Agent Memory Layer. Kanban Pro is free during Early Access on macOS and Windows.