Most companies are flying blind through their own data.

Every data-heavy company eventually meets the dashboard that used to matter. It was urgent when it was built, confusing six months later, and quietly wrong once the business changed around it. This is the typical lifecycle of a dashboard. It is not anyone's fault. It is the format.

For a decade, business intelligence has been organized around a wrong assumption: that the answer to "more decisions, better and faster" is more dashboards, more tiles, more SQL. The result is what you'd expect. Dashboards multiply faster than decisions get easier. Analysts spend too much time on reporting and reconciliation, not analysis. The CEO asks the CFO a question; the CFO asks the analyst; the analyst asks the data engineer; the data engineer rewrites a query she wrote three months ago for a question that has since changed.

We started Arcus because we believe this is the last era where this is acceptable. Not because the technology is finally ready — though it is — but because the cost of slow, untrustworthy decisions has gotten high enough that companies have to pay attention.

Belief 01The right unit of work is a question, not a dashboard.

Dashboards are an archive. They are useful when you know exactly what you want to monitor and the world is not changing. The world is always changing. The questions worth asking next quarter are not the questions worth asking this quarter.

A question is small, scoped, and disposable. It can be a four-word Slack message. It can be a 90-minute investigation that produces a memo. It is the smallest unit of work that produces a decision.

When the unit of work is the question, three things change. First, the friction of asking drops to near zero, which means people ask more — and ask better. Second, the artifact of the work is the answer, not the dashboard. Answers are smaller, more shareable, and easier to verify than dashboards. Third, the system can remember the question and re-run it, which is what most people actually want when they say "I want a dashboard." They don't want a dashboard. They want yesterday's answer, today.

Belief 02The right interface is conversational, but not chatty.

There has been a wave of "chat with your data" products since 2023. Most of them are bad. They produce confident, fluent, wrong answers. They strip the lineage off the data so you can't verify. They flatter you instead of pushing back when you ask a poorly-formed question. They are, in the end, more dangerous than the spreadsheet they replaced.

A good conversational interface is not a chat window with an LLM behind it. It is a reasoning system that happens to expose itself in conversation. It thinks step-by-step, in public. It cites every number to a source row. It asks for clarification when it should. It says "I don't know" when it doesn't, and it tells you what it would need in order to know.

We've made hundreds of decisions about what good conversation should feel like. A few of the ones we feel strongly about:

1. Show your work. Every artifact has a one-click view of the SQL, the model used, and the source rows. If a number can't be traced, the answer doesn't ship.
2. Be willing to disagree. If a user asks "did revenue go up?", and revenue went up by 0.3% within margin of error, the right answer is "no, not in any way that matters" — not a green arrow.
3. Refuse to fabricate. When the data is missing, the right answer is "I'd need X." When the data is conflicting, the right answer surfaces the conflict, not an averaged middle.
4. Respect the user's time. The conversational pattern is dangerous because it normalizes long replies. Most answers should be a number, a sparkline, and three sentences. Saving the user 90 seconds is more valuable than impressing them with 900 words.

The product we are building is, in some sense, the answer to: what would chat-with-your-data look like, if it were designed by people who actually do data work?

Belief 03Trust is the moat. Lineage is the trust.

The reason data products fail in production is not because they're slow or hard to use. It's because the team stops trusting the numbers. Once trust is gone, the dashboard becomes a starting point for an investigation, not an answer — and the team is back to spreadsheets within six months.

We obsess over lineage because lineage is what restores trust after it breaks. When the analyst, the CFO, and the head of growth disagree about whether revenue is up or flat, the right answer is not "let me check Looker." It is "click this number — see the SQL, see the source row, see the timestamp."

Most BI tools have abandoned this. Lineage was a feature in 2014. It got buried in 2018 because it was unfashionable. We bring it back because it is the only thing that matters when something is wrong.

Belief 04The next decade of work is operated on your behalf, not used by you.

Most software is something you open and use. The new pattern is software that runs while you sleep. The Friday brief that lands in Slack. The Wednesday alert that catches the CAC spike. The Sunday recap that's already on your desk Monday morning. Tools that do work, not just enable it.

This is a fundamentally different design problem. The user is not always present. The interface has to fail safely, recover quietly, and disclose its work in a form the user can audit a week later. Most software products are not designed for this — they are designed for presence. We are designing Arcus for absence.

