Tue, Oct 13 · 9:00 AM–9:18 AM · Simons Room (Metropolitan East)

Vault: Making Unstructured Data Work for Investing

Aaron Linsky, Bridgewater · Sam Green, Bridgewater

Bridgewater's Vault demonstrates that enterprise investment AI only compounds when internal and external unstructured data is enriched against a bitemporal firm ontology, served through native-filtered search built for both human precision and agent-storm scale, and embedded into existing researcher habits with automatic synthesis write-back.

← All talks · ← Prev talk · Next talk →5 of 7 built · Z4 Evidence Hub
Level 4 · Raw Evidence & DossierWant the visual narrative with stage slides?
Recording · 15 minTranscript · qwen3-asr-1.7bLinksPhotosNotesStory · draftTalk page
ThemesTheme 01: Bootstrapping Domain Evals Without Public Benchmarks →#Theme 07: Governed Ontologies, Provenance, and Financial Workbenches →#Themes presentation →

Speakers

no X handle found
no X handle found

My notes

None captured.

Photos

None filed.

Recording

My Voice Memos from the room. The public livestream: YouTube, around 0:12:08 (approximate).

2026-10-13_0904_Blackwater · 15 min · qwen3-asr-1.7b

Transcript

Machine transcript (qwen3-asr-1.7b). Garbled words are kept as heard.

Read the transcript

Vault: Making Unstructured Data Work for Investing

Transcribed by qwen3-asr-1.7b with a schedule prompt. Possible prompt artifacts, names heard more often here than in the unprompted Voice Memos transcript (Qwen vs Voice Memos): Bridgewater (3 vs 2). Check them against the audio before quoting.

00:00:00 — From Bitemporal Structured Data to Unstructured Knowledge in the Vault

All these phases of evolution, we've had a constant philosophy in mind, which is that we want to be constantly looking at how the world is changing, and what's going on in the world, noticing what dynamics are not yet encoded in our understanding, and use that learning to improve and account for the future. For most of Bridgewater's history, that meant building and overseeing time series models on structured data, and that structured data needed to be carefully built so that it could be saved for use in our research process and aligned to our internal ontology and world model, so that we could get great leverage out of using the data that we built.

With the emergence of language models, we had a huge new opportunity to engage with a much wider world of data — you know, news and research transcripts, policy documents, and all of the internal conversation that was previously just in the ether, so the internal memos and meeting transcripts and debate happening inside the firm. We quickly realized that all of that data needed the exact same treatment to be fit for purpose. It needed to be carefully cleaned, governed, and made ready for use in both point in time research questions today, and also our systematic study over time.

And when we looked out at the landscape of data vendors and data platform providers, there was nothing that provided us with all of the control that we needed to build and maintain our data advantage, and so we built the vault, which is our repository of external and internal unstructured data, and the platform that indexes, organizes, and makes all of it ready for use by our human investors and agents. Today, the vault has more than one hundred million documents in it, with thousands more added every day, minute by minute, from 135 external sources, and again growing all the time, as well as all of the data from inside of Bridgewater. And crucially, all that data is not just dumped on our investors' desks. It is carefully aligned to our internal ontology with enrichments like the countries, concepts, markets, and most importantly, time period discuss in the document.

00:02:20 — Open-Web Chat vs. Vault-Connected Query on the Korean Won

To bring this to life, I want to start with a quick motivating example. So what I did here is I asked a fairly basic representative investment question to an enterprise chat plan. I asked, "How is AI infrastructure investment impacting the Korean won, and do market participants expect this to continue?" And as you're all sure familiar with, the agent goes to the web and looks for resources it can draw on because I've explicitly asked it to go find other people's perspectives on the question, and you can see it zooms in and it finds fifteen relevant-looking resources to draw on before it gives a back to answer.

