And human labor comes with a couple of

main challenges, right? The first

challenge is accuracy. You know, humans

will always make mistakes.

>> How have you shifted the way you've

deployed LLMs both in building Dupa, but

how has it changed the market

environment for for your business?

>> Yeah. So, when we think about the

problems that we can solve for our

customers, right? Because at the end of

the day, Dupa has two sides to the

business. There is the data side, the

asset side, what we call content side.

Um there is also the workflow side, what

we call product side. A product at the

end of the day means you're solving

someone's problem for them. The job of

content is to acquire data sets that can

get us deeper and deeper into our

coverage.

All right, welcome to the next episode

of Invest with AI where we explore the

intersection of investing in artificial

intelligence. I'm really excited to have

Thomas Lee from Dalupa here with us

today. Um I I know about three people

who both sat in a hedge fund investing

seat and we're talking about AI before

November 2022 and Thomas is one of them.

So, uh, really excited to have Thomas

here to talk about, uh, what he's

building at DUPA and answer our

questions about the sort of current

state of AI and investing and the future

state of AI and investing. So, thanks

for being with us, Thomas.

>> Thank you for having me.

>> Maybe um, maybe just tell us a short

origin story of of Dupa. you worked at

some really well- reggarded hedge funds

and then in 2019 made the decision to go

after the the data oligopoly of

Bloomberg Faxet and Cap IQ which sort of

seemed like a crazy uh a bit of a crazy

uh decision at the time. So just walk me

through sort of your your headsp space

back then and in founding Dalupa.

>> Yeah, so in 2019 I think [clears throat]

this is obviously pre you know CHBT cla

and so on. uh but it's not pre- AI. So

we um and in the course of my job I

started to understand a little bit more

about you know the AI space and what AI

was capable of. And I think a big part

of that was I was fortunate to cover

semiconductors and a lot of hardware

equipment companies back in the day. So

I just got closer to like what these

things were being used for. Um

[clears throat] and the hypothesis was

you know there are two basically missing

pieces uh for data when it comes to

investing right the first piece is uh

can you do it at scale and at quality so

it's really really hard to collect high

quality data because uh the only

resource you have available to do so for

the most part were just human labor um

and human labor comes with a couple of

main challenges right the first

challenge is accuracy um you know humans

will always make mistakes. Um the second

problem was latency. So if you wanted to

collect a lot of data um you you would

just be slow right you can't have you

know a 100 people collect the same

income statement and make it 100 times

faster that unfortunately just wasn't

possible. Um and then the last problem

was uh trust right how do you collect

data in a way that you can essentially

not only guarantee that your existing

data is correct but also predict that

your next outcome is going to be at the

same accuracy and for humans that's

that's near impossible to do right

asking a human to like predict their

next set of accuracies for the next task

is near impossible um but those were the

early days of like AI as we know it

today but certainly not early for

machine learning some of these new

algorithms coming out. Google just

dropped this paper, attention is all you

seek. Um, so all of that started coming

together where we basically had the

hypothesis that you could leverage AI to

change how you think about data

collection, right? Maybe not completely

removing the human in the loop process,

but rethinking that architecture. And I

would equate it to thinking about like

how you build cars, right? So today the

way we build cars as you know as is

accepted as the norm is you have

essentially a production line right 100

years ago with the model T we created

this production line there are a

combination of machines and humans

operating under machines there are

process controls operational controls

six sigma and whatnot that sit on top of

this production line and therefore we

can get high quality you know bulk um

output of cars and we take that almost

for granted said today it's like so well

understood we take that for granted but

the way data is being collected and most

investment institutions um is actually

like you know the coach building

business it's all done by hand there's a

taste element to it um a good analyst

will be able to collect better and more

data than a bad one which we looked at

and we said this requires a production

line you can't build a production line

that's fully autonomous but a production

line is better than handcuffed coach

And that was the foundation of what

created Dupa, right? Using AI to build a

business at its very core and rethinking

like how you extract data, how you

quality control data. And obviously with

the birth of AI as we know it from the

consumer side, um it was very natural

for us to say we are an AI first

company. We understand how everything

works. Let's work with the labs. let's

put out data into an MCP and let's

distribute the data because not only

should data be collected using um

operational controls and AI and and

algorithms, you should also deliver it

in the same mechanism to maximize the

output for your customers.

>> That's great. Thank you. Thank you for

that. And and and what what have been

the more recent impacts on your

business? My sense is that sort of the

rise of the agentic workspace has been a

nice tailwind for for dupa. But how have

you shifted the way you've deployed LLMs

both in building DUPA but how has it

changed the market environment for for

your business?

>> Yeah. So when we think about the

problems that we can solve for our

customers, right? Because at the end of

the day, Dupa has two sides to the

business. There is the data side, the

asset side, what we call content side.

Um there is also the workflow side what

we call product side and if you think

about what product means right product

at the end of the day means you're

solving someone's problem for them right

if you don't have a problem then you

cannot have a product by almost

definition right you just have a trinket

or a bell whistle so when we used to

think about how to solve a problem for

our customers we had to go build a whole

you know we had to build our Excel addin

we had to build an environment we had to

do all of these things with a very clear

problem in mind. And if you look at our

content, right, we've collected all of

these data over time. On average, only

about 5% of all of our data was actually

being used by by all of our customers

every quarter. So 95% of the data that

we're collecting um basically never sees

the light of day. But because we collect

everything companies um disclose, we we

don't know which 5% is going to get

used. We just know 5% gets used um any

given quarter. What AI flips is because

an agent is able to take in so much more

information than humans can. Um it

changes how much data is being consumed

by our database and therefore it changes

the problem sets that we can go after.

So in you know early days of dupa the

problems that we went after was earnings

updates right we help people update

their models in their format. You click

a button you update your model. Your

model might have a lot of data, but it

doesn't have every single data point the

company has disclosed. So after you've

updated your model with us, a lot of the

data actually just doesn't get touched

by you. But when you use our data in an

MCP and you're running a research query

with the MCP. So now you're out of the

modeling um workflow. You're in the

research workflow. Now research requires

a lot more data because your model might

not have let's say inventory breakdowns

but in your research process that might

be something you're doing right you're

tracking gross margins visav you know

work in process inventory. Um so that

becomes something that gets used. Uh so

what we saw is essentially now almost

our entire database is getting used like

every single quarter because there's so

many agents from our customers that

deployed on top of it. Um and we saw a

remarkable shift in the volume of the

documents we provide, the data we

provide. Um I think year on year we've

seen data consumption grow over a 100

times.

>> So that 5% has that changed?

