The Agent Network — Dharmesh Shah, Agent.ai + CTO of HubSpot

Hey everyone, welcome back to the Latent Space podcast. This is Alessio, partner and CTO at Dazzle Partners, and I’m joined by my co-host, swyx, founder of Small AI.

Hello, and today we’re super excited to have Dharmesh Shah join us. I guess your relevant title here is founder of agent.ai.

Yeah, that’s true for this. Creator of agent.ai and co-founder of HubSpot.

Co-founder of HubSpot, which I’ve followed for many years. I think 18 years now.

Yeah, it’s going to be 19 soon.

People can catch up on your HubSpot story elsewhere. I should also thank Shaan Puri, who I’ve chatted with back and forth and who’s been getting me in touch with your people, but also giving us a lot of context, because obviously My First Million joined you guys. They’ve been chatting with you guys a lot.

For the business side, we can talk about that, but I wanted to engage your CTO and agent-engineer side of things. How did you get into agents?

Let’s see. I’ve been working on this—I’ll take a half step back—for a decade or so ago, actually more than that. Even before HubSpot, the company I was contemplating, that I had a name for, was called Injenesoft. The idea behind Injenesoft was a natural-language interface to business software.

Now, realize this was 20 years ago, so that was a hard thing to do. But the actual use case that I had in mind was that we had data sitting in business systems, like a CRM or something like that. My clever thought at the time was, “What if we used email as the interface to get to business software?”

The motivation for using email was that it automatically works when you’re offline. Imagine I’m getting on a plane or I’m on a plane—there was no internet on planes back then—and I’m going through business cards from an event I went to. I can type things into an email just to have them all in the backlog. When it reconnects, it sends those emails to a processor that parses the commands and updates the software, sends you the file, whatever it is.

There was a handful of commands. I was a little bit ahead of the times in terms of what was actually possible. I reattempted this natural-language thing with a product called ChatSpot that I did back 20.

That was your first post-ChatGPT project?

I saw it come out. I’ve always been fascinated by this natural-language interface to software because, as software developers, myself included, we’ve always said, “We build intuitive, easy-to-use applications.” But it’s not intuitive at all, right? What we’re doing is taking the mental model that’s in our head of what we’re trying to accomplish with a piece of software and translating that into a series of touches, swipes, clicks, and things like that.

There’s nothing natural or intuitive about it. Natural-language interfaces, for the first time, mean that whatever thought you have in your head, expressed in whatever language you normally use to talk to yourself, you can just emit that and have software do something. I thought that was a breakthrough, which it has been.

So that’s where I first started getting into the AI side of the journey, because now it actually works. Once we got ChatGPT, you could take something—even with a few-shot example—and convert it into structured text. Even back in the ChatGPT 3.5 days, it did a decent job at that if you knew what kinds of intents you were going to have.

That ultimately became a HubSpot project. But then agents intrigued me because I thought, “Okay, that’s the next step here.” I love ChatGPT’s chat UX, but if we want to do something even more meaningful, it felt like the next advancement was not this synchronous back-and-forth model of chatting with software. It was that software would do things for me in a multistep way to try to accomplish some goals.

That’s when I first got started. I thought, “Okay, what would that look like?” I’ve been obsessed ever since, by the way.

That goes back to your first experience with it, where you’re offline and you want to do a task. You don’t need to do it right now; you just want to queue it up for somebody to do it for you.

As you think about agents, let’s start with the easy question—which might be the hardest question in the universe. How do you define an agent?

You said you have an irritating take.

I do have an irritating take. Some number of people have been irritated, including people within my own team. I have a very broad definition for agents: it’s AI-powered software that accomplishes a goal. Period. That’s it.

What irritates people about it is that it’s so broad as to be completely non-useful. I understand the criticism. But in my mind, if you fast-forward months—I guess in AI years—the implementation of agents is already starting to take different forms, and we’ll talk about that.

I think that in addition to having a usable definition—and I like yours, by the way, and we should talk more about the one you just came out with—the classification of agents is also useful. Is it autonomous or non-autonomous? Does it have a deterministic workflow or a nondeterministic workflow? Is it working synchronously or asynchronously?

Then you have different kinds of interaction modes. Is it a chat agent, like a customer-support agent, where you’re having a back-and-forth? Is it a workflow agent that just does a discrete number of steps? There are all these different flavors of agents.

If I were to draw it in a Venn diagram, I would draw a big circle that says, “This is agents,” and then have a bunch of overlapping circles, because they’re not mutually exclusive. I think that’s what’s interesting, and we’re seeing development along a bunch of different paths.

If you look at the first implementations of agent frameworks, like BabyAGI and AutoGPT—I think AutoGen was the Microsoft one—they were way ahead of their time because they assumed a level of reasoning, execution, and planning capability that just did not exist. It was an interesting experiment, a thought experiment, which is what it was.

Even the guy I’m an investor in, Yohei, whose fund did BabyAGI—it wasn’t ready, but it was a sign of what was to come. The question then is, when is it ready?

Lots of people talk about the state of the art when it comes to agents. I’m a pragmatist, so I think about the state of the practical. What can I actually build that has commercial value or solves a discrete problem with some baseline of repeatability or verifiability?

That was a lot, and very interesting. I’m not irritated by it at all. As you know, I take an anthropological or linguistic view, and in linguistics you don’t want to be prescriptive. You want to be descriptive.

You’re a goals guy. That’s the keyword in your definition. Other people have other definitions that might involve delegated trust or nondeterministic work, with an LLM in the loop.

The other thing I think about is the comment you just made on BabyAGI and AutoGPT. In the piece that you just read, I was able to go through our backlog and track the winter of agents and then the summer we’re in now. We can tell the whole story as an oral history just by following that thread.

I tried to explain the “why now.” There are better models, of course. There’s better tool use—they’re just more reliable. There are better tools with MCP and all that stuff, and I’m sure you have opinions on that too.

There’s been a business-model shift, which you like a lot. I just heard you talk about RAS with the My First Million guys. Costs are dropping a lot, inference is getting faster, and there’s more model diversity, which I think is a subtle point. It means you have different models with different perspectives; you don’t get stuck in the performance basin of a single model. You can get out of it by switching models.

There’s also multi-agent research and reinforcement-learning fine-tuning. I just wanted to let you respond to any of that.

A couple of things. Connecting the dots on the definition side of it: we’ll get the irritation out of the way completely. I have one more, even more irritating leap on the agent-definition thing.

The way I think about it is—and I looked it up—the English dictionary definition of an agent is when you have someone or something that does something on your behalf, like a travel agent or a real-estate agent acting on your behalf as a proxy. That’s a nice, general definition.

The other direction I’m headed, and this is going to tie back to tool calling and MCP, is that if you—and I’m not a biologist by any stretch of the imagination—but we have these single-celled organisms, the simplest possible form of what one would call life. It’s still life; it just happens to be single-celled.

Then you can combine cells over time, and the cells become specialized. You have much more sophisticated organisms further down the spectrum. In my mind, at the most fundamental level, you can almost think of having atomic agents. What is the simplest possible thing that’s an agent and can still be called an agent? What is the equivalent of a single-celled organism?

The reason I think that’s useful is that we’re headed down a road—which I think is very exciting—around tool use. The LLM can now be provided with a set of tools that it calls to accomplish whatever it needs to accomplish in furtherance of whatever goal it’s trying to get done.

And I'm not overly bothered by it, but if you think about it, if you just squint a little bit and say, well, what if everything was an agent? What if tools were actually just atomic agents? Because then it's turtles all the way down, right? Then it's like, oh, well, all that's really happening with tool use is that we have a network of agents that know about each other through something like MCP and can decompose a particular problem and say, oh, I'm going to delegate this to this set of agents. Why do we need to draw this distinction between tools, which are functions most of the time, and an actual agent?

I'm going to write this irritating LinkedIn post proposing this. I'm not suggesting we should call even functions agents, but there is a certain amount of elegance that happens when you say, oh, we can just reduce it down to 1 primitive, which is an agent that you can combine in complicated ways to raise the level of abstraction and accomplish higher-order goals. Anyway, I'd say that's a philosophy. Thank you for coming to my TED Talk on agent definitions.

How do you define the minimum viable agent? Do you already have a definition for where you draw the line between a cell and an atom?

In my mind, it has to, at some level, use AI; otherwise, it's just software. We don't need another word for that. That's probably where I draw the line.

So then the counterargument would be, well, if that's true, then lots of tools themselves are not agents because they're just doing a database call or a REST API call or whatever it is they're doing. And that does not necessarily qualify them, which is a fair counterargument. I accept that. It's a good argument.

I still like to think about it, because we'll talk about multi-agent systems. I think we've accepted—which I think is true, and lots of people have said it, and you've helpfully combined some of those clips of really smart people saying this—that this is the year of agents, and I completely agree. It is the year of agents. But shortly after that, it's going to be the year of multi-agent systems, or multi-agent networks. I think that's where it's going to be headed next year.

OpenAI is already on that.

My quick philosophical engagement with you on this cell thing is that I've been thinking about the other end of the cell spectrum. A single cell is life, multicell is life, and you can clump a bunch of cells together in a more complex organism. They become organs, like an eye and a liver, whatever. Obviously, we consider ourselves one life form. There's not a lot of lives within me. I'm just one life.

And now, obviously, I don't think people really like to anthropomorphize agents in AI, but we are extending our consciousness, our brain, and our functionality out into machines. I just saw you wear a B, which is, you know, like the Limitless pendant in my pocket, which I got. I got one of these. I'm testing it all out; I've got to be an early adopter.

We want to extend our personal memory into these things so that we can be good at the things that we're good at, and machines are good at the things machines are good at. My definition of life is kind of going outside of my own body now. I don't know if you've ever had reflections on that—how yourself is actually being distributed outside of you.

I'm not—I don't fancy myself a philosopher, but you went there.

Yeah, I did. I did go there.

I'm fascinated by graphs and graph theory and networks, and have been for a long, long time. To me, we're all nodes in this larger thing. It just so happens that we're looking at individual life forms as they exist right now, but when you put a podcast out there, there are these little nodes you're putting out there of conceptual ideas.

Once again, you have varying forms of those little nodes that are up there, and they're connected in varying and sundry ways. I think of myself as being a node in a massive, massive network, and I'm producing more nodes as I put out content or ideas.

