Agents @ Work: Dust.tt — with Stanislas Polu

Hey everyone, welcome to the Lead in Space podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co-host Swyx, founder of Small AI.

Hey, and today we're in the studio with Stanislas Polu. Welcome.

Thank you very much for having me.

Visiting from Paris. Paris. And you have had a very distinguished career. It's very hard to summarize, but you went to college in, in both Ecole Polytechnique and Stanford. And then you worked in a number of places, Oracle, Totems, Stripe, and then OpenAI pre-ChatGPT. We'll spend a little bit of time about that. About 2 years ago, you left OpenAI to start Dust. I think you were one of the first OpenAI alum founders.

Yeah, I think it was about the same time as the Adep guys. So was that first wave?

Yeah. And people really loved our David episode. We love a few OpenAI stories for back in the day, like we were talking about pre-recording, probably the statute of limitations on some of those stories has expired. So you can talk a little bit more freely without them coming after you. But maybe we'll just talk about what was your journey into AI? You were at Stripe for almost 5 years. There are a lot of Stripe alums going into OpenAI. I think Stripe culture has come into OpenAI quite a bit.

Yeah, so I think the buses of Stripe people really started flowing in, I guess, after ChatGPT. But yeah, my journey into AI is—

I mean, Greg Brockman.

Yeah, yeah, yeah. Of course. And Daniela, actually, back in the days. Daniela Modríguez.

Yes, she was COO. I mean, she is COO.

She had a pretty high job at OpenAI at the time. Yeah, for sure. My journey started as anybody else. You're fascinated with computer science and you want to make them sing. It's awesome, but it doesn't work. I mean, it was a long time ago. I was like maybe 16, so it was 25 years ago. Then the first big exposure to AI would be at Stanford. And I'm gonna like disclose how old I am because at the time it was a class taught by Andrew Ng. And there was no deep learning. It was half-features for vision and A* algorithm. So it was fun, but it was the early days of deep learning at the time. I think few years after it was the first project at Google about that cat face or the human face trained from many images. Went to, hesitated doing a PhD more in systems, eventually decided to go into getting a job. Went at Oracle, started a company, did a gazillion mistakes, got acquired by Stripe, worked with Greg Buchmann there. And at the end of Stripe, I started interesting myself in AI again. Felt like it was the time. You had the Atari games, you had self-driving craziness at the time. And I started exploring projects. It felt like the Atari games were incredible, but they were still games. And I was looking into exploring projects that would have an impact on the world. And so I decided to explore 3 things: self-driving cars, cybersecurity and AI, and math and AI. It's like I think by a decreasing order of impact on the world, I guess.

Yeah. Discovering new math would be very foundational.

It is extremely foundational, but it's not as direct as driving people around.

Sorry, you're doing this at Stripe?

You were thinking about the next thing? Yeah, after Stripe, kind of a bit of time where I started exploring. Did a bunch of work with friends on trying to get RC cars to drive autonomously. Almost started a company in France or Europe about self-driving trucks. We decided to not go for it because it was probably very operational. And I think the idea of the company, of the team wasn't there. And also I realized that if I wake up a day and because of a bug I wrote, I killed a family, it would be a bad experience. And so just decided like, no, that's just too crazy. Then I explored cybersecurity. With a friend, we're trying to apply transformers to code fuzzing. So code fuzzing, you have kind of an algorithm that goes really fast and tries to mutate the inputs of a library to find bugs. And we try to apply a transformer to that and do reinforcement learning with the signal of how much you propagate within the binary. Didn't work at all because the transformers are so slow compared to evolutionary algorithms that it kind of didn't work. And then started interesting myself in math and AI. And started working on SAT solving with AI. And at the same time, OpenAI was kind of starting the reasoning team that were tackling that project as well. I was in touch with Greg and eventually got in touch with Ilya and finally found my way to OpenAI. I don't know how much you want to dig into that. The way to find your way to OpenAI when you're in Paris was kind of an interesting adventure as well.

Please. And I want to note, this was a 2-month journey. You did all this in 2 months. The search?

The search for what? Sorry.

Your search for your next thing, because you left in July 2019 and then you joined OpenAI in September.

I'm going to be ashamed to say that.

You were searching before.

Yeah, I was searching before.

I mean, it's normal.

No, the truth is that I moved back to Paris through Stripe.

Yeah.

And I just felt the hardship of being remote from your team 9 hours away. And so it kind of freed a bit of time for me to start the exploration before. Sorry, Patrick. Sorry, John. Hopefully they're listening.

Joining OpenAI from Paris and from, obviously you had worked with Greg, but not anyone else.

No. Yeah. So I had worked with Greg, but not Ilya. But I had started chatting with Ilya and Ilya was kind of excited because he knew that I was a good engineer through Greg, I presume. But I was not a trained researcher, didn't do a PhD, never did research. And we started chatting and he was excited all the way to the point where he was like, "Come pass interviews, it's going to be fun." I think he didn't care where I was. He just wanted to try working together. So I go to SF, go through the interview process, get an offer. And so I get Bob McGrew on the phone for the first time. He's like, hey Stanislas Polu, you've got an offer. When are you coming to SF? I'm like, hey, it's awesome. I'm not coming to SF. I'm based in Paris and we just moved. He was like, hey, it's awesome. Well, you don't have an offer anymore.

Oh my gosh.

No, it wasn't as harsh as that, but that's basically the idea. And it took me like maybe a couple more time to keep chatting and they eventually decided to try a contractor setup and that's how I started working at OpenAI officially as a contractor, but in practice really felt like being an employee.

What did you work on?

I was solely focused on math and AI, and in particular in the application, the study of the large language models, mathematical reasoning capabilities, and in particular in the context of formal mathematics. The motivation was simple. Transformers are very creative, but yet they do mistakes. Formal math systems have the ability to verify a proof, and the tactics that you can use to solve problems are very mechanical, so you miss the creativity. And so the idea was to try to explore both together. You would get the creativity of the LLMs and the verification capabilities of the formal system. A formal system, just to give you a little bit of context, is a system in which a proof is a program, and the formal system is a type system. A type system that is so evolved that you can verify the program. If the type checks, it means that the program is correct.

