Summary

Dharmesh Shah’s core call is that the agent era quickly becomes a multi-agent network, where software delegates to software and “tools” may collapse into atomic agents. Agent.ai is his working prototype: 1.3 million users, 3,000 builders and roughly 1,000 published agents, all callable through REST and MCP. The bottleneck shifts from creating agents to discovering and routing among them, because model quality once began to suffer materially beyond roughly 15–20 exposed tools.
MCP matters less as a perfect protocol than as the missing standard that lets independently built systems discover and call one another. Dharmesh’s answer to the “OpenAPI was already enough” objection is empirical: “the universe decided that this was useful.” Registries, agent profiles and new MCP clients could become the connective infrastructure for hybrid teams of humans and self-disclosing software.
The emerging agent economy is a routing and evaluation market, not “one model to rule them all.” Agent.ai users gravitate toward the highest number, including GPT-4.5, rather than trusting automatic selection; yet repeated runs and human ratings may show that a cheaper model delivers the same output quality at “multiple orders of magnitude” lower cost. The practical opportunity is therefore proof-of-work evaluation, model routing and marketplaces that match each task to the right capability and price.
AI code generation strengthens the case for under-engineering because refactoring costs may trend toward zero, but it makes product sprawl more dangerous. Dharmesh would “rather under engineer something than over engineer it,” since technical debt has a relatively knowable payoff while speculative abstraction may never be used. The new constraint is judgment: when features become nearly free to build, teams risk becoming “too promiscuous” and imposing complexity on users.
Outcome pricing works best where the result is objectively measurable and its economic value is stable. Customer support fits because businesses know the approximate cost per resolved ticket and can monitor CSAT or similar service levels; logo design does not, because taste, iteration count and value vary radically. Dharmesh thinks the industry is over-indexing on results as a service when many customers may prefer buying work cheaply and retaining the upside themselves.
Long-term, cross-agent memory may be the next platform layer, but coarse OAuth scopes may be inadequate for it. Dharmesh wants knowledge learned by one agent to become selectively available to another, and eventually to a hybrid team, without repeatedly interrogating the user. His three-million-email example makes the requirement concrete: useful agents need fine-grained, natural-language permissions such as labels, time windows and daily limits—not all-or-nothing inbox access.
Knowledge graphs might improve RAG by preserving relationships that chunking and top-X vector retrieval lose, yet Dharmesh treats that as a hypothesis rather than “graph religion.” His proposed NodeRank would add authority or relevance signals to graph nodes, but the hosts stress that graph systems become complex, evaluations stay small and some benefits appear only at scale. Dharmesh’s pragmatic answer is that opacity or messiness may be acceptable if the system reliably produces better results: “the one with the best results wins.”

Deep dive

1. Natural language finally became an executable interface

Dharmesh’s agent journey began roughly 20 years ago with Injenesoft, an imagined natural-language interface to business software. A user could email commands while offline on a plane; after reconnection, a processor would parse them, update a CRM or return a file. The implementation was premature, but the desired interaction model persisted.
ChatSpot was his post-ChatGPT return to the idea. Even in the ChatGPT 3.5 era, a few examples could turn natural language into structured text when the likely intents were known: “Now it actually works.” That broke software out of the supposedly intuitive—but actually learned—grammar of clicks, taps and menus.
Agents were the next step because synchronous chat still requires continuous human participation. Dharmesh wanted software that could take a goal, perform multiple steps and return later with completed work—the modern version of placing a request into that offline email queue.

2. A broad definition leaves room for many agent species

Dharmesh’s deliberately irritating definition is minimal: “AI-powered software that accomplishes a goal. Period.” Rather than add autonomy or nondeterminism to the definition itself, he would classify agents by dimensions including autonomous versus non-autonomous, deterministic versus nondeterministic, synchronous versus asynchronous, and conversational versus workflow-based.
BabyAGI, AutoGPT and Microsoft’s AutoGen were, in his view, “way ahead of their time.” They assumed reasoning, planning and execution capabilities that models did not yet possess. He therefore distinguishes the celebrated state of the art from the commercially relevant “state of the practical”: what can repeatedly solve a discrete problem with some verification.
The hosts’ explanation for “why now” combines stronger reasoning, more reliable tool use, MCP, cheaper and faster inference, model diversity, multi-agent research and RL fine-tuning. Diversity matters because switching models can escape a single model’s performance basin rather than endlessly optimizing within it.
His lower boundary remains AI use: without AI, an atomic unit is simply software. Dharmesh accepts the counterargument that a database call or REST function therefore is not itself an agent, but still finds value in reducing systems to one composable primitive.