You spend some portion of your life collecting dots—experiences, people—and some portion of your life connecting dots from the ones that you've collected over time. I found that really interesting things happen, and you just really can't know in advance how those dots are necessarily going to connect in the future. So that's my philosophical take.

Do you like graphs as an agent abstraction? That's been one of the hot topics with LangGraph and Pydantic and all that.

I do. The thing I'm more interested in, in terms of the use of graphs—and there's lots of work happening on that now—is graph data stores as an alternative for knowledge stores and knowledge graphs.

I've been in software now 30-plus years, right? So it's not 10,000 hours; it's like 100,000 hours I've spent doing this stuff. I grew up with—back in the day, I started on mainframes. There was a product called IMS from IBM, which was basically an indexed database, what we'd call a key-value store today.

Then we've had relational databases, right? We have tables and columns and foreign-key relationships. We all know that. We have document databases like MongoDB, which is sort of a nested structure keyed by a specific index. We have vector stores, vector-embedding databases, and graphs.

Graphs are interesting for a couple of reasons. One is that they're not classically structured in a relational way. When you say “structured database” to most people, they're thinking tables and columns in a relational database, set theory, and all that. Graphs still have structure, but it's not the tables-and-columns structure. People have made the case that they are a better representation of knowledge for LLMs and for AI generally than other things. That's kind of thing number 1 conceptually, and that might be true. I think it's possibly true.

The other thing that I really like about that in the context of data stores for RAG is that, with RAG, you say, I have 1 million documents, I'm going to build the vector embeddings, and I'm going to come back with the top X based on the semantic match. That's fine. All that's very, very useful, but the reality is something gets lost in the chunking process. With those 10, you don't really get the whole picture, so to speak, and maybe not even the right set of dimensions on the broader picture.

It makes intuitive sense to me that if we captured it properly in graph form, maybe feeding that into a RAG pipeline would actually yield better results for some use cases. I don't know, but yeah.

Do you feel like, at the core of it, there's this difference between imperative and declarative programs? If you think about HubSpot, people and graphs kind of go hand in hand, but I think maybe software before was more like primary key and foreign key, versus now the models can traverse through the graph more easily.

Yes. I like that representation. There's something conceptually elegant about graphs. Just from the representation of it, they're much more discoverable. You can kind of see it. There's observability to it versus embeddings, which you can't really do much with as a human. Once they're in there, you can't pull stuff back out. I like that kind of idea.

The other thing is that I love graphs. I've been long obsessed with PageRank from back in the early days, and it's one of the simplest algorithms; everyone's been exposed to PageRank. I had another idea for a project, not a company—I have hundreds of these—called NodeRank. The idea is to take PageRank and apply it to an arbitrary graph. I'm going to define what authority looks like, and then say, okay, that's interesting to me because if I take my knowledge store, maybe this person who contributed some number of chunks to the graph data store has more authority on this particular use case or prompt that's being submitted than this other one. Or maybe this one is more popular, or maybe this one has whatever it is. There should be a way for us to rank nodes in a graph and sort them in some useful way.

Yeah, I think that's generally useful for anything. I think the problem is that, even though GraphRAG is super popular at my conferences and people are getting knowledge-graph religion, I would say it's gaining traction in 2 areas: conversation memory, and then also RAG in general, like the document data source.

Most ML practitioners would say that knowledge graphs are kind of a dirty word. The graph database people get graph religion: everything's a graph, and then they go really hard into it, and then they get a graph that's too complex to navigate. The simple way to put it is, you, running HubSpot, know the power of graphs, the way that Google has pitched them for many years, but I don't suspect that HubSpot itself uses a knowledge graph.

No.

So when is it over-engineering, basically?

It's a great question. I don't know. The question now, in AI land, is: do we necessarily need to understand?

Right now, LLMs, for the most part, are somewhat black boxes. We sort of understand how the algorithm itself works, but we really don't know what's going on in there or how things come out. If a graph data store is able to produce the outcomes we want—

It's like, here's a set of queries I want to be able to submit, and it comes out with useful content. Maybe the underlying data store is as opaque as vector embeddings or something like that, but maybe it's fine. Maybe we don't necessarily need to understand it to get utility out of it, and so maybe if it's messy, that's okay. It's just another form of lossy compression. It's lossy in a way that we don't completely understand because it's going to grow organically and it's not structured.

It's like, I'm just going to throw a bunch of stuff in there. Let the equivalent of the embedding algorithm—whatever they call it in graph land—the one with the best results win, I think so.

Yeah, or the practical side of me is like, yeah, if it's useful, we don't necessarily need to understand it. I'm happy to push back as long as you want, but it's not practical to evaluate the 10 different options out there because it takes time, people, and resources. That's the first thing. The second thing is your evals are typically on small things, and some things only work at scale. Like graphs.

Yep. Yep. That's fair. I think this is one of the challenges in terms of implementation of graph databases. The most common approach that I've seen developers do—and I've done it myself—is, "Oh, I've got a Postgres database or a MySQL database or whatever. I can represent a graph with a very simple set of tables with a parent-child relationship or whatever, and that sort of gives me the ability. Why would I need anything more than that?"

The answer is, well, if you don't need anything more than that, you don't need anything more than that. But there's a high chance that you're missing out on the actual value that the graph representation gives you, which is the ability to traverse the graph efficiently in ways that, by going through the traversal in a relational database format, even though structurally you have the data, practically you're not going to be able to pull it out in useful ways. So you wouldn't represent a social graph using that kind of relational table model. It just wouldn't scale. It wouldn't work.

Yeah. I think we want to move on to MCP, but I just want to ask—just engineering advice. Obviously, you've run—you've had to do a lot of projects and run a lot of teams. Do you have a general rule for over-engineering or engineering ahead of time? People know premature engineering is the root of all evil, but sometimes you just have to. When do you do it?

Yes, it's a great question. This is a question as old as time, almost, which is: what's the right and wrong level of abstraction? That's effectively what we're answering when we're trying to do engineering. I tend to be a pragmatist. Here's the thing: lots of times, doing something the right way has only a marginally increased cost. In those cases, just do it the right way. This is what makes a great engineer, or a good engineer, better than not so great one. It's like, "Okay, all things being equal, if it's going to take you roughly close to constant time anyway, you might as well do it the right way." So do things well.

Then the question is, "Okay, well, am I building a framework? Is it a reusable library? To what degree—what am I anticipating in terms of what's going to need to change in this thing, along what dimension?" I think like a business person in some ways. What's the return on calories? You look at the expected value of it. It's like, "Okay, here are the 5 possible things that could happen." I try to assign probabilities.

"Okay, well, if there's a 50% chance that we're going to go down this particular path someday, or one of these 5 things is going to happen, and it costs you 10% more to engineer for that, it's basically something that yields compounding value as you get closer to the time of needing that versus having to take on debt." When you under-engineer it, you're taking on debt that you're going to have to pay off when you do get to that eventuality where something happens.

One thing, as a pragmatist, is that I would rather under-engineer something than over-engineer it if I were going to err on the side of something. The reason is that when you under-engineer it, yes, you take on tech debt, but the interest rate is relatively known and the payoff is very possible. It's like, "Oh, I took a shortcut here, as a result of which this thing that should have taken me 1 week is now going to take me 4 weeks." Fine.

But if that particular thing that you thought might happen never actually happens, if that use case never transpires or just doesn't, it's like, "Well, you just saved yourself time," and that has value because you were able to do other things instead of slightly over-engineering it. But there's no perfect answer. It's an art form.

Yeah. I'll bring these layers of abstraction back on the code-generation conversation, which I think I have later on, but I was going to ask—we can just jump ahead quickly. As you think about vibe coding and all of that, how does the percentage of potential usefulness change? I feel like we over-engineer a lot of times. It's like the investment in syntax, as I said, versus the investment in architecting. How does that change your calculus?

A couple of things. One is, going back to that ROI, or return-on-calories, calculus or heuristic, you think through: "Okay, what is it going to cost me to put this layer of abstraction above the code that I'm writing now, anticipating future needs?" If the cost of fixing or doing the under-engineering right now will trend toward 0, that says, "Okay, well, I don't have to get it right right now because even if I get it wrong, I'll run the thing for 6 hours instead of 60 minutes or whatever. It doesn't really matter, right?"

Because that's going to trend toward 0—the ability to refactor code. Not that long from now, we're going to have large codebases be able to exist as context for code-generation or code-refactoring models. So I think it's going to make the case for under-engineering even stronger. Why take on that cost? You just pay the interest when you get there.

It's not just: go on with your life, vibe-code it, and come back when you need to. Sometimes it feels like there's no decision-making in some things. Today I built autosave for our internal notes platform, and I literally just asked Cursor, "Can you add autosave?" I don't know if it's over- or under-engineered. I just vibe-coded it. I feel like at some point we're going to get to the point where the models decide where to draw the right line.

But this is where, in my mind, the danger is. There are 2 sides to this. One is the cost of development and coding and things like that—stuff that we talk about. But in your example, one of the risks that we have is that because adding a feature, like autosave or whatever the feature might be, to a product—as that price tends toward 0, are we going to be less discriminating about what features we add as a result of making products more complicated?

That has a negative impact on the user and a negative impact on the business. That's the thing I worry about: if it starts to become too easy, are we going to be too promiscuous in adding product extensions and things like that? It's like, "Why not add X, Y, Z or whatever?" Back then, it was like, "Oh, we only have so many engineering hours or story points," or whatever you measure things in. That at least kept us in check a little bit.

Yeah, and then with over-engineering, you're putting that on yourself. The models don't understand that if they add too much complexity, it's going to come back to bite them later. So they just do whatever they want to do.

Yeah, and I'm curious where in the workflow that's going to be. Where it's like, "Hey, this is the amount of complexity and over-engineering you can do before you have to ask me if we should actually do it versus doing something else."

You know, we've already—it's like we're living this in the code-generation world, this compressed cycle time. It's like, "Okay, we went from autocomplete in GitHub Copilot to, 'Oh, finish this particular thing.'" You hit Tab to, "Oh, I sort of know your file or whatever. I can write out a full function for you." To now, I can hold a bunch of the context in my head so we can do app generation, which we have now with Lovable, Bolt, Replit Agent, and other things.