Is the verification much faster than actually executing program? It is, right?

Verification is instantaneous, basically.

Yeah.

So the truth is that what you code in involves tactics that may involve computation to search for solutions. So it's not instantaneous. You do have to do the computation to expand the tactics into the actual proof. The verification of the proof at the very low level is instantaneous.

How quickly do you run into halting problem, PNP type things, impossibilities where you're just like, "Nah." I mean, you don't run into it at the time.

It was really trying to solve very easy problems. So I think the—

Can you give an example of easy?

Yeah. So that's the MATH benchmark that everybody knows today.

The Dan Hendricks one.

Dan Hendricks one. Yeah. And I think it was the low-end part of the MATH benchmark at the time because that MATH benchmark includes AMC. AMC problems, AMC 8, AMC 10, 12. So these are the easy ones. Then AIME problems, somewhat harder, and some IMO problems like Fraser.

For listeners, we covered this in our Benchmarks 101 episode. AMC is literally the grade of like high school, grade 8, grade 10, grade 12.

Exactly.

So you can solve this. Just briefly to mention this, because I don't think we'll touch on this again. There's a bit of work with like Lean and then with, you know, more recently with DeepMind scoring silver on the IMO. Any commentary on how math has evolved from your early work to today?

I mean, that result is mind-blowing. I mean, from my perspective, spent 3 years on that. At the same time, Guillaume Lampre in Paris, we were both in Paris actually, he was at FAIR, was working on the same problems. We were pushing the boundaries and the goal was the IMO. And we cracked a few problems here and there, but The idea of getting a medal at an IMO was just remote. So this is an impressive result. And I think the DeepMind team just did a good job of scaling. I think there's nothing too magical in their approach, even if it hasn't been published. There's a Dan Silver talk from 7 days ago where it goes a little bit into more details. It feels like there's nothing magical there. It's really applying reinforcement learning and scaling up the amount of data they can generate through auto-formalization. We can dig into what auto-formalization means if you want.

Let's talk about the tail end maybe of the OpenAI. You join and you're like, I'm going to work on math and do all of these things. I saw in one of your blog posts you mentioned you fine-tuned over 10,000 models at OpenAI using 10 million A100 hours. How did the research evolve from GPT-2 and then getting closer to DaVinci 003? And then you left just before ChatGPT was released. Tell people a bit more about the research path that took you there.

I can give you my perspective of it. I think at OpenAI there's always been a large chunk of the compute that was reserved to training the GPTs, which makes sense. So it was pre-Entropic split. Most of the compute was going to a project called Nest, which was basically GPT-3. And then you had a bunch of, let's say, remote, not core research teams that were trying to explore maybe more specific problems or maybe the algorithm part of it. The interesting part, I don't know if it was where your question was going, is that in those labs you're managing researchers. So by definition, you shouldn't be managing them. But in that space, there's a managing tool that is great, which is computer allocation. Basically, by managing the computer allocation, you can message the team of where you think the priority should go. And so it was really a question of you were free as a researcher to work on whatever you wanted. But if it was not aligned with OpenAI mission, and that's fair, you wouldn't get the compute allocation. As it happens, solving math was very much aligned with the compute, with the direction of OpenAI. And so I was lucky to generally get the compute I needed to make good progress.

What do you need to show as incremental results to get funded for further results?

It's an imperfect process. If you're working on math and AI, obviously there's kind of a prior that it's going to be aligned with the company. So it's much easier than to go into something much riskier, I guess. You have to show incremental progress, I guess. It's like you ask for a certain amount of compute and you deliver a few weeks after and you demonstrate that you have progress. Progress might be a positive result, progress might be a strong negative result. And a strong negative result is actually often much harder to get or much more interesting than a positive result. And then it generally goes into, as any organization, you would have people finding your project or any other project, cool and fancy. And so you would have that kind of phase of growing up compute allocation for it all the way to a point. And then maybe you reach an apex and then maybe you go back mostly to zero and restart the process because you're going in a different direction or something else. That's how I felt.

Explore, exploit.

Yeah, exactly. Exactly. Exactly. It's a reinforcement learning approach.

PhD student search process.

And you were reporting to Ilya, like the results you were kind of bringing back to him or like what's the structure? It's almost like when you're doing such cutting edge Research, you need to report to somebody who's actually really smart to understand if the direction is right.

So we had a reasoning team which was working on reasoning obviously, and some math in general. And that team had a manager, but Ilya was extremely involved in the team as an advisor, I guess. Since he brought me in OpenAI, I was lucky to mostly during the first years to have a direct access to him. He would really coach me as a trainee researcher, I guess, with good engineering skills. And Ilya, I think at OpenAI, he was the one showing the north star, right? It was his job and I think he really enjoyed that and he did it super well, was going through the teams and saying, this is where we should be going and trying to flock the different teams together towards an objective.

I would say the public perception of him is that he was the strongest believer in scaling.

Oh yeah.

He always pursued the compression thesis. You have worked with him personally. What does the public not know about how he works?

I think he's really focused on building the vision and communicating the vision within the company, which was extremely useful. I was personally surprised that he spent so much time working on communicating that vision and getting the teams to work together versus—

To be specific, vision is AGI?

Oh yeah, the vision is like, yeah, it's the belief in compression and scaling compute. I remember when I started working on the reasoning team, the excitement was really about scaling the computer on reasoning. And that was really the belief we wanted to ingrain in the team. And that's what has been useful to the team. And with the DeepMind results shows that it was the right approach with the success of GPT-4 and stuff shows that it was the right approach.

Was it according to the neural scaling laws, the Kaplan paper that was published?

I think it was before that because those ones, came with GPT-3, basically at the time of GPT-3 being released or being ready internally. But before that, there really was a strong belief in scale. I think it was just the belief that the transformer was a generic enough architecture that you could learn anything and that it was just a question of scaling.

Any other fun stories you want to tell?

Sam Altman, Greg, any?