>> Yeah, it's almost 100% now.

>> Wow.

>> Yeah.

Whether or not so an agent would consume

all the information, right? But after

the agent consumes the information,

whether or not they they surface all the

information to their end user, um I

don't know, right? Because that's their

internal system. Um chances are they're

not, right? But the agent is processing

all of that information. It's almost

like if your analyst went to read the

10Q cover to cover, they might not give

give you everything in the 10 Q because

a lot of it is irrelevant, but they

would have read it cover to cover and

they'll give you the top three most

important things.

And naively is that was that growth from

kind of the easier agentic services like

co-work cloud codeex

or did something else happen?

>> I think the most the the biggest change

and unlock for firms is going from using

chat as just a chatbot to connecting

MCPS with it. Um so that's like the

first lift. Um it's a it's a simple lift

which is which is sort of why the

adoption rates have been so high and we

just saw explosions there. Uh when we

dig into how users use us um you also

have these like very spiky users right

we have users using you know thousands

of times more data than our average user

is and that almost always is because

they're in a code engagement. Can you

can you frame Thomas a little bit of

just the path we've been on of

abstraction into the MCP?

Um and even 18 months ago, you know that

people were sort of building data lakes

and just like a much more complic O

talking about OCR and PDFs. It was much

more complicated

situation to get fundamental data into

into a chatbot. Can you just give us a

little bit of the highlights of what's

happened and and your sense of where

we're we're at right now because even

six months ago people were telling me

like MCP is still too brittle for some

of these use cases which seems to be

have become a solved problem. So just

give us that context if you would.

>> Yeah. So not all MCPS are created equal

because if you if you really think about

what is an MCP, right? An MCP is a set

of prompts like English prompts that sit

in front of your API. So really it's no

different like if you wanted to create

an MCP it's no different than writing a

very long prompt into claude or chatpt

and then ending it with your API

endpoint your URL right so now what is

this prompt the prompt in short is as a

set of instructions on how to use your

API so in human world we actually have

that we've had that for a long time it's

called documentation and API so when you

have a software engineer use the API

they always ask what where's the

document doumentation because just

giving me a URL for the API like is

meaningless if I don't know how to use

it right I don't know what's behind it

what are best practices what are limits

and all of that so the MCP prompt is

basically the documentations docu um you

know portal summarized into a text file

but ultimately what makes an MCP good or

bad or brittle comes down to what is in

the API right MCP is just an API that's

being used by a large language model

versus a human. And how you set up the

API still is the same as what it is

before. First of all, you need to have

the right data in it, right? I anyone

can create an API endpoint with nothing

behind it. It's a functionally useless

API, but you could create one. Um, two

is once you put the data in it, how do

you structure it, right? All the best

practices that exist for humans to use

an API is identical here, right? Are you

creating a pathway and an index to help

search through the API? Right? If an

engineer looks at API and they say,

"Hey, there's 15 different API like

endpoints within this first endpoint,

like how do I search through them? How

do I know what the syntax is? What a

best practice is like all of that still

needs to exist, right? Um, do does your

MCP have or the API in your MCP have

access to different tables? How do the

tables work together?" So, I give you an

example. In our MCP there are multiple

different tables right one table is just

numbers one table are documents so when

you hit our MCP and you ask a question

like summarize you know Amazon's

earnings right a few things needs to

happen the first thing is it needs to go

through all of the data and essentially

say okay what has happened to earnings

what are the historical numbers like and

so on and so forth but it also needs to

corroborate the numbers with the actual

transcript with the Q with the AK K with

the investors act right pull all that

information out to create a holistic

view. It also needs to gets access to

stock pricing right and look at how

Amazon stock price has change visav's

benchmark or other peer. So it needs to

pull in a bunch of stock pricing. So to

make your MCP really good, you need to

not only have multiple data sources in

there, um, but also the data sources

needs to be connected internally within

your API in a way where if the if the

large language model is pulling Amazon's

gross margins, it knows where it's

coming from. It knows the notes that

relevant to gross margin and it knows

based on these notes, what are the

historical notes that I should look at

um because that might be relevant to

helping me understand gross margins

today. So connecting all of those

tables, setting up an index, making sure

that you know the latencies are low,

that's what makes an API good. And if

you have a good API for humans, you

almost always have a good API for MCPS.

>> And where do you think is sort of

understanding that there it's a probably

heterogeneous answer? Where do you think

the MCP structure is today in terms of

reli reliability? Has that improved as

the the foundation models have improved?

agentic search etc. And sort of where

where where are we at in terms of you

know trusting that data to not

hallucinate or you know sort of break

break retrieval and MCP structure.

>> So I I think it has definitely improved

on the model side. Um but I think the

bulk of the improvement that we are

seeing with MCPS today is actually not

because of the models or the labs but

actually because of how data providers

are creating their MCP. I think people

are starting to get comfortable around

you know an MCP is not like a business

catchall right like someone senior says

we got to build an MCP we build an MCP

at the at the end of the day is still a

product it's a product that needs to be

maintained you need to talk to your

customers you need to understand what

problems you're actually solving for

what are the most likely used prompts

why they're using something and how do

you build your MCP to help that um what

other people have figured out is you

know one of the fastest ways you can

help people adopt your MCP is to teach

them what are the best use cases. So can

you create skills such that when your

MCP is invoked your customers can also

pull those skills to to invoke the MCP

right and your skills will have a clear

guide to how to use the MCP. So a lot of

it is just like how you know when you

deploy an API you would sit down with

your customer and say hey let me teach

you how to use the API here are some

case studies of how people have been

successful using that API. It's the same

thing here just instead of case studies

you're using skills or agents right so I

think there there is a lot of groaned

understanding amongst the vendor

community um about that where we see

roadblocks happening comes primarily

down to um this cannibalization debate

right because you could argue that if

all of my data is in the MCP so first of

all the question is does all my data go

into the MCP right but hypothetically

let's say you're you're a content

company or data company, you say all of

my data goes to EMCP and it goes to my

customers. Then if you have any other

products that are reliant on your data,

then the question is, is it still

relevant? Right? Like a a simple example

is let's say on the DUP website, I have

a summary table for a summary of

financials for every company and

customers would go to that page and just

look at summary financials. um if I put

financials in my MCP then theoretically

you don't have to go to my website to

look at summary financials because if

you prompted claude you will get the

same thing moreover if I gave you that

skill I'm making it even easier for you

to go and view my data in claude and not

on my website so I think for

organizations where they look at that

setup as a loss of adoption then it's

rightly so you get concerned right I

have a different view my view is so long

as I am the reason I can solve a

customer's problem gets solved. I don't

