Rule of thumb · Pick Tana if you're a power user who loves designing your own ontology. Pick Bcontext if you want sensible defaults that work with Claude Code in 60 seconds.
Markdown export at any time. Re-imports are idempotent — running the migration again updates in-place instead of duplicating.
Most tools support a markdown or JSON export. Drop the folder into the bcontext importer — sub-folders become folder nodes, pages become docs.
Run the auto-typer to suggest kinds — tasks, decisions, runbooks, meetings — based on title patterns and frontmatter. Review the diffs as proposals.
Side-by-side view of original + bcontext-typed nodes. Accept what's right, reject what's noise. The whole thing exports back to clean markdown anytime.
The argument for fixed types is empirical. Across the 200+ AI-first teams we interviewed for the design of Bcontext, the same kinds came up over and over: docs, tasks, decisions, meetings, bugs, ADRs, skills. The variation between teams was small. Forcing those kinds removes a tax — no schema design phase, no "what is a task in this workspace" debate, no per-team divergence in how RAG indexes content.
The argument against is well-known: real workflows have edge cases, and forcing them into wrong types creates friction. Bcontext's compromise is the `entity` kind, an escape hatch for the cases where none of the seven primary kinds fit. We've seen this used for things like "customer" or "contract" — but the volume of escape-hatch usage in practice is low (<5% of nodes in real workspaces).
On agents, Tana's MCP gap is structural. Their UI is the product. Bolting MCP on top of an outline-first data model is non-trivial; we'd be surprised to see it ship in 2026. Bcontext was built MCP-first: the typed graph is exactly the shape an MCP server wants to expose.
The importer runs both ways. Keep your existing tool live, add bcontext as the agent surface, decide later.