3. Atomic agents point toward networks, not monoliths

Borrowing from biology, Dharmesh asks for the agent equivalent of a single-celled organism. If a tool were treated as an atomic agent, higher-order systems could decompose goals and delegate through a network: “Then it’s turtles all the way down.” The distinction between tool calling and multi-agent collaboration would become mostly one of abstraction.
His forecast is that the “year of agents” will soon be followed—potentially the next year—by multi-agent systems and networks. Discovery, capability descriptions, delegation and shared protocols matter more in that future than a single agent’s illusion of general intelligence.
The hosts extend his cell analogy toward humans augmenting memory through wearables such as the B device and Limitless. Dharmesh’s own framing is less anthropomorphic: people, agents, podcasts and ideas are nodes in a massive network, while a life alternates between “collecting dots” and connecting them in combinations that cannot be predicted in advance.

4. Graphs may restore the context that vector retrieval discards

Dharmesh’s 30-plus-year database arc runs from IBM’s IMS, effectively an indexed key-value store, through relational tables, MongoDB-style documents and vector stores. Graphs interest him because they retain structure without forcing knowledge into rows, columns and foreign keys, and remain more inspectable than embeddings.
His case for graph RAG is conditional: vector search over a million documents returns the top semantic matches, but chunking can lose both the whole picture and relevant dimensions of it. A properly captured graph might preserve relationships that improve some retrieval pipelines—“might” being the operative hedge.
Inspired by PageRank, his unbuilt NodeRank project would rank arbitrary graph nodes by a chosen definition of authority. In a knowledge store, provenance, contributor expertise, popularity or task relevance could affect which nodes deserve weight rather than treating every matching chunk equally.
The hosts’ pushback is that ML practitioners often regard knowledge graphs as a dirty word: graph vendors acquire “graph religion,” complexity explodes and small evaluations miss behaviors visible only at scale. Dharmesh concedes he does not know when graphs become over-engineering; his practical test is utility, even if the graph becomes another opaque, lossy representation.

5. Under-engineering wins when technical debt is cheaply repayable

Dharmesh’s baseline rule is to do something properly when the marginal cost is small. The harder decision is whether to build a reusable abstraction for uncertain future needs, which he evaluates as “return on calories”: enumerate plausible paths, assign rough probabilities and compare preparation cost with expected future benefit.
When forced to err, he chooses under-engineering. Its debt has a relatively knowable interest rate: a future change that should take one week may instead take four. Over-engineering spends scarce time today against a scenario that may never occur, forfeiting whatever else could have been built.
Code generation pushes the calculus further toward postponement. As large codebases fit into model context and automated refactoring improves, fixing a shortcut may mean running a model for six hours instead of 60 minutes. If correction costs trend toward zero, “take on that cost” later and continue building now.
The hosts’ pushback is that teams cannot cheaply test every architecture: evaluations consume time, people and resources, and some approaches only work at scale. Dharmesh’s answer remains situational: a relational representation is sufficient until the use case truly requires graph traversal or social-graph-scale performance.

6. Cheap code transfers scarcity from engineering to product judgment

The darker side of near-zero implementation cost is feature proliferation. Dharmesh worries that teams will become “less discriminating” or “too promiscuous” about adding capabilities, leaving users and businesses with greater complexity. Limited engineering hours once imposed a crude but useful discipline.
Code generation has already compressed from autocomplete and tab completion to functions, applications and products. Dharmesh sees no principled stopping point: models may generate platforms—including UI, APIs and monetization—and eventually something approaching an entire software company with its go-to-market machinery.
The junior engineer is dead only if being junior is the entire contribution. Engineers who communicate with “carbon-based life forms,” speak with customers and understand products can use AI to operate above their nominal level. Dharmesh’s 14-year-old studies Python not for syntax, but to collect durable ideas about systems, functions and abstraction.
He sees AI engineering emerging from the overlap between generative-AI knowledge and classical software engineering. Python remains his preferred common denominator, used with Cursor; on Bret Taylor’s suggestion that AI needs a new language, Dharmesh’s lone disagreement is blunt: “No, Bret. I don’t think we do.”

7. MCP won because it adds just enough missing structure

