Note: We make Atlas. This is a comparison written by the team that built it, not a neutral third-party review. Where Tana has the better answer for a given research job, the article says so plainly. See the table rows where Tana wins and the "When to choose Tana" section below. The goal is to give you the data you need to choose the right tool for the kind of work in front of you, not to convince you Atlas is the answer to every research job.

Atlas is a visual research workspace for people whose work depends on understanding a body of papers: a thesis, a treatment decision, a major-purchase teardown, a literature review. Tana is a supertag-driven outliner: bullet-based notes with typed "supertags" that turn nodes into database-like objects, and queries that surface nodes across the graph based on tag and field structure. Both tools touch a researcher's daily work, the wedge is what happens after the first answer. Atlas deconstructs each paper into a Knowledge Map (a visual map of the argument), projects a whole corpus into a Semantic Map, runs every answer through claim-source-justification (the citation-grounded surface that explains why a passage supports a claim), and compounds prior work into a persistent knowledge graph so projects get smarter the longer you use Atlas. Tana's brand, supertag system, and integration of outliner blocks with database-style queries are a genuinely fresh take on networked-thought personal knowledge management, the supertag-as-typed-object approach is well-executed for power users. If you need to trust the answers (for a thesis, a treatment plan, a brief, a hire), the visual maps, claim-source-justification, and compounding graph are where Atlas earns the comparison.

How is Atlas different?

Tana and Atlas overlap at the surface: both touch the work of reading and reasoning over sources. But they diverge on three capabilities that decide whether the output is shareable, defensible work. This section walks through the three differences, in order.

1. Visual maps of every paper and project

Atlas builds two kinds of visual map automatically as you read. A Knowledge Map deconstructs each paper into its argument structure: claims, evidence, definitions, and labeled relations between them (motivates, causes, enables, contradicts), laid out as a multi-level zoom. You see the paper's spine at the top level and drop into the supporting passages with a click. A Semantic Map projects your whole project (sources, notes, chats, citations) into a spatial canvas where related items cluster by topic, and you can re-project the same canvas under a new topic angle without re-reading anything. The Semantic Map is how 200 papers stop being a folder and start being a corpus.

"It's like an ultimate GPT. I can finally see what I've read." Kyle Lao, NUS researcher

Tana does not have a per-paper claim-evidence deconstruction or a topic-angle re-projection across an entire project. If you've ever spent an afternoon trying to recover the structure of a paper you read three weeks ago, the Knowledge Map is the surface that pays for itself first. Visual maps make a body of papers legible at a glance, and the multi-level zoom of the Knowledge Map is the surface Atlas is built around.

2. Every claim traces to a source, and Atlas explains why the source supports it

The hallucination problem in AI research tools isn't "the model made something up." It's "the model put a citation next to a claim that the cited passage doesn't justify." Atlas renders every answer as a claim-source-justification triple: the claim, the passage, and a one-sentence explanation of why the passage supports the claim. You can click into the source paragraph and read the highlighted sentences in context.

The benchmark Atlas runs internally is the H/V ratio: the proportion of generated sentences whose citation does not survive a passage-level re-check, divided by the proportion that does. Atlas targets H/V < 0.1 on the citation-grounding benchmark, and we publish how the benchmark is constructed in Verifiable AI Research (2026): What It Actually Means. Tana's answers may include citations or links to sources, but they're grounded at the sentence-citation level (or not at all), not at the claim-justification level. For most casual question-answering the gap doesn't matter. For a thesis sentence, a legal brief paragraph, or a treatment-decision summary, it does. The wedge in one sentence: every claim traces to its source, and Atlas explains why the source justifies it.

3. Your projects compound: the second month is 10× the first

Tana treats each session (or project, or workspace) as a separable container: work goes in, an answer comes out, and the next session starts fresh. Atlas builds a persistent per-user knowledge graph across projects: every citation you jump to, every annotation you make, every Knowledge Map and Semantic Map you generate accumulates into a four-layer graph (citations + mentions + KMs + SMs) that the next chat can draw from. Open a new project on a related topic and Atlas can pull in the relevant sources, prior annotations, and chat history without re-ingesting.

This is the capability we hear about most from long-term users: the second month is 10× the first because the graph has something to work with. John Tan, a postdoc using Atlas for a multi-year literature review, describes it as "the only tool where the work I did last semester is still doing work for me this semester." Put plainly: projects get smarter the longer you use Atlas. Tana does not have an equivalent persistent compounding graph across projects, which is the wedge for sustained, multi-month research.