Weirdly, I didn't work that much with Greg when I was at OpenAI. He had always been mostly focused on training the GPTs and rightfully Absolutely. So one thing about Sam Altman, he really impressed me because when I joined, he had joined not that long ago and it felt like he was kind of a very high-level CEO. And I was mind-blown by how deep he was able to go into the subjects within a year or something, all the way to a situation where when I was having lunch by year 2, I was at OpenAI with him. Just quite know deeply what it was doing and what was the point.

With no ML background, like, let's, you know.

Yeah, with no ML background, but I didn't have any either, so I guess that explains why. But I think you can, it's a question about really, you don't necessarily need to understand the very technicalities of how things are done, but you need to understand what's the goal and what's being done and what are the recent results and all of that in you and we could have kind of a very productive discussion. Discussion. And that really impressed me given this size at the time of OpenAI, which was not negligible.

Yeah.

I mean, you were a founder before. You're a founder now and you've seen Sam as a founder. How's he affected you as a founder?

I think having that capability of changing the scale of your attention in the company, because most of the time you operate at a very high level, but being able to go deep down and being in the known of what's happening on the ground is something that I feel is really enlightening. That's not a place in which I ever was as a founder because first company, we went all the way to 10 people. Current company, there's 25 of us. So the high level, the sky and the ground are pretty much at the same place.

You're being too humble. I mean, Stripe was also like a huge rocket ship.

Stripe, I wasn't a founder. So I was like at OpenAI, I was really happy being on the ground, pushing the machine, making it work.

Last OpenAI question. The Anthropic split you mentioned, you were around for that, very dramatic. David also left around that time. You left. This year we've also had a similar management shakeup, let's just call it. Can you compare what it was like going through that split during that time? And then does that have any similarities now? Are we going to see a new Anthropic emerge from these folks that just left?

That I really, really don't know. At the time, the split was pretty surprising because They had been training GPT-3. It was a success. And to be completely transparent, I wasn't in the weeds of the splits. What I understood of it is that there was a disagreement of the commercialization of that technology. I think the focal point of that disagreement was the fact that we started working on the API and wanted to make those models available through an API. Is that really the core disagreement? That I don't know.

Was it safety? Was it commercialization? Or did they just want to start a company?

Exactly. That I don't know. But I think what I was surprised of is how quickly OpenAI recovered at the time. And I think it's just because we were mostly a research org and the mission was so clear that some divergence in some teams, some people leave, the mission is still there. We have the compute, we have a shot at it. So let's just keep going.

Yeah, very deep bench. Like just a lot of talent. Yeah.

So that was the OpenAI part of the history. Exactly. So then you leave OpenAI in September 2022. And I would say in Silicon Valley, the two hottest companies at the time were you and LangChain. What was that start like and why did you decide to start with a more developer-focused kind of like an AI engineer tool rather than going back into doing some more research on something else?

Yeah, first, I'm not a trained researcher, so going through OpenAI was really kind of the PhD I always wanted to do. But research is hard. You're digging into a field all day long for weeks and weeks and weeks and you find something. You get super excited for 12 seconds and at the 13 seconds you're like, oh yeah, that was a blip. And you go back to digging. I'm not a trained, like formally trained researcher and it wasn't kind of necessarily an ambition of me of creating, of having a research career. And I felt the hardness of it. I enjoyed a lot of like that a ton. But at the time I decided that I wanted to go back to something more productive. And the other fun motivation was like, I mean, if we believe in AGI and if we believe the timelines might not be too long, it's actually the last train leaving the station to start a company. After that, it's going to be computers all the way down. And so that was kind of the true motivation for trying to go there. So that's kind of the core motivation at the beginning personally. And the motivation for starting a company was pretty simple. I had seen GPT-4 internally at the time. It was September 2022, so it was pre-ChatGPT, but GPT-4 was ready since, I mean, it had been ready for a few months internally. I was like, okay, that's obvious. The capabilities are there to create an insane amount of value to the world. And yet the deployment is not there yet. The revenues of OpenAI at the time were ridiculously small compared to what it is today. And so the thesis was there's probably a lot to be done at the product level to unlock the usage.

Yep. Let's talk a bit more about the form factor maybe. I think one of the first successes you had was kind of like the WebGPT-like thing, using the models to traverse the web and summarize things, and the browser was really the interface. Why did you start with the browser? Was it important? And then you built XP1, which was kind of like the browser extension.

So the starting point at the time was, if you wanted to talk about LLMs, it was still a rather small community. A committee of mostly researchers and to some extent very early adopters, very early engineers. It was almost inconceivable to just build a product and go sell it to the enterprise, though at the time there was a few companies doing that. The one on marketing, I don't remember its name. Jasper. But so the natural first intention and the first, first, first intention was to go to the developers and try to create tooling for them to create product on top of those models. And so that's what DUST was originally. It was quite different than LangChain, and LangChain just beat the shit out of us, which is great.

It's a choice. You were cloud in closed source, they were open source.

Yeah. So technically we were open source and we still are open source, but I think that doesn't really matter. I had the strong belief from my research time that you cannot create an LM-based workflow on just one example. Basically, if you just have one example, you overfit. So as you develop your interaction, your orchestration around the LLM, you need a dozen examples. Obviously, if you're running a dozen examples on a multi-step workflow, you start parallelizing stuff. And if you do that in the console, you just have a messy stream of tokens going out and it's very hard to observe what's going there. And so the idea was to go with a new UI so that you could introspect easily the output of each interaction with the model and dig into there through UI, which is—

was that open source? I actually didn't—

oh yeah, it was. I mean, Dust is entirely open source even today. We're not going for no—

if it matters, I didn't know that.

Yeah, I know, I know. The reason why is because we're not open source because we're not doing an open source strategy.

Yeah.

It's not an open source go-to-market at all. We open source because we can and it's fun.

Open source is marketing. You have all the downsides of open source, which is like people can clone you.

But I think that downside is a big fallacy.

Okay.

