Nao vs Contextflo: which analytics agent fits your team?

Nao and Contextflo are chasing the same problem from different ends, and they say a lot of the same things about it. Both start from the observation that pointing a data team at raw Claude plus an MCP server does not scale: everyone runs their own local setup, and nothing about the context or the audit trail is shared across the company. Nao's own comparison pages make exactly that argument. So does mine. The real question is not who is right about the problem, it is which shape of answer fits your team. I run Contextflo, and the two products overlap more than any other pair I have written about.

What Nao is

Nao is an open-source analytics agent. You build the agent's context with a CLI (pip install nao-core, then nao init, nao sync, nao chat), and once it is dialed in you deploy a chat UI that anyone in the company can use to ask questions in plain language. It is licensed under Apache 2.0 and you can self-host the whole thing, including an end-to-end deployment on something like Cloud Run with Postgres.

The design idea worth understanding is context-as-files. Nao treats the agent's context like a file system: markdown definitions, YAML config, dbt references, business rules, and example queries, all of which you can keep in git and review through pull requests. It syncs metadata from your warehouse (BigQuery, Snowflake, Databricks, Postgres) and pulls from repos and business tools. It is dbt-native, and dbt teams get the fastest time-to-value because their models and lineage feed the context directly. It also ships something most tools in this space do not: a built-in evaluation step. You write test files with questions and expected SQL, run nao test, and measure whether the agent still answers correctly before you deploy a change.

That is a serious tool built by people who clearly know the data-team workflow. If your instinct is to own your stack, keep your definitions in version control, and prove the agent works before shipping it, Nao is built for you.

What Contextflo is

Contextflo is a hosted context layer. Instead of adopting a new agent and a new chat UI, your team asks in the Claude or ChatGPT app they already have open, connected over MCP. The model writes and runs real SQL against your data, and the answer comes back in the chat with the query shown so anyone can check it. Underneath, Contextflo does the jobs you open a BI tool for: dashboards, scheduled reports, governed metric definitions, and access control, where admins set which schemas and tables each person or group can query, with every query attributed to a user and logged.

Two things it does not ask of you: run the software, or write the context by hand. Contextflo generates the context from your schema, source code and docs, and re-syncs schemas daily as they change. Setup runs about ten minutes because there is no modelling project and no CLI to configure.

Who each is for

Nao suits a technical data team that wants to own and operate the agent. You are comfortable with a CLI, you want the code in your own infrastructure, your definitions already live in dbt, and you value being able to eval the agent before rollout. That is a real and defensible set of preferences.

Contextflo suits a team that would rather not run or configure the layer at all, wants access control and audit managed for them, and wants answers to show up inside the Claude or ChatGPT window people already use rather than in a separate app. Tilt, a live-auction marketplace for limited-edition goods, runs about 6,000 queries a month this way with a one-person data team and most of the company self-serving.

The five axes

Where Nao wins

Four of these are not close.

Nao is open source and self-hostable. You get the code under Apache 2.0, you can run it entirely inside your own infrastructure, and nothing about your data has to leave. Contextflo cannot match that. If self-hosting is a hard requirement, the comparison ends here in Nao's favor.

It is also dbt-native. If your semantic layer already lives in dbt, Nao consumes your models and lineage as first-class context and your team gets value faster. Contextflo generates context from schema, code and docs and does not lean on dbt, which is the wrong trade if dbt is the center of your world.

The context is git-versioned and reviewed. Definitions live in files you edit, diff, and approve through pull requests. That is the workflow a lot of data engineers actively want, and it makes the context checkable in a way a generated layer is not.

And there is a real eval loop. Being able to run nao test and confirm the agent still returns the right SQL before you ship a context change is something Contextflo does not offer today, and for a team that treats the agent as production software, that gap is significant.

Where Contextflo wins, and where it just matches

On several axes Nao matches Contextflo rather than trailing it. Two differences are real; the rest are ties.

Start with the ties. Both products give you central context and a shared audit trail, which is the whole reason either exists. Both let you use Claude's model (Nao behind your model key, Contextflo through the Claude app itself). Both keep example or golden queries and business definitions in context. Both show the SQL behind an answer. If you read a claim that Contextflo alone solves "no central context, no shared audit," that claim is wrong, because Nao solves it too. The difference is how.

The two real differences. First, the agent and where answers land. Nao asks your whole company to adopt a new chat UI. Contextflo puts the answers inside the Claude or ChatGPT people already use, and adds dashboards and scheduled reports for the BI jobs a chat window does not cover. Neither is strictly better; a single governed UI is easier to lock down, while meeting people in their existing tools is easier to adopt. Pick the friction you would rather carry.

Second, who does the work. With Nao you engineer the context and operate the software. With Contextflo the context is generated for you and the access control is enforced at query time, table by table, before anything reaches the warehouse, with per-user audit, all managed. Nao's docs describe central audit logs and approval gates but do not spell out table-level, query-time access control the way Contextflo does, so if that is decisive for you, verify it against Nao's current docs rather than taking my word for it.

The one honest limit

You do not own Contextflo. It is a hosted, closed service, so you cannot run it in your own infrastructure or read its code, and there is no built-in eval harness like nao test to prove the agent before you ship. On top of that, the generated context is a draft someone should review rather than a finance-signed-off, versioned model, and access control is table-level, not row-level. For a team whose starting requirement is "we self-host everything and we gate every change behind a test," Nao is simply the better fit and I would tell you so.

If none of that is a blocker, Contextflo is free for one user and one data source to try, and you can ask a question about your data in Claude within about ten minutes.

How to choose

Answer one question first: do you want to own and run the agent, or do you want it run for you?

If you want to own it, self-host it, work dbt-native, keep context in git, and eval it before rollout, Nao is the stronger pick and a genuinely good piece of software. If you would rather have the access control and audit managed, the context generated instead of hand-written, and your team asking in the Claude or ChatGPT they already use, Contextflo is built for that. Both beat the thing they were each reacting against, which is a room full of people running their own local MCP setups with no shared context and no audit at all.

FAQ

Is Nao open source, and can I self-host it? Yes. Nao is licensed under Apache 2.0 and you can run the whole thing yourself, including an end-to-end self-hosted deployment on something like Cloud Run with Postgres. That is a real advantage if owning the code and keeping everything in your own infrastructure matters to you. Contextflo is a hosted service and is not self-hostable.

Does my team have to use Nao's chat UI, or can they stay in Claude and ChatGPT? Nao deploys its own chat interface that you roll out company-wide, and you plug in your own model key (Claude, OpenAI) behind it. Contextflo takes the other route: your team asks in the Claude or ChatGPT app they already have open, connected over MCP, so there is no separate destination to adopt. Which one is better depends on whether you want a single governed UI or answers inside the tools people already use.

Is Contextflo dbt-native like Nao? No. Nao is dbt-native and dbt teams get the fastest time-to-value from it, since your models, lineage and definitions feed the agent's context directly. Contextflo generates context from your schema, source code and docs and does not require dbt. If your semantic layer already lives in dbt, that is a point for Nao.

Which should I pick, Nao or Contextflo? Pick Nao if you have a technical team that wants to own the stack, self-host, work dbt-native, keep context in git, and run built-in evals on the agent before shipping it. Pick Contextflo if you want a hosted layer with query-time table-level access control and per-user audit managed for you, context generated automatically rather than hand-engineered, and your team asking in the Claude or ChatGPT they already use.