Try Atlas: Sign up for an evaluation sample (10 sources · 5 lifetime AI chats) and run a Knowledge Map on one of your own papers. Used by researchers at NUS, NTU, SMU, and eight other universities.

Comparing Atlas and Tana

Both Atlas and Tana touch a researcher's daily work, but they live in different categories. Atlas spans paper deconstruction, project navigation, source-cited AI answers, and compounding context across a research corpus, Tana spans supertag-driven outliner personal knowledge management with structured queries. Tana's integration of structure into the outliner is broader as a personal knowledge management substrate, Atlas's research depth at the citation surface is deeper. The rest of this article walks through the five capability surfaces where the two tools differ: per-paper deconstruction, project-level navigation, source-cited answering, literature-grounded annotations, and compounding context across projects. Each section is a two-column table where every row is a real capability, and at least one row in each table is one where Tana wins or ties.

Paper deconstruction (Knowledge Map)

The Knowledge Map is Atlas's per-paper surface. It deconstructs a single paper into a multi-level argument structure with labeled relations between claims, faithful-to-source nodes (the node text comes from the paper, not from a generated summary), and hierarchical breadcrumbs that let you read down from the high-level thesis to a specific paragraph.

Good to know: The bottom row belongs to Tana. Atlas does not ship that surface. The Knowledge Map's payoff is recovering a paper's argument three weeks after you first read it, when topic chips alone are no longer enough.

Project / corpus view (Semantic Map)

The Semantic Map is Atlas's per-project surface. It projects all the sources, notes, chats, and citations in a project into a spatial embedding where related items cluster by topic. Re-project the same canvas under a different topic angle without re-ingesting anything.

Good to know: Tana's strength on that row is genuine. If your work depends on it, that's the boundary. The Semantic Map's payoff is when 200 papers stop being a folder and start being a corpus you can re-project under different topic angles without re-reading.

Citation-grounded answers

Atlas produces claim-source-justification triples: the claim, the passage, and a one-sentence explanation of why the passage supports the claim. You can jump to the source paragraph, read the highlighted sentences, and check whether the reasoning holds.

Good to know: Both tools have a citation surface, the wedge is whether the surface explains why a passage justifies a claim, not just which passage was cited. For everyday Q&A the gap is invisible, for a thesis sentence or a brief paragraph it's the whole game.

Literature-grounded annotations

Atlas auto-annotates each paper on ingest. Citations inside the paper become first-class objects: Atlas resolves the cited source (when open-access), pulls the relevant passage, and lets you see how a citation in the paper builds up its argument across multiple sources without leaving the document.

Good to know: Literature-Grounded Annotations resolve citations inside the paper you're reading. When a paper cites a source that's open-access, Atlas pulls in the cited passage. It is not a web-grounding feature, it is a way to see how a single paper builds its argument across the sources it cites.

Compounding context across projects

Atlas builds a four-layer persistent graph (citations + mentions + KMs + SMs) across all your projects, so chats, annotations, and maps from one project become context for the next.

Good to know: Compounding is the slowest capability to demonstrate in a demo and the biggest payoff in week eight. If your work is many small, unrelated projects, Tana's session-isolated design is the right choice, isolation is a feature, not a gap. Compounding pays off for sustained, multi-month research.

Price comparison

Atlas is a paid product. There is no perpetual no-cost plan, you get a short evaluation sample (10 sources · 5 lifetime AI chats), and after that you pay $20/mo or $204/yr for Atlas Pro. At the paid tier, Atlas is the only tool with Knowledge Map, Semantic Map, claim-source-justification, and compounding graph. You aren't paying for chat tokens, you're paying for capabilities that Tana doesn't have at any tier.

When to choose Atlas vs Tana

• Want paper structure deconstructed multi-level? Go with Atlas. (Knowledge Map)
• Want answers that explain how each citation justifies the claim? Go with Atlas. (claim-source-justification)
• Want your projects to compound over months? Go with Atlas. (4-layer graph)
• Want a supertag-driven outliner with database-style queries? Go with Tana.
• Tied: keeping a structured database of papers you read with custom fields**: both work fine, different jobs. The wedge only opens up once you're building a corpus you'll return to.

Recommendations by user type

