The first generation of business intelligence tools — Looker, Tableau, Metabase — was built around a clear primary user: a human analyst writing queries, building dashboards, and sharing links. When large-language-model agents started doing data work, they ignored these tools entirely. They hit the database directly, ran SQL, returned text, and moved on.
That created a problem nobody quite named. Humans lost visibility into what agents were doing with the data. Agents lost the audit trail, provenance, and reproducibility that dashboards provided for free. Each side was operating with half the context.
BitBoard, which launched on Hacker News this week as part of YC P25, is the first product to argue that the workspace itself should be the shared primitive. This article walks through what that means, why the technical choices matter, and what it signals about where business intelligence is going.
The problem BitBoard is actually solving
If you have watched a team try to integrate LLM agents into their data stack in 2026, you have probably seen this pattern. The agent is given database credentials. It runs queries directly. It produces a text answer in Slack or a notebook. Nobody knows what it queried, what assumptions it made, or whether the underlying data has shifted since.
Meanwhile, the team's BI tool still exists, with carefully built dashboards that the agent never opens. Two parallel analytics workflows are running on the same database, neither aware of the other.
The cost of this split is real:
- Provenance loss. When an agent writes "revenue dropped 12% last quarter" into a report, nobody can trace which query produced that number, against what data, at what time.
- Duplicated work. A dashboard already exists with that exact metric. The agent did not check.
- Trust erosion. Analysts stop trusting agent output because they cannot verify it. Agents are deployed for routine tasks but never trusted with anything that matters.
BitBoard's pitch is that all three problems disappear if humans and agents work in the same workspace, on the same datasets, with the same provenance layer, looking at the same dashboards.
What "shared primitives" actually means
The phrase is fuzzy until you see what it implies for the architecture. In BitBoard's model:
- The dataset is a first-class object with a stable identity, not an ephemeral query result.
- Every query — whether typed by a human or generated by an agent — is recorded against that dataset with full provenance.
- Dashboards are live views over datasets, and either a human or an agent can build them.
- The agent's outputs are not loose text in a Slack message. They are queries, datasets, and dashboard panels that another user can open, audit, and edit.
Think of it like a shared Google Doc, except the editors include both your data analyst and the agent that runs overnight to flag anomalies. Both can see what the other did. Both can build on it. The agent's work is not a black box that produced an opinion; it is a trail of artefacts you can step through.
The "agent or human" framing was a category error. The right primitive is the workspace they both work in.
Why DuckDB and Apache Arrow matter here
BitBoard is built on DuckDB — an in-process analytical database — and Apache Arrow, the columnar memory format. These choices are not incidental.
DuckDB runs inside the application process, which means queries do not require a separate database server, scale horizontally with the workspace, and stay close to the data. For an agent that needs to issue dozens of exploratory queries per task, the cost of round-tripping to a remote warehouse becomes the bottleneck. DuckDB removes that round trip.
Apache Arrow is the lingua franca of modern analytical tooling. Pandas, Polars, DuckDB, ClickHouse, and most ML libraries can all read and write Arrow tables without re-serialising. That matters in a shared workspace because the same dataset has to be readable by a human analyst in Python, an agent calling DuckDB, and a dashboard panel rendering visualisations — without anyone copying or converting it.
The combination — a fast in-process database speaking a universal columnar format — is what makes "shared primitive" technically affordable. Without it, every interaction between a human and an agent would involve a slow, lossy translation layer.
Where this pattern is going
BitBoard is one product, but the architectural shape it represents is broader. Compare the three generations of BI tooling:
| Generation | Primary user | Agent integration | Shared primitive |
|---|---|---|---|
| Legacy BI | Human analyst | None | Dashboard (human-only) |
| Agent-first | Autonomous agent | Direct DB access | None (parallel workflow) |
| Shared workspace | Human + agent | First-class participant | Dataset with provenance |
The third row is where the next several years of analytics tooling will be built. Not because the second row is wrong — it is too useful to abandon — but because the third row absorbs the second row without throwing away what the first row already knew about audit, provenance, and trust.
What this means for builders
If you are building anything in the analytics or agent-tooling space, three implications follow.
Design APIs assuming both human and agent consumers. Every endpoint, every dataset, every result should be addressable by either a person clicking a link or an agent following a reference. Outputs that only make sense in a human-rendered UI become invisible to agents. Outputs that only make sense in a raw API become invisible to humans.
Build provenance in from day one. It is much cheaper to track which query produced which result, against which data, at which time, when you design for it upfront. Bolting it on later means rewriting your storage layer.
Treat datasets as durable objects, not query results. If a dataset only exists as the output of an ephemeral query, neither humans nor agents can reliably build on it. Give datasets stable identities, versions, and references, the way you would a Git commit.
Conclusion
The interesting thing about BitBoard is not the product itself, which is early. It is that the framing has shifted. A year ago, the debate was whether agents would replace BI tools or coexist with them. That framing assumed they were separate things competing for the same job. The actual answer turning out is different: they were never separate things, and the workspace they share is the thing worth building.
The next generation of analytics infrastructure is unlikely to be either a better dashboard or a smarter agent. It is the connective tissue that lets the two operate on the same primitives. BitBoard is one early bet on what that connective tissue looks like.