URI:
       [HN Gopher] Launch HN: BitBoard (YC P25) - Analytics Workspace f...
       ___________________________________________________________________
        
       Launch HN: BitBoard (YC P25) - Analytics Workspace for Agents
        
       We're Connor and Ambar from BitBoard (https://bitboard.work).
       BitBoard is an agentic analytics workspace. We give you the
       infrastructure and visualization layer to analyze data with AI.
       Today, we're launching dashboards that you and your agents can work
       on together. You can connect your coding agent or AI chat to
       BitBoard and build live reporting. Here's a demo:
       https://www.youtube.com/watch?v=HPl0K565a7c.  AI tools treat data
       analysis as ephemeral, making it hard to report or collaborate.
       Legacy BI tools weren't intended for AI users, so they bolt on
       chatbots and can't offer meaningful control to your agents.
       Software can now make far more of a business legible than BI ever
       could, but neither legacy BI nor chat bots are built to handle it.
       Our original product was AI agents for administrative tasks in
       healthcare (https://news.ycombinator.com/item?id=44237769), but
       customers kept pulling us toward their data analysis problems:
       queries scattered across disparate sources, spreadsheets floating
       everywhere. We kept building tooling for addressing that, and at a
       certain point those tools were becoming our product.  We ran into
       several problems. Agents made bad inferences because they had no
       context on the business. They couldn't be trusted to make decisions
       because nothing checked their work. And anything one agent or one
       person figured out was invisible to everyone else. In BitBoard,
       humans and agents interact with the same data primitives but get
       tools designed for their own work.  We're building dashboards to
       make the human reading experience better. These dashboards
       progressively use intelligence - starting from code or SQL queries
       and leading to full embedded apps. Humans and agents will need to
       agree on methods to interpret data, so we're letting both
       contribute to canonical sources, entities, and measures (using your
       favorite semantic model or ours). Every answer comes with
       provenance, and the same call with the same parameters returns the
       same number.  Looking ahead, these shared primitives let long-
       running agents operate inside a business, and we're building those
       agents too. An agent needs a measurable goal and a way to verify
       its work. BitBoard gives it both. The agent takes a problem like a
       metric drifting or a funnel leaking and figures out what to do
       next. Its work becomes datasets, dashboards, and traces that the
       team can observe and sign off on.  Technically, we're building a
       collaboration engine with isomorphic updates for humans and AI,
       columnar analysis (we use DuckDB and Apache Arrow), grounding and
       verification infrastructure, and enabling long running tasks with
       agent containers and traces. For agentic work we're big fans of
       applying LLM judgement to discover problems, and then generating
       deterministic software to automate them.  Try it out at
       https://app.bitboard.work. (We require an email so we can set up
       your account).  We're excited about how data analysis and science
       can change in the age of LLMs, and welcome all your thoughts!
        
       Author : arcb
       Score  : 53 points
       Date   : 2026-06-12 16:58 UTC (1 days ago)
        
  HTML web link (bitboard.work)
  TEXT w3m dump (bitboard.work)
        
       | spmartin823 wrote:
       | Highly rec going after a specific vertical - healthcare might be
       | the right spot given your experience. Why did you use DuckDB
       | instead of CockroachDB/Snowflake?
        
         | arcb wrote:
         | Our outreach is vertical-specific, and healthcare is indeed on
         | the list! But what we learned working a vertical is that the
         | primitives underneath (shared queries, permissions, caching,
         | refresh semantics) repeat across industries.
         | 
         | We use DuckDB internally because we like its ergonomics - it's
         | flexible, runs well in memory, manages a lot of file structures
         | under the hood, but we do work with Snowflake (and Databricks
         | and other warehouses) as well.
        
       | straydusk wrote:
       | Great concept. Had this idea myself recently.
        
         | arcb wrote:
         | Thank you! If you try it out let us know how it goes!
        
       | htrp wrote:
       | Is there a way to sign up without going through google oauth?
        
         | arcb wrote:
         | Not at the moment but it's in the queue. If there's a sign up
         | method that works better for you feel free to DM me.
        
       | mritchie712 wrote:
       | Looks cool! It's a lot of work to get a full data stack set up
       | and people are losing interest in stitching the pieces (ETL,
       | warehouse, BI) together.
       | 
       | > Agents made bad inferences because they had no context on the
       | business
       | 
       | We've been working on this since before the chatgpt launch.
       | 
       | We started with a semantic layer since there were already good
       | open source options and LLMs at the time were good at writing the
       | JSON (remember function calling?) to run a semantic query.
       | 
       | But as LLMs have gotten smarter and people wanted to do more data
       | work in agents, we found we needed something more flexible, so we
       | built an "Ontology" that lets you store all the terms you use in
       | your company and connect them to the data points (e.g. tables,
       | columns, metrics) that matter.
       | 
       | https://www.definite.app/blog/ontology-ai-analytics
        
       | baetylus wrote:
       | First, I love this concept and I think your demo is great!
       | Collaboration with existing harnesses makes a ton of sense. Just
       | had a conversation with some folks in the non-tech world raving
       | about using Claude.
       | 
       | A few questions:
       | 
       | - How do you think about competing with ChatGPT Canvas or
       | Anthropic's artifacts, when these are shareable, native
       | experiences in their products where users already work?
       | 
       | - Is a "dashboard" limited to analytics or are you trying to
       | expand it to include written reports?
       | 
       | Since teams are connecting MCPs like Granola, Slack, I imagine
       | BitBoard would facilitate sharing demos, PRDs/briefs, or customer
       | reports. This seems like a natural expansion and trivial
       | functionally, so I'm wondering if that's part of the sell now or
       | something you're looking at expanding into as you grow.
        
         | infakelife wrote:
         | Thanks! Non-OP BitBoard cofounder here. Would love to hear your
         | thoughts when you get a chance to check it out.
         | 
         | > How do you think about competing with ChatGPT Canvas or
         | Anthropic's artifacts, when these are shareable, native
         | experiences in their products where users already work?
         | 
         | The flexibility is amazing for static content and playing
         | around with visuals, the experience is just more like a
         | whiteboard than a dashboard. It's hard to do both well in the
         | same place. For reporting I want live connections, consistent
         | logic, the ability to trace provenance, and a more opinionated
         | starting point for the UI.
         | 
         | We started with an extremely flexible surface but there are
         | just a ton of things you don't want to leave up to the agent to
         | implement and we gradually layered those in. It's no fun having
         | to prompt the agent to expose a "view source" affordance, "run"
         | button, or working data labels. But it's a lot of fun building
         | whatever visualization you want and generating a dashboard
         | without a billion clicks in some SQL-abstraction UI.
         | 
         | > Is a "dashboard" limited to analytics or are you trying to
         | expand it to include written reports?
         | 
         | We weakly support written reports today (technically possible
         | with markdown blocks in dashboards for commentary) but will do
         | more to support them in the future for exactly the reasons you
         | called out.
         | 
         | We actually built a more notebook-like artifact for this but
         | cut it to focus on dashboards since they seemed to be a bigger
         | pain point for users. One-off reports can be hit or miss with a
         | chat or coding agent today but static reporting is at least
         | supported with some effort. Live reporting with connection
         | infrastructure, provenance, etc. is much harder to pull
         | together.
        
       | dennis16384 wrote:
       | Nice, I recently did a similar but much simpler thing and open-
       | sourced it under MIT, maybe some bits and pieced will be useful
       | https://github.com/eatmydata-org/eatmydata
       | 
       | For example, MIT-licensed sqlite vector search extension.
       | 
       | Overall, I have a orchestrator - sql coder - js coder -
       | dashboards, all without backend, running locally in the browser.
       | It's mostly tested on small analysis and question answering with
       | Gemini Flash Lite, and the overall target was speed from question
       | to answer, including data sharing and waiting.
        
         | arcb wrote:
         | There are a lot of cool and useful things in there. What are
         | you most excited about?
        
           | dennis16384 wrote:
           | Fast response. I can upload Excel/csv and iterate under 10
           | seconds from question to result. Doing same thing in Claude
           | with 10x less data takes 5 minutes.
        
             | arcb wrote:
             | I hear you on fast responses. One of the frustrations I've
             | had using BI / data tools in the past was not being able to
             | get local performance... which led to me exporting data to
             | spreadsheets or local code. We're taking this to heart for
             | BitBoard as well.
        
               | dennis16384 wrote:
               | Totally. One thing that all major AI vendors are not
               | doing currently is merging server AI with edge devices.
               | 
               | For example, there is no way neither in Claude nor in
               | ChatGPT to run your own WASM or JS or whatever AI
               | produces directly in user's browser context as a
               | tool/skill - there is no call site for that. The only
               | option is remote server-side.
               | 
               | My whole idea was that AI can perfectly write SQL and
               | dashboard code knowing only the shape of your data and
               | not it's contents. With direct upload to vendor now we're
               | forced to share the contents.
        
               | arcb wrote:
               | I suspect stronger edge performance will come as a side-
               | effect of local inference. Your point on edge tool calls
               | is interesting and I'll think about that. Features like
               | offline mode could be a great motivating reason. Re
               | knowing the shape vs not the internals - I'm mixed here.
               | It feels like there's always a sampling period where you
               | have to look at contents in order to understand what you
               | want. But edge AI (like antirez's work running DeepSeek
               | on Mac) will let you have both. I'm excited for that
               | future!
        
               | dennis16384 wrote:
               | Why would an LLM want to look into the contents, what
               | for?
               | 
               | We have low-cardinality data and yes this is safe to
               | share and required to build an actual query.
               | 
               | Then we have high-cardinality and possibly PII - there's
               | absolutely no reason to share that data, there's nothing
               | for LLM to analyse there. Also semantic index (vector
               | search) will find relevant records much faster and more
               | accurately that any chain-of-thoughts just with an LLM-
               | authored search fn call.
               | 
               | Further there are continuous numerical values and there's
               | not much LLM needs to see in there either. We can say,
               | for example, if you look at data distributions when
               | building your analysis, it can drive your analysis logic,
               | but another point of view here is taht it creates
               | unnecessary bias instead.
        
               | arcb wrote:
               | On re-read I think I might have overreached in my reply.
               | I think having local LLMs being able run tool loops to
               | _transform_ data, rather than just summary or analysis,
               | will become 1/ great for non-technical users, 2/ fast.
        
       | rancar2 wrote:
       | I do exactly this (and more since my role is much broader and so
       | is my approach) as a fractional head of product, data, and
       | operations for multiple companies all in healthcare (fast growing
       | self-funded to series D/IPOing soon). I saw your initial launch
       | and felt validated by you all working on it, and now I'm further
       | validated by the pivot. I have more work than I can handle, so
       | I'm happy to share tips. You can find me via a bit of googling my
       | HN handle or just adding a dot com to the end.
        
         | infakelife wrote:
         | Appreciate the validation. Would be great to connect and
         | exchange notes - will reach out directly.
        
       | BoorishBears wrote:
       | How are you connecting to various data sources?
        
         | arcb wrote:
         | We're offering secure connections to sources like SQL DBs,
         | warehouses, file stores, and MCP/API sources like PostHog or
         | Salesforce. Customers can choose to set up credentials in our
         | key store. We also support directly dropping data into BitBoard
         | (where we sync it to object storage).
        
       | sails wrote:
       | > but customers kept pulling us toward their data analysis
       | problems
       | 
       | I hear this all the time, I still don't think it's a good
       | justification to build a BI tool, but I hope this time it is
       | different.
       | 
       | Product looks cool! I'm hopeful that agents do actually unlock
       | business analytics and we can move on from the BI concept
       | 
       | Edit: a rough explanation of why you get pulled towards data
       | problems is that they are intractable symptoms of upstream
       | process issues. Customer sees a capable startup and co-opts them
       | into trying to solve their tarpit problems. Happens all the time!
        
         | arcb wrote:
         | We hear you on getting pulled into tarpit problems, and on the
         | pattern you're describing leading to them. The core product
         | motivation we're excited about is letting humans and their
         | agents act on data together, but we do think that requires
         | thoughtful tooling to exist before that becomes desirable (more
         | to come here). Our newer customers tend to be a little more
         | technology forward, which helps us focus on the product we're
         | offering them rather than internal politics or process issues.
        
       ___________________________________________________________________
       (page generated 2026-06-14 01:01 UTC)