I maintain an OSS SDK for Databento market data. A year ago, I naively wrapped the API and certainly felt this pain. Having an API call drop a firehose of structured data into the context window was not very helpful. The tool there was get_range and the data was lost to the context.

Recently I updated the MCP server [1] to download the Databento market data into Parquet files onto the local filesystem and track those with DuckDB. So the MCP tool calls are fetch_range to fill the cache along with list_cache and query_cache to run SQL queries on it.

I haven't promoted it at all, but it would probably pair well with a platform like this. I'd be interested in how people might use this and I'm trying to understand how this approach might generally work with LLMs and DuckLake.

[1] https://github.com/NimbleMarkets/dbn-go/blob/main/cmd/dbn-go...

This is a problem with pretty much everything beyond easy single-shot tasks. Even day-to-day stuff, like e.g. I was researching a new laptop to buy for my wife, and am now enlisting AI to help pick a good car. In both cases I run into a mismatch with what the non-coding AI tools offer, vs. what is needed:

I need a persistent Excel sheet to evolve over multiple session of gathering data, cross-referencing with current needs, and updating as decisions are made, and as our own needs get better understood.

All AI tools want to do single session with a deliverable at the end, that they they cannot read, or if they can read it, they cannot work on it, at best they can write a new version from scratch.

I think this may be a symptom of the mobile apps thinking that infects the industry: the best non-coding AI tools offered to people all behave like regular apps, thinking in sessions, prescribing a single workflow, and desperately preventing any form of user-controlled interoperability.

I miss when software philosophy put files ahead of apps, when applications were tools to work on documents, not a tools that contain documents.

It's a full stack open-source agent harness (Apache 2.0). Persistent sandboxed workspaces, code execution against financial data, and a complete UI with TradingView charts, live market data, and agent management. Works with any LLM provider, React 19 + FastAPI + Postgres + Redis.

You might be interesting in what I've been working on. I've discovered giving an autoresearch approach to letting Claude write Claude, it will find lots of alpha everywhere beating SPY buy and hold. It will even find alpha filling in gaps with trading gold ETFs as a hedge. [0] What it really is a bug squashing agent. LLMs will lie and cheat at every move and can't be trusted. 75% (3/4 of agents and code is dedicated to this) of creating agents and using LLMs with financial data is hunting and squashing the bugs and lies.

[0] https://github.com/adam-s/alphadidactic

What I missed from the writeup were some specific cases and how did you test that all this orchestration delivers worthwhile data (actionable and full/correct).

E.g. you have a screenshot of the AI supply chain - more of these would be useful, and also some info about how you tested that this supply chain agrees with reality.

Unless the goal of the project was to just play with agent architecture - then congrats :)

Debatable. Making money is more about structure than being right as per se e.g. short vol is usually right...

The concept overall is basically ok though I think e.g. agents 100% going to be a big thing in finance but it's about man machine synthesis.

Is this kind of like a Karpathy 2nd brain for investing then?

This is slop - the mcp could expose a query endpoint

Obligatory: Brilliant Work. Brilliant.

"We wanted both and couldn't find it, so we built it and open-sourced the whole thing."

\m/ \m/ /m\ /m\