Yes, anybody can clone Dust today, but the value of Dust is not the current state. The value of Dust is number of eyeballs and hands of developers that are creating to it in the future. And so yes, anybody can clone us today, but that wouldn't change anything. There is some value in being open source. In discussion with the security team, you can be extremely transparent and just show the code. When you have discussion with users and there's a bug or a feature missing, you can just point to the issue, show the pull request, show the— exactly. Oh, PR welcome. That doesn't happen that much. But you can show the progress. If the person that you're chatting with is a little bit technical, they really enjoy seeing the pull request advancing and seeing all the way to deploy. And then the downsides are mostly around security. You never want to do security by obfuscation. But the truth is that your vector of attack is facilitated by you being open source. But at the same time, it's a good thing because if you're doing anything like bug bountying or stuff like that, you just give much more tools to the bug bountiers so that their output is much better. So there's many, many, many trade-offs. I don't believe in the value of the codebase per se. I think it's really the people that are on the codebase that have the value and the go-to-market and the product and all of those things that are around the codebase. Obviously, that's not true for every codebase. If you're working on a very secret kernel to accelerate the inference of LLMs, I would buy that you don't want to be open source. But for product stuff, I really think there's very little risk.

I signed up for XP1, I was looking January 2023. I think at the time you were on DaVinci 003. Given that you were seeing GPT-4, how did you feel having to push a product out that was using this model that was so inferior and you're like, please just use it today, I promise it's going to get better. It's like just overall as a founder, how do you build something that maybe doesn't quite work with the model today, but you're just expecting the new model to be better?

Yeah, so actually XPay-1 was even on a smaller one. That was the post-ChatGPT release small version. So it was—

Ada, Babette.

No, no, no, not that far away, but it was the small version of ChatGPT, basically. I don't remember its name. Yes, you have a frustration there, but at the same time, I think XPay-1 was designed, was an experiment, but was designed as a way to be useful at the current capability of the model. If you just want to extract data from a LinkedIn page, that model was just fine. If you want to summarize an article on a newspaper, that model was just fine. And so it was really a question of trying to find a product that works with the current capability, knowing that you will always have tailwinds as models get better and faster and cheaper. So there's a little bit of a frustration because you know what's out there and you know that you don't have access to it yet, but it's also interesting to try to find the product that works with the current capability.

And we highlighted XP1 in our Anatomy of Autonomy post in April of last year, which was where are all the agents, right? So now we spent 30 minutes getting to what you're building now. So you basically had a developer framework, then you had a browser extension, then you had all these things, and then you kind of got to where Dust is today. So maybe just give people an overview of what Dust is today and the core thesis behind it.

Yeah, of course. So Dust really want, we really want to build the infrastructure so that companies can deploy agents within their teams. We are horizontal by nature because we strongly believe in the emergence of use cases from the people having access to creating an agent that don't need to be developers. They have to be tinkerers, they have to be curious, but they can, anybody can create an agent that will solve an operational thing that they're doing in their day-to-day job. And to make those agents useful, there's two focus, which is interesting. The first one is an infrastructure focus. You have to build the pipes so that the agent has access to the data. You have to build the pipes such that the agents can take action, can access the the web, etc. So that's really an infrastructure play. Maintaining connections to Notion, Slack, GitHub, all of them is a lot of work. It is boring work, boring infrastructure work, but that's something that we know is extremely valuable in the same way that Stripe is extremely valuable because it maintains the pipes. And we have that dual focus because we're also building the product for people to use it. And there it's fascinating because Everything started from the conversational interface, obviously, which is a great starting point, but we're only scratching the surface, right? I think we are at the Pong level of LLM productization, and we haven't invented the Civ III, we haven't invented Counter-Strike, we haven't invented Cyberpunk 2077. So this is really our mission, is to really create the product that lets people equip themselves to Just get away all the work that can be automated or assisted by LLMs.

And can you just comment on different takes that people had? So maybe the most open is like AutoGPT. It's just trying to do anything. It's all magic. There's no way for you to do anything. Then you had the Adept. We had David on the podcast. They're very super hands-on with each individual customer to build super tailor. How do you decide where to draw the line between this is magic, this is exposed to you, especially in a market where Most people don't know how to build with AI at all. So if you expect them to do the thing, they're probably not going to do it.

Yeah, exactly. So the AutoGPT approach obviously is extremely exciting, but we know that the agent capability of models are not quite there yet. It just gets lost. So we're starting where it works. Same with Experiment. And where it works is pretty simple. It's like simple workflows that involve a couple tools. Where you don't even need to have the model decide which tools it uses in the sense of you just want people to put it in the instructions. It's like, take that page, do that search, pick up that document, do the work that I want in the format I want, and give me the results. There's no smartness there, right? In terms of orchestrating the tools, it's mostly using English for people to program a workflow where you don't have the constraint of having compatible API between the two.

That kind of personal automation, would you say it's kind of like an LLM Zapier type of thing? Like if this, then that, and then do this, then this. So very, you're programming with English?

So you're programming with English. So you're just saying, oh, do this and then that. You can even create some form of APIs. You say, when I give you the command X, do this. When I give you the command Y, do this. And you describe the workflow, but you don't have to create boxes and create the workflow explicitly. It just needs to describe what are the tasks supposed to be and make the tool available to the agent. Tool can be semantic search, the tool can be querying into a structured database, the tool can be searching on the web. And obviously the interesting tools that we only starting to scratch are actually creating external actions like reimbursing something on Stripe, sending an email, clicking on a button in the admin or something like that.

Do you maintain all these integrations?

Today we maintain most of the integrations. We do always have an escape hatch for people to custom integration spec. But the reality is that the reality of the market today is that people just want it to work, right? And so it's mostly us maintaining the integration. As an example, a very good source of information that is tricky to productize is Salesforce, because Salesforce is basically a database and a UI, and they do the fuck they want with it. And so every company has different models and stuff like that. So right now we haven't we don't support it natively. And the type of support, of real native support, will be slightly more complex than just OAuthing into it, like is the case with Slack as an example, because it's probably gonna be, oh, you want to connect your Salesforce to us? Give us the SOQL, that's the Salesforce QL language. Give us the queries you want us to run on it and inject in the context of Dust. So that's the interesting whole, not all integrations are equal, and some of them require a little bit of work on the user, And for some of them that are really valuable to our users, but we don't support yet, they can just build them internally and push the data to us.

