Building Pat, the AI Pocket Analyst – Bridgewater

Speaker(s): Brendan McManus (Team Lead, Applied AI, Bridgewater); Michael Ran (Senior Investment Engineer); Santi Weight (Technical Lead)
Session: Interrupt 2026 · Day 2 (May 14) · ~2:50 PM PT
Source: in-person audio recording, transcribed locally with Whisper large-v3.

Summary

Brendan McManus, Michael Ran, and Santi Weight from Bridgewater (systematic macro investing) present Pat, the AI Pocket Analyst — an internally deployed agent that performs hours of expert investment research in minutes, learns from every interaction, and is used by hundreds of investors daily. They frame Bridgewater's 50-year practice of writing down every trading rule into a machine- and human-readable expert system, which now gives Pat access to all of the firm's content, frameworks, structured time-series data (tens of billions of series), and millions of unstructured documents. The demo walks through Pat researching how markets responded to a recent Middle East conflict: per-user tailored context/tools for security, web and time-series search (embedding human-like inspection lifted accuracy from ~15% to ~90%), a planning phase where 'the plan really is the analysis,' parallel code generation via sub-agents, and self-validation. Santi (the architect) reframes agentic coding as a compiler problem: a chat agent (built in LangGraph) compiles intent into a detailed plan, a separate coding agent compiles the plan to Python, correctness is enforced in the architecture (95% of the time two agents produce identical code), and a static-analysis execution layer with caching makes repeat runs near-instant. Key takeaways: specialize agents over generic ones, benchmark heavily, and treat coding as a compiler problem.

Key Points