And when I when I zoomed in on the answer I gave back, a couple things stood out. The first is that even though it found 15 relevant-looking sources, it only picked one or two to answer to answer my question. And the second is down at the end of its response, where the agent itself acknowledges that it hasn't answered my question. It didn't find enough documents on the open web to establish a market consensus and meet the meet the parameters that I laid out. When I double clicked even further, the problem got even worse. One of the notes that it primarily drew on to answer my question was published way back in July 2026, even though I asked this question and captured this answer just at the end of last week in early October. In the age of AI and investing, three months is a massive amount of time. It's not even close to good enough to draw on this resource to answer my question.

When I ask this exact same query attached to the bot, something totally different happens. The first is that the connection to the vault helps to prompt the agent that it should look for a specific period of time when answering my question, so it zooms in on October first to raise, it finds a much wider array of resources: fifty-two candidate documents that are relevant the query over this specific period of time, because of the vast, much more significant corpus of content that's relevant to investing questions. And when it ultimately answers my question, it draws on seven instead of only one or two, and gives me back a rich answer that the agent is more confident is going to address my question. And so for us, this is the big lesson for building vault to kind of motivate the talk, which is that it takes great data and the right connectors to make AI powerful. And I'm going to talk hand over to Aaron now to talk about some of the product engineering takeaways from building Bolt.

00:05:00 — Designing Search for Two Consumers: Humans vs. Agents

Thanks, Sam. So I'm Aaron. I run product engineering at Bridgewater. I'm going to take us through a few of our learnings from building the vault over the past few years. I'm going to start with one that might seem obvious, but I still think it's worth saying, which is search is hard, but it gets even harder if we're designing for two different consumers. In this case, we're designing for humans. Me, let me go over the difference here. Starting with us, so humans need precision and a high signal-to-noise ratio because we can only read so much. Even a fast reader manages about 300 words a minute. Personally, I'm much slower.

Agents are a different kind of reader. They're far less sensitive to precision. If the data is there, they'll find it, and basically anything you hand to them will get attended to. They scale super quickly, and they come and they consume about a hundred times faster, thirty thousand words per minute. And so we need to build well for both of these. And when we're thinking about the dimensions that matter are these five on the board: recall, precision, filtering, entitlements, and scale. Some of them matter to people. Some matter more to agents. Many to both. I'm going to go deep on three of these: precision for people, scale for agents, and then filtering.

00:06:23 — Benchmarking Precision at Ten & Native Vector Filtering

So, precision. Once we've filled the vault, which was a heroic effort by our data and legal teams, recall is no longer a pressing issue. However, the number one complaint was faults such as that. As the product owner, it's painful to hear that. But my response was, "Let's benchmark it." And that's what we did. We collected questions and found the best documents by hand, including ones that looked helpful but boring. In all, in total, was about two hundred examples, and it took us less than a week. It was not fun or very glamorous, but it was very helpful.

And after we were very clear, search was bad. The key metric we were looking at is precision at ten, which is of the top ten results, how many are the right documents, and we were hitting about sixty percent. So the people were right; it was bad. But now we had a way to measure all the improvements and here on board are five of them. By the time we got done with agenda search, we were up in the ninety five percent recall time or precision time.

All right. So that was precision. Now on a filter. Like anyone, we want the most relevant documents. But when we looked at the production traces, what we were seeing is that almost always there was some condition, either as of a certain date or from a certain source, or about a specific asset, and all of that requires advanced filtering. And that's where we ran into our first major performance issue.

We're going to quickly go through this. A little bit technical here. There's classically, two ways to build a vector database. Post filtering, we'll use that vector index first, and then filter the top results by metadata. It's fast, but recall could be pretty low because the globally relevant results might not match your focus. On the other side, we have pre-filtering, where we'll filter first, and then calculate distances for every one of those matches. The advantage there is that the recall is very good, but it can be very slow, and we needed something in between. So that's what led us to try, and then ultimately switch to TurboBuffer. Their approach, which they call native filtering, looks only in the nearest clusters if it can matches, and then scores just those. What you end up getting is something that's fast, like post filtering, but with close to the same recall as pre-filtering.

And lastly, I'm going to talk about scale. Human scale for us is pretty pedestrian. 100 queries an hour. We have 300 users. They're going to search every so often. It takes our users minutes to docs that they're receiving. Agents, on the other hand, are a few orders of magnitude beyond that — easily 100 plus queries a second, and agent storms can hit thousands easily. And they obviously will read, as I said earlier, will read docs in seconds. So we needed something that could scale as well, and again, Turbo Buffer handled that easily too.