really care if you're solving it in my

system or, you know, in someone else's

system so long as I I am solving your

problem. Um, so I'm willing to put every

single asset I have into the MCP. But

you can see how at different

organizations you end up at different at

different conclusions.

I've I've noticed that I'm a Faxet

subscriber and I've found that my the

time I spent in the faxet terminal is

down materially which is sort of nice

because the UI is like not great. U but

I'm accessing a lot of that data via an

agentic workspace. Um, how do you think

about like one of the things I'm

struggling with is and I get hear you

sort of get this question from my

students and clients is like what's the

right MCP stack

within an agentic workspace because dupa

was early as a as a connector into many

of these workspaces but now I could get

fundamental data from six or seven

different players in the same agentic

workspace. How do you think about that

competitive environment where more

fundamental data pipes, KPI pipes are

coming in in into the agent? How you

would counsel an investor to decide on

that stack and how you think about DUPA

as being differentiated within that

stack?

>> Yeah. So, I I love the way you frame it,

which is like pipelines, right? So, yes,

we were the first to build this

pipeline. Um but you know anyone can

build a pipeline and ultimately if

you're an investor you should have you

know hund hundreds of these pipelines

coming into your firm. Um but just like

a pipeline if let's say every pipeline

is carrying water right um what you

really want is to get the pipeline with

the highest quality water. Usually the

highest quality water tends to also come

at a premium. Um and you might say hey I

am a science lab and this water needs to

be so pure it doesn't even conduct

electricity right pure water. Or you

could be a household where you're like

that doesn't really matter. It just

needs to be portable. I just need to be

able to drink it. Or you could be a

factory where it's like it doesn't even

need to be like portable. I just needed

to cool a machinery. Who cares? So

depending on your needs, you probably

have different types. You could connect

to all of those pipes, but you should

only turn on the pipe that solves your

problem. So I don't pretend that the

Lupus data and content can solve

everybody's problem at at their

perceived price to value, right? What we

do is we go for the extreme quality, the

low latency, the high coverage, right?

No fundamental data set out there has

deeper data than we do, has more

accurate. So, we are the most accurate.

We have the lowest latency and we are

probably by far the most uh the most

comprehensive, right? We cover data

points that other firms just simply

don't cover. We have, you know, guidance

and adjustments and KPIs and guarantees

and enterprise SLAs's. Um, so we are

sort of like the pure water that goes

into a lab, right? It's ent truly

enterprisegrade targeting some of the

largest institutional investors and

today serving some of the largest

institutional investors, right? But I

will argue, you know, if you're a

smaller firm and the quality doesn't

matter because your investment style and

uh process just doesn't require like

extreme high quality like this is

company dropped earnings, I need to know

everything right away. um then we might

not be at the right price point because

your perceived value of our data will be

lower um and there are as you pointed

out a lot of other sources.

>> Yeah. How do you think about I sort of

you know debate with myself both sides

of this sort of like best of breed stack

within an MCP pathway of like let me go

pull in the six highest quality stack

sort of pieces of the stack which makes

sense. I sort of agree with you

certainly for the tier one client

although the MCP pricing for that stack

now can be like an aggregate like 60 70k

like the numbers get pretty high when

you start to add up the MCP price versus

a number of vendors um chasing this one

pipe strategy where they're trying to be

very good but with one MCP price and

there's some creative licensing sort of

you know um vendor licensing strategies.

How do you think about where does Dupa

want to play in that? Uh and how do you

think about the the juxtaposition of

those two MCP strategies?

>> Yeah. So um because the beauty of a

large language model is that whether you

have one pipe or three pipes is

fundamentally the same to the large

language model, right? Because if let's

say I'm connected to three MCPS, which

basically means the model is connected

to three APIs and if behind every API is

three other APIs, the model is now

connected to nine endpoints, right?

versus if I had nine MCPS with only one

endpoint each. The model at the very

core is actually connected to the same

amount of resources. So it doesn't

really matter from a buyer's

perspective. Yeah, you have to deal with

more vendors and contracts and like

people. Now, uh but at least from a

product angle, you you should be getting

the same outcome. Now, from a vendor

perspective, obviously if you have more

content, you could make the argument I

can sell to more people and therefore I

can build a bigger business. Um, but I

think that the core to whether or not

you want data into your pipe or not is

whether there are synergies between the

data assets. So one example is that the

clearest example is data and documents.

Right? If all I had was numbers but I

don't have the documents then you are

losing the context for the numbers

because the number 27 in and of itself

means nothing until I can describe what

it is. I can describe the history. I can

describe the context and how the context

has shifted. So having a pipe of just

documents and having a pipe of just data

will not get you the same output as

having one pipe where they are

interconnected and woven together where

texonomy has been built. Um but said

differently, let's use like stock price

as an example, right? If I have a pipe

of just end of day stock price and I

have another pipe of just um fundamental

data, like that map is relatively simple

because end of day stock price doesn't

have a lot of like you don't have a

security master issue with end of day

stock price uh for let's say the New

York Stock Exchange tickers. So then it

works well with a large language model.

However, if you say hey end of day stock

price is not enough. I need tick by

tick, you know, L2, L3 stock price data.

Now all of a sudden you have a security

master issue, right? So now you need all

of your security pricings to get mapped.

If you throw in like option prices into

that, now you have a real security

master issue. So trying to get the LLM

to say, hey, I'm going to buy one L1

panel, one L2 panel, one L3 panel. I'm

going to buy a fundamental data panel

and magically assume that the LLM can do

the mapping in real time or in runtime.

like that's not that's not that's just

not possible, right? You will end up

with a lot of hallucination. So, there

are data sets that require the vendor to

build texonomies and mapping beforehand

and there are data sets that don't.

>> Yeah. And how do you think how do you

think about the moat of your of your

data set? I mean, I sort of would seem

that armed with agents, it would be

easier for a competitor to recreate what

you've built, but what what are the sort

of defensible elements of the the moat

of your high quality data? [snorts]

>> Yeah. So, the the mode ironically itself

is high quality, right? Because um being

able to collect data and being able to

collect data at like a 99.9% accuracy

are wholly different problems. Um I'm

going to use the car car factory

example. So when you build a car and

Toyota is famous for like you have six

sigma right when they when they build a

car the car has the same quality as

every other car down to you know six

decimal points of nine. Um that is

really really hard to do and even if

someone else has access to all the

engineers to build the factory like you

cannot replicate the quality of the

Toyota factory. Now why is that? It's

because it's it's never about just a

tool. Like giving someone a really good

hammer doesn't make him a good

carpenter. It's everything else. It's