So then the question is, "Okay, well, where does it naturally go from here?" We're going to generate products, makes sense. We might be able to generate platforms. It's like, "Oh, I want a platform for ERP that does this whatever, and that includes the APIs, includes the product and the UI, and all the things that make for a platform."

There's nothing that says we would stop at, "Okay, can you generate an entire software company someday, right? With the platform and the monetization and the go-to-market and whatever?" That's interesting to me in terms of what happens when you take it to almost ludicrous levels of abstraction.

Turn it to 11. You mentioned vibe coding, so I have to ask: this is a blog post I haven't written, but I'm exploring it. Is the junior engineer dead?

I don't think so. I think what will happen is that the junior engineer will be able to—if all they're bringing to the table is the fact that they are a junior engineer, then yes, they're likely dead.

But hopefully, if they can communicate with carbon-based life forms, interact with product, and are willing to talk to customers, they can take their basic understanding of engineering and how software works. I think that has value.

I have a 14-year-old right now who's taking a Python programming class. Some people ask me, “Why is he learning to code?” My answer is that it's not about the syntax; it's not about the coding. What he's learning is the fundamental thing of how things work, and there's value in that.

I think there's going to be timeless value in systems thinking and abstractions and what that means, whether functions are manifested as math, which he's going to be exposed to regardless, or whether there are some core primitives to the universe. I think the more you understand them, the more those become what I would think of as really large dots in your life that have a higher gravitational pull and value to them. So I want him to collect those dots, and he's not resisting, so it's like, “Okay, while he's still listening to me, I'm going to have him do things that I think will be useful.”

Yeah. One of the pitches that I evaluated for “AI engineer” as a term is that maybe the traditional interview path, or career path, of a software engineer goes away, because what's the point of LeetCode?

Yeah. And it actually matters more that you know how to work with AI to implement the things that you want.

Yep. That's one of the interesting things that's happened with generative AI. You go from machine learning and the models and just that underlying form, which is true engineering—what I call real engineering. I don't think of myself as a real engineer, actually. I'm a developer.

But now with generative AI, we call it AI, and it's obviously got its roots in machine learning, but it just feels fundamentally different to me. You have the vibe, and it's like, “Okay, well, this is just a whole different approach to software development and so many different things.”

I'm wondering now, with an AI engineer, if you were to draw the Venn diagram, it's interesting because the cross between AI things, generative AI, what the tools are capable of, what models do, and this whole new body of knowledge that we're still building out—it's still very young—intersects with classic engineering, software engineering.

Yeah. I just described the overlap: it separates out eventually until it's its own thing, but it's starting out as software engineering.

Yeah, that makes sense. So, to close the vibe coding, the other big hype now is MCPs. Obviously, I would say Claude Desktop and Cursor are the 2 main drivers of MCP usage. I would say my favorite is the Sentry MCP. I can pull in errors, and you can just put the context in Cursor.

How do you think about that abstraction layer? Does it feel almost too magical? You don't really see how the server itself is repackaging the information for you.

I think MCP as a standard is one of the better things that's happened in the world of AI, because a standard needed to exist, and absent a standard, there was a set of things that just weren't possible. Now we can argue whether it's the best possible manifestation of a standard or not. Does it do too much? Does it do too little? I get that, but it's just simple enough to both be useful and understandable and adoptable by mere mortals, right? It's not overly complicated. A reasonable engineer can stand up an MCP server relatively easily.

The thing that has me excited about it is that I'm a big believer in multi-agent systems. This goes back to our idea of an atomic agent. Obviously, an MCP server calls tools, but here's the way I think about it. I'm working on my current passion project, Agent.ai.

I think we should talk more about it, because I think it's interesting. Not to promote the project at all, but there are some interesting ideas in there.

One of those ideas is that we're going to need a mechanism for agents to collaborate and delegate. There's going to need to be some form of discovery, and we're going to need some standard ways to know what this thing over here is capable of. We're going to need a registry, which Anthropic is working on. I'm sure others will be doing directories of agents as well, and there's going to be a standard around that, too.

So how do you build out a directory of MCP servers in a standard way? I think that's going to unlock so many things, because we're already starting to see it. I think MCP, or something like it, is going to be the next major unlock because it allows systems that don't know about each other—and don't need to know about each other—to interact. It's that kind of decoupling of Sentry and whatever tools someone else was building.

It's not just about Claude Desktop or things like that, even on the client side. I think we're going to see very interesting consumers of MCP—MCP clients versus just the chatbot kind of things, like Claude Desktop, Cursor, and things like that. I'm very excited about MCP in that general direction.

I think the typical cynical developer take is like, “We have OpenAPI. What's the new thing?” Do you have a quick MCP-versus-everything-else explanation?

Yeah. I like OpenAPI. It's basically a self-documenting thing. We can machine-generate lots of things from that output. It's a structured definition of an API. I get that, and I love it.

But MCPs are use-case-specific. They're perfect for exactly what we're trying to use them for around LLMs, particularly in terms of discovery. I don't necessarily need to know all this detail. Right now, we have—we'll talk more about MCP server implementations. I do think MCP adds value above OpenAPI, because it solves this particular problem.

If we had come to the world—which we have—and said, “Hey, we already have OpenAPI,” if that were good enough for the universe, the universe would have adopted it already. There's a reason MCP is taking off: it marginally adds something that was missing before and doesn't go too far. That's why the rate of adoption has been so high. You folks have written about this and talked about it. It won because the universe decided that this was useful.

Maybe it gets supplanted by something else, and maybe we discover that OpenAPI was good enough the whole time. I doubt that, but we'll see.

The meta lesson in this is, I mean, I'm an investor in dev tools companies. I work in developer experience and DevRel in dev tools companies. Everyone wants to own the standard. I'm sure you guys have tried to launch your own standards. Is HubSpot known for a standard? Obviously, inbound marketing—but is there a standard or protocol that you ever tried to push?

No, and there's a reason for this. I don't mean to speak for the people at HubSpot, but I personally don't. I'm not smart enough. I'm much better off understanding the standards that are out there and being on the composability side: taking the pieces of technology that exist out there and combining them in creative, unique ways. I like to consume standards. I'm not saying I don't like to create them; I just don't think I have both the raw wattage and the credibility.

It's like, “Okay, well, who the heck is Dharmesh, and why should we adopt the standard he created?” I'm much better off understanding and using the standards that already exist.

Yeah, I mean, there are people who don't monetize standards. OpenTelemetry was a big standard, and Lightstep never capitalized on that.

So, okay, if I were to do a standard, there are 2 things that have been in my head in the past. One was a very basic one around—I even have the domain; I have a domain for everything—Open Marketing, because the issue we had as HubSpot grew up in the marketing space was that there was no standard around data formats and things like that. It didn't go anywhere.

The other one—I did not mean to go here, but I'm going to go here—is called Open Graph. I know the term was already taken, but it hasn't been used for its original purpose for 15 years now. What I think should exist in the world is this: right now, all of us, as nodes, are in the social graph at Meta or the professional graph at LinkedIn, both of which are actually relatively closed in very annoying ways, especially LinkedIn.

I personally believe that if it's my data, and I would get utility out of it being open, I should be able to make my data open or publish it in whatever form I choose, as long as I have control over it and it's opt-in. The idea behind Open Graph is: here's a standard, here's a way to publish it, and I should be able to go to opengraph.org/dharmesh.json and get it back. It's like, “Here's your stuff,” right?

I can choose along the way, and people can write to it. There can be an entire system, and if I were to do that, I would do it as a public-benefit, nonprofit kind of thing—as a contribution to society.

I wouldn't try to commercialize that.

Have you looked at the AT Protocol?

What's that?

The AT Protocol. It's the protocol behind Bluesky. My good friend Dan Abramov, who was the face of React for many, many years, now works there. He actually did a talk that I can send you that basically tries to articulate what you just said. He loves doing these really great analogies, which I think you'll like. A lot of our data is behind a handle, behind a domain.

So he's like, “All right, what if we flip that? What if it was like our handle and then the domain?” And that's really: your data should belong to you.

Yep. And I should not have to wait 30 days for my Twitter data to export.

Yep, totally.

And you should be able to automate it. I should be able to plug it into an agentic thing.

Yes. Because so much of our data is locked up, I think the trick here isn't the standard; it is getting the normies to care.

Yep. Because normies don't care.

That's true. But building on that, normies don't care. Privacy is a really hot topic and an easy word to use, but it's not a binary thing. There are use cases where—and we make these choices all the time—I will trade some privacy for some productivity gain or some benefit to me. I'll say, “I don't care about that particular data being online if it gives me this in return,” or, “I don't mind sharing this information with this company if I'm getting this in return.” But that should be my option.

I think now, with computer use, you can actually automate some of the exports. Something we've been doing internally is that everybody exports their LinkedIn connections, and then internally we kind of merge them together to see how we can connect our companies to customers or things like that.

Not to pick on LinkedIn, but since we're talking about it, they feel strongly enough about “do not take LinkedIn data” that they will block even browser-use kind of things or whatever. They go to great lengths to see patterns of usage and say, “Oh, there's no way you could have gotten that particular thing or whatever.”

Wasn't there a Supreme Court case that they lost?

Yeah, so the one they lost was around someone scraping public data that was on the public internet, and that particular company had not signed any terms of service or whatever. It's like, “Oh, I'm just taking data that's on there.” There was no signed terms-of-service agreement, and so that's why they won.

But the question is: can LinkedIn? I think they can. When you, as a user, use LinkedIn, you are signing up for their terms of service. If they say, “This kind of use of your LinkedIn account violates our terms of service,” they can shut your account down, right?

They can.

By the way, I love the company, don't get me wrong. I'm an avid user of the product.

Yeah, I mean, you've got over 1 million followers on LinkedIn, I think.

And I've known people there for a long, long time, right? I have lots of respect, and I understand even where the mindset originally came from: this kind of members-first, privacy-first approach. I sort of get that. But sometimes you have to wonder. It's like, okay, well, that was 15 or 20 years ago. There's likely some controlled ways to expose some data on some members' behalf, and not just completely be binary like, “No, thou shalt not have the data.”

I just pay for Sales Navigator. Right. Before we move to the next layer of instruction, anything else on MCP you mentioned?

Let's move back, and then I'll tie it back to MCPs.