• PhD researchers: Atlas. Lit-review-heavy years 1–2 benefit most from the Knowledge Map (deconstruct each paper without re-reading). Thesis-writing years 3–4 benefit from claim-source-justification (every thesis sentence anchored to a passage). Tana works for one-off tasks, the multi-year compounding graph is what makes Atlas the right tool here.
• Students doing literature reviews and thesis research: Atlas, scoped to research workflows (dissertation, thesis, literature review). The Knowledge Map is the largest time-saver in the lit-review phase, and the compounding graph keeps prior work accessible across semesters.
• Knowledge workers (consultants, analysts, PMs, journalists): Atlas when reading PDFs and citing them is the core work, Tana when supertag-driven structured personal knowledge management is the daily need.
• Personal researchers with stakes (medical, legal, major-purchase, deep autodidact): Atlas. Burst-usage research where the stakes are high (medical, legal, major-purchase, deep autodidact) is exactly where citation-grounded reasoning earns its keep. Tana is a fine starting tool, Atlas is the tool you graduate to once you realize you'll need to defend the answer.

The honest one-liner across all four segments: if the research compounds, Atlas is the bet, if each session is self-contained and the next one starts fresh, Tana's form is genuinely the better fit, and we'll say so plainly. The expensive mistake is using a session-isolated tool for compounding work (every project pays the re-ingestion tax) or using a corpus tool for one-off questions where simpler tools are faster. A useful diagnostic: ask whether you expect to come back to the same corpus in three months. If yes, the project-graph approach carries its weight, if no, lighter tools win on friction. Most research workflows we hear from at universities (Cambridge, Harvard, MIT, Stanford) sit firmly on the "yes" side: the corpus is the same corpus across semesters, advisors, and grant cycles, which is the cohort Atlas is built for. The corollary is that picking the right tool is mostly a question about your work pattern, not a question about which feature list is longer, both tools do their job well within the form they're built for.

Migrating from Tana to Atlas

Tana's data model is the part of the migration that needs the most attention before you export anything. A Tana workspace is a graph of bullet nodes, supertags promote those nodes into typed objects with custom fields (a #paper supertag might add authors, year, doi, status, verdict), queries surface those nodes by tag and field across the workspace, and AI commands act on the structured fields. The supertag schema, the queries, and the AI commands are the part of Tana that is genuinely doing work for you, and they are also the part that does not have a direct analog in Atlas.

What migrates cleanly: markdown export. Tana can export a node (or a workspace) as markdown or JSON. The bullet text, nested bullets, and inline references render as plain markdown lists with reasonable fidelity. Any PDFs you attached to Tana nodes are files on disk and can be uploaded directly to Atlas, where ingest will deconstruct each one into a Knowledge Map and add it to your project. Highlights you captured as bullet text under a #paper node can be pasted into Atlas as a note alongside the source, and the citations Atlas resolves on ingest will overlap with the ones you tracked manually.