how do you set up um your process? How

do you set up your controls? How do you

set up internal SLAs's down to how is

your company culture? How do you

incentivize and reward people? How do

you hire? Right? Every single thing that

we care about um has an angle towards

accuracy. Right? Okay, within Zupa, we

even talk about what are the personality

traits that lend to higher quality

output versus what are the personality

traits that lend to faster output and

are they the same personality traits,

right? So, we care about like

microscopic little decision making. Uh

we care about how we get incentives

aligned at the 15 minute mark of

earnings, the 30 minute mark, the 45,

the one hour mark. and how do you think

those incentives translate into actual

human outcomes and the engineers

outcomes. So you can't just go into just

like how you can't go into cloud and be

like collect all the data for me. Um

it's about how you set up your entire

factory with like very clear goals in

mind. And for us we have three things we

care about. We care about completeness,

we care about accuracy, and we care

about speed, right? And that's like

frankly the only three things we care

about. Um and you can't just go to

Claude and say and maybe you could in

five years. Who knows, right? But you

can't go to cloud and say I want perfect

data extracted from every document in a

database in real time. Go.

>> And if you look at um those those three

parameters assuming you're hitting them,

you're you're delivering at the quality

that you want and you fast forward is

the is the company's strategy to expand

into more data sets or to move more into

the application layer or is there like

what's the where do you go from here?

>> Yeah. So we we always think of a company

as made up of two two pieces. The

workflow piece and the content piece. Um

so they have this the central goal is to

solve problems for our customers, right?

So if there is a problem that requires

more data, then we will collect more

data. If there's a problem that requires

us to get better aligned with workflows,

we will do that. uh but high level the

the job of work the sorry the job of

content is to acquire data sets that can

get us deeper and deeper into our

coverage right so we cover 6,000

companies today we we constantly expand

our coverage that's just a motion that

we have um but it's also about can we

get deeper right so um let's use like uh

commodity companies as an example right

commodity companies disclose a lot of

data just stand alone um but they

actually have regulators that are not

security regulators. So, think about

like the the environmental agencies

around the world. Um, and for particular

commodities that might even be their own

like regulatory agencies and there are

filings, right? A lot of these mines

will tell you the reserve number where

their minds are at. These they file

landscaping uh with all these regulatory

agencies. These are all information that

can help you make better and more

informed decisions. And the content is

really hard to assemble, right? Some of

these guys, you literally need to call

the regulator for them to like FedEx you

the documents. Some of these guys you

need to develop a relationship. Um, and

so the content team's job is to make

sure that we get deeper and deeper. The

workflow team um the way we the way we

think about it is we call our work

basically the 13week problem work where

every quarter has 13 weeks and if I

looked at week four of every quarter,

they have a tendency to look the same.

If I look at week one, they all have a

tendency to look the same. So the

question is like what is the most

painful week? And of the most painful

week, what is the most painful problem?

And is that problem a problem we can

tackle with a workflow solution? So for

example, our first product is updating,

right? We basically said the most

painful week in a hedge fund analyst uh

quarter is the earnings week and the

most painful minute of earnings week is

literally the minute when earnings drops

because you have to update your model.

So what is the ideal workflow solution

here is to create a button where if I

hit the button I update my model. So our

workflow team's job is okay identify

this unique problem and what is the

ideal workflow outcome which is to hit

this button right so given that we have

now developed that what is the next set

of problems and what is the ideal

workflow outcome for that and usually

our framework is the best workflow is

always an invisible one so we don't want

to build into like some big UI that you

have to like tinker with and there's

like knobs to turn right we want to

build an invisible experience or an

experience experience where you

basically hit a button and it works. Um,

but the magic comes in identification of

the problem and creating a system that

is so good that it feels invisible.

>> And on that identification problem, are

you using a forward deployed model or

are your product managers is that that's

being done kind of uh in-house?

>> Yeah, so we don't do forward deploy. Um

we and maybe we will in the future, but

right now the way we like to think about

it is you need to be so integrated into

your customer that you shouldn't have to

have a forward deploy engineer, right?

We should be able to just sit down, get

a coffee with any of our customers at

any time and just like really really

dig. If you have the philosophy and the

culture of a business that is so deeply

ingrained with the problems of your

customers, you shouldn't need a proxy to

tell you what the problems are, right?

You should almost be at one with how

your customers operate,

right? So, if I went to my team today

and I asked them, hey, it's earning

season, like what's going on? I should

be getting a response be like, hey, this

is what's happening. You know, this is

the peak. Here's what we expect at 4

p.m. here's what B. Here's what miss.

Those are the high level things that we

should be able to experience internally

because we need to live like our

customers too.

>> Thomas, how are you seeing funds

integrate other sources of data, their

internal data or their alternative data

with with with the loop and how has that

changed as as more top funds have have

gone down the agent path?

>> So, they don't quote unquote integrate

into dupa. What we see a lot of is they

basically start to create these

orchestration layer internally within

the fund. Um folks have taken different

approaches. Some are building knowledge

graphs to solve that problem. So

everything feeds into the knowledge

graph. The knowledge graph feeds into um

the the large language model layer where

the agents sit. Some folks are basically

not using that. There are other ways you

can solve it. You can connect a bunch of

MCPS. You can create skills that help

you orchestrate the MCPS. So some folks

are doing that. Um the key benefit of

doing it without the knowledge graph is

access control because if let's say team

A does not have access to a certain

asset and team B does then you can't

really go to create two different

knowledge graphs. You can't create a

knowledge graph for every single person

based on their based on their you know

uh their licenses. So um it's hard to do

that when you are really really scaled

out and you're trying to build

infrastructure for everyone. Um but you

can say okay instead of building a

knowledge graph which captures context

can I use um a bunch of orchestration

skills to do that and then connect all

the MCPS. I think the most forwardinking

bite firms they also tend to be larger

um we'll work with vendors and walk them

through where the MCPs are good and not

good and where they need to work on. I

think it's easy for a vendor to look at

their MCP and say here here's the

customer's problem but your enduser's

problem and the enterprises problem

might be wholly different problems right

so like making sure that you can solve

both problems in your MCP um also really

matter can can you unpack the the

knowledge graph a little bit more some

logistics of that what does that look

like sort of in in in the specific sort

of build structure of a knowledge graph

>> so a knowledge graph is nothing but

folders and and skills, right? If you

think about like the Obsidian wiki or

whatever, um it's basically sorry,

folders and markdown files. Uh the magic

of a knowledge graph is to have all your

markdown files connect to each other and

creating a system to generate markdown

files um automatically and basically

like delete quote unquote delete

