Rule of thumb · Pick Tana if you're a power user who loves designing your own ontology and uses voice / mobile capture daily. Pick Bcontext if you want fixed defaults that work with Claude Code in 60 seconds via a real MCP.
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 export into the bcontext importer — pages become real nodes, while nested paths become reusable tags.
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 AI-first teams we've talked to, the same kinds come up over and over: docs, tasks, decisions, meetings, bugs, ADRs, skills. The variation is 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 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 stays low.
On agents, Tana's MCP gap is structural and acknowledged: an official MCP server sits on their public Ideas board as a community request, not as a shipped feature. The Input API is write-only and the read API is unverified in public docs. Bcontext was built MCP-first; the typed graph is exactly the shape an MCP server wants to expose, and the write tools are idempotent on day one.
The importer runs both ways. Keep your existing tool live, add bcontext as the agent surface, decide later.