The implication is that what you ask for and what you actually want are often different things. You don't really want a dashboard. You want yesterday's question, answered by Friday at 5pm, with the right people CC'd. You don't really want an alert. You want to be told before standup when something is breaking — and not told otherwise. We work very hard on the difference.

Belief 05Specialization is over. Or rather, it has moved.

For the last decade, the bottleneck of every growing company has been the same: not enough analysts. The cargo cult was to hire more. The reality was that hiring an analyst takes nine months to ramp, costs $180k all-in, and produces at best four investigations a quarter — which everyone agrees were the right ones to do six months later.

The bottleneck has moved. The new bottleneck is asking better questions. The teams that win this decade are not the teams with the biggest data org. They are the teams whose operators ask better questions and whose analysts spend their time on the questions that actually deserve a senior person.

This is what Arcus is for. The marketer asks the question — Arcus drafts the answer with full lineage. The analyst spends Monday building the model that the marketer's question revealed they need. The CFO reviews the answer and approves it. Three different people, three different jobs, one piece of work. The way analytics should always have worked.

Belief 06The model is not the product. The system around it is.

A reasonable observer in 2025 might say: "Aren't you just an LLM with a SQL connector?" That observation, charitably, conflates a model with a system. A model is a tool. A system is what gives the tool a world to operate in: a semantic layer, a lineage graph, a tool-call protocol, a safety boundary, a trust model, a memory, a way to fail.

We pay constant attention to model quality, because better models make our system better. But the model is interchangeable, and we treat it that way. The bet we are making is that the value compounds in the system — the semantic layer that aligns 14 sources into one truth, the audit log that survives ten model upgrades, the threading model that lets you go back six months and re-run an analysis with new data, the org-shape memory that knows which Mira asked the question. None of that is the LLM. All of it is what makes the LLM useful.

In ten years, the model behind Arcus will be a model that doesn't exist today. The system around it will be a recognizable descendant of the system we are shipping now. We design accordingly.

Belief 07A few things we refuse to do.

A manifesto without commitments is just an essay. We hold ourselves to these. If we ever break one, you have grounds to call us out:

• We will never train models on customer data. Not ours, not third-party. Not for "improvement." Not for "evaluation." This is enforced contractually and technically.
• We will never charge for seats with the explicit goal of suppressing usage. Read-only access is free for everyone in the workspace. The math has to work without your data team having to ration adoption.
• We will never ship an answer without lineage. If we cannot cite it, we will not ship it. Even if it's slower. Even if it's less impressive.
• We will never produce a confident wrong answer when we should produce an honest "I don't know." This is the hardest commitment to keep. We invest more in it than in any other quality.
• We will publish every security incident we have. Even the small ones. Even the embarrassing ones. The trust center is the receipt.
• We will not lock you in. Every thread, dashboard, and audit log is exportable. If you ever leave us, you take your work with you.

Belief 08What we owe the next generation of operators.

There is a generation of marketers, finance leaders, founders, and operators coming up right now who will never know what a Looker explore feels like. They will not learn SQL. They will not build a dashboard from scratch. They will work in environments where the data is conversational, the answers are auditable, and the agent is a colleague.

This is a transition the same shape as knowing how to format a memo in WordPerfect. A skill that mattered a great deal for a decade. A skill that nobody under thirty has now, and which they don't need.

What we owe this generation is a tool that doesn't make them dumber. It is easy, with conversational software, to produce fluent stupidity. Confident, articulate, wrong. The thing we work hardest on is making Arcus the rare conversational tool that makes its users more skeptical, more rigorous, more curious — not less.

A user of Arcus, three years in, should ask sharper questions, defend their answers more carefully, and respect the data more than a user of dashboards ever did. If we get this right, we have produced a generation of operators who think better. If we get it wrong, we have produced a generation that trusts answers it shouldn't. We know which side of that we are working on.

Belief 09What this is, and what it isn't.

Arcus is not a Looker replacement, though it can replace a Looker. It is not a "ChatGPT for data," though it answers questions in plain English. It is not a generic AI agent, though it does work on your behalf.

Arcus is a system for asking, answering, and acting on questions about your business — with the rigor of an analyst, the speed of a search bar, and the trust model of a financial audit. It is built for the operator in the room, the analyst behind the operator, and the founder behind both. It is built for teams of three and teams of three thousand.

If we describe it well, you should already have a sense of whether it's for you. If you've nodded along to most of this, we'd love to talk. If you haven't, we'd love to hear why — we'd like to know if we're wrong.