I think I understand the Salesforce thing, but let me just clarify it. Are you using browser automation because there's no API for something?

No, no, no, no, no. In that case, so we do have browser automation for all the use cases that imply the public web. But for most of the integration with the internal system of the company, it really runs through API.

Haven't you felt the pull to RPA, browser automation, that kind of stuff?

I mean, what I've been saying for a long time, maybe I'm wrong, is that if the future is that you're going to stand in front of your computer and looking at an agent clicking on stuff, then I'll eat my computer. And my computer is a big Lenovo. It's black. It doesn't sound good at all compared to a Mac. I mean, if the APIs are there, we should use them. There's always going to be a long tail of stuff that don't have APIs, but as the world is moving forward, that's disappearing. So the core API value, the in the past as really being, oh, this old '90s product doesn't have an API, so I need to use the UI to automate. I think for most of the ICP companies, the companies that ICP for us, the scale-ups that are between 500 and 5,000 people, tech companies, most of the SaaS they use have APIs. Note as an interesting question for the open web, because there are stuff that you want to do that involve websites that don't necessarily have APIs. And the current state of web integration from, which is us and OpenAI and Anthropic, I don't even know if they have web navigation, but I don't think so. The current state of affair is really, really broken because you have what? You have basically search and headless browsing. But headless browsing, I think everybody's doing basically body.innerText and fill that into the model, right?

There's parsers into Markdown and stuff.

We're super excited by the companies that are exploring the capability of rendering a web page into a way that is compatible for a model, being able to maintain these selectors. So that's basically the place where to click in the page through that process, expose the actions to the model, have the model select an action in a way that is compatible with models, which is not a big page of a full DOM that is very noisy. And then being able to decompress that back to the original page and take the action. And that's something that is really exciting and that will kind of change the level of things that agents can do on the web. That I feel exciting, but I also feel that the bulk of the useful stuff that you can do within the company can be done through API. The data can be retrieved by API, the actions can be taken through API.

For listeners, I'll note that you are basically completely disagreeing with David Wang.

Exactly.

Exactly. And Adept is where it is and Dust is where it is. So Dust is still standing.

Can we just quickly comment on function calling? You mentioned you don't need the models to be that smart to actually pick the tools. Have you seen the models not be good enough or is it just like you just don't want to put the complexity in there? Is there any room for improvement left in function calling or do you feel usually consistently get always the right response, the right parameters and all that?

So that's the tricky product question because if the instructions are good and precise, then you don't have any issue because it's scripted for you and the model just look at the scripts and just follow and say, "Oh, he's probably talking about that action and I'm going to use it and the parameters are kind of abused from the state of the conversation. I'll just go with it." If you provide a very high level, kind of an AutoGPT-esque level in the instructions and provide 16 different tools to your model, yes, we're seeing the models in that state making mistakes. And there is obviously some progress can be made on the capabilities. But the interesting part is that there is already so much work that can assist, augment, accelerate by just going with pretty simply screw-to-four actions agents. What I'm excited about by starting in pushing our users to create rather simple agents is that once you have those working really well, you can create meta agents that use the agents as actions. And all of a sudden you can have a hierarchy of responsibility that will probably get you almost to the point of the AutoGPT value. It required the construction of intermediary artifacts, but you're probably going to be able to achieve something great. I'll give you some examples. We have our incidents are shared in Slack in a specific channel, all shipped are shared in Slack. We have a weekly meeting where we have a table about incidents and shipped stuff. We're not writing that weekly meeting table anymore. We have an assistant that just go find the right data on Slack and create the table for us. And that assistant works perfectly. It's trivially simple, right? Take one week of data from that channel and just create the table. And then we have in that weekly meeting, some, obviously some graphs and reporting about our financials and our progress and our ARR. And we've created assistants to generate those graphs directly. And those assistants work great. By creating those assistants that cover those small parts of that weekly meeting, slowly we're getting to a world where we'll have a weekly meeting assistant. We'll just call it. You don't need to prompt it. You don't need to say anything. It's going to run those different assistants and get that Notion page just ready. And by doing that, if you get there, and that's an objective for us to, us using Dust, get there, you're saving an hour of company time every time you run it.

That's my pet topic of NPM for agents. It's like, how do you build dependency graphs of agents and how do you share them? Because why do I have to rebuild some of the smaller levels of what you built already?

I have a quick follow-up question on agents managing other agents. It's a topic of a lot of research, both from Microsoft and even in startups. What you've discovered, best practice for let's say like a manager agent controlling a bunch of small agents, it's two-way communication. I don't know if there should be a protocol format.

To be completely honest, the state we are at right now is creating the simple agents. So we haven't even explored yet the meta agents. We know it's there, we know it's going to be valuable, we know it's going to be awesome, but we're starting there because it's the simplest place to start. And it's also what the market understands. If you go to a company, random SaaS B2B company, not necessarily specialized in AI, and you take an operational team and you tell them, build some tooling for yourself, they'll understand the small agents. If you tell them build AutoGPT, they'll be like, auto what?

And I noticed that in your language, you're very much focused on non-technical users. You don't really mention API here. You mention instruction instead of system prompt. That's very conscious.

Yeah, it's very conscious. It's a mark of our designer Ed, who kind of pushed us to create a friendly product. I was knee-deep into AI when I started, obviously. And my co-founder Gabriel was at Stripe as well. We started a company Glazer that got acquired by Stripe 15 years ago, was at Alan, a healthcare company in Paris after that. It was a little bit less knee-deep in AI, but really focused on product. And I didn't realize how important it is to make that technology not scary. To end users. It didn't feel scary to me, but it was really seen by Ed, our designer, that it was feeling scary to the users. And so we were very proactive and very deliberate about creating a brand that feels not too scary and creating a wording and a language, as you say, that really tried to communicate the fact that it's gonna be fine, it's gonna be easy, you're gonna make it.