I think the opportunity is with agent data. Okay, so I'll start with my running thesis: as AI and agents evolve—which they're doing very, very quickly—we're going to look at them less as just raw tools and more like teammates. I don't like to anthropomorphize, and we'll talk about why this is not that. They'll still be software. They should self-disclose as being software. I'm totally cool with that.

But I think what's going to happen is that, in the same way you might collaborate with a team member on Slack or Teams or whatever you use, you can imagine a series of agents that do specific things, just like a team member might do, that you can delegate things to and collaborate with. You can say, “Hey, can you take a look at this? Can you proofread that? Can you try this?” Whatever it happens to be.

I will go so far as to say it's inevitable that we're going to have hybrid teams someday. Back in the day, hybrid teams were, “Oh, well, you have some full-time employees and some contractors.” Then it was like hybrid teams are some people who are in the office and some who are remote. That's one form of hybrid. The next form of hybrid is the carbon-based life forms and agents and AI and some form of software.

Let's say we temporarily stipulate that I'm right about that over some time horizon, that eventually we're going to have these digitally hybrid teams. If that's true, then the question you sort of ask yourself is: what needs to exist in order for us to get the full value of that new model?

If I'm building a digital team, in the same way that if I'm interviewing for an engineer, a designer, or a PM, that's why we have professional networks, right? They have a presence, likely on LinkedIn. I can go through that semistructured form and see the experience—whatever they self-disclose. But agents are going to need that someday.

So I'm like, okay, this seems like a thread worth pulling on. I create Agent.ai. It's LinkedIn for agents. It's a professional network for agents.

The more I pull on that thread, the more things start to make sense to me. It may be more than just a pure professional network. My original thought was, okay, it's a professional network, and agents as they exist out there—which I think there's going to be more and more of—will kind of exist on this network and have a profile.

But then—and this is always dangerous—I'm like, okay, I want to see a world where thousands of agents are out there, because those digital employees and digital workers don't exist yet in any meaningful way. So then I'm like, oh, can I make that easier? As one does, it's like, oh, I'll build a low-code platform for building agents. How hard could that be, right? Very hard, as it turns out. But it's been fun.

So now Agent.ai has 1.3 million users. 3,000 people have actually built some variation of an agent, sometimes just for their own personal productivity, about 1,000 of which have been published.

The reason this comes back to MCP for me is, imagine that—and other networks, too. Right now, we have an MCP server for Agent.ai that exposes all the internally built agents that we have that do super-useful things. I have access to the Twitter API, which I can subsidize the cost of, and I can say, “If you're looking to build something for social media, you can do these kinds of things with a single API key.” It's all completely free right now. I'm funding it.

That's a useful way for a developer to say, “Oh, I have this idea. I don't have to worry about OpenAI. I don't have to worry about whether this particular model is better. It has access to all the models with one key.” We proxy it behind the scenes and then expose it.

So then we get this kind of community effect, right? Someone else may have built an agent to do X. I have an agent right now that I built for myself to do domain valuation for website domains because I'm obsessed with domains, right?

There's no efficient market for domains. There's no Zillow for domains right now that tells you, “Here's what houses in your neighborhood sold for.” Why doesn't that exist? We should be able to solve that problem. And yes, you're still guessing. Fine. There should be some simple heuristics.

So I built that. Let me go look for past transactions. You say, okay, I'm going to type in agent.ai, agent.com, whatever domain—what's it actually worth? I'm looking at buying it. It can go and say—and which is what it does—“I'm going to go look at whether there are any published domain transactions recently that are similar, either use the same word, the same top-level domain, whatever it is.”

It comes back with an approximate value, and it comes back with this rationale for why it picked the value and comparable transactions. “Oh, by the way, this domain sold for—” Okay. So let's say that agent existed on the web at Agent.ai.

Then imagine someone else says, “Oh, you know, I want to build a brand-building agent for startups and entrepreneurs to come up with names for their startup.” A common problem for every startup is, “I don’t know what to call it.” They type in 5 random words that define whatever their startup is, and you can do all manner of things. One of them is, “I need to find a domain name for it. What are the possible choices?”

Now it’s like, “Okay, it would be nice to know if there’s an aftermarket price for it. Is it listed for sale?” Awesome. Then imagine it calling this valuation agent: “I want to find where the arbitrage is—where the agent valuation tool says this thing is worth $25,000, and it’s listed on GoDaddy for $5,000. It’s close enough. Let’s go do that,” right?

That’s a kind of composition use case that, in my future state, has thousands of agents on the network, all discoverable through something like MCP. Then you, as a developer of agents, have access to all these LEGO building blocks based on what you’re trying to solve. You blend in orchestration, which is getting better and better with the reasoning models now. Just describe the problem that you have.

The next layer that we’re all contending with is: How many tools can you actually give an LLM before the LLM breaks? That number used to be 15 or 20 before it started to matter dramatically. That’s the thing I’m thinking about now. If I want to expose 1,000 of these agents to a given LLM, obviously I can’t give it all 1,000. Is there some intermediate layer that says, “Based on your prompt, I’m going to make a best guess at which agents might be able to be helpful for this particular thing?”

Yeah, like RAG for tools. I did build the Latent Space Researcher on agent.ai.

Okay. Yeah, that seems like—then there’s going to be a Latent Space Scheduler, and once that schedules and researches, you build all of these things.

By the way, my apologies for the user experience.

No, no, no. It’s pretty good. I would say it’s not a normie-friendly thing.

Yeah, that’s your magic. HubSpot does the same thing.

Yeah. Just to quickly run through it, you can basically create all these different steps. These steps are static versus variable-driven things.

How did you decide between this kind of low-code-ish approach, doing low-code with a code back end, versus not exposing that at all? Any fun design decisions?

Yeah, and I think lots of people are likely sitting in exactly my position right now, choosing between deterministic and nondeterministic approaches. If you’re in a business or building some sort of agentic thing, you decide whether to do a deterministic thing or go nondeterministic and just let the LLM handle it with the reasoning models, right?

The original idea, and the reason I took the low-code, stepwise, very deterministic approach, is, first, the reasoning models did not exist at that time. That’s thing number 1. Thing number 2 is, if you know in your head what the actual steps are to accomplish whatever goal, why would you leave that to chance? There’s no upside. There’s literally no upside. Just tell me what steps need to be executed.

So right now, what I’m playing with—one thing we haven’t talked about yet, and people don’t talk about UI and agents enough—is the primary interaction model. We’re used to the chatbot back-and-forth. Fine, I get that. I think we’re going to move to a blend: Some of those things are going to be synchronous as they are now, but some are going to be asynchronous. It’s going to put it in a queue.

Man, I talk fast, but I have only 1 other speed: even faster. So imagine you’re working with these hybrid digital teams. You would not go to a coworker and say, “I’m going to ask you to do this thing,” and then sit there and wait for them to go do it. That’s not how the world works. It’s nice to be able to hand something off to someone: “Okay, maybe I expect a response in an hour or a day or something like that.” There’s some implicit contract that we have with our coworkers in terms of when things need to happen.

The UI around agents—if you look at the output of agent.ai agents right now, they’re the simplest possible manifestation of a UI. It says, “We have inputs of 4 different types. We’ve got a dropdown, multiselect,” all the things from back in the original HTML 1.0 days. Here are the smallest possible set of primitives for UI: We need to collect some information from the user, go do steps and things, and generate some output in HTML or markup. Those are the 2 primary examples.

The thing I’ve been asking myself is, if I keep going down that path, people ask me—I get requests all the time—“Can you make the UI sort of boring? I need to be able to do this,” right? Then if I keep pulling on that, it’s like, “Okay, well, now I’ve built an entire UI builder thing. Where does this end?”

I think the right answer—and this is what I’m going to be coding once I get done here—is around injecting code generation and UI generation into the agent.ai flow. As a builder, you’re like, “I’m going to describe the thing that I want,” much like you would do in a vibe-coding world. But instead of generating the entire app, it’s going to generate the UI that exists at some point in either that deterministic flow or something like that.

It’s like, “Here’s the thing I’m trying to do. Go generate the UI for me,” and I can go through some iterations. I’m going to generate the code, tweak it, and go through this kind of prompt-style process like we do with vibe coding now. At some point, I’m going to be happy with it, hit Save, and that’s going to become the action in that particular step. It’s like caching the generated code so that I don’t incur any inference-time cost. It’s just the actual code at that point.

Yeah, I invested in a company called E2B, which does code sandboxes, and they powered LMArena and WebArena. Just like you do with LLMs—text-to-text—they do the same for UI generation. So if you’re asking a model, how do you do it?

Yeah, I think that’s where—that’s the thing I’m really fascinated by. The early LLMs were understandably but laughably bad at simple arithmetic, right? That’s the thing my wife and normies would ask us: “You call this AI? It can’t—” My son would be like, “It’s just stupid. It can’t even do simple arithmetic.”

Then we discovered over time that there’s a reason for this, right? It’s a large language model. The word “language” is in there for a reason in terms of what it’s been trained on. It’s not meant to do math. But now the fact that it has access to a Python interpreter that it can actually call at runtime solves an entire body of problems that it wasn’t trained to do. It’s basically a form of delegation.

The thought that’s rattling around in my head is that’s great. It took the arithmetic problem first. Now, for anything that’s solvable through a relatively concrete Python program, it’s able to do a bunch of things that it couldn’t do before. Can we get to the same place with UI? I don’t know what the future of UI looks like in an agentic AI world, but maybe let the LLM handle that in a nonclassic sense. Maybe it generates it on the fly, or maybe we go through some iterations and hit cache or something like that, so it’s a little bit more predictable. I don’t know.

Especially, when is the human supposed to intervene? If you’re composing them, most of them should not have a UI, because then they’re just webhooking to somewhere else. I just want to touch back on this. I’m going to ask: When you said you’re going to go back to code, what are you coding with? What’s your stack?

Python’s my language. I’m glad that it won in terms of the AI language. It’s the lingua franca, like the second language for everything.

By the way, there’s exactly 1 thing that I disagree with Bret Taylor on. Generally, I’m a massive Bret Taylor fan—smart, one of my favorite people in tech. He was talking about, “Oh, we need a different language than Python, or whatever that is, built for AI and built—” It’s like, “No, Bret. I don’t think we do, actually.” It’s just fine. It deals with it just fine, it’s expressive enough, and it’s nice to have a language that we can use as a common denominator across both humans and AI.