Dharmesh calls MCP “one of the better things that’s happened in the world of AI.” It is simple enough for a reasonable engineer to stand up, but structured enough to let models discover and invoke external capabilities. A useful, adoptable standard mattered more than theoretical perfection.
The cynical objection—OpenAPI already describes APIs—is worth retaining. Dharmesh likes OpenAPI, but says MCP is narrower and better aligned with LLM discovery. If OpenAPI had already met the need, adoption would reflect that; instead, “the universe decided that this was useful.” MCP may be supplanted, but its rate of adoption signals real marginal value.
The next requirements are standardized registries and directories describing what agents and MCP servers can do. Dharmesh also expects clients beyond Claude Desktop, Cursor and conventional chat interfaces, allowing systems that were never designed together to compose without tight coupling.
He prefers consuming standards to creating them, describing himself as stronger at combining existing pieces than claiming the authority to impose a protocol. The exception he imagines is a public-benefit “Open Graph” through which people could publish selected personal data under their own control.

8. User-owned data remains an incentive problem, not a protocol problem

Dharmesh’s hypothetical Open Graph would let a person publish an opt-in record—his example is opengraph.org/dharmesh.json—rather than remain trapped inside Meta’s social graph or LinkedIn’s professional graph. A host points him toward the AT Protocol, the protocol behind Bluesky, as an existing attempt to separate identity and user data from a controlling domain.
The obstacle is that “normies don’t care” about data architecture in isolation. Dharmesh reframes privacy as a trade rather than a binary virtue: people routinely exchange limited data for productivity or utility, but they should control which data, which recipient and which return benefit.
LinkedIn embodies the conflict. The hosts describe internally combining voluntarily exported connection lists; Dharmesh notes LinkedIn may detect and block automated access. When a host raises the scraping court case, he distinguishes public data gathered by a non-user from an account holder bound by terms of service—the latter can still lose access.
His criticism remains qualified: he is an avid LinkedIn user with more than a million followers and respects the company’s original “members first” reasoning. But a position formed 15–20 years ago need not justify a permanent rule that “thou shalt not have the data.”

9. Hybrid teams need a professional network for agents

Dharmesh believes it is “inevitable” that teams will blend humans and software. Earlier hybrid teams mixed employees with contractors or office workers with remote staff; the next version mixes carbon-based workers with agents that remain software and should disclose themselves as such, yet can receive delegation much like colleagues.
That premise produced Agent.ai as a professional network for agents. Agents could have a presence and profiles on the network, while discovery becomes the analogue of recruiting through a professional network.
Dharmesh then pulled the thread further: because useful digital workers scarcely existed, the network also needed a low-code creation platform. Agent.ai has reached 1.3 million users; about 3,000 people have built some form of agent, often for personal productivity, and roughly 1,000 agents have been published.
The project is free and currently funded by Dharmesh. He treats it partly as research and infrastructure, not a promotion for a finished business, but the usage provides the experiments, human feedback and callable supply needed to test his network thesis.

10. Composition turns agent discovery into economic leverage

Agent.ai exposes every built agent through a REST API and its MCP server. One key can reach multiple models and subsidized capabilities such as Dharmesh’s Twitter API access, reducing the setup cost for developers who want to test an idea without separately arranging every provider.
His sharpest composition example begins with a personal domain-valuation agent. Because domains lack a Zillow-like efficient market, it searches published comparable transactions by word or top-level domain, then returns an estimated value, rationale and supporting sales rather than pretending to know a definitive price.
A startup-naming agent could invoke that valuation agent while searching aftermarket listings. If the valuation agent estimated a domain at $25,000 and GoDaddy listed it for $5,000, the combined system could surface the apparent arbitrage. The value lies in recombining agents whose original builders never coordinated.
The immediate technical constraint is context. Dharmesh says the practical tool limit used to be around 15–20 before it became a major issue; exposing 1,000 agents directly is untenable. The missing intermediate layer is “RAG for tools,” selecting a plausible subset from the user’s prompt before orchestration begins.

11. Deterministic workflows and generated interfaces can coexist

