arcb

Thank you!

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.

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.

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).

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!

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.

There are a lot of cool and useful things in there. What are you most excited about?

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.

Thank you! If you try it out let us know how it goes!

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.

I believe we will at some point. All question of the right need coming up. Text OCR has gotten really good, and if you think of it from a UI perspective, the only real contract is that a screen will show text that's representative of the information entered. The DOM is useful but is a changeable contract!

It's a great repo! We had issues with iframes and framesets (which are old DOM tags) we had to write custom code for. Some DOMs need annotation to provide meaning to an LLM (for example, a button is clearly an "add demographics" button to the human eye, but is ambiguous in the DOM (ul contains li...). Some bottlenecks in navigation required manual attention. We keep those to a minimum. I think the future is being able to progress from highly deterministic JS code, to more agentic LLM-driven decisions. One does need to be able to control this for performance, cost, and accuracy. And yes we have some overlap with workflow-use's direction, but I hope that more such OSS methods gain popularity! It'd simply mean we can go after higher value and more complex clinical tasks!