The interesting product launches in AI right now are not the ones that show off model capability. They are the ones that show off product shape — how an interface should work when one of the users is a long-running agent and the other is a human.
BitBoard (YC P25), which launched on Hacker News this week, is a clean example. It is an analytics workspace — dashboards, queries, datasets — but designed from the start to be operated by humans and AI agents working on the same artifacts. Underneath, it uses DuckDB (an in-process analytical database) for query execution and Apache Arrow (a columnar memory format) for moving data between components.
The product itself is a piece of business intelligence (BI) tooling. The design pattern is broader than BI. This article looks at what BitBoard is, the specific engineering choices that make it work, and the general pattern — shared primitives, provenance, and reviewable artifacts — that builders should be stealing for their own products.
What BitBoard actually is
The team's own description, paraphrased from their Launch HN post: BitBoard is a collaborative analytics workspace where teams and AI agents share dashboards, queries, and datasets, with verifiable provenance for every result.
Three things are worth flagging from that sentence.
Agents are first-class users, not bolted-on features. Most analytics products have added a "chat with your data" button in the last eighteen months. BitBoard inverts the design: the agent is one of the operators of the workspace, not a feature inside a human-only interface. That is a different starting point and produces a different product.
The primitives are shared. A dataset created by an agent is the same kind of object as a dataset created by a human. A dashboard is a dashboard regardless of who built it. There is no separate "agent output" surface that humans then approve into the real product. The workspace has one object model.
Every result has provenance. Every query result, every chart, every transformed dataset carries metadata about where it came from — the SQL that produced it, the source tables, the agent or human who initiated it. This is the part that makes the agent collaboration safe for use against real business data.
The team's founding story is also notable: they pivoted from building healthcare administrative agents after watching their customers struggle with the underlying data analysis. The pivot is a useful tell — they did not start by thinking "AI plus BI." They started by watching what agents actually needed to be useful, and shipped the workspace those agents required.
The engineering choices that matter
A surprising amount of what makes BitBoard interesting sits in the choice of underlying components. Three are worth pulling apart.
DuckDB as the query engine. DuckDB runs in-process, executes analytical SQL fast on local data, and reads Parquet, CSV, and Arrow directly without an ETL step. For an agent workspace, this matters because agents iterate quickly — they want to run twenty exploratory queries to figure out what is in a dataset, then a few targeted ones to answer the actual question. A traditional warehouse round-trip would make that pattern miserable. DuckDB makes it feel local.
Apache Arrow as the data interchange format. Arrow is a columnar in-memory format designed so that different tools (Python, JavaScript, Rust) can read the same buffers without copying. In an agent workspace, this lets the agent's reasoning pipeline, the visualisation layer, and any user-facing UI work against the same data without serialisation overhead at each hop. Agents are token-expensive and latency-sensitive; cutting copies between layers compounds.
Provenance as a first-class column, not an afterthought. Most data products treat lineage as something you reconstruct later from logs. BitBoard appears to attach provenance to the artifact itself, so a chart "knows" which query produced it, which dataset that query ran against, and which agent or human asked. This is the only way a long-running agent and a human reviewer can look at the same dashboard and agree on what it means.
Provenance is what turns "the agent built a chart" into "the agent built a chart you can audit and trust."
The combined effect of these three choices is a workspace where an agent can do a meaningful amount of analytical work — investigate a metric drop, build a draft dashboard, transform a dataset — and produce artifacts a human can review without having to recreate the work from scratch.
The pattern beneath the product
Step back from BI for a moment. The pattern BitBoard is implementing applies to almost any domain where you want long-running agents and humans to collaborate on shared output. It has three components.
Shared primitives. Agents and humans should operate on the same objects, not parallel copies. If the agent writes a "draft" and the human edits the "real version", you have two systems to keep in sync and a constant integration cost. One object model, with edits tracked but the object identity preserved, eliminates that cost.
Provenance attached to artifacts. Every artifact records how it was produced. This is what makes review possible. The reviewer does not need to trust the agent in the abstract — they can look at the chart and see exactly what query, what data, and what reasoning step produced it.
Approval as a first-class action. The agent produces work continuously; the human signs off in discrete decisions. The interface should make those decisions cheap. A clear pending/approved state, an obvious diff between agent output and prior baseline, a single click for the common cases.
The pattern shows up in other recent products too. Coding assistants that produce pull requests for humans to review have exactly this shape: shared primitive (the PR), provenance (the diff plus the prompt), approval as a first-class action (merge or close). Document-drafting tools moving in the same direction. The interesting thing about BitBoard is that it applies the pattern to analytics, where the artifacts are queries, charts, and datasets rather than code.
| Domain | Shared primitive | Provenance | Approval action |
|---|---|---|---|
| Software engineering | Pull request | Diff plus prompt history | Merge or close |
| Analytics (BitBoard) | Query, chart, dataset | SQL plus source tables plus agent step | Promote to dashboard |
| Document drafting | Document version | Edit history plus model prompts | Accept or reject changes |
| Customer support | Conversation reply draft | Source documents plus model trace | Send or revise |
This is the shape of useful agent-assisted products. The agents are not novelty features; they are operators of the same workspace humans use, producing artifacts that humans review through native workflows.
Where the pattern breaks down
It would be misleading to suggest this pattern is finished. Three open problems show up in every implementation, and BitBoard's launch does not yet resolve them publicly either.
Long-running coordination. When an agent is investigating a metric drop and takes several hours to do it, what does the human see in the meantime? A spinner is wrong; partial drafts are confusing. There is no clear convention yet for how a workspace should represent in-progress agent work.
Conflict resolution. When the agent edits a dashboard at the same time as a human, who wins? Git-style merge in a visual workspace is awkward. Last-write-wins loses work. Lock-based editing makes the workspace feel single-user. Nobody has fully solved this.
Trust calibration. Provenance lets a human audit any single artifact, but humans cannot audit every artifact. The workspace has to surface which artifacts deserve attention and which can be trusted by default. Today this is mostly heuristic — first runs are reviewed carefully, repeated patterns earn trust over time — but the explicit mechanics are still missing.
These are interesting problems to watch. The product that solves them well will set the template for agent-assisted workspaces in every domain.
What this means for builders
If you are building a product where humans and agents share output, BitBoard's design choices generalise into three concrete recommendations.
Pick a fast local query engine for any agent-facing data work. Whether or not you use DuckDB specifically, the principle holds: agents iterate, and iteration is killed by round trips. An engine that runs in-process and answers small queries in milliseconds will produce a meaningfully different product than one that requires a network hop and a warehouse warm-up.
Build provenance into the artifact, not into a separate audit log. Audit logs are read by no one. A chart that carries its own provenance — visible on hover, exportable with the artifact, durable across copies — is one a human can actually review. Treat lineage as a property of the data, not a separate compliance feature.
Design one object model for humans and agents. Resist the temptation to add a "drafts by AI" pane that is separate from the real workspace. The agents and humans should operate on the same primitives, with edit history tracking authorship. The integration cost of parallel systems shows up later and is hard to remove.
Conclusion
BitBoard is a useful launch to study because it is opinionated in the right places. The opinions — agents as primary users, provenance as a property of artifacts, a shared object model — are the ones that turn AI features from novelty into useful infrastructure. The DuckDB and Arrow choices follow from those opinions.
The broader takeaway is that the next generation of agent-assisted products will not be the ones with the smartest models. They will be the ones with the cleanest collaboration model — where a human and an agent can look at the same artifact, agree on what it means, and act on it without re-doing each other's work. That is a product design problem, not a model capability problem, and BitBoard is one of the clearer attempts at it so far.