Why we're making our Analytics Agent open source

Open source should not be a marketing strategy.

When we released our first fully open source product, we looked hard at other open source companies and found two categories: those where open source genuinely served the product — and those where open source only served distribution. We wanted to be in the first category, not the second.

For us at nao, it is a full commitment. We build both our code and our company in the open. That means being transparent about our decisions, our product roadmap, everything. Our roadmap for the next four months is public on GitHub milestones.

So why open source for an analytics agent? Three reasons that matter in practice:

• We want to establish a context engineering standard for data teams. No gatekeeping. A community that practices and improves this together.
• Data teams need to customize their analytics agent — context providers, custom tools, UI specificities. Open source makes that real.
• When you self-host, you are in full control of your data and LLM interactions. No data leaves your environment unless you decide it does.

That is the commitment. Here is the full reasoning behind it.

The trust gap in analytics agents

Analytics agents promise to democratize data — let anyone ask a question and get an answer.

But here's the paradox: the data team is the gatekeeper of trust, and most agents give the data team no tools to verify how the agent reasons.

When an agent gets your churn rate wrong, you can't tell if it missed a table join or misread a column description. When it picks the wrong data source, you can't see what context it assembled. When it ignores your dbt docs, you have no way to trace why.

Vendors treat their context pipeline as a competitive advantage — which means it's opaque by design.

The very thing that determines whether the agent is reliable is the thing you can't inspect.

Every data leader I talk to says some version of the same thing:

"I'm excited about analytics agents, but I'm not comfortable putting this in front of my CEO yet."

That's the trust gap. You can't close it with better marketing or a nicer UI.

You need to open the box.

Why open source is the answer

Open source solves the trust problem at the architectural level.

You can read the code. When nao builds context for a query, you can trace every step — which files were selected, how they were assembled, what rules were applied. If the agent gets an answer wrong, you can see exactly what happened and fix it.

You can own your context. Context lives as files in a git repo — markdown definitions, YAML configs, dbt references, rules, example queries. You version it, review it in PRs, deploy it like code. Not locked inside a vendor's UI.

You can audit the evaluation. nao test is in the same open source repo. You can see how test suites work, how metrics are computed, how context changes affect performance. If you trust an agent with business decisions, you should be able to audit the code that says "this is good enough."

You can leave. This is the one no vendor wants to talk about. If your context — your curated representation of how your business works — lives inside a closed product, you're locked in at the most strategic layer of your stack. With nao, you take your files, your tests, and your rules to any other tool or model.

We think earning your trust every day is a better business model than trapping your knowledge.

Trust requires a community, not just a vendor

There's a deeper reason beyond code transparency.

Context engineering — designing and optimizing the information agents use to reason — is still a very young discipline.

Nobody has figured out the best practices yet. Not us, not the warehouse vendors, not the BI tools. We're all experimenting.

The question is: do those experiments happen in isolation inside closed products? Or in the open, where everyone can learn?

I think about how dbt changed data transformation. Before dbt, every data team wrote custom SQL scripts. No shared patterns, no common language. dbt gave the community a framework to converge on — and the best practices that emerged are now the standard.

Context engineering needs the same thing. The full case for an open context framework is in Why data teams need an open framework for context engineering.

I keep meeting data teams building their own context stacks from scratch:

• Scripts to pull schema stats
• Jobs to sync dbt docs
• Notebooks with curated queries

Right instinct, but fragile and siloed. Nobody learns from anyone else's experiments.

Open source is how we turn isolated experiments into shared knowledge.

That's the real argument — not just that you can read our code, but that the entire discipline matures faster when the framework is open.

For the technical details, see Why we need an open framework for context engineering.

What this means for you

If you're evaluating analytics agents, here's what open source means in practice.

Start small. Install nao, point it at your warehouse and dbt project, write a few context files for your most important metrics. Test it on your stakeholders' top 10 questions. No procurement cycle, no vendor call, no commitment.

Inspect everything. When the agent gets something wrong — and it will, because all agents do — you can see why and fix it. That's the difference between a toy demo and a production deployment.

Contribute. Found a better way to structure context for revenue metrics? A smarter evaluation strategy? Share it. The whole community benefits.

For the launch story and full vision, read We're launching the first Open Source Analytics Agent.

Ready to try it? Head to GitHub and start building.

I'm curious — what would make you trust an analytics agent enough to deploy it to your whole company?