What does not migrate: the supertag schema (Atlas does not have typed tags with custom fields), the saved queries (Atlas does not have a query language over outliner blocks, the navigation primitives are the Knowledge Map, the Semantic Map, and search), and any AI commands wired to supertag fields (Atlas's AI is anchored to sources and project context, not to user-defined field structures). If your Tana setup leans heavily on a supertag pipeline (for example: capture → triage → #paper with status:to-read → query for unread papers → AI summarise), that pipeline has to be re-thought rather than re-built. The Atlas-native equivalent is: upload the PDF, let ingest produce a Knowledge Map, use the project as the unit of organisation, and let the four-layer graph accumulate.

The pragmatic migration path most users take: keep Tana running for the supertag-driven workflows that are already paying off, export the research-adjacent subset (papers, highlights, source notes) as markdown, upload the PDFs to a new Atlas project, and let Atlas rebuild the structure from the source side rather than from the tag side. After a few weeks the Atlas project carries its own navigation through Knowledge Maps and the Semantic Map, and the question stops being "how do I port my supertags" and starts being "which jobs belong in which tool."

A worked example: literature-review section from 8 papers

A concrete scenario makes the difference between the two tools easier to see. Imagine you have eight papers on a single sub-topic (say, retrieval-augmented generation for biomedical question answering) and you need to write the literature-review section: roughly 1,500 words that situates the work, names the open problems, and cites every claim back to a passage. This is the kind of task both tools can touch, and it is also the task where the underlying model of each tool starts to matter.

In Tana, the typical setup is a #paper supertag with fields for authors, year, method, dataset, and a free-text key_findings. You read each paper, capture the findings as nested bullets under the supertagged node, and tag the bullets with sub-topic tags (#retrieval, #hallucination, #evaluation). When you start drafting, you run a query: "all bullets under #paper tagged #hallucination from 2023 or later." Tana returns the matching bullets across the eight papers, and you compose the paragraph by hand from those bullets. The structure works, the labour is in the capture step (you have to have read carefully and tagged accurately) and in the synthesis step (the query returns bullets, not arguments, so the connective tissue between findings is on you).

In Atlas, the eight papers go into a single project. On ingest, each paper gets a Knowledge Map: claims, evidence, and labeled relations between them, with faithful-to-source node text. You read the Knowledge Map first (a few minutes per paper) to recover the spine of the argument, and you click into the source paragraph for any node you want to verify. Once all eight maps are in the project, the Semantic Map projects the sources, notes, and chats into a spatial canvas, re-project under "hallucination" and the relevant nodes from all eight papers cluster together regardless of how the original papers framed the issue. When you ask Atlas to draft a paragraph on hallucination across the eight papers, every sentence in the draft comes back as a claim-source-justification triple: the claim, the passage from one of your eight papers, and a one-sentence explanation of why that passage supports the claim. You click through, verify, edit, and the paragraph is ready to defend.

The labour shifts. Tana asks for careful capture and manual synthesis. Atlas asks for careful reading of the Knowledge Maps and verification of the citation-grounded draft. The Tana path produces a query result, the Atlas path produces a defensible paragraph with the reasoning trace attached. For an eight-paper section that you will defend to an advisor or a reviewer, the verification step is the one that matters, and that is where the claim-source-justification surface earns the comparison. For a quick personal summary you will never share, either path works, the gap only opens when the output has to survive scrutiny.

When Tana is the right call

There are real research-adjacent workflows where Tana is the better starting point and we will say so plainly. Three patterns come up repeatedly.

The first is structured database use cases. If your actual job is to maintain a registry (a list of grants you have applied to, a CRM of collaborators with status fields, a database of experiments with parameters and outcomes), the supertag-and-field model is the right tool and Atlas does not try to replace it. Atlas's organising primitive is the project, not the typed record, if you need typed records with custom fields and queries across them, Tana is doing a job Atlas does not do.

The second is supertag-driven daily workflows that wrap around capture and triage. A daily-note workflow where you dump tasks, notes, and bullets, then promote items to typed supertags as they crystallise (#todo, #meeting, #decision), is exactly what Tana's outliner-plus-supertag model is built for. Atlas's surface is research-first (sources, annotations, maps, citations), not capture-first, for the daily inbox, Tana's form fits better.

The third is voice-to-text capture. Tana Capture lets you push audio or quick text into the workspace from a mobile device and have it land in your inbox tagged and ready to triage. If a meaningful slice of your inputs is captured on the move, that capture surface is doing real work that Atlas does not try to match.

The overlap with Atlas is the research corpus specifically: the body of papers you read, the annotations you make on them, the arguments you build from them, the answers you cite back to them. Outside that overlap, Tana's form is genuinely the better fit and the right recommendation.

Common objections and edge cases

My Tana workspace is huge. Will Atlas feel like a downgrade because it does less?

It will feel narrower, and that is by design. Atlas is built around the research corpus, not the whole life-personal knowledge management stack. Most users who keep Tana for general personal knowledge management and add Atlas for research do not experience this as a downgrade, they experience it as the right tool finally appearing for the job that was hardest in Tana (deconstructing papers and grounding answers). If your Atlas use ends up substituting for your full Tana workspace, that is a sign one of the two is being used outside its fit, Atlas is not built to replace Tana's general structured personal knowledge management and does not try to.

Can I get the Knowledge Map view without uploading the PDF (e.g. for a paper I can only access through an institutional reader)?

The Knowledge Map is generated on ingest, which requires the PDF (or the text) to be uploaded. If you can copy the text out of the reader, you can paste it as a source, if the paper is fully locked behind a reader, neither tool can deconstruct it. For open-access papers and most preprints, the upload path is straightforward.

I already have a Tana query that pulls every paper with status:to-read. Does Atlas have an equivalent?

Not in the query-language sense. The Atlas equivalent is project-level navigation: sources, annotations, and chats live inside a project, and the Semantic Map plus search is the navigation surface, not a query DSL. If query-driven retrieval over typed fields is central to how you work, Tana's form is the better fit for that specific job, and many users keep both tools for that reason.