Agent.ai began with stepwise, low-code deterministic flows partly because capable reasoning models did not yet exist. Dharmesh’s second reason remains valid: if the builder knows the required sequence, “there’s literally no upside” in asking a model to rediscover it and introduce avoidable variance.
Interaction should nevertheless move beyond synchronous chat. A person does not assign work to a colleague and stare until it is finished; agents similarly need queues, implied response times and asynchronous handoffs.
Agent.ai currently uses deliberately primitive inputs and HTML or markup outputs—close to “HTML 1.0” controls. Rather than grow a conventional UI builder indefinitely, Dharmesh wants builders to describe an interface, iterate through generated code, then save the accepted result as a stable workflow action without recurring inference cost.
The hosts connect this to an underdeveloped middle ground between app generators and function-calling over premade components: generate a “Mad Libs” form, pin it, and let deep research fill it. The hosts also suggest that AI may eventually invent interaction primitives beyond checkboxes, radio buttons and dropdowns.

12. Proof of work can replace reputation in agent markets

Unlike human candidates, agents can be evaluated repeatedly before selection. Agent.ai could let a publisher offer 50 or 100 trial calls, retain an audit trail and expose usage history. Its existing agents have tens of thousands of reviews averaging about 4.1 out of five stars, though Dharmesh sees direct task evaluation as the stronger signal.
A company could generate 15–20 examples from its actual engineering issues and test AI software engineers on code and collaboration behavior, echoing paid human take-home work. The hosts’ criticism is that almost everyone endorses evaluations while “almost nobody actually does” the internal investment.
OpenAI rebuilding the GPT Store is, to Dharmesh, inevitable rather than an Agent.ai-specific fear. His rule is “don’t compete with Sam,” but Agent.ai differentiates by acting as Switzerland across providers: individual workflow steps can use different models for writing, reasoning or image generation.
Users still select the largest visible number—sometimes GPT-4.5—instead of trusting “let the system pick.” Dharmesh is testing whether thousands of identical runs plus human ratings can shift work to cheaper models with no detectable quality loss. He would buy routing rather than build it; Chai AI’s provider marketplace and DSPy’s eval-first approach illustrate the direction.

13. Results as a service has a narrower domain than the hype suggests

Dharmesh separates software as a service, where a human consumes software, from work as a service, where the software performs the task. Results as a service goes further by charging for the completed outcome rather than time, usage or work performed.
Customer support is the strongest specimen because buyers already know the rough cost of resolving a ticket. Resolution can be judged with Net Promoter Score, CSAT or a defined service level; across high-volume tier-one support, one successful ticket is often economically comparable with another.
He thinks the industry is over-indexing on that example. A logo has no equally objective finish line: five iterations or 100 may be required, the buyer may not know what they want, and “weird taste” is not under the software provider’s control. The hosts’ 99designs experience—many capable designers, no clear desired outcome—makes the limitation concrete.
Dharmesh’s 99designs tactic is to guarantee that someone will be paid, increasing participation. Where a listing might imply 30–60 submissions, the result can approach 200. Yet customers may still prefer purchasing work cheaply and retaining the delta between its cost and their eventual value rather than surrendering that arbitrage through outcome pricing.

14. Attribution remains missing while AI expands engineering’s numerator

Dharmesh says meaningful attribution barely exists because the parties holding necessary data lack incentives to expose it. Even paid-search and analytics systems provide less directly connectable information than before, frustrating any attempt to assign one result across all the contributing inputs a business might have used.
One host notes that there may be 18 contributing inputs to an outcome, making attribution difficult even before AI adds more layers.
Dharmesh predicts web3 “in the way that it was meant to be done” will return through practical primitives: verifiable audit logs, attribution and fractional digital ownership. Blockchains impose a storage or transaction tax and therefore do not fit everything, but he believes the appropriate set of use cases is limited rather than zero.
On employment, Dharmesh is bullish on engineers because the usual automation argument watches only the denominator—the growing supply of digital engineers. He expects the numerator, the total economic value and number of software-solvable problems, to grow faster. Human engineers receive better power tools and can address work that previously could not justify software.
Employment forms may still diversify. Some engineers will remain inside organizations, some will sell discrete work like freelancers, and others may build agents that earn through marketplaces. The economic unit changes without implying a one-for-one elimination of engineering value.

15. Shared memory requires permissions finer than today’s OAuth