And another big point that David had about Adapt is like, we need to build an environment for the agents to act. And then if you have the environment, you can simulate what they do. How's that different when you're interacting with APIs and you're kind of touching systems that you cannot really simulate? If you call the Salesforce API, you're just calling it.

Yep. So I think that goes back to the DNA of the companies that are very different. ADEPT, I think, was a product company with a very strong research DNA, and they were still doing research. One of their goals was building a model. And that's why they raised a large amount of money, etc. We are 100% deliberately product company. We don't do research, we don't train models, we don't even run GPUs. We're using the models that exist and we try to push the product boundary as far as possible with the existing models. So that creates an issue indeed. So to answer your question, when you're interacting in the real world, well, you cannot simulate, so you cannot improve the models, even improving your instructions. Is complicated for a builder. The hope is that you can use models to evaluate the conversations so that you can get at least feedback and you could get quantitative information about the performance of the assistants. But if you take actual trace of interaction of humans with those agents, it is even for us humans extremely hard to decide whether it was a productive interaction or really bad interaction. You don't know why the person left. You don't know if they left happy or not. Being extremely pragmatic here, it becomes a product issue. We have to build a product that incentivizes the end users to provide feedback so that as a first step, the person that is building the agent can iterate on it. As a second step, maybe later when we start training models and post-training them, et cetera, we can optimize around that for each of those companies.

Do you see in the future products offering simulation environments the same way all SaaS now offers APIs to build programmatically. In cybersecurity, there are a lot of companies working on building simulative environments so that then you can use agents to red team, but I haven't really seen that.

Me neither. That's a super interesting question. I think it's really going to depend on how much— because you need to simulate to generate data, you need to generate data to train models. And the question at the end is, are we going to be training models or are we just going to be using frontier models as they are? On that question, I don't have a strong opinion. It might be the case that we'll be training models because in all of those AI-first products, the model is so close to the product surface that as you get big and you want to really own your product, you're going to have to own the model as well. Owning the model doesn't mean doing the pre-training, that would be crazy. But at least having an internal post-training realignment loop makes a lot of sense. And so if we see many companies going towards that over time, then there might be incentives for the SaaSes of the world to provide assistance in getting there. But at the same time, there's a tension because those SaaS, they don't want to be interacted by agents. They want the human to click on the button.

They got to sell seats.

Yeah, exactly.

Just a quick question on models. I'm sure you've used many. OpenAI, probably not just OpenAI. Would you characterize some models as better than others? Do you use any open source models? What have been the trends in models over the last 2 years?

We've seen over the past 2 years kind of a bit of a race in between models. And at times it's the OpenAI model that is the best. At times it's the Anthropic models that is the best. Our take on that is that we are agnostic and we let our users pick their model.

Oh, they choose? Yeah.

So when you create an assistant or an agent, you can just say, oh, I'm going to run it on GPT-4 or GPT-4 Turbo.

Don't you think for the non-technical user, that is actually an abstraction that you should take away from them?

We have a sane default. So we move the default to the latest model that is cool and we have a sane default and it's actually not very visible in our flow to create an agent. You would have to go in advanced and go pick your model. So this is something that the technical person will care about, but that's something that obviously is a bit too complicated for the And do you care most about function calling or instruction following or something else? I think we care most for function calling because there's nothing worse than a function call including incorrect parameters or being a bit off because it just drives the whole interaction off.

So got the Berkeley function calling leaderboard.

These days, it's funny how the comparison between GPT-4o and GPT-4 Turbo is still up in the air on function calling. I personally don't have proof, but I know many people and I'm probably part of them to think that GPT-4 Turbo is still better than GPT-4 on function calling.

Wow.

We'll see what comes out of the O-1 class if it ever gets function calling. Claude's 3.5 Sonnet is great as well. They innovated in an interesting way, which was never quite publicized, but it's that they have that chain of thoughts step whenever you use a Claude model or Sonnet model with function calling. That chain of thought step doesn't exist when you just interact with it just for answering questions. But when you use function calling, you get that step and it really helps getting better function calling.

We actually just recorded a podcast with the Berkeley team that runs that leaderboard this week. They just released v3. It was v1 2 months ago, then v2, v3. Turbo is on top.

Turbo is on top.

Turbo is over 4.0. And then the third place is XLAMM from Salesforce, which is a large action model they've been trying to popularize. O1 Mini is actually on here, I think. O1 Mini is number 11.

But arguably O1 Mini has a better line for that.

Do you use leaderboards? Do you have your own evals? I mean, this is counterintuitive, right? Like using the older model is better. I think most people just upgrade. Yeah. What's the eval process like?

It's funny because I've been doing research for 3 years and we have bigger stuff to cook. When you're deploying in a company, The second thing where we really spike is that when we manage to activate the company, we have a crazy penetration. The highest penetration we have is 88% daily active users within the entire employee of the company. The kind of average penetration and activation we have in our current enterprise customers is something like more like 60 to 70% weekly active. So we basically have the entire company interacting with us. And when you're there, there is so many stuff that matters most than getting evals, getting the best model, because there is so many places where you can create products or do stuff that will give you the 80% with the work you do, whereas deciding if it's GPT-4 or GPT-4 Turbo or et cetera, and it'll just give you the 5% improvement. But the reality is that you want to focus on the places where you can really change the direction or change the interaction more drastically. But that's something that we'll have to do eventually because we still want to be safe.

It's funny because in some ways the model labs are competing for you. You don't have to do any effort. You just switch model and then it'll grow. What are you really limited by? Is it additional sources? It's not models, right? You're not really limited by quality of model.

Right now we are limited by, yes, the infrastructure part, which is ability to connect easily for users to all the data they need. To do the job they want to do.

Because you maintain all your own stuff. You know, there are companies out there that are starting to provide integrations as a service, right? I used to work in an integrations company.

Yeah, yeah, I know. It's just that there is some intricacies about how you chunk stuff and how you process information from one platform to the other. If you look at the end of the spectrum, you could think of, you could say, oh, I'm going to support Airbyte and Airbyte has—