It doesn’t slow the AI down enough, but it does make it awfully useful for us to also be able to participate in that kind of future world, where we can still be somewhat useful. Anyway, yeah: Python, Cursor as my code-generation tool.

I’d also mention that I really like your code-generation thing. I have another thesis I haven’t written up yet about how generative UI has not fulfilled its full potential. We’ve seen Bolt and Lovable, and those are great. Vercel has a version of generative UI that’s basically function calling pre-made components. There’s something in between where you should be able to generate the UI that you want, pin it, and stick to it, and that becomes your form.

Yep.

Yeah. And so the way I put it is, I think the 2 form factors of agents that I’ve seen a lot of product-market fit in recently have been deep research and the AI builders, like Bolt and Lovable.

Yep. I think a version of this is where you generate the UI, but you sort of generate the Mad Libs fill-in-the-blank forms, and then you hit that stable UI, and the deep research just fills that in.

Yep. Yep. And that's it. I like that.

Yeah. I love those simple limitations and abstractions. But if you look at the almost polar opposite of that, most of the UIs that you and I think about, conceive, or even use as examples are based on the primitives and vocabulary that we have for UI right now. It's like, “Oh, we have text boxes, checkboxes, radio buttons, pull-downs, navigation, clicks, touches, swipes, and now voice.”

We combine the set of primitives that exist right now in interesting ways. But where I think AI is going to be headed on the UI front is the same place it's headed on the science front. Originally, it's like, “Well, based on the things that we know right now, it'll sort of combine them.” But we're right at the cusp of it being able to do actual novel research.

So maybe a future version of AI comes up with a new set of primitives that actually work better for human-computer interaction than the things that we've done in the past. I don't think it ended with the checkbox, radio button, and drop-down list. I think there's life beyond that.

Yeah. I know we're going to move to business models after, but when you talked about hybrid teams, one way we talked to folks about it is that you had offshoring, and you had onshoring, which is moving to a cheaper place in the country instead of offshoring. Now it's AI-shoring. You're moving somewhere else away from it. That's the thing people say: AI-shoring.

That's the first time I've ever heard of that.

Yeah. I don't know what it means. But to me, the most interesting thing about professional networks is that with people, you have limited availability to evaluate a person, so you have to use previous signals as a kind of evaluation. With agents, theoretically, you can have proof of work. You can run simulations and evaluate them that way.

How do you think about that when building agent.ai? Instead of just choosing one, I could literally run across all of them and figure out which one is going to work best.

Yep. I'm a big believer in that. Under the covers, when you build an agent—because the primitives are so simple—you have some sort of inputs, and we know what the variables are. Every agent that's on agent.ai automatically has a REST API that's callable in exactly the way you would expect. It automatically shows up in the MCP server, so you're able to invoke it in whatever form you decide to.

My expectation is that in this future state, whether it's a human hiring an agent to do a particular task or evaluating a set of 5 agents to do a particular task and picking the best one for their particular use case, we should be able to automate that. I just want to try it, and there should be a policy that the publisher or builder of the agent has that says, “Okay, I'm going to let you call me 50 times, 100 times, before you have to pay,” or something like that.

We should effectively have an audit trail. “Okay, this agent has been called this many times.” We also have human ratings and reviews right now, and we have tens of thousands of reviews of the existing agents on agent.ai. They average around 4.1 out of 5 stars. All those things are nice signals to have, but the callable, verifiable kind of thing is super useful.

If I can just call an API that says, “Here are 5 agents that solve this particular problem for me,” and I have a simple eval, I think that would be so powerful. I wish I had that for humans, honestly. That would be so cool.

Yeah, because when I was running engineering teams, people would try to come up with these rubrics when hiring, and they're not really helpful. You just need some ground truth.

Say you want to hire an AI software engineer. You could literally generate 15 or 20 examples of your actual issues in your organization, both from a people perspective, like collaboration, and actual code generation, and just pay for it to run. Today we do take-home projects and pay people. This should be kind of the same thing: “I'll just run you.”

Sure. Like today, we do take-home projects and pay people. This should be kind of the same thing. But I feel like people are not investing in their own evals internally. That's present company included, right? Everyone talks about evals. Everyone accepts the fact that we should be doing more with evals. I won't say nobody, but almost nobody actually does. That's a topic for a whole other day.

It's funny because HubSpot is famous for launching graders of things. You'd be perfect for it.

Yeah. I agree on evals, by the way. I just force myself to be the human in the loop, or someone I work with, and that's okay. But obviously, the scalable thing needs to be done.

Just as a fun fact or question on agent.ai: you've already talked about the Chat.com acquisition and all that, and that was around the time of custom GPTs and the GPT Store launching. I definitely feel agent.ai is kind of the GPT Store, but don't take it seriously. Do you feel that if OpenAI woke up one day and said, “Agent.ai is a thing. We should just reinvest in the GPT Store,” is that a fear?

I think that's an inevitability. It won't be agent.ai-driven; it'll be OpenAI. I don't have any insider information—I'm an investor, but I have no insider information. It just makes too much sense for them.

They've taken multiple passes at it, right? They did the plugins back in the day, then the custom GPTs, and then the GPT Store. Being the platform that they are, I think it's inevitable that they will ultimately come up with something. They already have custom GPTs. It's going to happen.

One of the things I promised myself I would never do is compete with Sam—ever. Not intentionally, anyway.

But here you are.

But, yeah, here I am. But I'm not really competing, right? It's free, so whatever. At some point, if it's actually valuable, they're solving a much, much bigger problem. I'm a small, tiny rounding error in the universe.

But the reason that compelled me to actually create it in the first place—because I knew custom GPTs existed, and I did have this rule in my head, “Don't compete with Sam”—was the thing I needed for my own personal use. That's how agent.ai got started.

I was building a bunch of what I call solo software, things for my own personal productivity gain, and I found myself doing more and more LLM-driven stuff because it was better that way. AI showed up in those solo projects a bunch.

The thing I needed was an underlying framework to build these things. High on the list was that I wanted to be able to straddle models, because certain steps in the process are like, “Oh, look, this particular thing involves writing, so maybe I want to use Claude. For this particular thing, maybe I want to use this other model.”

The same thing applies to image generation and different types of tasks, whether they have text or don't have text. I want to be able to mix and match.

My sense is that whether it's OpenAI, Anthropic, or whoever, they're likely to have an affinity for their own models, which makes sense for them. But I can be, for my own purposes and for our user base, a little bit of Switzerland. We don't think there's one model to rule them all. Based on your use case, you're going to want to mix and match, maybe even change them out, and maybe even test them, going back to the eval ideas.

We have enough users now that they use the LLM, and I look at the bill, and it's like, “I'm spending real money now.” That's just human nature. It's not just normies. We have this drop-down of all the models, so you can see which model you want to use in your agent.ai agent.

As it turns out, people pick the largest number. They'll pick GPT-4.5 or whatever it is.

You're doing 4.5? Ouch.

Yes. But the thing I've promised myself is that we will support all of them, regardless of what they cost. Once again, I see this as a research thing, a benefit to humanity, and inference costs are going down—at least, that's what I tell myself late at night so I can sleep.

People pick the highest-numbered one. We have an option in there right now that's the first option: “Let the system pick for me.” Auto-optimize.

Auto—yeah.

As it turns out, people don't do that. They just pick the highest one, which is fine. They shouldn't trust it completely.

But one thing we discovered is that if we back-channel it—and this is what we're testing—we can run the exact same agent 1,000 times. We'll do it on our own internal agents first. If the ratings and reviews—we're getting human evals all the time on these agents—show that the quality is the same, we can get a dramatic, multiple-orders-of-magnitude reduction in cost by going to a lower model with literally no change in the quality of the output.

That makes sense, because so many of the things we're doing don't require the most powerful model.

And it's actually because there is higher latency; it's not just a cost thing. So anyway, in that kind of future state, I think we're going to have model routing and a whole body of people working on that problem too. It's like, “Help me pick the best model at runtime.”

Would you buy or build model routing?

I buy everything that I can buy. I don't want to build anything if I don't have to.

One of the most impressive examples of this, I think, was our Chai AI conversation, which I think about a lot. He views himself explicitly as a marketplace. You are kind of a marketplace, but he has a third angle, which is the model providers, and he lets them compete. I think that sort of three-way marketplace may make a lot of sense. I don't know why every AI company isn't built that way.

It's a good point, actually. It makes sense. It's on my list of things I'm super passionate about. I'm very passionate about efficient markets and extremely irritated by inefficient markets.

Efficient markets, for the normies listening, are markets where every possible transaction that should occur actually does. That's an efficient market. So then why do inefficient markets exist? Maybe the buyer and seller don't know about each other. Maybe there's not enough of a trust mechanism, or there's no way to actually price it or come up with fair market value for fair pricing.

As you knock those dominoes down, the market becomes more and more efficient, and lots of latent value exists as a result of inefficiency. Whoever removes those inefficiencies for high-value markets makes a lot of money. That's been proven time and time again.

This is one of those examples of an inefficiency right now, because we're either overusing models or whatever. Let's just reduce that to an efficient market: The right model should be matched up with the right use case for the right price.

Very, very interesting. Have you ever looked into DSPy?

I have looked at it, though not deeply enough. It's supposed to be, as far as I know, the only evals-first framework. If evals are so important—and, by the way, the relationship between this and all of that is that DSPy would also help you optimize your models.

Yep, because you did the evals first. I wonder why it's not more popular, you know. But it is growing in traction, I would say. We're keeping an eye on it.

Let's talk about business models. Obviously, you have two: work as a service and results as a service. I'm curious how you divide the two.

Work as a service is—so, we know about software as a service, right? I'm licensing software that's delivered to me as a service. That's been around for decades now, so we understand that. But the consumer of that service is generally a human who's doing the actual work, whichever software you're buying.

With work as a service, the software is actually doing the work, whatever that work happens to be. That's work as a service. So, come up with discrete use cases, whether it's classification, legal contract review, or whatever—the software is actually doing the thing.

Results as a service is where you're actually charging for the outcome, not the work. Instead of saying, “I'm going to pay you X amount of dollars to review a legal contract,” or paying for a certain amount of time or number of uses, I'm going to pay you for the actual result.

My take on this is that the industry, or parts of the industry, are super excited about results as a service, or outcomes-based pricing. I think we're over-indexing on it, and the reason we're over-indexing on it is that the most popular use case on the agent side right now is customer support.