markdown files that are no longer

relevant. And so what you're trying to

mimic is basically the human brain,

right? you're trying to recreate um a

set of memory and context and analysis.

So what some firms will do is they'll

say, "Hey, we have 10 MCPS, we have 10

skills, right? If I ran 10 skills on

every ticker through every MCP, I can

create, I don't know, 10,000 markdown

files, right? If I can connect all the

markdown files together um and instead

of having the MCPS directly connect to

my large model, I connect my endpoint to

my folders with my markdown files or the

knowledge graph uh to the large language

model. So I think a lot of firms are

doing that. Um there's a tendency for

those firms to be more of a one team one

dream type setup. Um and the key benefit

of that is uh you basically have the

analysis and the context pre-done. So

the AI doesn't have to do analysis. So

let's say Amazon drops earnings. Instead

of a user prompting the system to

analyze earnings, it autoan analyzes

earnings, creates the markdown file,

connects to last quarter, Amazon

earnings, connects to Costco earnings,

connects to Nvidia earnings, connects to

all these companies as relevant to

Amazon's earnings. So when I come into

cloud and I say, "Hey, Amazon just

reported earnings. What are the macro

trends I need to take away from Amazon

and their peers and how does that

influence how I should think about next

week's earnings?" A lot of that work has

already been pre-done. So Claude's job

is really just to walk through your

knowledge graph and figure out where all

the pieces lie and assemble it together

as opposed to generating that output on

the fly which significantly improves the

quality of the output and drops your

token your token cost. step stepping

away from from data and dalupa for a

minute. Um we thought we'd fire a few

just broader AI questions at you and one

of the things that it feels like the

debate is picking up again um and in a

few of my evals some of the models have

gotten surprisingly good on the open

source like Chinese open source models.

I'm curious sort of your perspective

um on the sort of frontier models versus

open source models how you see that

debate uh evolving.

So this is a personal view. This not

dupa view. I'm a big believer in open

source. Um I mean if you look at aloopa

github we've open source every time we

create a skill or an agent we open

source it. So I'm a big believer in

that. Um my view is it's very very hard

to build something that is technical um

faster than an open-source creator can

especially when the literal contribution

um world today is everybody because

everybody can now code so everybody can

contribute to open source so all it

takes is will and will and and passion I

guess and there are just more people

who's not working in anthropic and is

working in anthropic right so it it

becomes really hard to combat open

source I think um and but in this case

we're specifically talking like open

weight models right like the K3s of the

world um I think it's really hard I

think at the bleeding edge when you

think about how you actually make a

model better there are a couple of

different elements to it right one

element and this is like way

oversimplifying it but one element is

increase parameter size, right? If if

you can build a 20 trillion parameter

model, chances are it's going to be

better than a one trillion parameter

model, right? Because you just have more

weights to play with. Um, but where you

get a lot of efficiency actually isn't

in the base model, but what you do in

post- training, right? So, if I took a

small parameter model and I really

postrain it to a very specific task,

let's say this task is building a DCF,

right? If I had $10 million to have a

model build a DCF, instead of spending

it increasing the parameter count of the

base model, I just take a small base

model and I just post train the the heck

out of the DCF piece. I f I hire a bunch

of people, build a thousand DCFs, feed

it in, do it again and again and again.

Um, you end up with a model that can

build a DCF better uh than the increased

parameter size. Obviously it taps out

like if you don't have a model with big

enough parameter size like you end up

going to these like really really deep

um targeted you know use cases but if

you think about the use cases of all the

different things you do within AI in any

industry it's actually somewhat

quantifiable of of course there's a long

tail but you know when you use AI in

Excel right there's really only like

five to 10 different things you're

trying to do with when you use it in a

hedge fund, in a chatbot, there's really

only five to 10 different things. So

there is a case to be made where the

labs can work closely because they're

are enterprises can work closely with

their customers on the post training

piece to get the output really precise

to what they need to do um in a way that

the open-source guys can't because it

would be very hard for a hedge fund to

speak to an open source model and say

I'm going to give you how I think about

the world so that you can train your

open source better, right? So, that's a

disadvantage of open source, which is

industry seekers tend to not get in. So,

post- trainining becomes difficult, but

their advantage is on the pre-training

side. Um, they have a much lower lift.

I' I've heard the I've heard the

opposite argued a bit with some of the

like local host locally hosted

post-trained Quen models where that sort

of that post- training actually lives

within the walls of the hedge fund where

there's actually a little bit of growing

skepticism about working with the

foundation labs as a large asset manager

because you're sort of leaking your

leaking your proprietary knowledge back

into the back into the foundation lab.

How would you sort of rebut that? you

sort of seem to have been observing the

opposite.

>> Yeah, I think post- training is more art

than science. I think yeah, in theory

you can go into GitHub and just download

like a post- training module and just

put all your data in there and you know

local host Quen or K3 or whatever and

run post training. I think the reality

is like when you think about what post

training really is, it comes down to a

very very simple problem. You have to

know your objective function, right? So

when when we say train a model for a

specific problem, what we are assuming

is that we can very in a very

quantifiable way write down this

problem. Right? And a lot of business

problems cannot do that. So if you go to

an analyst and you say, I'm going to

train a model that can do what you do. I

need you to write down in a few

sentences for me a measuring stick on

how I know the output is good or worse.

And the analyst will be like, I I I

don't know. Like, yes. And the final

outcome is P&L, right? Like we all know

that. But when we start to break down

what creates P&L, like what makes a

pitch better or worse? Like is a 10-page

pitch better than a onepage pitch? Like

probably not. So that's not a good

measure. Is detail of analysis better?

Maybe. But like how do you know it's

more detail? More numbers, right? So it

becomes [snorts]

very taste driven and very art driven.

So anyone can post train but what is

your objective function? That's like the

key problem. If we could take a

particular problem and say definitively

there is a quantifiable objective

function then that problem can be

post-trained on. So a very good example

is math right if you're trying to solve

math proofs there is a very quantifiable

objective function because you either

prove it or you don't and a proof is

either right or wrong. So in that world

post training becomes I wouldn't say

easy but quantifiable and therefore you

can just run cycles on but if let's say

we are writing poetry what makes one

poetry better than the other like I

don't know it's not quantifiable so if

it's not quantifiable I cannot create

that feedback loop of like this wasn't

good this is good look like this next

time

>> so that's what makes post training so

>> it almost sort of like investing or sort

of the the the craft of creating a

thesis almost is more like writing than

math obviously where it's hard to sort

of verify X anti and there's been more

sort of watching the narrative around

the latest set of models that actually