I used to work at Airbyte.

Oh really? Makes sense.

The French founders.

French, yeah. I know, I know.

I know him very well. I'm seeing him today. And the reality is that if you look at Notion, Airbyte does the job of taking Notion and putting it in a structured way. But it's a way that is not really usable to actually make it available to models in a useful way. Because you get all the blocks, details, et cetera, which is useful for many use cases.

It's optimized for data scientists.

Exactly.

Not for AI.

The reality of Notion is that sometimes you have a, sometimes you have, so when you have a page, there's a lot of structure in it and you want to, you want to capture the structure and chunk the information in a way that respects that structure. In Notion, you have databases. Sometimes those databases are real tabular data. Sometimes those databases are full of text. You want to get the distinction and understand that this database should be considered like text information, where this other one is actually quantitative information. And to really get a very high quality interaction with that piece of information, I haven't found a solution that will work without us owning the connection end to end.

That's why I don't invest in these. There's Composeo, there's All Hands from Graham Newbing. There's all these other companies that are like, we will do the integrations for you. We have the open source community, we'll do off the shelf. But then you are so specific in your needs that you want to own it.

Yeah, exactly.

You can talk to Michel about that. He wants to put the AI in Airbyte.

I will, I will.

Cool.

What are we missing? What are the things that are sneakily hard that you're tackling that maybe people don't even realize they're really hard?

The real hard parts, as we kind of touched base throughout the conversation, is really building in fraud networks for those agents because it's a tenuous walk. It's an evergreen piece of work because you always have an extra integration that will be useful to a non-negligible set of your users. I'm super excited about is that there's so many interactions that shouldn't be conversational interactions. And that could be very useful. Basically, know that we have the firehose of information of those companies, and there's not going to be that many companies that capture the firehose of information. When you have the firehose of information, you can do a ton of stuff with those, with models that are just not accelerating people, but giving them superhuman capability, even with the current model capability, because you can just sift through much more information. An example is documentation repair. If I have the firehose of Slack messages and new Notion pages, If somebody says, I own that page, I want to be updated when there is a piece of information that should update that page, this is not possible. You get an email, you receive an email saying, oh, look at that Slack message. It says the opposite of what you have in that paragraph. Maybe you want to update or just ping that person. I think there is a lot to be explored on the product layer in terms of what it means to interact productively with those models. And that's a problem that is extremely hard and extremely exciting.

One thing you keep mentioning about infra work, obviously, Dust is building that infra and serving that in a very consumer-friendly way. You always talk about infra being additional sources, additional connectors. That is very important. But I'm also interested in the vertical infra. There is an orchestrator underlying all these things, right, where you're doing asynchronous work. For example, just the simplest one is a cron job. You just schedule things. But also, for If This Then That, you have to wait for something to be executed and proceed to the next task. I used to work on an orchestrator as well, Temporal, Temporal.

We use Temporal.

Oh, you use Temporal?

Yeah.

Oh, what's the experience? I need the NPS.

We're doing a self-discovery call now?

But you can also complain to me because I don't work there anymore.

No, we love Temporal. There's some edges that are a bit rough, surprisingly rough. And you would say, why is it so complicated?

It's versioning, it's always versioning.

Yeah, stuff like that. But we really love it. And we use it for exactly what you said, like managing the entire set of stuff. Stuff that needs to happen so that in semi-real time, we get all the updates from Slack or Notion or GitHub into the system. And whenever we see that piece of information goes through, maybe trigger workflows because to run agents, because they need to provide alerts to users and stuff like that. And Temporal is great. Love it.

You haven't evaluated others. You don't want to build your own. You're happy with—

Oh no, we're not in the business of replacing Temporal. And Temporal is so, I mean, it is, or any other competitive product. They're very general. If it's there, there's an interesting theory about buy versus build. I think in that case, when you're a high-growth company, your buy-build trade-off is very much on the side of buy. Because if you have the capability, you're just going to be saving time. You can focus on your core competency, et cetera. And it's funny because we're seeing, we're starting to see the post-high-growth company, post-S-curve company going back on that trade-off, interestingly. So it's the Klarna news about removing Zendesk and Salesforce.

Do you believe that, by the way?

Yeah, just heard a podcast with them.

It's true.

Yeah.

No, no, I know. Of course they say it's true, but like also how well is it going to go?

So I'm not talking about deflecting the customer traffic. I'm talking about building AI on top of Salesforce and Zendesk, basically, if I understand correctly. And all of a sudden, your product surface becomes much smaller because you're interacting with an AI system that will take some actions. And so all of a sudden, you don't need the product layer anymore. And you realize that, oh, those things are just databases that I pay 100 times the price, right? Because you're a post-S-curve company and you have tech capabilities, you are incentivized to reduce your costs and you have the capability to do so. And then it makes sense to just scratch the SaaS away. So it's interesting that we might see kind of a bad time for SaaS in post-hypergrowth tech companies. So it's still a big market, but it's not that big because if you're not a tech company, you don't have the capabilities to reduce that cost. If you're a high-growth company, always going to be buying because you go faster with that. But that's an interesting new space, new category of companies that might remove some SaaS.

Yeah, Alessio's firm has an interesting thesis on the future of SaaS in AI.

Services as software, we call it. It's basically like, well, the most extreme is like, why is there any software at all? Ideally, it's all a labor interface where you're asking somebody to do something for you, whether that's a person, an AI agent or not.

Yeah, that's interesting.

I have to ask, are you paying for Temporal Cloud or are you self-hosting?

Oh no, we're paying, we're paying.

Okay, interesting. We're paying way too much.

It's crazy expensive, but that's why— That makes sense.

As a shareholder, I like to hear that.

Makes us go faster, so we're happy to pay.

Other things in the infra stack, I just want to list for other founders to think about. Ops, API Gateway, evals, anything interesting there that you build or buy?

I mean, there's always an interesting question. We've been building a lot around the interface between models. And because the Dusk The original version was an orchestration platform and we basically provide a unified interface to every model providers.