It's well documented. A lot of the providers that have agents for customer support do it based on the number of tickets resolved: X dollars per ticket. The reason that makes a lot of sense is that customer support departments and teams already have a sense for what a ticket costs to resolve through their current way of doing things. So you can come up with an approximation for what the economic value is.

There's also at least a semi-objective measure for what an acceptable resolution or outcome is. You can say, “We measured the net promoter score or CSAT for tickets,” or whatever. As long as 90% of the tickets were handled in a way that made the customer happy, that's whatever your line is. As long as the AI is able to replicate that same SLA, it's like, okay, they're the same. They're fungible, one versus the other.

I think the reason we're over-indexing, though, is that there aren't that many use cases that have those 2 dimensions to them: that they're objectively measurable and that there's a known economic value that's constant. Customer support tickets are an example because they're handled by humans, and humans have a discrete cost.

Especially in retail, which is where this originally got started, in B2C companies that have a high volume of customer support tickets, a ticket is roughly worth the same amount because it takes most humans the same amount of time to do that kind of level-1, tier-1 support. But in other things, the value per outcome can vary dramatically—literally by orders of magnitude—in terms of what the thing is actually worth.

The second thing is, how do you objectively measure it? Let's say you're going to do a logo creator as a service based on results. That's a completely subjective thing. It may take me 100 iterations; it may take me 5 iterations. The quality of the output is not completely under my control. It's not up to the software.

Maybe you have weird taste, or you didn't describe what you were looking for well enough, or whatever. It was just not a solvable problem. Design and other qualitative, subjective disciplines deal with this all the time. How do you make for a happy customer?

There's a reason why they say, “We'll go through 5 iterations, but our output is that we're going to charge you $5,000 or $500, whatever it is, for this logo.” But that's hard to do at scale.

Just a relatable anecdote: Our podcast actually just got a new logo, and we did it through 99designs. There are so many designers who are working really hard, but I just didn't know what I wanted. I was like, “It's too bad. You seem great, but, you know...”

Yep. Yeah, that's another example of a market made efficient. I've been a 99designs user and customer for a dozen-plus years now. It's fantastic. There are so many designers, and it doesn't cost that much for them to do, but it's worth a lot to us who can't design.

By the way, a pro tip on 99designs is that, on the margin, you're better off committing to paying the designer that you're going to pick as the winner. Whether you like it or not doesn't really matter. That gets higher participation, and you're still going to get a bunch of noise. You'll get a bunch of poor designs, but the quality outcome is often a function of the number of iterations.

Logo design is one of those examples where, if you had to choose between 200 logos and 20 logos, chances are higher that you're going to find something you like.

For those of you who are interested, I have a blog post on my reflections on the 99designs thing. They give an estimate of how many designs you get, and I think the estimate is like 30 to 60, but actually it's 200. So it's underpriced.

Do you think some markets are just fundamentally going to move to more results-driven business models?

Probably. I don't understand enough markets well enough to know, but if we had to sort and rank them, there's likely some dimension along which we could sort them. How are these kinds of businesses measured? Is there an objective measure of truth or of the outcome? Is there a way to price it in terms of low variance or variability in the value per outcome?

If those things are true, whatever industry that is true in—customer support is an example, but there are likely lots of other examples where those 2 things are true—then it makes sense.

But the thing I wonder, though, is whether, from the customer's perspective, they would rather pay for work as a service versus an actual result. Maybe the way they think about it is, “That's my arbitrage opportunity. I can get work done for X, but the value is actually Y. Why would I want that delta to be squeezed out by the provider of the software if I have a choice?” I don't know.

I mean, okay—attribution. There are 18 things that go into that. You're one of them, so it's hard to tell. By the way, have you seen—obviously, you're in this industry, though not exactly HubSpot's exact part of the market—what have you seen in attribution that's interesting? That directly ties into work as a service versus results.

Yeah, not enough, because we, as a world and as an industry—just pick your thing—are so behind on tracking.

This is why I think Web3, in the way that it was meant to be done, is going to make a comeback, because the fundamental principles of it make sense. I think what happened in that world was a bunch of crypto bros and grifters and NFT stuff, or whatever, that was loosely related because there was no actual—

But the idea of a blockchain, of a trackable thing, of being able to fractionalize digital assets, of attribution, of having an audit log—a published thing that's verifiable—all those primitives make sense. Maybe there's a limited, but not zero, set of use cases where what we would now call the inference cost, or the overhead—the tax for storing data on the blockchain—makes sense. There's certainly a tax to it, and it doesn't make sense for all things.

But it makes sense for some things, for sure. But we just don't have attribution in any meaningful way, I don't think.

Isn't it sad that it's so important?

I know. No answer. It partly comes down to incentives. The people that actually have the data, or parts of the data from which attribution could be calculated or derived, don't really have the incentives to make that data available. So even something as simple as, on the PPC side—on the Google Search side, which is sort of my world, or has been—we have less data now than we did back in the day in terms of click-throughs and things like that.

Before, Google would actually send you the keywords people typed, and years ago they even took that away. So it's hard to really connect the dots back on things, and we're seeing that across—not just PPC.

They took that away from Search Console.

What's that?

Their Search Console has that. They took that away.

Search Console has that, but your website—if you go to Google Analytics, you can connect it back to Google Search Console.

I see, I see. Yeah, yes. Okay. All right. Yeah, well, it's a known thing. You don't have to make it a rant about Google.

What about software engineering? Do you think it will stay as work-as-a-service, or do you think—I think most companies hire a lot of engineers, but they don't really know what to do with them, or they don't really use them productively. I think now they're kind of hitting this crisis where it's like, okay, I don't know how I will price an agent because I don't really know what my people are doing anyway. How do you think that changes?

I think I'm actually bullish on engineers in terms of their long-term economic value—not despite all the movements in code generation and all the things that we're already seeing, but because of it. Because what's going to happen as a result of AI—and people have talked about this in other disciplines—is that we're going to be able to solve many more problems.

The math guy in me is like, okay, we always say, “Now agents are going to be doing code, and there are going to be 1 million virtual, digital software engineers out there, so the value per engineer is going to go down, because I'm just in that same mix as an engineer.” What they don't recognize is that it's not just about the denominator. There's a numerator as well, which is: what's the total economic value that's possible?

I would argue that's growing faster than the denominator—the actual economic value that's possible as a result of software and what engineers can produce with the tools that they will have at hand. So I think the value of an engineer actually goes up. They're going to have the power tools, and they're going to be able to solve a larger base of problems that are going to need to be solved.

Yeah, it feels to me like it'll stay as work-as-a-service. You're paying for work. I don't think there's a 1-to-1 relationship.

There will be a set of engineers, and we see this all the time. In the media industry, you have people who are kind of writers, but then you have freelancers who write articles or write however they manifest their creative talent, and both make sense, right? There's the work-for-hire. There's also the outcome-based, or “I produce this thing,” and maybe some of those engineers actually produce agents. So they put them in a marketplace like Agent.ai someday, and that's how they make their millions.

Any other thoughts just on agents? We have a lot of miscellaneous things that we want to talk to you about. I think we covered a lot of territory, so I'm excited about agents.

My message to the world would be: don't be scared. I know it's scary. It's easy for me to say as a techno-optimist, but learn it. Even if you're a normie, even if you're not an engineer, if you're not an AI person, if you don't think of yourself as an AI person, use the tools. I don't care what role you have right now or where you are in the workforce. It will be useful to you.

Start to get to know agents. Use them. Build them. My message to engineers is always: there's more to go. We're still in the early days of figuring out what an agent stack looks like, and I want to push people toward agents with memory.

Yeah, right. Agents with planning. Oh, we have to talk about memory. We have to talk about memory.

No, let's do it, because I think that's the next—in my mind, the next frontier—is actual long-term memory, both for agents and then for agentic networks, in a trustable, verifiable—I won't say privacy-first, but privacy-oriented—way.

I have an issue with the term “privacy-first,” because a lot of times we say “privacy-first” when we don't really mean that. “Privacy-first” means I value that above all things, no matter what we're talking about, and that's just not true—not for any human or anything that wants to be used. So memory is an interesting thing, right?

The thing I'm working on right now—lots of things are in play in Agent.ai—is around implementing memory, and there are great projects out there, Mem0 being one of them. But what's interesting for me is that we see this in ChatGPT and other things right now, where it does have the notion of a longer-term memory. You can pull things back into context as needed.

The thing I'm fascinated by is cross-agent memory. If I'm an agent builder right now, it's like, okay, here are the things that I know or learned from the user, in terms of pulling out the—I’ll call them knowledge nuggets, for lack of a better term—and that's great. But then when the next agent builder comes out and it's the same user, shouldn't all the things that Agent 1 learned about me, if they're going to be useful for Agent 2, be available?

As long as I opt into it, it's like, “Yeah, I don't care about those things.” In fact, I would find it awfully annoying to tell Agent 2, Agent N, and Agent N+1 all the same things I've already told them, because they should know. The system should know.

This is part of the reason why I'm a believer in these networks of agents and shared state: user utility gets created as a result of having shared memory. We shouldn't just solve the memory problem for independent agents; we should also be able to share that context, share that memory, across agents.

That's part of the value proposition for Agent.ai. When you're building stuff, when we get to whatever million users, we're going to have growing memory about all of them. Instead of you going off on your own thing and building an agent out as a disconnected node in the universe or whatever, here's the value for building on the network, on the platform—ours or someone else's: more user value gets created. So it's utility.

How do you think about authorization for that? Because part of memory is selective memory. Take scheduling: I want you to have access, if I have a scheduling agent, to the events you're part of and to what times I have available, but it shouldn't tell you about other events on my calendar.

I have so many thoughts on this. This is the opportunity out there: solving these fundamental problems. This is going to need to exist, right? Right now, the closest approximation we have is OAuth 2.0, and everyone has it: you approve, and it's a very coarse set of scopes.

It depends on the provider of the OAuth server—Google, whoever it is, HubSpot, it doesn't matter. It's like, “Oh, I pick a set of scopes.” They could have defined the scopes to be super-granular and fine, but it's sort of up to them. That is going to move so slowly.

For instance, the use case I have right now is that I use email for everything. I use it as an event and data bus for my life. What I mean by that, literally, is that anything I do—if there's a way to get that into email, because I know it's an open protocol—I will be able to get to that data in useful ways.