like writing is number of people

observed like writing has actually

deteriorated the writing quality has

deteriorated due to

>> sort of the um uh reinforcement learning

with verifiable rewards is sort of one

hypothesis I've I've seen. So that's

interesting. K you had a question

>> on that on that point Thomas that none

am I hearing you correctly that a lot of

knowledge work is not ver verifiable and

like discreet with like discrete metrics

does that it how does that impact how

does that what's the long-term impact of

this unverifiability

for our knowledge work like do we you

know coding went exponential because it

is verifiable you know whether Amazon is

a good buy is is hard to verify. Does

that create a natural like ceiling for

LLM usefulness or in the long term?

>> No, it does not. I don't think so. Um, I

think what it does is it creates a

ceiling for trying to post-train a model

to solve that problem, but doesn't mean

you cannot break that problem down.

>> Right? So um we know we we we know we

cannot determine if one pitch is better

than the other just by reading it right

I mean past a certain point right we

know we we we can't really discern it

becomes a judgment call but what we do

know is that within a certain pitch

there are things that are quantifiable

and verifiable like your numbers should

be right your historical numbers should

be right if you're calculating gross

margins like your your math should be

right if you're telling me that there is

some historical effect that went through

the business, right? Jeff Bezos retired

as CEO. Like those are facts that

shouldn't be questionable. So those you

can verify, right? It's the judgment

piece that you probably can't, but it

doesn't mean that there is nothing that

you can you can verify on. Um, and

that's where you can add a lot of value,

right? Say differently, when I think

about historically what a human is

doing, right? A human does three things

at an investment institution. You're

either gathering facts, you're analyzing

the facts, or you're passing judgment on

the facts. And for the most part,

anything you don't you're doing that's

not part of these three is not a good

use of your time. There's a lot of like

random stuff that comes up, but it's

probably not a good use of your time.

Um, the analysis

piece, you can very easily quantify a

lot of it today. Is this a right

analysis, the right calculation or not?

If you build a if you build a three-step

model, did it balance or did it not

balance? It's verifiable, right? But the

judgment piece is hard to verify. If

someone pitched an Amazon long and you

bought Amazon and it's down tomorrow,

like was he wrong? Like we know probably

not. But why is it that we know that?

What is the right time horizon, right?

So that becomes a human judgment piece

that I would say is very hard to do post

training on uh but on the analysis piece

is is much easier today.

I push back a little a little bit on

that and in and sort of one one world

that's sort of grown meaningfully over

the last 10 or 15 years is world of

factor investing which sort of tries to

capture that judgment like there is sort

of an X anti- table odds improvement of

a company with high free cash flow

margins versus low free cash flow

margins. So this is sort of a

demonstrated sort of tilting of the

table odds and I think a number of funds

are starting to think about this concept

of pattern recognition. How do you

codify the patterns that have been 60 40

coins versus 40 60 uh coins? Um

obviously this this realm of AI has a

much higher um sort of value quotient

than update this model. What do you see

what do you see out there? So there's a

more nuanced um ability to verify

um than hey update this model are the

numbers right? What what what are your

observations on on sort of that side of

the world that this thinking machines

Bridgewater report got a lot of uh

despite being sort of a um just a very

simple analysis got a lot of discussion

about can AI actually start to pass

better judgment and investment tests.

>> Yeah, this a good question because the

question you're really asking is what is

judgment, right? Can you actually take

this whole concept of judgment and break

it down and factors does a great job of

that. So um I think in short yes the

answer is yes like AI can get to some

piece of judgment um assuming that we

can break down what judgment is. So

let's think about factors, right?

[clears throat] Very simply, when I

think about what makes a stock move,

there's only one thing that ever makes a

stock move, which is demand and supply,

right? Every stock moves because they're

buyers and they're sellers and there's

like a higher willingness to buy than

then sell, prices go up, whatever.

Demand supply curves. Um, what we're

trying to figure out is why someone is

buying. And the reason different people

buy are very very different. The reason

the index is buying or like a big mutual

fund is buying um is very different from

the reason you know a long only hedge

fund is buying is very different from

like a quantis buying right but in the

market they all get expressed as buying

signals obviously if a big mutual fund

is buying let's say the market the S&P

500 they're probably not just buying

Amazon they're buying you know 500

different companies at the same time so

the so the that creates a market vector

move that might be different from you

know whatever a single stock investor

buying Amazon right so what factors try

to do is given any single period of time

break down the reasons for why someone

is buying by looking at what other

things are moving so instead of saying

hey whatever Amazon is the only factor

is the S&P 500 or you know the Q's or

whatever you can basically say I have a

much more intelligent way of thinking

about it right I can run PCA and I can

say hey Amazon is you know X amount you

know correlation with the first factor

in the PCA and Y amount in the second

factor and so on and so forth and that

allows you to without naming what the

PCA is like what the first order is to

say that there is a first order right

there is something you can make a guess

maybe it's momentum like I don't know

but you can make a guess right but we

know that you can statistically

quoteunquote prove that um the the

beauty of this is not that the AI can

pass judgment is that we have taken

judgement ment of what makes a stock

move and we have actually broken it down

into a language that we all agree on

right which is like sort of like this

PCA language and therefore we it's

quantified and then you can bring it to

an AI what I would actually argue is

that the stuff that is not quantifiable

today is the new set of judgment

>> yeah so let me frame it this way a like

the factor world has grown up around

observations of the present right So

it's sort of by you know by definition

looking in the rearview mirror of what's

happened. This company sort of

accumulated a high momentum loading. The

sort of intriguing element at least to

me is started thinking about actually

the the the look ahead. If I had two

companies to sort of give a simple

example one's going to raise revenue

guidance by 5% one's going to cut

revenue guidance by 5%. That's like a

sort of most like not it's not going to

be a 100% batting average, but that will

be a good batting average on the

trajectory of those two stocks, you

know, sort of classic PCA analysis

hasn't been able to sort of, you know,

um find correlations to that. But these

sort of agent the agentic digital

analyst approach fed with the right data

is getting close to having ability to do

that in some sort of reliable um uh and

that's a that's a verifi that's sort of

a more verifiable framework like you can

sort of look at batting a batting

averages of revisions. Well, the the the

thing that is really hard for a human to

do and if you look at most funds um you

don't even have the same people solving

this this problem is that the person

who's trained in fundamental analysis

really only thinks in one factor which

is fundamentals, right? So a person you

might be really good at predicting

whether a company is going to raise

guidance because of all the work that

you've done but you might not actually

know or most of the time these people

aren't in tune with the factor

environment to say sometimes raising 10%

