Your tasks need to be data, not decoration

A Markdown checkbox is easy to read, but it is usually just a line of text. Org2 has first-class TODO states, scheduled dates, deadlines, repeaters, priorities, effort, tags, and planning edits. That means the same plain files can drive agenda views, status filters, date windows, grouping, sorting, and editor commands.

That difference matters when you stop asking "what did I write?" and start asking "what is due, blocked, stale, delegated, high effort, or connected to this project?"

Your notes need stable identity

Markdown links are great for pages. Knowledge work also needs durable nodes. Org2 supports stable IDs, id: links, wiki links, backlinks, node creation, graph reports, and health checks around broken or ambiguous references.

That makes Org2 a better fit for long-lived research notes, project memory, meeting trails, and roam-style workflows where a heading can be a real addressable object inside the corpus.

You want structure without leaving plain text

Markdown can grow extensions forever: front matter, task-list syntax, wiki links, callouts, custom attributes, app metadata, and fenced conventions. Each app then chooses a different subset, which makes shared semantics fragile.

Org2 makes the important structure explicit in one syntax family:

• headlines and nested outlines

• TODO states and planning lines

• drawers and properties

• timestamps and repeaters

• tags, priorities, effort, and IDs

• blocks, tables, lists, links, and source ranges

The payoff is that tools can read the text with a shared model.

AI changes the verbosity tradeoff

Org2 structure can look heavy if you imagine typing every property, date, source pointer, and provenance trail by hand. That is no longer the right default assumption.

Humans should still be able to write terse notes:

* TODO Follow up with design by Friday

Then tools and agents can enrich the note when the extra structure is useful: assign an ID, normalize the date, connect it to a project, cite the source transcript, add provenance, or prepare a reviewable draft. The human keeps the capture surface small; the corpus gains the audit trail and machine-readable context when it matters.

That makes Org2's explicitness a durable target format for collaboration between humans, editors, scripts, and agents.

You want one corpus to produce many views

Markdown's strongest default output is rendered prose. Org2 treats prose as one output among several. The same source tree can compile into:

• agenda and work views

• TODO and planning edits

• backlink and graph views

• lint and corpus-health diagnostics

• formatter output

• cited search/query results

• HTML export and published sites

• editor features through shared parser, CLI, and optional LSP surfaces

That is the core pitch: Org2 is a compiler/runtime for personal and team knowledge.

You expect editors, CLIs, and agents to share the same model

Markdown workflows often depend on one app's interpretation of your files. Org2 puts the semantic model underneath the editor. VS Code, the CLI, publishing, graph tools, JSON output, linting, and future integrations can all read the same corpus model.

That matters for automation. A script or agent should be able to ask the corpus for tasks, links, sources, provenance, generated artifacts, and publishable output through stable commands and JSON output.

You need AI workflows with a trail

AI makes the Markdown-vs-Org2 distinction sharper. If generated summaries, extracted tasks, source transcripts, and reviewed notes all live as loose prose, the trail gets fuzzy fast.

Org2 gives those workflows natural boundaries: raw source material, reviewed notes, compiled semantics, derived views, generated drafts, and published output. Properties such as artifact role and provenance keep generated work inspectable before it becomes durable knowledge.