This is before all of this, so I have 3 million emails that I've built a vector store off of to solve my own personal use cases. I'll give you the example, but obviously I'm not going to build all my own software for everything.

If a startup comes along and says, “Dharmesh, can you make your email inbox available in exchange for these things?” I'm like, “Hell no.” That's literally my life; everything is in here. So you need to share subsets.

I think there's a—maybe this is not the actual implementation, but imagine if someone said, “Okay, I have a trusted intermediary for that, for trust, however defined, that says, ‘I'm going to OAuth into this thing,’” and it gets to control that.

I can say in natural language, “I only want to pass email to this provider where the label is one of X, and no more than 50 emails in a day,” or whatever controls I want to put on it, so I don't have them dumping the entire 3 million back.

It's unlikely that all the OAuth server sides right now—the Googles, even the big ones, small ones, it doesn't really matter—are going to do that. But this is an opportunity for someone, and they're going to need to get to some scale, build some level of trust, that says, “Okay, I'm going to hand over the keys to this intermediary.” But then it opens up a bunch of utility because it gives me more fine-grained control.

Yeah, I think LangChain has an interesting one. There are a bunch of people who have tried to crack AI email. Every single one of them who's tried has pivoted away. And I'm waiting for Superhuman to do it.

Yep. I don't know why they haven't, but at some point, that's some cool AI stuff. I think the pace is going to increase, but I think this goes back to the Open Graph, right? I think Google is not incentivized to build better scopes.

Nope. They're just not going to do it. We can't even get semantic search out of Google.

Yeah, just now they made the announcement this week.

What do you mean? Semantic search in Gmail?

Oh, I see. So, they have all my 3 million emails. Why don't they have a vector store where I can do a basic graph, right? They're not indexing the entire internet in real time. I don't think my email is that big a deal.

My standard thing on memory is, it sounds like you're using Mem0. There's also MemGPT—now Letta—which gave a workshop at my conference. There's Zep, which uses a graph database, kind of open source and quite interesting, and LangMem from LangGraph, which I would highlight.

It's also really interesting, this developing philosophy that people seem to be agreeing on: a hierarchy of memories, from semantic memory to episodic memory to, I think, just overall sort of background processing. We have independently reinvented the idea that AI should sleep—

Yep.

—to do that deep REM processing of memories. It's kind of interesting.

Yeah, that is. Just on the notion of memory and hierarchies: the memory we're working on right now is at the user level and it's cross-agent, right? But the other, kind of one step up, would be—once again, going to these hybrid digital teams—you can imagine saying, "Oh, well, my team has this kind of shared team memory. I don't want to share it with the world or anything else, but with this set of agents across this group of people, I want to have shared state, like we would have in a Slack channel or something like that."

That should sort of exist as an option, right? The platforms should provide that. And the B folks, I should also mention, have said that they're working on that as well. So, imagine being able to share selective conversations with people. That's nice.

Limitless has, I guess, voice-based shielding.

I don't think they have, actually. I'm an investor in that, too, by the way.

I'm trying to think about all the things I've said. I'm invested in OpenAI, Perplexity, LangGraph, CrewAI, Limitless, and a bunch of them. So, if I've said anything, by the way, I have no insider knowledge. I'm not trying to plug or pitch or anything like that.

No. We have some miscellaneous questions that may be zooming out from agent AI. First of all, you mentioned this and I have to ask: you have so many AI projects you'll never get to. What's 1 or 2 that you want other people to work on?

Oh, wow. What other people should work on because I'll never get to it? What I need to do, because I've had this thought before, is maybe pick 1 a week or something like that and give the domain away. Have people submit their 1-pager or something like that. If you can convince me that you have at least enough of an idea, enough willingness to commit to actually doing something, it's the ones that you keep mentioning but haven't gotten into for whatever reason.

Traffic?

Some of them I don't have the underlying business model.

We're going to have to come back to this. Maybe do a follow-up episode.

I don't know. There's just nothing jumping to mind. I need the business model. So, I own Scout.ai. I think that's an interesting one.

By the way, pretty much all of them started with an idea at the time. It was one of those late-night moments: "Ah, I could do this. Is the domain available?" And I'll go grab it. I'm trying to think what else I have in the AI space. I have a lot of nonprofit domain names as well, for nonprofits, like Open Graph.

I'm not sure why things aren't jumping to my head. I have Agent.com, which obviously is tied to Agent.ai. That's going to be big. Oh, my God, that's going to be $30–$50 million. It's going to be big.

It has to be.

Yeah. I think it'll end up being bigger than Chat.com, which was $15 million. It's more work-oriented.

That's interesting. Do you want to talk about the Chat.com thing? I would love just the backstory. Did you just call up Sam one day and say, "I got the domain"? Did they get back to you knowing that you had it?

It's a good story. Back in the original ChatGPT days, the first thought I had in my head, which lots of people had in their heads, was that OpenAI was going to build a platform and ChatGPT was actually just a demo app to show off the thing. There had been precedents for tech companies that had demo apps to help normies understand the underlying technology.

My original thought was, "Well, someone should actually create it as a real product." That product should be called Chat.com because GPT is not consumer-friendly at all. It's an acronym; it doesn't roll off the tongue. So, I'm like, "I'll build Chat.com," because ChatGPT was just a demo app back then.

I got Chat.com. As it turns out, ChatGPT is a real product. I was at an event here in San Francisco that Sam spoke at, where he launched plugins—I think that was the announcement at that time.

That's the thing. I had sort of suspected, "Okay, things seem to be going this way. There's no way that OpenAI is going to launch plugins for ChatGPT if they weren't thinking of it as an actual product." So, it's not just about the GPT APIs. This is a real thing. I'm like, "Crap. This violates the first rule of Dharmesh: don't compete with Sam."

I knew when I bought the domain that there was competition for it. There were other companies looking to buy it. I don't know who they were. I had suspicions. So, I bought it, and then I'm like, "Okay, well, I'll reach out to Sam."

I said, "Hey, Sam, I happen to have Chat.com. I don't know whether you were or weren't in the running or trying to acquire it, but I have Chat.com. I'm not looking to make a profit on it. If you want it, you'll obviously do something much better and bigger with it. I don't want to be in the 'compete with Sam' game." That's effectively what I said.

They did want it, and we struck a deal. It looks like it's been a very good deal if the valuations are real.

Who knows?

It's one of those weird things.

The Agent.ai domain evaluator said that Latent Space is worth between $5,000 and $15,000. Does that feel right, ish?

Well, it's missing some of it. This one does not incorporate the transactional data. I have not published that one yet, because the other one is also operationally very intensive. But anyway, we actually had it donated by a listener, so I don't know what the real cost is.

By the way, I also own Crew.ai, which I've offered to them. I'm an investor in CrewAI. I've told them that whenever you're ready, let me know. I'll sell it to you at cost.

Yeah, I've heard about that. Since you buy a lot of domains, what are your favorite domain-buying tips, apart from having a really good domain broker, which I assume you have?

No, I actually don't. I do my own deals. I have a very cards-face-up approach to life. Some people would tell you, "If they know you're behind the transaction, the price is going to go up." Sure, but it's still a willing seller and a willing buyer, whatever. It doesn't mean I'm necessarily going to have to pay that price.

The upside is that I always reach out as myself when there's a domain out there. They can look me up, but I also come off as legitimate. There are very few people who aren't going to return my email when I say I'm interested in a domain that they may have for sale—or that they hadn't considered selling but would consider selling.

I still own some of my favorite domains. I still own Prompt.com, by the way. That could be a big one. I used to own Playground.com, and this is one I don't regret selling.

The original idea behind Playground.com was that, at the time, OpenAI had its Playground where you could play around with the models and things like that. So, I thought there should be a platform-neutral thing—a playground across all the LLMs where you could go test them out and play around with them, just like you could with OpenAI's GPT stuff. There are obviously products and startups that do that now.

Then Sahil was out there with Playground, the company. I think he reached out to me over Twitter or something like that. We knew of each other. I'd never met him, and I've still never met him. He asked me whether I would consider selling it. That was a tough one because I actually had the business idea already in my head. I thought it was a great domain name—a really simple English word that had relevance in a whole new context.

But once again, I took equity.

So, on the bright side, some domains get me into deals that I likely would never have been able to get into in 2 other ways.

Yeah. We should securitize your GoDaddy account and just make it a fund.

It's basically a fund. And by the way, this goes back to the kind of weird things or whatever. I'm invested—I don't know if it's public yet—in a company that's going to treat domains as a fractionalizable, tradeable asset. Because that's the original NFT, in a way, right? It's like, okay, if you can make both fractionalization and the transfer of ownership easy. Right now, it's so painful when you buy a domain: you go through an escrow service, and there's all this friction. I just want it to be instantaneous. Charge me in Bitcoin or a credit card or whatever it is, and then it should show up, and I should be able to read out the DNS. That should be minutes, not weeks or days.

ENS on Ethereum is basically the same.

But it's not for normies.

Yeah, exactly. They should bring it.

Yeah, ICANN and all of that is its own thing. I have a question on just that. You keep bringing up your Sam Altman rule. One of my favorite My First Million episodes of all time was actually without you there, but it was talking about you. Shaan was describing you as a fierce nerd.

I'm sure you were there. I think Sam is also a fierce nerd, and he is—I was listening to this Jessica Livingston podcast where she had him on and described him as a formidable person. I think you're also very formidable, and I just wonder: what makes you formidable? What makes you a fierce nerd? What keeps you this driven?

Sam's fiercer and nerdier, just for the record. But I think part of it is just the strength of my conviction, I guess. I'm willing to work harder and grind it out more than people who are smarter than me, and I'm only slightly stupider than people who are willing to work harder than me, right? I'm just the right mix of grind, working at it, and sticking to it for extended periods of time.

If I think I'm right, I will latch on and not let go until I can prove to myself that I'm not. So even with the natural-language thing, it took 20 years, but eventually I got to a point where the world caught up and it became possible. Part of what makes me formidable is that I'm a nice guy, and sometimes they're the most dangerous kind, right? I don't make enemies or whatever.

My advice would be—this is my take on competition—I don't think of it as war. I think of it as opponents. It's not war; it's a game, right? You can use whatever analogy you want. I happen to play a fair amount of chess. I'm a student of the game, and that's partly what makes me effective.