guidance in some environments create 10%

moves for your stock sometimes it

creates 2% move to your stock right so

that people who know that tends to be

PMs risk they tend to not be close

enough to the fundamentals to be able to

marry them together. And that's always

been like a a problem for a lot of

funds, right? Which is people who

understand factors don't understand

fundamentals and vice versa. But the

stock doesn't care. The stock is a

combination of both,

>> right? The move of the stock is a

combination of every demand and supply

in the market at that moment. It doesn't

say today I live in, you know, the

momentum factor and tomorrow I live in

the fundamental factor. like everything

is influencing it at the same time. Uh

we just don't have people that can

capture that and the question is can an

AI do that? Yeah, probably.

>> Yeah. Yeah. This sort of promise of you

know quantimental which has been this

sort of you know one plus one equals

three concept for decades really which

has been really hard to like people have

sort of you know made money on

quantimental but it's more of like an

overlay strategy rather than a true

merging of the best of

>> both both um uh both practices. I don't

think there's really any scaled manager

that has brought the best of both into

but that's sort of my hypothesis is like

agent you know the agent architecture

allows allows a new way of investing

almost like systematizing the

fundamental investor

>> I mean what what what we're seeing a lot

is like there there is this race to the

medium right now which is the quan funds

are basically saying our challenge

historically has never been on

understanding factors like we got this

stuff down pretty good but We couldn't

get our hands on fundamental data and

make sense of it in a way we

systematically could do so with stock

price with security prices. And with

fundamental guys, it's we've we've

always been able to build models and

talk to companies that understand that,

but we couldn't systematically think

about factors and overlay that onto our

process the way the quants could. So you

almost see this race into the middle

where the quants are saying AI has

unlocked the ability for me to get

fundamental data, right? How do I marry

that into my process and to become a

quant fundamental shop? And the

fundamental guys are saying now clock

code has changed the way I look at the

world. I can now be a software engineer.

I can analyze security pricing, right?

How do I go from fundamental to

fundamental quant and you almost have

like this like race to the middle

>> 100%.

>> Thomas, one other question I had. I I

spent a couple weeks head heads down

head down a couple months ago um with

some of the Excel in integrations

including you know the dupa MCP into

claude XL and I was actually quite like

the simple update a quarter worked. Um,

beyond that, I was actually quite

disappointed in the ability to um to do

things I was hopeful would be um

possible like asking Claude XL to you

know rebuild my revenue you know build

for a resegmentation or handle more um

complicated issues which you know across

300 models like you know 100 are going

to be simple 200 are going to have some

sort of messy messiness to them. Um,

where do you think we're at in terms of,

you know, uh, LLM fluency with Excel?

The ability to just speak into speak

into the XL LLM and have it do more

complicated tasks like that.

>> Yeah. So, I would have given you a

different answer a year ago than what

what I'm going to give you now. So if

you asked me that a year ago, I would

have said um the dupa philosophy is we

build the best data and we pipe it into

uh whatever platform to go solve that

problem because the platform is going to

take care of that problem. Um and so we

were hopeful that cloud excel with IMCP

will be able to solve you know all the

Excel problems. Uh but as you just

pointed out it's been a year and it's

not there. And so we looked into why.

And

very simply put, the Excel problem, it's

about a set of specific business use

cases in Excel um that require a very

very fine-tuned understanding of what's

going on. So let's say someone comes

into a model and says something very

simple. I want to understand the

operating leverage of the business. The

amount of analysis that needs to happen

is actually very detailed, right? You

need to first get cash numbers. You need

to get the non-GAAP numbers out. You

need to understand everything from how

capex changes changes your revenue. How

much of that is because of opex versus

capex? Um can you actually spend on uh

can you actually cut back on capex or is

that like you know fake capex right? So

there are a lot of little little steps

that needs to happen that doesn't get

captured by the simple question um help

me understand operating leverage for

this business and then every business is

different right understanding operating

leverage for an industrial company and a

software company despite the fact that

they have different amounts of operating

leverage the way you would approach your

question is also different. So once we

realized that there are multiple layers

of depth to this problem, uh we started

asking ourselves is there an ultimate

solution of basically saying hey clot

with my MCP can solve like if the model

became better can we get there and in

the near term I think our answer is no

it cannot get there. Um and so what

we've then decided to do is we've then

decided to build our own version of an

Excel addin. It's not launched yet. Um,

but the idea is in order to solve the

Excel problem, it's not an Excel

problem. It's a very specific problem.

It's the operating leverage problem.

It's the hey, can I get the KPIs broken

down problem? Is the hey, can I

understand what each KPI represents? Can

I understand if this company needs to be

forecasted using FX neutral same store

sales or non-FX neutral same store sales

and how do I think about that? So

each of these set of problems require

very specific harnesses. Um and it is a

very very large set of harnessing that

needs to get produced. So um my view at

least as of right now is that because

the labs won't get to the level of

detail in the harnessing to be able to

solve this problem. This is actually

down to the vendor's guide like guys

like me who are willing to build into

workflow to go solve

>> and the LA labs you know have really

built their modeling corpus towards like

tuned to investment banking right which

is a very different which a very

different modeling exercise than build a

hedge fund model to forecast revenues e

>> yeah and the other thing is like is is

if you think about it this might be

something that you and I take for

granted um getting access to hedge fun

models even knowing what they look like

is not obvious, right? Because you can't

just go onto the internet and download a

model that is hedge fund grade. You can

download a model that looks like a hedge

fund grade model, but it's very

different because what makes it a high

quality model is not what it looks like.

I mean, how it looks like is important,

but it's how it's wired,

>> right? Is the thought that went through

the whole thing is why did he forecast

seasonality versus year-on-year growth?

Why use incremental costs? Why say the

company is increasing SGNA by 10 million

bucks as opposed to percentage of

revenue like why are each of these micro

decisions being made? That's what makes

a good buy model a buy model

right but very it it's it's not readily

available on the internet and I think

most product managers don't even know

like how what makes like if I showed a

really good product manager two models

uh one is a really good one and one is

an okay one and they look identical on

the formatting side it's not clear to me

that your average product person will be

able to discern it without having done

the job before.

One other question I'm I'm wrangling

with is um sort of we've been on this

pathway of abstraction with the models

like you know Claude is three from

Anthropic has talked about the system

prompt going down 80% and I'm sort of in

the process of sort of again narrowing

down my skills architecture uh with that

I've sort of going from like a chunking

like visibility uh like you many many

skills where I can see the outputs of

each skill they're more verifiable to

the model can now take sort of one shot

with that it sort of feels like eval

become much more critical because you