00:09:34 — Migrating Investor Email Habits into Vault Workflows

So we were covering all five dimensions. I didn't talk about autonomous, but I'll be talking about that later today. But we covered it all. It unlocked new workflows, but it didn't change how our researchers work. They still weren't coming to vault every morning, and that's my second lesson that I want to share here is that no matter how amazing the tools are, we can't just drop them on our investors' desks and expect them to be used. We need to migrate their habits into a new form.

And so we looked at what they were already doing. Many of them were living in email. The research came straight from the brokers. They had subscribed lists. They had rules that filtered everything into folders. It worked. It was familiar, and they knew that they weren't missing anything. So we had to build all of these features into the model. So that's exactly what we did: everything searchable, the subscriber lists became saved searches, and folders became saved collections. It's the same habits, just a new home. And once we had them there, we could open up new habits. So we can ask. They can ask questions across all the data sets and show. They can follow dynamic feeds by topic, and they can hand those collections over to their agents to take further action, and that's when we truly add power to market data. And once we had that fit, the users wanted it everywhere, so we put it in chat. We made a phone app. It's in Slack and AI, and of course we avail all that to the agents as well, including a CLA because it involves.

00:11:07 — Pocket Analyst, Researcher, Forecaster & Investment Signals

And so the main question here is: okay, so what does this enable? Sam is going to talk about what we're building right now, but first and foremost, it's helping us to move around that research circle faster. With our pocket analyst, which is our first AI analyst, it can do it can do hours can do hours of research in just a few minutes or a few dollars, and that's a lot on the ball. And then we're expanding that now with the researcher, which is the next generation. It's the same idea stretched across days or weeks.

We're also able to train custom models more intelligently, recent over the vaults data, and use those together with other foundation models, to feed systematic decision-making processes. The forecaster is our first one, which produces AI-generated macro-relevant predictions, and then we also have built investment signals from the ball, turning unstructured data into structured tradeable trajectories. Now, I'll hand it to Sam to take us through LLM's latest capability.

00:12:12 — Proactive Agents, the Investor Workbench & Compounding Knowledge

So, like I alluded to at the beginning of the talk, the real prize is when you can get agents from a reactive resource that can be ready to answer a human's question, and instead, make them proactive participants, helping to steer your high-value professionals towards the most important areas for their attention. And the way that we're solving that problem is in an experience we're calling the investor workbench, where the agent is always on, tracking what's important to that investor and presenting them with the areas that are most in need of their attention.

It looks like an experience like this that relies on the balance, where a topic is proposed and several pieces of information are presented to the investors to decide whether they should dig deeper or ignore that topic entirely. You can see here the card that investor sees in order to decide whether to dig in deeper into the same AI impact on currencies question that we looked at earlier in the talk. And the investor receives everything they need — an agentic summary, if they want a quick scan across the agent's findings. They also get the exact evidence that the agent was drawing on, so that they can assess for themselves what was leading to this recommendation. And if they choose to dig deeper, they have a direct connection to the research output from the analytical tools that Aaron's just describing. And when they dig deeper alongside the agent to look at the dynamic driving this question, the learnings are automatically captured — the results of their collaboration are automatically captured back in the model.

And so, this for us is the key lesson: the vault enables compounding because it provides the right evidence, the right internal and external information at the fingertips of our investors and agents, and it automatically captures the synthesis that they generate and puts it back in the forest for the next turn. And that makes us go around the circle faster and better. And so when we think back to our the question we began with: What it takes to make an agent work is the right context and the right understanding of what's going on in your world. And so our question for you is: Does your AI know the world, and does it remember what your firm has learned about it? Because we are teaching ours to you, and if these sound like sound like an exciting challenge, we'd love to meet.

Coming up next, we're delighted to welcome two speakers from Anthropic. Please put your.

Generated Nov 14, 2026 at 6:27 PM · bun scripts/render-pages.ts