That's what I call gateway.

That we add because Dust was that and so we continued building upon and we own it. But that's an interesting question. Wasn't you want to build that or buy it?

I would say LightLLM is the current open source consensus.

Exactly. There's an interesting question there.

Ops, Datadog, just tracking.

Oh yeah. So Datadog is an obvious What are the mistakes that I regret? I started as pure JavaScript, no TypeScript. And I think you wanna, if you're wondering, oh, I wanna go fast, I'll do a little bit of JavaScript. No, just start with TypeScript.

Life will be better.

That is really—

So interesting, you are a research engineer that came outta OpenAI that bet on TypeScript.

Well, the reality is that if you're building a product, you're gonna be doing a lot of TypeScript, right? And Next, we're using Next as an example. It's a great platform. And our internal service is actually not built in Python either, it's built in Rust.

That's another fascinating choice. The Next.js story, it's interesting because Next.js is obviously the king of the world in JavaScript land, but recently ChatGPT just rewrote from Next.js to Remix. We are going to be having them on to talk about the big rewrite. That is like the biggest news in front-end world in a while.

All right, just to wrap, in 2023, you predicted the first billion-dollar company with just one person running it. And you said that's basically like a sign of AGI once we get there. And you said it already, been started. Any 2024 updates on the take?

That quote was probably independently invented, but Sam Altman stole it from me eventually. But anyway, it's a good quote. So I hypothesize it was maybe already being started, but if it's a uni-person company, it would probably grow really fast. And so we should probably see it already. I guess we're going to have to wait for it a little bit. And I think it's because the dust of the world don't exist. And so you don't have have that thing that lets you run those, just do anything with models. But one thing that is exciting is maybe that we're going to be able to scale a team much further than before. All generations of company might be the first billion-dollar companies with engineering teams of 20 people. That would be so exciting as well. That would be so great. You don't have the management hurdle. You're just 20 focused people with a lot of assistance from machines to achieve your job. That would be great. And that I believe in a little bit more.

Yeah, I've written a post called Maximum Enterprise Utilization, kind of like you have MFE for GPUs, but it's basically like so many people are focused on, oh, it's going to displace jobs and whatnot. But I'm like, there's so much work that people don't do because they don't have the people. And maybe the question is how you just don't scale to that size to begin with. And maybe everybody will use Dust and Dust is only going to be 20 people and then people using Dust will be 2 people.

Semi-hot take is I actually know what vertical they'll be in. They'll be content creators and podcasters.

There's already two of us, so we're at max capacity.

Most people would regard Jimmy Donaldson, like MrBeast, as a billionaire, but his team is— he's got about like 200 people, so he's not a single-person company. The closer one actually is Joe Rogan, where he basically just has like a guy.

Hey, Jimmy, put it on the screen.

But Joe, I don't think— he sold his future for $250 million to Spotify. So he's not going to hit that billionaire status. The non-consensus one, it will be the Hawksworld girl who just signed up for podcast. Anyway, but like you want creators who are empowered by a bunch of agents, dust agents to do all this stuff because then ultimately it's just the brand, the curation. What is the role of the human then? What is that one person supposed to do if you have all these agents?

That's a good question. I mean, I think it was I think it was Pinterest or Dropbox founder at the time was when you're CEO, you mostly have an editorial position. You're here to say yes and no to the things you are supposed to do.

Okay, so I make a daily AI newsletter where I just, it's 99% AI generated, but I serve the role as the editor. Like I write commentary, I choose between 4 options.

You decide what goes in and goes out. And ultimately, as you said, you build your brand through those many decisions.

You should pursue creators. Yeah, that's true.

And you've made a, I think you've made a, you have an upcoming podcast with NotebookLM, which has been doing a crazy startup.

Oh yeah, yeah, that is exciting. They were just in here yesterday. I'll tell you one agent that we need. If you want to pursue the creator market, the one agent that we have and pay for is our video editor agent. So if you want, you need to wrap FFmpeg in a GPT and go nuts.

Awesome. This was great. Anything? We missed any final kind of like call to action hiring. It's like obviously people should buy the product and pay you.

And no, I think we didn't dive into the vertical versus horizontal approach to AI agents.

Quick take on that. Yeah.

We mentioned a few things. We spike at penetration and that's just awesome because we created a tool that the entire company has and use. So we create a ton of value, but it makes our go-to-market much harder. Vertical solutions have a go-to-market that is much easier because they're like, oh, I'm going to solve the lawyer stuff. But the potential within the company after that is limited. So there's really a nice tension there. We're true believers of the horizontal approach, and we'll see how that plays out. But I think it's an interesting thing to think about when, as a founder or as a technical person working with agents, what do you want to solve? Do you want to solve something general or do you want to solve something specific? And it has a lot of impact on eventually what type of company you're going to be Yeah, I'll provide you my response on that.

So I've gone the other way. I've gone products over platform. And it's basically your sense on the products drives your platform development. In other words, if you're trying to be as many things to as many people as possible, we're just trying to be one thing. We build our brand in one specific niche. And in future, if we want to choose to spin off platforms for other things, we can because we have that brand. So for example, Perplexity, we went for products in search, right? But then we also have Perplexity Labs. Webs that like, here's the infra that we use for search and whatever.

The counterargument to that is that you always have lateral movement within companies, but if you're Zendesk, you're not going to be— Zendesk Web Services.

There are a few, you know, there's success stories on both sides, but there's Amazon and Amazon Web Services.

And sorry, by platform, I don't just mean the platform as the platform platform. I mean like the product that is useful to everybody within the company. And our take on that is that there is so many operations within the company. Some of them have been extremely rationalized by the markets, like salespeople, like support has been extremely rationalized. And so you can probably create very powerful vertical product around that. But there is so many operations that make up a company that are specific to the company that you need a product to help people get assisted on those operations. And that's kind of the bet we have. Excellent.

Awesome, man. Thanks again for the time.

Thank you very much for having me. It was so much fun.

Yeah, great discussion. Thank you.