I'm solving for the long term, so I'm kind of hard to deter. For those of you out there looking to compete with HubSpot, good luck. No, I've been here 18 years, and I'm going to be here for another 18 years. But not that you shouldn't do it. It's a big market. I'm not trying to sway anyone.

Something I struggled with is this conviction you talked about. You start out not knowing anything, so how do you develop a conviction? Do you find it along the way, then lose conviction and stop working on it? How do you keep going?

The way I've approached it is that I don't generally tend to have conviction around a solution or a product. I have conviction around a problem. That says, “This is an actual, real problem that needs to be solved,” and I may have an idea for how to solve it right now.

I may get dissuaded—I'm not smart enough, the technology is not good enough, whatever the constraints are—but it's the problem I have conviction around. It's like, “That problem still hasn't gone away.” So I file it away in the back of my brain, and I'll revisit it. The world changes, and it changes really fast now with AI. Things that weren't possible before are now possible.

So you go back to your roster of things that you believe or believed and say, “Maybe now is the time. Maybe then wasn't the time.” But I'm a big believer in attaching yourself passionately, with conviction, to problems that matter. There are some that are just too highfalutin for me, that I'm never going to be able to take on. I have the humility to recognize that.

I feel like I need an updated founder's version of the Serenity Prayer: give me the confidence to do what I think I'm capable of, but not to overestimate myself.

Yep. Anyway.

When you say the world changes, how do you keep up on AI?

A lot of YouTube, as it turns out. A lot.

Fireship? I don't know what Fireship is.

It's a current meme right now. Whenever OpenAI drops something—you know, they love these live streams of stuff on the OpenAI channel—the top comment is always, “I will wait for the Fireship video,” because Fireship just summarizes their thing in 5 minutes.

My kind of modus operandi is—I keep very weird hours. My average go-to-bed time is roughly 2:00 a.m., but I do get an average of 7 to 7.5 hours in. I don't use alarm clocks because I don't have meetings in the morning at all, or try not to, at least. My late-night thing is that I'll watch probably a couple of hours of YouTube videos, often in the background while I'm coding.

That's how you see me in our talks.

Yeah, I've seen that. Okay.

There's so much good material out there. The thing I love about YouTube—and this, by the way, is in terms of use cases and things that agents should be able to do but don't yet—is that I would love to, and technology exists now to build this, be able to take a YouTube video of a talk, say, on Latent Space or at the AI Engineer event, and say, “Just pull the slides out for me, because I want to put them into a deck for use,” or some form of distillation or translation into a different format. Pull the slides out of a video. I think that's interesting.

By the way, on the agent—sorry, AI—side, one of the commonly used action primitives that we have is the ability to get a transcript from a video. That seems like such a trivial thing, but if you don't know how to do it programmatically, or if you're just a normie, it's like, okay, I know it's there, and I can copy and paste it, but how do I actually get the transcript for you?

Then, once you have the transcript, you can encode it and say, “I can actually give you timestamps.” If you have a use case that says, “I want to know exactly when this was; I want to create an aggregate video clip,” this was the original agent that I built for my wife. She wanted to pull multiple clips together without using video-editing software because she wanted to make this aggregate thing to send to a friend. She's on the nonprofit side.

There are video-understanding models that have come out from Meta, but the easiest one by far is going to be Gemini. They just launched YouTube support.

Yep.

They're doing good work over there. In terms of the coolest thing AI-wise recently—I'll say in the last 7 to 10 days—it has been the new image model, Gemini Flash Experimental, whatever they call it, because it lets you effectively do editing.

My son is doing an 8th-grade research project on AI image generation, so he's gone deep on Stable Diffusion and the algorithms and things like that. I don't know much about it, but I know enough about Stable Diffusion to know why editing is nearly impossible. You can't recreate something, because you can't go back that way. It's going to be a different thing, because it's sort of spinning the roulette wheel another time. The next time you try a similar prompt, you get something different.

So the fact that they were able to pull it off is still very much a V1. One of the test cases was, “Take the HubSpot logo and replace the O with this kind of sprocket, with a donut.” It will do it, but it won't size it to the degree that it will actually fit into the original thing.

Do you know the backstory behind that one?

Mostafa Mostafa, who was part of—so they had image generation in Lama 3. Lama didn't improve it. Mostafa quit Meta, joined Gemini, and then shipped it. It is rumored—and that's all I can say—that they got rid of diffusion. They did autoregressive image generation, and I think it's been interesting watching these 2 worlds collide.

Diffusion was really about images, and autoregressive was really about language. People were asking, “How are they going to merge?” On the Midjourney side, David Holtz was very much betting on text diffusion being their path forward. But it seems like the autoregressive paradigm is one.

Playground is doing exceptional work in that domain, around image editing and not just text-to-image.

It's fascinating. I thought diffusion was kind of dead. There wasn't that much left beyond bigger models and higher detail, and now autoregressive models have come along and the whole field is open. I think if there was any real threat to Photoshop or Canva, it's this thing.

Just to wrap up the conversation, you have a great post called “Sorry, I Must Pass,” which, if I did the math right, you first wrote in 2007.

Yep, that’s right.

And then you re-updated it post-COVID. You mentioned you made a lot of changes to your schedule and your life based on the pandemic. How do you make decisions today? Has anything changed since you updated this in 2022? I think now we’re kind of 5 years removed from COVID and all that. I’m curious if you’ve made any changes.

Yeah, so that post, “Sorry, I Must Pass,” was a reaction to what happened: my schedule and life just got overwhelmed, right? There were just too many dots and connections, and I love interacting with new people online. I love ideas. I love startups. But it turns out every time you say yes to anything, you are, by definition, saying no to something else. Despite my best attempts to change the laws of the universe, I have not been able to do that.

That post was a reaction to that, because when I did say no, I would feel this guilt. It was like, “Okay, whatever it happens to be—‘Can you spend 15 minutes and just review this startup idea?’” Sometimes it would be someone who was second-degree removed, like an introduction through a friend or something like that, and I felt real guilt. This was a very honest, vulnerable, “Here’s what’s going on in my life.”

This is not a judgment on you at all, whatever your project or whatever thing you’re working on, but I have come to the realization that I just can’t do it. So I’m sorry, but my default thing right now—and lots of people will disagree with this default position—is that I have to pass. Derek Sivers said this really well: It’s either a hell yes or it’s a no, right?

There’s going to be a limited number of hell yeses that I’m going to be able to inject into my life. Of all the blog posts I’ve ever written, that has been the most useful for me. I still send it out personally, right? I don’t have automated email responses at all yet. I don’t do automated social media posts, but that one’s been very useful.

I encourage everyone, wherever your line happens to be, to think about this. Lots of people have this guilt issue, and that’s one of the most unproductive emotions in human psychology. No good comes from guilt, not really—unless you’re a sociopath or something like that. You don’t need more guilt.

I would also encourage people to blog more, because a lot of times people want to pick your brain and then ask you the same 5 questions that everyone else has asked. If you blogged it, then you can just say, “Here.”

One thing I’m working on—and there are startups working on this as well, but I started before then—is Dharmesh.ai, right? It captures my knowledge, and it’s interesting because that’s one of the agents on Agent.ai, on the underlying platform.

Oh, there’s a Dharmesh AI.

It’s out there. It’s Dharmesh.ai, yeah. It’s purely text-based—no video or audio right now—but the thing I’ve found useful is figuring out how to give it knowledge.

I have a private email address, because a lot of the interactions that I have, or if I do answer questions, happen there. The other thing, by the way, is I don’t do any phone calls at all—not even Zooms. I’ll get on Zoom with teams, but no 1-on-1 meetings, no 1-on-1 anything. It just doesn’t scale.

So I’ve moved as much as possible to an async world. As long as I can control the schedule, I will take 20 minutes and write a thoughtful response. But I reserve the right to anonymously, with no attribution, share that either with my model or with the world through a blog post or something.

It’s been useful because now that I have that email backlog, I can go back and say, “Okay, I’m trying to answer this question.” I go through the vector store, and it’s shockingly good. I’m still irritated that Gmail doesn’t do that out of the box. They’re Google. I think it’s got to be coming now.

I think the giant has finally been woken up. I think the process has gotten faster now.

Yeah, you know, it’s one of the biggest giants in the world ever.

Yeah, yeah. When I first told Alessio, you were one of our dream guests, I never actually expected to book you because of “Sorry, I Must Pass.” We were just like, “Let’s send an email and he’ll say no, and we’ll move on with our day.” So I just have to say, we’re very honored.

I’m just thrilled to be here. Huge fan. First-time guest.

Yeah, yeah. Thank you for all that you do for the community. I speak for a lot of them.

You guys taught me a lot of what I think I know. I mean, I am explicitly inspired by HubSpot.

Oh, thank you.

Inbound marketing, I think, is a stroke of genius. AI engineering is explicitly modeled after that. You created your own subsection of an industry that became a huge thing because you got the trend right. That’s what AI engineering is supposed to be if we get it right.

So how do we screw this up?

You know, the common failure modes, right? The original thing that makes inbound marketing work—the kernel of the idea—was to solve for the customer, solve for the audience, solve for the other side. The thing that was broken about marketing was that marketing was very self-centered: “I have this budget. I’m going to blast you and interrupt your life and interrupt your day because I want you to buy this thing from me,” right?

Inbound marketing was the exact opposite. It was, “Use whatever limited budget you have and put something useful in the world that your target customer, whoever they happen to be, will find valuable.”

Anyway, the common failure mode is that you lose that. I don’t think you will, but it is very common. It’s like, “Now I’m just going to turn the crank and squeeze just a little bit.” But you have the right reasons, I think. Folks like me appreciate that community so much because you have that genuine want.

There’s nothing wrong with making money. There’s nothing wrong with having fun. None of that. But at the core of it, we want to lift the overall level of awareness for this group of people and create value and create goodness in the world.

I think if you hold on to that over the fullness of time, the market becomes more efficient and rewards that generosity. That’s my fundamental life belief. So I think you guys are doing pretty well.

Thank you for your help and support.

My pleasure.

And just to wrap, in very Dharmesh fashion, you have a URL for the “Sorry, I Must Pass” blog, which is SorryMustPass.org. I thought that was a good nugget. Thanks so much for coming on.

Oh, thanks. Thanks for having me.