Dharmesh calls long-term memory “the next frontier,” especially across agents. ChatGPT-style memory can retrieve past facts within one system, but a user should not have to repeat the same “knowledge nuggets” to agent two, agent N and agent N+1 when selective reuse would improve the experience.
Memory should also exist at team level: a chosen group of people and agents could share state resembling a private Slack channel without publishing it globally. The hosts connect this to Mem0, MemGPT—now Letta—Zep and LangMem, plus an emerging hierarchy of semantic, episodic and background memory in which “AI should sleep” to consolidate experience.
Authorization is the unsolved counterpart. The scheduling example requires an agent to reveal availability or shared events without exposing unrelated calendar entries. OAuth 2.0 scopes are generally too coarse and evolve at the provider’s pace, while Google and other incumbents may have little incentive to create every granular permission agents need.
Dharmesh’s own inbox contains three million emails and powers a private vector store, yet his answer to a startup requesting full access is “hell no.” A trusted intermediary could accept natural-language policies—only selected labels, only recent messages, no more than 50 per day—and release the minimum useful subset.

16. Domains, conviction and disciplined refusal compound over decades

Dharmesh bought chat.com because he initially believed ChatGPT was a demo for OpenAI’s underlying platform and that someone should build the consumer product under a friendlier name. OpenAI’s plugin launch convinced him ChatGPT was the product; unwilling to compete with Sam Altman, he offered the domain without seeking a conventional resale profit and struck a deal.
He still owns agent.com, prompt.com and scout.ai, and owns crew.ai while offering it to the company at cost. Dharmesh predicted that agent.com could ultimately be worth $30 million–$50 million and might exceed chat.com’s $15 million; he sold playground.com to Sahil’s company for equity despite having his own cross-model playground thesis.
His “cards-face-up” buying style sacrifices anonymity but establishes credibility with sellers. He is also invested in a company seeking to make domains fractional, tradeable assets with near-instant settlement and DNS transfer—an attempt to remove the escrow friction that leaves the market inefficient.
Asked what makes him a “fierce nerd,” Dharmesh cites conviction, endurance and a particular balance: willing to work harder than smarter people, but “only slightly stupider than people that are willing to work harder than me.” Competition is a game, not war; after 18 years at HubSpot and with a 19th approaching, he says he expects to remain another 18.

17. Conviction attaches to problems while tactics remain disposable

Dharmesh avoids becoming doctrinaire about products or solutions. He attaches conviction to a problem that genuinely needs solving, then shelves an implementation when technology, timing or his own ability is insufficient. As AI changes the board, he revisits the backlog and asks whether “now is the time.”
He keeps current largely through YouTube, often watching a couple of hours while coding. His average bedtime is around 2:00 a.m., but he reports seven to seven-and-a-half hours of sleep and avoids alarm clocks and morning meetings. Desired agents include extracting slides from talks and producing timestamped transcripts or combined clips.
The standout recent model for him was “Gemini Flash Experimental, whatever they call it,” because it could edit an existing image rather than simply reroll Stable Diffusion. His V1 test—replace the HubSpot logo’s O with a donut—worked semantically but failed to size the donut correctly.
A host supplied the tentative backstory: Mostafa Mostafa moved from Meta’s Lama 3 image-generation work to Gemini, and the system was rumored to use autoregressive generation rather than diffusion. The hosts see that paradigm shift reopening image generation and potentially challenging Photoshop or Canva; the account remains explicitly rumor, not confirmed architecture.

18. “Sorry, I Must Pass” protects the work that receives a yes

Dharmesh first wrote “Sorry, I Must Pass” in 2007 and updated it in 2022 as an explanation for declining requests without judging the requester or project. Every yes necessarily says no elsewhere, and Derek Sivers’s standard—either “hell yes” or no—became his default defense against an overloaded life.
He regards guilt as one of psychology’s least productive emotions. The essay lets him decline personally rather than automate the response, while making clear that a 15-minute favor, second-degree introduction or startup review still consumes capacity he has already allocated.
His operating model is aggressively asynchronous: effectively no phone calls, no one-on-one Zooms and only selected team meetings. He will spend 20 minutes writing a thoughtful answer when he controls the timing, while reserving the right to reuse anonymized insight in a model, blog post or Dharmesh.ai.
His closing advice to the AI-engineering community returns to HubSpot’s original inbound-marketing kernel: solve for the audience rather than the organization’s desire to blast a message. Money and fun are compatible with that purpose, but enduring value comes from “putting something useful in the world” and trusting a more efficient market to reward the generosity.

The AI Cold War, Signalgate, CoreWeave IPO, Tariff Endgames, El Salvador Deportations The Tech Behind Signalgate + Dwarkesh Patel's "Scaling Era" + Is A.I. Making Our Listeners Dumb?