AMA with Stanislas Polu, Co-Founder of Dust: Revolutionising Tech with AI Agents

In this recorded AMA, Daniel (founder of Unicorn CTO) interviews Stanislas Polu, co‑founder of Dust, about the emerging AI agent landscape and Dust's approach to building an enterprise AI operating system. Stanislas outlines his personal background (Polytechnique, Stanford, Stripe, OpenAI) and explains Dust's three core hypotheses: focusing on the product layer rather than training models ("no GPU before PMF"), building robust data pipelines and permissioned access to company data, and enabling many specialized agents rather than a single assistant. He defines an AI agent as a program whose branching logic is driven by an LLM, distinguishing it from simple tool use. The conversation covers data connectors, security models (VPC deployments, zero‑retention agreements), the challenge of integrating sensitive data, and the need for fine‑grained permissioning. Stanislas discusses use‑case categories (customer support, sales, engineering, infrastructure remediation) and the market shift toward AI‑augmented workforces, noting a growing seriousness among midsize tech firms. He shares Dust's QA practices (Ranger.net, AI‑driven Playwright test generation) and cautions against over‑optimizing against model benchmarks, emphasizing an 80‑90% performance ceiling and the importance of principled, human‑centric evaluation. The interview also touches on organizational changes required for AI‑first product development, the impact of next‑generation chain‑of‑thought models (O1, O3, L1) as potential game‑changers, and a vision of Dust as an enterprise OS analogous to Windows, allowing SaaS providers to build apps that agents can consume. Finally, Stanislas provides contact information for further engagement.
Chapters
All right, Stan, we're recording. Granola is in the background taking notes, so all the AI are on board. Uh, let's start with just a brief introduction, uh, for this session, and then I want you to also talk about your background and what you've done. Uh, so hey everyone, my name is Daniel, I'm the founder of the Unicorn CTO. So if you don't know me, we're community of CTOs and tech leaders. I also have a day job now, which is investment banker at Avolta, where I advise companies on M&A and fundraising. And the reason I organized this event today is that I've talked with a lot of you recently, and first of all, I got a lot of feedback on organizing events where you can learn about new things. And the top topic for most of you was AI and AI agents. So I said, okay, who better than Stan to talk about AI agents? So if you can, well, tell us your background, Stan, where you come from, what you've done until now, and then also if you can present what you guys do at Dust.
Yeah, sure. Thanks. So my background, I studied at Polytechnique, then Stanford for a master's. I went to Oracle in the US for 9 months. It was pretty short but quite interesting, pretty large company. Moved back to France, started a company with Gabriel, my current co-founder. We did all the mistakes you can think of as like out-of-school entrepreneurs, pivoted gazillion times. Eventually found something that worked on Instagram Analytics. We grew it into— we addressed a nice niche of 2 million ARR, but the growth wasn't there yet. And through a succession of lucky events, we eventually got acquired by Stripe. We started Stripe from 180 employees to something like 3,000 for 5 years. And after that, I started getting interested in AI again. It was 2019, so it was the period of Atari Games and AlphaZero, so Go games, etc. And through my connection with Greg Brockman, who was the CTO at Stripe. I eventually found my way to OpenAI. At OpenAI, despite not being a trainer, I did research for 3 years on the large language models' mathematical reasoning capabilities, in particular in the context of formal math. So formal math is a programming system with a very advanced type system where theorem, a type and a proof is a program. And so if the program type checks, that means that you have a proof. So really, for models, it's a coding, um, it's a coding exercise, it's a coding, uh, it's a coding modality with perfect verification. So it gives you kind of interesting ways to explore generating data and retraining, etc. Uh, did that for 3 years. Eventually wanted to go back to more product stuff, So that's how I started working on Dust. Gabriel joined me in January 2023. We raised $5 million with Sequoia. ChatGPT went through there, and we decided to focus on LLMs and the enterprise, which is a pretty large scope, obviously. And so Dust really is a platform that has 3 main hypotheses, core hypotheses at the beginning, which are the 3 followings. Which will give you an idea of what we do. First, we focus on the product layer, so we don't train models, really try to take models off the shelf. We don't run GPUs. We even have an operating principle that is called "no GPU before PMF," and PMF is something that evolves. We'll maybe never get GPUs. We, from the get-go, we focused on getting connected with the enterprise infrastructure, which means that We build the pipes to get the company data in, to give those models access to actions to edit the company in a way. And the third one is that we wanted to build a platform where it wasn't one assistant but many assistants or agents. And basically the idea is that when you get access to all of the company context and data, that data is kind of big. So if you have specific use cases, Being able to build a specific agent, if only just to give it the right actions and give it the right context, the right piece of data that it needs for the task, gives you mechanically much better results. And so we really try to enable people to build agents, which has a nice effect that once they build, they are a nice artifact that kind of propagates within the company. And so this is what we're building. Platform, which is a sandwich on top and below models, the infrastructure to connect to the company, the product layer to interface with humans. And we really want to be, in a sense, the enterprise AI OS that people use to change the way they work. That's what we're doing and the stuff that happened before.
So thanks for that. I'll start with the first question. Oh, Bastien already won. So I'll start with the first question and then Bastien will ask his question. We were supposed to talk about AI agents.
Yeah.
Agentique workflow, agent as a service. So everything is about agents now. What's your definition of an AI agent?
I mean, to me, everybody talks about agentique and it's the year of the agents. I don't think that's really I mean, there's more of a fashion than anything else. I think the definition of an agent for me is a program in which the branching at some point is managed by a model instead of code. Anything where the branching decision in the program is driven by an LLM can be characterized as agents because it means that you're not following a strict workflow. So to give you an example, something that takes an email in English and maybe sends it back to me, that's not an agent because the LLM is used, but it's not used to decide which branching you're taking in the workflow. So an agent is more like an email comes in and you decide whether you want to translate it or maybe forward it to different services or maybe reply directly, and that is made by a model, that I think characterizes an agent. But at the end of the day, agents really are in practice, they are the use of the interface that kind of emerged on top of models, I mean as an interface to models, which is tool use. When you interact with an LLM, you can ask it a question, get an answer, or you can ask it a question with a set of tools and let it decide which tool to use. And in a sense, that's what has been the main driver of what we could call the agentic AI revolution. All right, thanks for that.
Bastien, you had a question?
Yeah, so I'm not sure how are we supposed to ask questions? We raise our hands?
Don't have a plus like that.
Okay, my question was actually more about as well.
Sorry, can you introduce yourself?
Oh yeah, sorry.
Hi, I'm Bastien, I'm the CTO at Innato. We're operating a marketplace for clinical trials, and my question was more about DUST itself than agents. To start, it looks to me that one of the keys is having access to all the data for the agents to be valuable afterwards. And so how do you intend to do that? Connectors to all the systems we already have look like a key element. Are you planning to do something like Airbyte and open sourcing connectors for people to build their own? What's your strategy here?
Yeah, it's a good question. So obviously, to connect to the infrastructure. I think you get a lot of value with 80%. I mean, you have a nice 80% here. You get a ton of value with the big rocks. And then we also have an API for whenever— I mean, in every large company we're at, some of the data is pushed by the company to us through our API. And obviously you can think of strategies like Airbyte where you let the connector being built through open source The reality is that building a native connector is actually quite a lot of work and it's pretty involved. It's not just building a wrapper on an API because it's a near real-time ingestion of data. The data, the way you structure the data really depends from a connector to another one. Sometimes some of the data should be represented in a tabular way, sometimes should be represented in a textual way, and there's a lot of finicky stuff about having a really great integration. But just zoom back for a bit. This is kind of a crucial thing about agents because we're talking about— what we believe is going to happen is the following. As you understood, like, Dust is a very horizontal platform, and being an horizontal platform is great for something. It's great because you have very efficient penetration inside the company. We had 70% weekly active employees in many of our users, which is incredible and fun and great. The pity part is the go-to-market, because when you're horizontal, you have to read the go-to-market motion is harder and more complex. But what we believe is going to happen is that you, as you said, you said for agents to be useful, they need to have access to all of the context. And I think that's that's something that the market hasn't yet realized. Basically, as the models get more and more powerful, the level of abstractions of what they're going to be able to take is going to go up. And if we take the parallel of the software engineers, if we think about a software engineer, part of the job is writing the code and need to write good code. And at this stage, models are probably better than us at writing code. But being a great software engineer is not about writing code only. It's also about knowing the design doc, knowing the Slack chatter, having context, knowing the coding rules, knowing what the company prefers, etc., etc. And so what we think is going to happen is that many of the verticalized AI products, and we can think of for the software engineer Cursor as an example, or Devin, will probably need to go out of their vertical to get access to the data that is outside of the place where they started. So they start in GitHub and they'll need to go to Notion, to Confluence, even to Salesforce to get more information on what has been said on the sales call about that feature. To imagine really an agent that would take a very big task autonomously. And so if you think about that wall, it's very interesting because we're entering a world where every vertical will build AI capabilities. The models getting better and better, the abstractions level will go up, and at some point they will all try to get the data that they don't have from the get-go. And so we're seeing that with Notion. Notion AI starts asking for Slack and GitHub, We're seeing that with Salesforce going, renaming itself almost in Agentforce and wanting to go everywhere. And we're seeing that with, and I think we're going to start seeing that in engineering stuff. Like, I bet Cusco will start digging into Slack very soon. And so it's interesting because from a CISO perspective, from a security or data management perspective, it's going to be really a challenge to manage that quadratic relationship between products. And so that's why we think there's an exciting opportunity to kind of try to build that layer that gets the company data, gets the context, implements the permissioning for agents, which is something that is brand new, and be able to be maybe that, that kind of central enterprise AIOS. But I think as CTOs and thinking about the data infrastructure of our companies, it's interesting to anticipate that move where you start having queries for many SaaS for asking for other SaaS. Sorry, it was a bit of a long answer, but I think it's a super interesting subject.
Thanks.
And so if I don't have questions, I ask questions. I have a million questions. So I don't mind if you don't have questions. I can do the call alone with Stanislas Polu.
So basically, you've been—
I know you already have customers and you've already been talking to CIOs and CTOs about rolling LLMs within their companies. What's your feedback about the current state of companies rolling out LLMs and rolling out models and training them with their data? So, do you see like a surge of companies interested, or is it more timid?
I think everybody is interested, of course. There's interest everywhere, and there is obviously as well many, many actors trying to capture that opportunity. Some are verticalized, some are more horizontal like us. I think we're entering a phase where AI was a bold discussion at every company. Big. And I think we're starting to enter a phase where many kind of midsize tech companies, which is kind of our ICP, are starting to define them themselves as AI-first for real, not for the marketing, because many have done that for marketing, of course, but no, it's really for real. And AI-first in the sense of having an AI-augmented product, obviously, but also having an AI-augmented workforce. I think we're really starting to enter that phase where companies are starting to realize that, fuck, that was not— we were not kidding there. There's really a massive amount of gains to be made as the models get better. It's funny, last year I would have told you, you can get 25% productivity across your entire employee base for sure. And today I think we it's not being like, not unrealistic to think in terms of productivity multiplier, not increase, but multipliers in many, in many sense of different jobs. So the models are, the ecosystem is moving fast, the models are moving fast, the capability of the models are moving fast, the companies are still adapting, but I think the dynamics are extremely positive. And there is no sign of, oh, this was just, this was just a phase and we'll go back to where we were and let's continue like that. It seems like the, not necessarily the excitement, but the seriousness that companies have with respect to being AI augmented in the way they operate is actually growing.
And Bastien again. And then François.
Yeah, so we are not going to leave you alone with your questions, Daniel. So indeed, we are trying to ride the AI wave too, for real, not just for marketing. One of the issues I have in my context is that we, and I guess a lot of companies have the same, is that we The data we have, some of it is like sensitive. It's not only our own internal business data, it can be customer data, it can be health data. And I see this as a challenge because some of the work we do requires access to this sensitive data. And if we want to increase our productivity using an AI agent, they need access to this data too. And I've used this as a challenge. What's your thinking here? For instance, I know OpenAI can sign zero data retention agreements. Is this a way forward, or should we think about stopping using off-the-shelf models when we deal with sensitive data? I'm curious.
I mean, I think, so if we're talking about you building stuff internally and deciding on which provider to use, I personally would trust, I personally trust fully the zero data retention that is provided by OpenAI and Anthropic. It is so directly aligned with their business interests that there is no way they're just not taking that seriously. And I think there's no way they're not enforcing it very strictly. That being said, if you're talking about using off-the-shelf models today, we are in the world where they are readily available inside your VPC, right? Most of the models are on GCP. If you want to use OpenAI, you have to create an Azure VPC, but that you can control. And so if we're talking about direct access to the APIs, I think there is a large set of possibilities that allows you to create a setup where you have the guarantees that the data never escapes your own VPC or VPC you control. If we're talking about a product like us, which is obviously useful because you don't want to rebuild everything, I think we are still in a transitory phase where you have the big ones. So we're talking about, let's say, Gemini from Google, Copilot from Microsoft. They're rolling out AI products, but they're kind of shitty for the typical reasons. They're massive. When they release a product, it's for a billion people. They can't— so they don't have kind of the freedom to create rich products. And so it's the typical startup versus incumbent situation. And I think the, the, the class of companies that are attacking that market, whether they like us, pretty horizontal, or whether they're pretty vertical like Cursor or 11x or stuff like that, I think in— are in that transition period of building themselves and grow and going up markets towards enterprise users where they will and we will be capable of doing, as an example, dedicated VPC setups. But I think we are still in that transition. To give you an example, we were a uni-region, US-based only SaaS service. As we signed big European clients recently, we moved to being a multi-region service, still SaaS-based, and there is no question that there is a set of users, and eventually we'll do it very like naturally, that will require— that we would want to sign— that would require to have a dedicated VPC. And so as the companies like us are kind of growing in that market, there will be providing solutions that I think will give you good guarantees. I think the right trade-off here, the fair trade-off, is the dedicated VPC. Meaning that we spin up a VPC, everything lives inside of that VPC, you have visibility on it, we manage it, and you have that guarantee that if you click that big red button, everything is wiped. And so from a safety and security of the data perspective, it gives you a lot of control. But I think we are still in that transition where the innovative projects are still mostly SaaS-based. The ones that are provided by very big enterprise stuff are either extremely custom, let's say Palantir coming in for $3 million and building some custom stuff for you, or maybe Gemini and Copilot. Which are not super great. And so as we move forward, you'll get a lot of solutions, that space that will emerge, I presume. But I agree, it's being a recipient of so much critical data from our users is extremely humbling and is obviously a top priority. It's like a necessary condition for our existence, being secure.
Cool. Laurent, I think, raised his hand before François. So Laurent. Laurent Lecomte?
No?
One time, two times, three times.
François, I think.
Hello, so I'm François. I'm VP of Engineering at Worldia, a tour operator. My question is about We are seeing customer software agents, like customer support software agents, and this is growing. This is a market growing fast. We are also seeing infrastructure management and remediation agents also NLM-based. So I'm thinking in the very near future, these two will actually try to communicate to each other. What's happening?
What was the second one?
The infrastructure maintenance and incident remediation. Which can open tickets to suppliers automatically when things go wrong. And so I'm thinking, so these two are obviously bridging and talking to each other. Do you have any other examples of business-to-business which is entirely replaced by agent-to-agent mediation?
Yeah, I mean, the canonical examples are the following. We focus on augmentation more than replacement. So to give an example, on customer support, we generally serve the tier 3 internal customer support to really accelerate them and help them get the data they need. But we don't do any end-user-facing product, which would be the kind of intercom theme, and so the tier 1, tier 2 customer support deflection type of products. But so the typical ones is customer support. Typical ones is sales-related functions. There is a whole set of sales functions that some products try to really completely automatize. At the current state of the company, the very easy proxy you can use for detecting what can be applied by an AI function that replaces people entirely, I think, is the typical places where companies have been outsourcing work. So companies have been outsourcing their tier 1 customer support, companies have been outsourcing to some extent some of their sales function, companies have been outsourcing some of their engineering function. Once the thing is perfectly specced— I see Bastien doing no, fuck no. I'm just saying it's good, I'm saying it's happening. But so all those, all those things where we've seen in the past outsourcing, it means that there is a clear, well-defined API and specification for doing a job. And if you have that, you can at this stage, I think it's fair to say that you can build a product to take the job with AI entirely. And the interesting bit is going to be to think about what's going to be the function or the part of the function that will maybe almost fully automatize in the future. And there, I think, to see the future, you want to look at engineering. Engineering has been historically the job that has been the most disrupted by AI as it came out. Copilot, like, for code, like, had a massive impact long before we started using any LLM inside of companies. We're starting to see a product like Devin that takes really tasks end-to-end emerging. And I think engineering is really a place where you can get a vibe of the future because it is one of the jobs that is the— so not as I made the argument for, there's a certain level where it's not self-contained anymore because you need to have the context. It's almost a product decision, etc. But it's been one of the jobs where that is the most specified inside of the company at the end of the day. And so it's interesting to look at that as a way to, to fill the future. But technically today, I'm mostly, we mostly, I mean, with tech companies, tech companies, it's sales support. Thank you very much. You're welcome. Laurent.
Yeah, can you hear me now?
Yeah.
Sorry, I had the wrong mic selected. So Laurent, CTO of Sousou. I work in health the tech. My question— the, the— I, I read a phrase a few weeks ago which I really like. Uh, it says like, uh, AI currently is having an infinite number of interns, and that's kind of like the, the way I think about it currently. So agentic AI is like having a bunch of, uh, an infinite number of, uh, interns with, uh, sharp tools. If I like, uh push the metaphor. So what kind of safety net or framework do you see as necessary to put around those interns with sharp tools before you have them in customer-facing situations or in your product, rather than, you know, being helpful inside of your internal processes?
To be honest, I think it's, uh, it's, uh, the metaphor is quite good for the current state of the technology, and so the mitigation should be aligned with that metaphor. We do let interns have some sharp tools at times, and so we have, operating with interns, been creating, uh, as a necessity, some kind of safety nets around that. Maybe the problem here is that, as you pointed, uh, we, because that here you can reproduce the interns or spin up new interns at will. It's maybe the, the sheer volume of intern type of work that might augment. I don't have, I don't have a great answer there because what we, what we really focus on at Dust and what we really, what I'm really excited about is not necessarily deflection or entire replacement, which begs a lot of questions around what you're asking, which is how do I make sure that it's not fucking up everything with my customer. We've heard on the market, as an example, if you take companies that are trying to replace SDRs. So for the context, you probably all have it, but I didn't have it up until quite recently. But an SDR is what? Is somebody does a bunch of outreach by email all the way to getting a call, and when they get a call, they just pass it to the EA. And so that's really something— somebody is doing a lot of outreach on LinkedIn, email, etc., and when they get a ping, they're not even doing the call, they're just passing it on. And we've heard from the market that pushing on the button of AI-driven SDR is actually not that great yet because you get much more leads much more quickly, but because it's a machine going through the market for you, it's burning, burning kind of field much more rapidly than a set of humans would do. And they're kind of burning future potential, meaning that they create a very large amount of low quality interactions. Out of them you'll get some leads, but you're also creating a large amount of low quality interactions. And so that kind of creates a bias for the future that might hurts the potential of your— have in the market. So you really always have to think when you turn the automation on, on whether— on what's going to be the impact over the long term. I think that's the biggest thing. As far as we're concerned, most of our usage internally, there's always kind of a human in the loop in one way or another. So things remain much more in control. The impact is nonetheless big because if I can go through 3 times more work being assisted by AI than without, the potential is huge. But we generally build products, we really focus on products where we keep, we really keep the human input. So I did a long answer to not answer your question. Okay, thanks.
Somehow you did. Kevin.
Yes, hello, I'm Kevin from Welcome to Wrangle and a happy Dusk customer, by the way. Related to your answer, do you have some recommendation regarding QA of AI agents? And besides QA, you mentioned a few AI tools you are using at Dusk, like Cursor, like Devin. Is there any other AI tool you recommend that you cannot do with this. Yeah, um, so that's it.
Uh, yeah, so in terms of QA, we're actually using Ranger.net, which is pretty neat. Uh, they take a very interesting approach. And there's also a French company which I don't remember the name, and it's a shame because we're in France, but they have very different approach. Ranger, what they do is they, they tell you, we'll do QA for you, and they, uh, they do QA for you and they do it at a price that is much lower because they can do it with the help of AI at a much lower cost. But you do have a human in the loop, and they're humans in the loop, and they give you kind of a QA, externalized QA service. They're pretty neat. The technology underneath is obviously kind of a browsing, an LM-driven browser that has both modalities, does a lot of thinking each time it interacts with the UI. And the goal is internally, they don't show you, they don't even show you that. Internally what they do, they have a prompt, they say I want to test this, this, this, and that. The agent goes, tries to do the tests, and if the agent decided at the end that it properly tested the feature, the whole interaction is transformed into a Playwright test that they start running on a periodic basis. And then when a Playwright test fails, they have an agent that goes back, look at the test, try to rerun the tests, and maybe qualify the test— the failure as transient, or maybe qualifies the failure as needing a fix. Or, and if the fix is there, maybe try to fix it itself. But so all those bricks, I think the prompt to test.io to Playwright are really interesting technology for QA. And I think there's a French company, I don't remember the name again, but hopefully we can send an email afterwards because it's always good to advertise, that actually gives you those capabilities and you can use them for yourself internally. But on QA, a ton of stuff to do around, for the web at least, around the agent queues of the web browser. Internally, we're using, uh, internally we're using, uh, we're definitely using Copilot, Cursor, and to some extent Devin. At this stage, the 500 bucks, Devin is pretty broken at this stage, uh, but it's still thing, at least for thinking about it, might, what it might look like in the future, uh, pretty interesting to try lots, um, What we're also using, we actually, what we do is Dust. I'll tell you also what we do with Dust, which we fully prioritized, but we do automatic pull request reviewing. And so that you'll be able to do with Dust, working on it. So hopefully you'll be able to do it real quick. You also have Devlo, which is kind of nice in that space. They do that as well. But automated PR review is a nice one, I think. Especially when you have context with all of your company data, because it's not about reviewing the code out of context, it's reviewing the code with access to your coding rules, reading the code with access to the code that was written related to the work that's being done. And so we get kind of a nice level of reviewing that saves reviewing times within the team, because as an engineer, you are— we kind of— if you send me a PR and I see obvious stuff that I think the AI would be able to review, I'm going to shame you into asking you what the fuck why didn't you ask the bot first? And so there's a nice incentive of having those things reviewed by a bot. At this stage we trigger it ourselves, but we might automate it obviously. But there's a nice incentive of, as an engineer, to do a pre-review of your code and saves a ton of time down the line because you have less interactions on PR reviews, stuff gets shipped faster. In terms of other engine-related tasks, The one thing we haven't prioritized yet as well, but you can create in this because, you know, you have a Dust apps that can create custom actions. That's the way we're using it internally, but we never file an issue anymore, like ever. It's like, uh, starts by a thread on Slack, uh, and we've, uh, no, uh, we can capture events. And so start on thread on Slack and at the end you do a Dust file issue on the— find the issue on Discord. And it finds it in a template we like in a way that is almost better than a human would do because it really tries to do it best. Or we're all pretty lazy, so we don't do it. So that's not miraculous, but it saves 5 minutes every year. And then in terms of coding, again, we are We have much better results interacting with an assistant that has access to the code and the rest of the company data. You interact with it in conversation, like to pair program through the conversation with it, creates diff, and actually at the end, the artifact, the conversation that you have, can be used as something that can create an actual diff on your branch. And that's kind of something that we— that's an interaction that is extremely different than Cursor, where you have that that agent embedded internally, but that lacks a lot. Extremely different than Devin, which is supposed to be fully automatic with some pings. It's more like you spitballs with the AI through conversational interface, and once you think you've covered most of the ground, you just use that as an artifact to guide the actual code generator. So that's something we're experimenting as well with. And obviously, finally, just for the rest of it, When you're on call, having access to an assistant that knows all of the runbooks is useful and actually less stressful. When you have an incident, having an assistant that can write reports is something that is helpful because writing and sending reports is not the best part of the job, especially when everything is— all the context is right there in that Slack thread. And so these are the different stuff that we use with us in massive uses of Cursor Copilot in English. Thanks.
Bastien, you had a question?
Yeah, I had a question about QA and more generally evaluation, because having an agent that uses your product to raise issues about usability, a button that doesn't work, is nice. But what I found, what I I have found tricky when we built AI use cases, agentic use cases internally, is evaluating how well the feature works in the end. Like the content of the answer. I mean, there is text. Yes. So the ranger.net will tell you, yes, there's text. Great. But actually, it can be wrong. It can be good. It can be amazing. How do you— did you equip yourself with tools to measure this when building initially and then monitoring down the line? How do you deal with this difficult evaluation of how well the feature works?
I'm going to have an extremely controversial take on this one. So brace, brace. If your use case is very precise, which is not our case at Dust, so that's a different question, but if your use case is very precise, the scientific method tells you to create an evaluation set. I think it's perfectly acceptable to use models as judge if the output of your agentic flow is not binary or cannot be checked mechanically or by programming. But maybe it's a blob of text and you have the ground truth blob of text and you can still use a model to compare the two and rate it. And so the scientific methods tell you to do that. It makes sense, but beware, because if you do only that, what's happening is that you're gonna be— so basically what's happening with those models, whatever you do, you'll get 80% of the value for free. And so from there, trying to optimize against the benchmark will get you from the 80% to the 90% with a lot of work. And as you do that, you're overfitting on the model you're using. And so what happens is that the moment you switch model— and you will switch model because you'll get a better model— the moment you switch model, the work you've done that were a +5% might become a -5% because it was too biased in the model. It wasn't, it it was just overfitting, right? And so my take on that is that you generally want to really never forget to just be principled. You do something, take an approach, you take it in a principled way. Keep in mind that those models are extremely anthropomorphic. So if you're doing it— if the principal way to do it as a human is this way, it's probably the right way. And Keeping that principledness and not overfitting too much on the model kind of maybe won't get you to the 90% and you'll be stuck at the 80% for now, but who cares? Because in 3 months there's going to be a model and it's going to push you to 85%. And so that would be my general take. I'm not against benchmarking, obviously, but I am cautious about optimizing against benchmark.
Okay, so embrace the fact that it's not going to work more than 80-90% and trust in the future of the models that will get you there without having you to do the work.
And it obviously depends on the case because some use cases you need 95 or you're dead. And you have to accept that you're going to be optimizing for a given model and you have to accept that you might have to redo the work later on. But I think for many use cases, It's more a question of doing the principal thing, getting a lot of value even if it's not perfect, and educating your users, whoever is the user of that, because you'll get better models down the line. And that doesn't seem to be any stop on that dynamic, as we've seen with O-103 and L-1. And so it's mostly about being principled, yes. Thanks.
Thomas?
Yes, hello, my name is Thomas Paré, so I'm the CPTO of Urbans. We are a SaaS last-mile delivery management platform. My question is related more to the DUST product and in particular for SaaS providers. So when we talk about integrating agents, there are a lot of things that we could offer to our customers like Carrefour or IKEA, or like, if we knew more about their other pieces of data, right, which is what you guys are doing. So how do you think about the integration of DUST or the use of DUST in this context? As a SaaS provider, right, I want to enable a higher level of automation for my customers, And but for that, I need to build an agent that knows their data, right? Other than the last mile part, which I know, right? I have this data on my side.
I mean, you're pitching exactly the kind of vision we have, which is eventually— and I think it's not going to be just us, it's going to be many different players— but eventually Ideally for you, you would talk to your customer and say, what's your AIOs? They will tell you it's DUST, or somebody else will tell you it's ServiceNow, or maybe somebody else will tell you it's Salesforce. And as a SaaS provider, you would be able to build apps inside of that enterprise OS so that your product is ready to be used by the agentique, or the agents that are already running on their company data and all on their company infrastructure. The parallel with Windows is quite interesting. When you think about Windows as an OS, what is the value of Windows? It's the user interface, multiple window management, mouse and keyboard. And you can only have one window manager, right? And so what they did is that they packaged the window manager, but the window manager alone cannot sell. And so they packaged the window manager with a bunch of very basic broad apps: Word, a clock, Excel, a notebook, whatever. And then they opened up the platform to say, hey, now I have all those people that are running my window manager, so if you want to build something that lives in a window, you can build it on Windows. And once you get into that position, it's really exciting because you create the substrate that everybody can use to build apps that can be used by users. And I think here there's an interesting parallel because you, you have all the data of the company. And as we've made the argument during the discussion, there might be not many players that will be able to have access to all the data because it's just not sustainable for a company that have 20 SaaS that have access to everything. And so you have kind of that same dynamic, you have that same dynamic of an OS that would open its gates for other products to build apps on top of it and, and, or make tools available to agents, etc. So I think, I, I hope I understood your question correctly, but that's, that's kind of the, the kind of broad vision we're seeing. And at least even if it's not us, I think that's what I see as the future, is that you're going to have that every company will be running a type of layer that maintains, that has access to the data cross-software, maintain permissions that are agent compatible, which is a broad new world because if you look at the perms in any SaaS today, they're mostly human driven and will be open for companies that need to equip people and their agents to build and create the tools or maybe the UI, etc., to get there. And I feel like in your case, that's pretty much it, right? You would want to— if they were using Google Gemini, you would want to say I can add a tool to use my product to your Gemini agents.
That makes sense.
But we're not there yet, unfortunately. Or you can do that with us, but you won't get many Carrefour and Decathlon. Thanks. Laurent and then Kevin.
Building on the previous question, so basically you said trust in the fact that the models will get better and the 80% that you get for free or almost today will get better tomorrow. In that regard, how do the chain-of-thought models, so the ChatGPT 0.1, 0.2, 0.3, the DeepSeq R1, do you see them as a game changer is maybe too strong, but like more than an incremental improvement for your specific use cases? I mean, have they, you know, do you consider them to be the natural evolution of the previous models, or do you see them as being fundamentally more capable?
So I think game changer is not an exaggeration. The question is whether what they sell is really what it is. And because we don't— we— so L1 hasn't been reproduced. The exact secret source of O1, O3 is not, is not public. We can trace back through the people that worked on it, uh, kind of what it is underneath. But the promise of O1, O3, L1 is the following: is that you can, from training one way or another— in the case of L1, it's mostly reinforcement learning without the need of data. In the case of O1, O3, it's probably a lot label data plus some reinforcement learning. But you can, from reinforcement learning, make reasoning emerge in a way where as you expand more tokens, you don't get more bullshit. You actually get better response because the model is capable to explore and backtrack and be critical about itself and eventually kind of run some self-consistency loops in its thinking to eventually converge, as we do humans, to an answer that is probably the best. That has been the absolute grail for many years. And so I cannot tell you if it's truly the case that from a research perspective we've achieved that, because however open L1 is, it's still a bit secretive. If you look at the paper, they don't disclose the dataset that they use for the RL process. OpenAI is obviously pretty secretive, etc., etc. But if we assume that's true, and from using the product, I mean, I invite everybody to use Deep Research from OpenAI. It is blowing. I mean, it's going to blow your mind. You pick something you've spent a few hours working on as a non-expert to try to explore. Let's say for us, we had somebody work on what are the best solutions to do server-side code execution in a safe environment for agents. There are many answers to that question. Somebody spends half a day, maybe more, trying to get a view of what are the best platforms. You ask the same question to Deep Research, you wait for 10 minutes, you have something that is the same quality, if not better. And the most impressive part is looking at how it navigates the page, thinks, backtracks, etc. You get that when you open the side panel and you look at— you have the kind of rather precise traces. And so if that— the product kind of seems to say that it's the true thing. And so, and if it is the true thing, it is a total game changer. I think it's a total game changer. It will change the— it will completely redefine the type of task that you'll be able to handle with that. And deep research, when you think about it, deep research is an AutoGPT that works with just one tool, which is web search. And when you think back about it, AutoGPT with one tool. So AutoGPT, I hope everybody has the context, but it was kind of an open source project from 2 years ago with the idea of doing those kind of open-ended loops of work. AutoGPT with one tool 2 years ago just didn't work. It just didn't. And now you have Deep Research, it's AutoGPT with one tool, which is web search. It brilliantly works. So I think we are really entering a new phase here. I was among the people that would that would be on the team, we're plateauing at the end of last year. And I was quite convinced we were plateauing in terms of techno. We're entering a commoditization phase. Even with the technology of last year, the potential was humongous. And so it wasn't kind of a sad position to have. It was just, okay, we've entered the phase of plateauing and now we're commoditizing. It's all about deploying the technology everywhere. But I think O1O3R1 kind of, to me, made me go from completely being unconvinced by people saying at OpenAI, ah, I think we've got all the bricks we need to build AGI at this time. And I was deeply convinced that they were just full of bullshit. And I think today I am pretty convinced they were actually probably just saying the truth. And so I think it's a big game changer. I think we have to brace for what's coming. It's gonna be fun, and the way we work will definitely change. The one thing to keep in mind as well is that we're only getting started to having companies understand, get an appreciation, and start dipping their fingers into what we could do with Laskius technology, basically. And so they are— most of companies out there, they are ages from being ready to absorb that new technology anyway. So it's going to take time, etc. And so it's going to be interesting to see how the technology permeates the society, whether it's going to take time, no time, how people will evolve. But there must be also a kind of a like speed of light. There must be a maximum speed at which you can change an organization. And I think we're going to be hitting that pretty hard because the technology potential will be super high, but the rate of change will be limited. And so there's going to be a lot of tension there. So yeah, pretty bullish on those rigs. Okay, cool.
Uh, Kevin, last question.
Perfect.
Um, so yeah, it's quite related to your last answer. Um, I was curious to have your thoughts about the evolution of tech organization to build AI products and AI agents, because in the past you got more data science data scientists on the side, engineering on the side, and they were working on a given product, but after months and years of research. Now things are going really fast. We need to evolve this organization. So I was curious to have your thoughts about what are you doing at Doers and what have you seen from other companies, how they evolved and what works according to you.
Yeah, I don't have a good answer there because I was doing research at OpenAI, so I was at Stripe before, but I think it was pre-AI world. I was doing research at OpenAI, and then Dust went from basically me to 10 engineers at this stage. So it's still extremely early, so we're being shaped in that world. And so obviously everybody is up to date on the— and try to play and try to be very experimental about the models. But at the end of the day, it feels like, I mean, I would say it feels like the SaaS transition, right? Everybody has to use, everybody has to understand and use GCP, AWS, and those kind of stuff. And so you had to rethink it. It was just a new skill and a new thing, a new tool that you would use on a day-to-day basis. And I think it feels kind of the same. You might have very different views on the future of SaaS. There are some people, the SaaS doomers, that are saying agents will eat SaaS forever and there will not be— and kind of resonates to what Thomas was saying about serving customers through agents basically. But you could think those agents will eat SaaS. You could think that SaaS will still remain but will be AI-driven for it, obviously, because why wouldn't I as a user? I would want to have the AI everywhere in all SaaSes I use. And so it really feels like just a new technological substrate that every engineer needs to be aware of. Feels like, I mean, I don't know many SaaS companies that are defining themselves as AI companies at this stage, which is fair, normal, and perfectly understandable. And so the consequence is that everyone must be using AI all day, every day to to get a feel of what you can do with it and what you can do on top of it. So my only advice, and it's not an expert advice because I've done that transition through very different teams than yours, is really to make sure that everybody uses AI every day for everything and for as much stuff as possible.
So making sure that everybody becomes an AI engineer.
Yeah, exactly. But it's not an AI engineer, it's just when you use GCP, you're not you're not an infrastructure network expert, right? You're using the end product and it's easy to use, but you have to know how to use it. And I think it's the same here. The end product is actually very easy to use. The API is trivially simple. It's just you have to have the— you have to understand how it works a bit and you have to create a mental model and intuition of what it can do and cannot. And that is moving fast. Obviously, as we just said. But I think the only thing to do is to just use, use, use. Should be, should all— I mean, to me, it should almost be something that you track as a metric and should be very weird for somebody to not use AI as an engineer, for an engineer to not use AI in any way today. That feels like a professional fault almost. But I think you don't even need to enforce that because we're seeing the gains, we're seeing the dynamics. And so if they're not doing it, they'll just be left behind to some extent and they'll probably flee it on their own. Thanks.
Cool. Thank you very much. It's 1 PM, so I want us to stay on time. Thank you very much, Stan, for that. That was super interesting. We still have a lot of questions. Last one for you. How can people contact you?
Yeah, so the best is— so because we're hiring, I'm starting to be good on LinkedIn. I was really, really bad for many years, but I want to invite you to contact me on LinkedIn nonetheless. Email is best: spolu@dust.tt. So my name is Stanislas Polu, so it's spolu@dust.tt. If you look me up, that email is probably everywhere on the net, so you find it. And over email, I'm trying Exactly, I'm trying to, I'll be responsive and I would be glad to interact and answer questions or anything.
All right, thank you very much everyone, have a great lunch and see you soon for another.
Thank you for the great questions, have a nice day. Thanks, bye. Thank you, bye.
More from Stanislas

Getting the Most From AI With Multiple Custom Agents ft Dust’s Gabriel Hubert and Stanislas Polu

Getting the Most From AI With Multiple Custom Agents ft Dust’s Gabriel Hubert and Stanislas Polu

dotAI 2024 - Stanislas Polu - LLMs reasoning and agentic capabilities over time

No GPU Before PMF // Stanislas Polu // AI in Production Conference Lightning Talk

[EXTRAIT] Décryptage du fonctionnement d’un LLM en 5min - par Stanislas Polu, CEO de Dust

Qdrant x Dust: How Vector Search helps make work work better - Stan Polu | Vector Space Talk #010