• Pat (the Pocket Analyst Tool) performs hours of expert research in minutes, is deployed internally to hundreds of investors using it daily, learns from every interaction, and is explicitly not about how Bridgewater trades but about deep exploratory research
• Foundation is 50 years of writing down every trading rule (starting with a 1980 bond system on a yellow legal pad) into a machine- and human-readable expert system, giving Pat access to all of Bridgewater's investment processes and frameworks
• Data scope: a time-series database with tens of billions of series modeled internally for 50 years (external data like oil prices plus internally derived concepts) and a database of millions of unstructured documents (broker pieces, earnings transcripts, internal emails) updating with thousands of new pieces each day
• Security: each person at Bridgewater has a unique version of Pat tailored to what they can and cannot see — uniqueness is a function of each person's context and tools — to avoid leaking secure IP to analysts who shouldn't see it
• Embedding human-like inspection into the time-series search agent (checking frequency, currency, and whether values align with priors, not just the series name) raised accuracy from roughly 15% to 90%
• 'The plan really is the analysis': a relatively expensive planning phase produces data frames, their schemas, and how they connect, enabling parallel code generation by sub-agents so a 20-task (or 30-data-frame) plan takes about the same time as a 3-task plan
• Compiler framing: a chat agent (built in LangGraph) and user reach a common understanding, then it compiles a plan that a separate coding agent compiles to Python; correctness is enforced in the architecture and agents are forced to validate — 95% of the time two different agents produce exactly the same code
• Execution layer runs code for the LLMs via a classical static-analysis pipeline that injects caching annotations to avoid re-execution, making the second run near-instantaneous; analysis outputs land in the same time-series database as inputs so humans and agents compound each other's work; a 'teach' button lets users spawn an agent that builds a benchmark, iterates the context until it passes, and ships a change via Slack
• Takeaways: specialize agents (don't rely on generic powerful agents), benchmark narrow workflows heavily and hill-climb them, and think of agentic coding as a compiler problem rather than an agency problem

Notable Quotes

embedding this sort of reasoning into our search agent is actually something that got us up to roughly like 15% accuracy, all the way to 90

During Pat's development, we came to the view that the plan really is the analysis.

The takeaway is thinking of agency coding as a compiler problem, not as a agency problem.

Full Transcript

Show the full timestamped transcript (auto-generated; lightly cleaned)

[00:00] Hello everyone, my name is Brendan McManus, the team lead of the Applied AI team at Bridgewater
Systems, a systematic macro-agent. I've been at Bridgewater for almost a decade now, where I started
as a software engineer, then became a systematic investor and researcher, and for the past few years
I've been focused heavily on bridging the gap between investing and technology.

[00:38] I'm here today with my colleagues Michael Rand and Stacey Wade, our investor lead and technical lead
of this project respectively, to talk to you about a great tool that we built internally called Path
to TalkNet. Now, by the end of this talk, all of you should have seen how we built an AI analyst
that's capable of performing hours of expert research work in minutes, that's been internally
deployed to hundreds of investors, and that learns from every single interaction. On top of that,
we'll also show you exactly how we architected Cybernetics.

[01:10] So, before we actually show you what we built, I wanted to go through some quick framing on
Bridgewater's approach to AI. So, Bridgewater has been a successful AI analyst since its inception.
It's been in the decades, 50 years, thinking about how to do the encoded markets and economies, and
how we can do that. And all of this really started with what you're seeing on this screen, our 1980
bond system, written down on a yellow legal tab. The idea here was quite simple. Every time you
wanted to take a trade, write down exactly the rules of why you made that trade make sense.

[01:41] Write down the exact call to life. Because once you do this, another investor can take a look at
what you've written, help you to figure out where you went wrong. And help you to improve upon this
process. Every time you learn something new, you scratch out a rule, you write down what you want.
And this creates a pretty incredible learning process that has been the foundation of everything
that we've done in Bridgewater for the past 50 years. Over the decades, we've compounded upon this
process pretty significantly. As we've taken every lesson, every methodology, every rule that we've
developed about the trades that we make and how and why,

[02:13] and we've quantified them into an expert system that's both machine readable and human readable. And
it's really now that we're just sitting on a pretty tremendous flow of data. And all of this data is
really what sets us up well for the AI era. We didn't have to go back and write down every
information. It was already there for us to draw upon. And so, before we get into the tool a bit
more, I wanted to talk about how we're approaching AI at Bridgewater Project. We're doing this in
two ways. The first is as investors. As investors, we need to deeply understand every major dynamic
that's shaping global markets and economies.

[02:46] Just as we have had to on the show. Much than COVID or the recent oil supply shock, we've also had
to understand AI. What's the shape of the supply-demand dispatch? What's driving the build-out? And
how do these things ultimately impact markets? This understanding is enabled based on us as
investors. The second way that we're approaching AI is as practitioners, which is what we're mostly
going to be spending our time on here today. As practitioners, we're applying AI across all aspects
of our research process. With the ultimate goal of building out an artificial investor

[03:17] that's capable of the full range of activities that our human investors are performing every single
day. So, what do our human investors actually do? Well, we think about it as a research circle.
Investors are constantly perceiving what's happening in the outside world, formulating questions
about what is true and what they might potentially be missing, performing analytical investigations
to try to answer these questions, synthesizing their findings, and ultimately taking anything
they've learned and putting it back and common understanding the extra systems that we built on.
It's really this last step here at SP.

[03:50] Everything that we learn as a function of this process is put back into a shared memory that humans
are able to draw upon. And so, you might even imagine that if you're going to build out an
artificial investor, they need to be able to do all of the different steps of this research process.
You can imagine having built out discrete sub-agents that are focused on each portion of the
research circle. And that's exactly how we're approaching AI. We're building out discrete sub-agents
for each of these different things that human investors must do,

[04:22] drawing upon the same understandings that we've built up over the last 50 years. But today, we're
only going to be talking about one of these agents that we've built out, which is really focused on
the investigation portion of the research process. The kinds of deep analytical work that take our
human analysts days and weeks to perform. We call this tool that we've built PAT, the Pocket Analyst
Tool. And just to set expectations, PAT is not about how we trade. It's really about performing deep
exploratory research, enabling our investors to go after questions

[04:52] that they never would have had the bandwidth to go after before. So, what did we actually build? So,
we built this tool called PAT, the Pocket Analyst Tool. And from day one, the spec was simple. We
had to enable PAT to be able to do all of the things that our human investors are doing as they're
performing investigatory or analytical work. And that really starts with data. PAT had to be able to
search across and read all of the different data that we have in terms of from structured time
series data, for example stock prices going back decades, or unstructured data, for example broker-
dealer research pieces that we subscribe to,

[05:25] or internal memos that we produce. PAT has to be able to search across and read all of them. PAT
also has to be able to use all of the different tools that our human analysts have access to. All of
the proprietary tools that we built out for visualization, for diagnostics, or for evaluating the
quality of the TDP or ideas that we built out. In addition to this, and I think this is where things
might get a little bit more interesting for a technical argument, many of the analyses that PAT's
running would take a human analyst many hours at a time to run. And this means that the analyses are
quite complex,

[05:55] which means that PAT's analyses have to be completely diagnosable, not just for humans, but also for
agents running in the background, reading through the traces, understanding and making sure that
every calculation is correct. On top of this, and I think this is really where building on all of
the things that we've written down over the past 50 years starts to pay off, is that PAT knows all
of our content. It has access to all of our investment processes, our frameworks, it knows exactly
how our analysts are supposed to be doing work, because we've been writing it down for the past 50
years.

[06:26] And lastly, PAT has to learn. It has to compound upon its own learning, not just for one investor,
but for every investor at the time. PAT's not a prototype today, it's actually been deployed
internally several months ago, and we now have hundreds of investments making it every single day.
Which is leading to a pretty incredible flywheel of improvement, where as investors are using PAT
for real research, we have agents continuously running in the background, scanning through these
interactions, figuring out where PAT went wrong, developing human audited benchmarks,

[06:57] which then results in changes to context, and also to the harnesses that we've built for PAT, which
results in PAT improving not just for one, but for everyone. And so, lastly, before we get into what
we built, I wanted to leave you with one question that I've already commented on, which is how does
a 50 year old hedge fund actually build out something, like what you're about to see? Well, it
really starts with being able to, being willing to shake yourself up. The team that built out PAT
was ultimately an internal applied AI startup that was incorporated in the broader firm.

[07:27] The ability to move incredibly flexibly and quickly, while being able to draw on the resources of
the broader firm. In addition to this, we've established multi-architect teams, where we have
investors, technologists, and scientists, ultimately sitting side by side, building along one,
alongside each other. And I think this is really a key thing that you need if you're going to build
out a product like this. Investors bring the context and the domain-specific expertise,
technologists bring the architectural capability, and scientists bring the rigor.

[07:58] It's really these types of multi-architect teams that are necessary if you're going to be building
AI systems for expert users. And speaking of expert users, we have hundreds of them internally,
using all of our AI tools, not just PAT, which you're about to see, generating signal daily, on how
these things should be evolving and improving over time. And lastly, we have a pretty incredible
accounting ecosystem at the plugin. 50 years of shared data, tooling, and methodologies, all built
out, not just for our human analysts at Plugins2, but also for agents on our journey to build out a
fully artificial investment

[08:31] that's capable of everything that humans are able to do today. And so with that, I'm going to pass
things off to Michael Graham, who invested in me, to go through a demo of what we built, and take
you through the product architecture. Right? Thank you, Brendan. My name is Michael Graham. I'm the
investor lead working on the Pocket Analyst, and a little bit about myself. I've been here at
Bridgewater for five years, where I joined as a technologist, and then I spent most of my time in an
investor role. And then nowadays, the thing I'm mostly focusing on is how we can use AI for our
investment process.

[09:02] So with that being said, I'd love to jump into a demo of the Pocket Analyst to highlight its
capabilities and show you all how invested in Bridgewater is now. So behind me, you can see the
path-handing page with some of the prompts we'll be using for today's demo. Where the gist of it is,
we're asking Pat to look at how markets have responded to the recent conflict in the Middle East,
and to compare today's events to similar historical episodes. And lastly, we asked Pat to put
together some visualizations that highlight how similar and or dissimilar today is relative to
previous world supply shocks. This is a real question we've been working on at Bridgewater

[09:34] over the past couple of months, and Pat has been a tool leveraged by investors to help expedite our
research process. But before we submit the prompts, I'd like to spend a moment talking about the
interesting security problems that we ran into when designing Pat's partners. So our starting point
was, for Pat to truly be helpful, it needs to be able to access all of the information that
investors have access to when conducting research. But the thing is, at Bridgewater, different
investors have access to different information. So for example, you may have one investor who has
access to what our positions are across all markets today,

[10:04] and it's important for that person's path to also have this information. But then you might have
analysts who are not exposed to this, and it's similarly critical that we do not accidentally leave
the secure IPs with analysts. So unlike a harness like Bosco, where everyone is interfacing with the
same system prompt and the same tools, each person at Bridgewater has a unique version of Pat,
tailored to what they can and cannot see. Now practically speaking, this uniqueness is just a
function of what context and what tools each person's path has. So with that, we'll go ahead and
submit the prompts.

[10:34] And the first thing that takes place in this analysis is Pat searches the web and our multiple
unstructured data to better understand what's happening in the world today and to contextualize it
against history. Now web search itself is table stapled and accustomed to these modern chat
applications, but the real differentiator here is the breadth of unstructured content that we
subscribe to that Pat is able to search over. We have a database containing millions of documents
from all around the world that includes contents such as broker pieces, earnings transcripts,
internal emails, and more. And this database is updating in near real time

[11:06] with thousands of new pieces coming in each day. And this ties back to the point I was making on the
previous slide, which is for Pat to freely provide leverage, it has to access everything that the
user has access to, such that it can try and emulate what its users actually do. Now once this
context is gathered, the next thing that Pat does is it searches our time series database for the
data required for the analysis. This is a database that contains tens of billions of series that
we've been modeling internally for 50 years. And this database contains data from the outside world,
like the price of oil, and also internally derived concepts,

[11:37] such as what we think in place will be 12 months out. Now, the search agents use kind of your
traditional search techniques, like RAG, uranium, etc. But the thing we found to be a huge
difference maker was layering on an element of human life inspection. And what I mean by that is
when a human researcher is looking for data, they don't just anchor to what the name of the time
series is, they'll do things like look at the frequency, the currency of the series, and then most
importantly, whether the values in the series align with their priors. So embedding this sort of
reasoning into our search agent is actually something that got us up to roughly like 15% accuracy,

[12:09] all the way to 90. Now, after Pat has the context of the data at hand, it comes back to the use of a
clarifying question, potentially ideas for additional language to explore. During Pat's development,
we came to the view that the plan really is the analysis. If we can create a high quality detailed
plan, we felt confident that we could consistently take this plan, intelligently execute it, and
produce our desired outcome. And Sandy will be diving into this a bit more later. So while agents
asking questions is pretty standard with Fatbots nowadays,

[12:39] the thing we really focus on was the substance of those questions. We developed lots of time and
energy into developing the context of Benchmark to help shape this capability. We taught Pat what
makes a good research question versus a bad one, so this back and forth helps humans, who tend to
underinvest in planning, flesh out what we consider to be a high quality research question. Now,
after the ambiguous points are oversold, Pat enters its planning phase, where during the planning
phase, the things it's doing are A, coming up with all of the data frames that will be used in the
analysis,

[13:10] coming up with the schemas of all of those data frames, and then most importantly, coming up with
how all of those data frames connect. Now, this planning phase is relatively expensive from a time
perspective in our analysis, but it's a cost that we take deliberately because of what it lets us do
during execution. So, now we have the plan locked in, and the first step of plan execution is
generating the code. And given we have such a detailed plan, the thing we're able to do is generate
the code for each data frame in our analysis in parallel using sub-agents. And this works because
each sub-agent knows what data frame it depends on,

[13:42] it knows the schemas of those data frames, and it also knows what the schema of the data frame it's
increasing should be. So, this lets it be such that you can have an analysis with, say, three data
frames, or a meeting one with something like 30 data frames, and it takes us roughly the same amount
of time to generate the code in both of those scenarios. Once we finish generating the code, we just
execute the Python functions with an agent over the data frame, and then we can start the first data
set execution and stepping in if it sees things like runtime errors and nonsensical values. And
before we proceed to execution, I want to call out the fact that the time series outputs from these
analyses

[14:14] land in the same database that we actually pulled our inputs from. And I think this is important for
a couple of reasons. One, it shows that any output from a Python analysis is indistinguishable from
any of the human-uploaded series that we've been producing for many years. Then, more importantly,
any output from a Python analysis can serve as an input to a subsequent one. So what this does is it
creates an environment where humans and agents can very easily compound a bunch of each other's
work. Now, after execution completes, just like you want your junior analysts to double-check their
work before coming back to you,

[14:44] we want Pat to do the same. So at this point in the analysis, Pat will look at the data as computed
and the visualizations it's produced, and make sure that the numbers seem sensible and the charts
look clean. If it sees something that looks a bit off, Pat will take a step back, diagnose the
issue, then refine the analysis, and make sure it satisfies the results that work for the user. And
then, the result itself is this interactive report where in the report, the visualizations look just
like the ones that the investors at Bridgewater are producing. Pat is using the same in-house target
library

[15:15] and leveraging the same existing text deck that we've been developing internally for decades. So you
can see here how you can zoom in and zoom out of these charts, and you can even send the data from
this interactive report to our internal target pool where you can make further modifications on the
fly. And now, before handing over to Sandhya, I want to speak a bit to how Pat can better use it.
There are two primary ways in which this happens. The first is the autonomous one that Brandon
alluded to earlier, where we just have agents reviewing completed conversations, looking for ways
for Pat to get smarter.

[15:45] And the second one, and the one we'll be showing here, is the more explicit option, where a user can
kick off this learning process within the context of an analysis if they think there is something to
be learned from their interaction with Pat. So right here, we just have the user asking for a
different set of values and a set of visualizations. Note, the user didn't say anything was wrong,
they just wanted a different perspective that they thought was important to answer the question at
hand. If they think that Pat should have produced or suggested this set of visualizations from the
jump, they can click the teach button, which will then spawn an agent to go through the conversation

[16:16] looking for things like behavioral mistakes, context gaps, for users to hear and identify from. The
user is then able to modify this or set it as this, and when they submit this, what happens is,
first, an agent on the back will create a benchmark for the expected fail. This shows that we can
reproduce this poor behavior. It will then iterate on our context repositories for the harness
itself until the benchmark passes. And then after confirming that by making this benchmark pass, we
didn't cause the rest of our suite to fail, we get a slack nice for the full request, including the
change to agent one, making Pat.

[16:47] And the thing this does is that the next time a human comes to Pat with a similar question, we
expect them to get the better version of Pat right out of the box. So now we can hand it over to
Sandy to text what we've got. Woo! All right. Hi. My name is Michael, and I'm the architect on
Patalyst. I'm sure many of you are proud of our coding agent products, just like we are, and it's
really hard to build one. Coding agents are really fickle, unpredictable, they often make mistakes,
and then when you really have them, they go crazy and try and cheat your data

[17:18] and all the rest of it. And so it's really hard to build a good product that people like, but then
it's really hard to build a product that they want to invent and that they want to use. At Hedge
Fund, we're trying to share billions of dollars, and so we can't have just white code in the
underpinning of how the analysis goes. My background is in pilot theory and design, and compilers
have very similar footprints of requirements, which is they're fully deterministic, fully correct,
and reliable.

[17:48] You can't have it done by one when you're playing a game. And there's also a similar shape here. A
compiler takes a user code and compiles it down to something like AX, and then a coding agent takes
a user prompt or plan and compiles it down to Python. We really like this approach, and so I don't
have a lot of time today, but we're going to focus on this as a learning that maybe you guys might
be able to take on to your own work. We're going to start with a chat mode. So the goal here is for
the chat agent and the user to come to a common understanding of what they're trying to accomplish
here.

[18:19] The chat agent was implemented in LandGraph. We primarily use it for system support. It has out-of-
the-box cancellations and simulations. And we use it to manage our stuff ourselves with much worse
effects. The chat agent has access to tool calls and might pull some of these out. So data theory
search, unstructured search, and each of these would be a tool for themselves. And then once the
chat agent knows all the data that it needs for its analysis, it's going to make a plan and invoke a
tool call to a sub-agent, which is our coding agent. And that's going to produce a Python-based
analysis.

[18:50] So why would we separate those two agents? Early on, we decided that our investors are not broken by
trade, and they care about investment. And so we decided to keep the chat purely about the
investment content. The result is that we have a product where coding is a pure interpretation of
detail. From the chat, you can't tell if there's code under the hood. And other happy accidents are
that you get non-people context. So each agent becomes specialized in his job and naturally
improves. And we get to tailor the chat experience a lot.

[19:21] And that's what we're going to talk about in a sec right now, is that our investment domain context
is really a type of so we teach the chat agent how to support a very important investor. There's a
lot of jargon to teach in. And so user and agent both report to each other like their co-workers are
very important. We also let our investors contribute, like we're showing now, contribute like a
developer on the code base. And this is a pretty good point. Your user is better at writing context
than you are, most likely. And so having low ego about it and making a contribution directly is a
good way to win.

[19:54] The last point I'll make in the chat is, we teach the chat agent not just context, which you end up
with this nebulous context that is very high information but doesn't really feel like a workflow.
And so instead we have step-by-step guides for the agent, on how to handle certain types of
analyses, and it feels much more like a product at that point. It's like dependable workflows. So
the rest of the talk is about my personal favorite part, which is the coding agent. This is the
high-level architecture diagram of the coding agent. Everything you see here is actually just type
of code.

[20:24] Influence is bankrupt, but there's no agent of orchestration. Everyone think of both of those,
that's great. We're going to start with the left, which is the analysis plan that the chat agent
makes. So the analysis plan is broken up into tasks. Each task maps approximately to one Python
function that's going to calculate a data memory. And here's an example schema. So it gets a name,
it has a description of what to calculate, and then the structure adds some math information about
the data memory that should come out.

[20:56] We expect every task to statistically compile via LLN two of each code. So two LLNs operating on the
same task should produce code that, when run, is mathematically equivalent to the same algorithm.
Exactly. The result is that our analysis plan isn't just like a to-do list where you might have to
code. Instead, we think there's a natural language by the project. And because we have so much
detail, now we're going to go to the code gen, and we can apply some fancy techniques. So the first
thing is we split it into tasks.

[21:26] And then we do a parallel LLN generation. And because our plan is so detailed, a visualization task
at the end of the plan already knows everything it needs to consume code generation that hasn't yet
been completed for a loading data state. And then when we compare this to the code of our benchmark
suite, you can see that in the mean, so this is called the same context, the same plan, we have our
four-times-fast generated code. But then we have this type of schema. So a 20-task plan takes the
same amount of time as a three-task plan. Okay, so now we have code and we're going to execute it.

[22:00] You would want to just execute code that you leave as family elements today on public on our task,
so they don't only one-shot them. Instead, what we do is we take the task that came in from the
plan, and then we have code that was generated from that task. And then we're going to run the code,
compare it to the task, see if it's correct. And if it's not, then we'll edit the code and we can go
ahead and sort it. The first thing we do on the code is we use staff analysis, and then figure out
the DAG. And we're going to apply our validation agents in parallel. So here, there's two tasks that
are going to be validated at the same time.

[22:33] So a five-task plan comes down to three layers. And then like a 20-task plan might be four or five
layers of validation. And the main point I want you to take away from this part of the slides is
that we enforce correctness in the architecture. So again, no identical description. This is regular
Python code. And the agents cannot forget to validate. They are forced to validate. When we run our
test suite, anyone planned for a test suite, 95% of the time, the code that comes out is exactly the
same for two different agents.

[23:04] So it's like a deterministic test code to be able to do that. And then because we have such a
reproducible agent, the idea is that as we're scaling and hill-timing and evaling, then we have to
be much more dependable than like five-space or LLM as judge evals. Cool. So there's one more topic
I'm going to touch on here, which is the execution layer. Normally, coding agents, they invoke their
code themselves. They generate code and then they call themselves by terminal. There's a couple of
trade-offs here. That's high latency with the tool calls, but I'm sure you've all experienced like
there are some points that get lost along the way.

[23:38] And so instead, we run the code for the LLMs. We do a classical static analysis pipeline where we
inject caching annotations into Python code to avoid re-execution and run it through a custom
framework. So this is like an example benchmark that we have for Python. We've got audit focus on
code versus pocket analysis. And you can see we're, again, faster because we're not, we're not
double-editing data or double-executing intermediate. But the actual win is not on the first time
you run the code, it's the second time.

[24:08] There we go. So this is the benchmark where we take the last chart in a plan and then just change
the name. And so the board code is going to go read the front of the code, so it's basically the
same amount of time, though it is faster editing code. But pocket analysis basically has an
instantaneous code execution to the second round. And this means that when you work on a product
with a investor, you can make small tweaks to your investment analysis without having to do that
overload, the overhead of a regular operation. Okay, so we're out of time. We have many learnings,
but unfortunately we can only stick to these.

[24:40] The first takeaway, I think, is that we really believe in specializing our agents. So we don't
really believe in generic powerful agents. They make really cool demos. I'm sure many of us have
given them. But it's really hard to make that a daily workflow that you can depend on. Instead, we
take often very narrow workflows and then benchmark them very heavily. And then we hill climb those
benchmarks. And then you can compound the agents off the back. But it's hard to go back all the way.
And this last thing is kind of like that thought exercise on hopefully it's exciting for everyone
later.

[25:11] The takeaway is thinking of agency coding as a compiler problem, not as a agency problem. Compilers
have already been generating code for decades, and they have a ton of techniques for how you can
generate code more reliably, correctly, and distinctly. And so yeah, we'd love to chat about this.
With that, I'd like to shout out our direct team. There were many others, but this is direct from
the direct team. We're going to be outside the AMA. We'd love to chat and talk about it and see if
you're excited about the conference too.

[25:45] And then see you all around tonight. Thank you so much. Thank you.