have less visibility. How have you

thought about building and designing

evals and managing sort of a skills you

know creation process through this trend

of abstraction and and better model

capability.

So we we've we've about a year ago maybe

a little more than a year ago we changed

the way we think about how to run

product organizations. So, historically,

you run product organizations by saying,

"Hey, here's my PRD. Here's what I'm

going to build. Here's why. Here's how

I'm going to build it." And then you go

build it. Uh, about a little over a year

ago, we changed it. We basically say,

you start every PRD with a set of evals.

So, you ask questions. Um, I care a lot

about the orthogonality of the

questions. So, you don't want to ask the

same questions five different times. You

want to make sure every question is

designed to go reflect a particular

thing a customer will do. And a lot of

times, we actually ask our customers for

these questions. So we get eval eval

from our customers and then everything

we then do is like as we build a product

we run through all the eval. So I

actually have a whole team in my

business a very large team. Um their job

is to do eval right. So you're

constantly running evals. You're

constantly testing. Sometimes an eval

takes a week and we don't have time. So

we just run a small version of it.

Sometimes we have to run a very very

broad scope one. We run it across all

the different models, across

orchestrations, across MCPs, across

token costs. So I think it's a cultural

thing. Um, when we first made the shift,

it was a little bit awkward. Uh, but now

we're like very used to it. And I think

that's just how product is going to have

to be built in the future. This is like

the new paradigm of thinking just like

how Amazon created sort of like the old

paradigm like start with the output in

mind, the press release, and then work

backwards. um today instead of starting

with the press release, you're starting

with the end evo and you're working

backwards towards that eventual like

let's say you need 100% score on all the

evos you're working towards that.

>> What's uh Thomas what's on your your

bingo card for the next uh three to nine

months of AI and investing like where

where do you think we'll be you know by

spring of 27 what will what will have

changed?

Uh I think the biggest change is going

to come in how people think about team

structure. So I think we all have a good

sense of you know the Excel problem.

Hopefully the loop is the one that that

gets the enterprisegrade Excel solution

out there. Um but you know there will be

an enterprisegrade Excel solution. Um

there will be more data vendors into the

space. Um the adoption rates will be

higher. I think all of that are

predictable. Uh I think the part that

people aren't spending enough time

thinking about is how you hire, how you

train, and how you do career lettering

in finance especially on the buy side

because when I think about the job of an

analyst, right? Um and this loosely

tracks with like the career you start

with fact gathering. Get your numbers

right, get your facts right, know where

the documents lie. If Amazon's reporting

at 4 pm, know that you know facts. And

then it goes from facts to analysis.

Right? Now you're a senior analyst. Now

you're trusted with building models like

you own the model, you own the analysis,

you own the pitch. Um to ultimately

judgment, right? What factor risk am I

taking? What stocks am I take going

long? What am I going short? For how

long? How much leverage do I take?

Right? There's a taste. I mean obviously

you get tools, but there's a huge taste

element to that. Um we are starting to

see the middle layer collapse, right?

where

a good well setup agents can run

analysis basically at the same quality

humans can. The difference is that it

can run 100 times the amount of analysis

a human can because it doesn't need to

sleep and I can open up a bunch of

different agents to go do it. So then

what that changes is the humans gets I

wouldn't say forced into but the human

now needs to spend time on how do I set

up the infrastructure for the content

side because an agent is not just going

to magically go out there and sign a

contract for you to you know purchase

fundamental data from dupa or credit

card data consumer edge or whatever you

still need to go do that how do you hold

your vendors accountable how do you hold

your internal people accountable to

creating a high quality infrastructure

and ultimately how do you spend more and

more of your time on collecting content

that cannot be easily connect collected.

So let's say calls with IR teams, right?

A good agent isn't going to help you win

more calls with IR teams or talk to the

right experts like you still have to go

do that work on your own. And then like

how do you process judgment? Can you

create frameworks for like creating more

judgments for yourself? Like how do you

increase the ability for yourself to

pass judgment? How do you even know

you've gotten better? Right? How do you

meditate on how much of a decision is

emotional versus logical, right? Has

your thesis slipped? Do you think your

thesis has slipped because you let it or

because you're because you didn't know?

So like I think there is a lot more of

the hiring training side that's going to

go into the judgment piece, but a lot

more time is going to be spent on the

infrastructure piece, whereas

historically the bulk of the time is

actually spent on the analysis piece.

Yeah. Yeah.

Great. Well, uh, thank you so much, uh,

for being with us, Thomas. Any any, uh,

any last thoughts or anything you're

you're you're wrangling with, uh, right

now?

>> I mean, the funny thing is, um, this is

a conversation we've had recently. The

single biggest challenge for for us and

a lot of peers is hiring and

specifically is in hiring engineers. And

if you think about it, it's ironic

because a year ago there was SAS

apocalypse and everyone was like

engineers are going to be out of a job

like clock code is able to code now. And

now we're sitting here saying well yes

coding is a solved problem but aligning

what you're coding with the company's

direction is not right. Communicating to

make sure that your evals represent your

customers problems like that's not

solved agentically. So while we

agentically solved the coding problem,

we did not solve the engineering

problem, right? So the engineering

problem now became bigger because we can

write more code and every single tech

company is desperately trying to hire

more engineers,

which is which I think is very ironic

but totally logical of like how we ended

up here.

>> And I wonder if that's going to be the

same thing in finance.

>> Yeah, [snorts] at least for the moment,

Jevans paradox holds. It's probably

about a year ago that Daario made his

prediction that in one to five years,

you know, white collar work will be down

uh entry- level white collar work will

be down 50%. That's thankfully looking

incredibly absurd as a prediction. I

think that's true in finance too. I mean

all the firms we talk to, the people are

busier than ever. you're maintaining

your portfolios and research in

incredibly volatile markets while trying

to sort of you know shift your process

>> um agentically and no one's even close

to the finish line of that. I think it's

still just starting. So yeah, at least

for 18 to 36 months I don't I don't see

any I've not talked to one investment

team was like wow this is so great that

we're just going to cut 30% of our

headcount because it's like we have

analysts sitting around with nothing to

do. It's like the exact opposite.

>> That's right. Yeah. I mean, if you have

analysts sitting around with nothing to

do, you are more likely to have an HR

and analyst problem than you have like a

business problem.

>> Yeah. Yeah. You know. Yeah. Awesome.

Great. Well, um yeah, excited to um

excited to get my hands on that Excel uh

thing when it when it comes out as well,

too. And uh thanks so much for for being

with us uh for being with us, Thomas.

This was a great great great discussion.

>> Thank you for bringing me on.