The Agent Network — Dharmesh Shah — Part 1 of 3

Queue the intention, let software do the work

Before HubSpot, Dharmesh Shah imagined processing business cards on a plane without internet access. He would type requests into emails and let them queue. After reconnection, a processor would recognize a limited set of commands, update business software, or return a file. His contemplated company, Ingenisoft, would make natural language the interface to that work.

That example establishes the ambition behind the conversation: express an intention and set work in motion. Shah argues that conventional interfaces require users to translate their intentions into clicks, touches, and swipes. He later revisited the idea with ChatSpot, which became a HubSpot project.

Even in the ChatGPT 3.5 era, Shah found that providing a few examples could produce reasonably useful conversions from natural language into structured text—when the expected intents were known. Agents extended that ambition beyond a synchronous chat exchange: software could perform several steps toward a goal.

Agents: goals, workflows, and composable units

Shah defines an agent as AI-powered software that accomplishes a goal. He accepts the criticism, including from his own team, that this definition is too broad. More specific classifications describe overlapping dimensions: - Autonomy: autonomous or non-autonomous operation. - Workflow: a predetermined sequence or a non-deterministic path. - Timing: synchronous exchanges or asynchronous work. - Interaction: conversation, such as customer support, or execution of discrete workflow steps.

Swyx favors describing how people use the term over prescribing one definition. He identifies goal accomplishment as Shah’s criterion, alongside alternatives emphasizing delegated trust, non-deterministic work, or a large language model in the loop. Shah’s practical test is solving a discrete problem with baseline repeatability or verifiability. In his assessment, early BabyAGI, AutoGPT, and AutoGen implementations assumed reasoning and execution-planning capabilities that were not yet available.

The proposed explanation for agents becoming practical combines stronger models, more reliable tool use, better tooling, faster inference, falling costs, changing business models, multi-agent research, and reinforcement-learning fine-tuning. Model diversity offers another possibility: switching models may bring a different approach when one reaches its limits.

The definition then extends to an atomic agent: the simplest unit that still qualifies, analogous to a single-celled organism. If tools could be treated as atomic agents, tool use would become delegation within a network. A system would decompose a problem, discover suitable capabilities, and hand off pieces of the work. A common primitive could make increasingly complex goals easier to express through composition.

The boundary remains unresolved: a tool need not be an agent. If an agent must use AI, a database query or ordinary API call does not necessarily qualify. The proposal explicitly stops short of renaming every function. Its appeal is composability, supporting a forecast that multi-agent networks will follow individual agents; the episode introduction places that prediction in 2026.

Knowledge graphs: context, ranking, and traversal

The network analogy first becomes personal. Memory devices, including a Limitless pendant, illustrate the desire to extend human memory into machines. Creative work is described as collecting people, experiences, and ideas, then connecting them in ways that were difficult to predict. From there, the discussion turns to graphs as knowledge stores.

Graphs represent structure through connected nodes without requiring a table-and-column organization. Their attraction for retrieval is that top semantic matches can miss the broader picture. Splitting documents into chunks and retrieving the closest matches may omit useful relationships or dimensions. Feeding graph-based knowledge into a RAG workflow might improve some use cases. This remains an intuition, not a demonstrated result.

Graph relationships also offer human inspectability compared with information encoded in vector embeddings. NodeRank is proposed as a project applying PageRank-like ranking to arbitrary graphs, with a configurable definition of authority. A knowledge store might rank contributions by their author’s authority for a particular prompt or use case, or use popularity as a separate signal.

The objection is that modeling everything as a graph can produce something too complex to navigate. Asked whether HubSpot uses a knowledge graph, the respondent says no. The pragmatic defense accepts some opacity: an organically growing graph might behave like lossy compression and still justify itself through useful query results.

That leaves two practical distinctions: - Evaluation costs matter. Comparing alternatives takes time and people; small evaluations may miss benefits that emerge only at scale. - Representation is not efficient traversal. Parent-child tables in Postgres or MySQL can represent a graph and may be sufficient. A dedicated graph implementation becomes attractive when following those relationships through relational queries is too costly to be useful.

Build for likely change; defer speculative abstractions

The graph debate leads to a general engineering rule: choose the better implementation when its extra cost is marginal. Larger investments in frameworks and reusable libraries require expected-value reasoning. Identify the dimensions likely to change, estimate the probability of those changes, and compare the extra work now with the future benefit.

Under uncertainty, the respondent prefers under-engineering. Technical debt can often be repaid at a reasonably foreseeable cost; preparation for a use case that never arrives consumes time permanently. A hypothetical shortcut that turns a later one-week change into four weeks illustrates the accepted downside. If the need never appears, the initial savings remain available for other work.

AI strengthens this argument if refactoring becomes substantially cheaper. One speaker forecasts that large codebases will fit into generation or refactoring context and that correction costs will trend toward zero. Another reports asking Cursor to add autosave to an internal notes platform without explicitly deciding how much engineering the feature warranted.

Cheaper implementation creates two different risks: - Product complexity still costs users. Teams may add features less selectively when development becomes cheap. Limited engineering hours previously constrained expansion. - Generated complexity needs human judgment. Models may introduce abstractions without accounting for their future consequences. A proposed workflow boundary would require the model to ask before adding more complexity.

Engineering value beyond producing code

Code generation has progressed in the discussion’s account from completion to functions and then applications, with Lovable, Bolt, and Replit Agent as application-generation examples. Generating whole platforms—including APIs and interfaces—and eventually software companies with monetization and go-to-market plans is presented as a possible further progression.

That does not imply the disappearance of junior engineers. The respondent argues that engineering knowledge remains valuable alongside communication and customer understanding. Working with product teams and talking to customers broadens a contribution beyond coding alone. A 14-year-old’s Python class supplies the personal example: its enduring value is learning systems thinking, abstractions, and functions.

Another participant questions whether LeetCode-centered interviews and traditional career paths will persist as effective collaboration with AI becomes more important. AI engineering is framed as the intersection of generative model capabilities, an emerging body of practical knowledge, and conventional software engineering—potentially developing into its own discipline.

MCP: discover capabilities before delegating

A concrete tool example brings the discussion to MCP, a standard used here to connect clients with capabilities exposed by servers. One participant uses Sentry’s MCP integration to bring error information into Cursor. That convenience prompts a transparency question: how does the server repackage information before presenting it as context? The respondent has not used the integration and addresses the standard’s broader merits.

The defense of MCP centers on useful capability with manageable implementation complexity. A reasonable engineer can stand up a server relatively easily. Agent collaboration also needs discovery: systems must learn what other systems can do before delegating work. That motivates registries and standardized directories; Anthropic is described as working on a registry at the time.

The architectural promise is decoupling capability providers from consumers, including future clients beyond chat-oriented applications. Challenged on what MCP adds beyond OpenAPI, the respondent distinguishes OpenAPI’s structured, machine-readable API descriptions from MCP’s more targeted fit for language-model discovery.

Adoption is offered as evidence of usefulness, rather than a measured technical comparison. The respondent allows that another standard could replace MCP or that OpenAPI might prove sufficient. The broader preference is to compose existing technologies and consume standards: creating one also requires the credibility to persuade others to adopt it.

Personal data should be available to personal agents

An unrealized idea for standardized marketing data leads to a proposed Open Graph concept for person-controlled data. People would opt into publishing their social or professional information through a retrievable JSON resource. Others could propose updates, subject to the person’s approval. The proposed effort would be public-benefit or nonprofit, without commercialization.

Another participant recommends At Proto, identified as the protocol behind Blue Sky, and recounts a Dan Abramov talk about personal data ownership through an inversion of handles and domains. The practical connection is agent access: people should be able to automate retrieval of their data and connect it to their workflows.

The adoption challenge is getting ordinary users to care. The response treats privacy as a choice about particular data and benefits: someone may willingly share information for a productivity gain, but that decision should remain theirs.

A reported internal workflow illustrates the benefit: people export LinkedIn connections and merge the exports to find paths between companies and potential customers. Computer-use automation is suggested for some exports, though it is not described as part of that existing workflow. The access debate distinguishes two cases: - Public scraping: collecting publicly available data without having agreed to account terms. - Logged-in automation: using an account whose terms, a participant argues, can be enforced through account closure. The argument for controlled access on members’ behalf seeks a middle ground between privacy protection and blanket blocking.

Agent.ai: discover specialists and compose their work

Agent.ai is positioned as a professional network for agents. Its underlying forecast is that people will delegate specialized tasks to software teammates through interfaces such as Slack or Teams. Agents should disclose that they are software. Structured profiles would help people discover capabilities and assemble teams of humans and agents.

The envisioned network includes profiles, connections, follows, and agent posts such as release announcements. Agent.ai expanded into a low-code builder because its creator wanted thousands of useful agents to populate that network. At the time of the conversation, it reportedly had 1.3 million users, about 3,000 agent builders, and roughly 1,000 published agents. Some builders created agents only for personal productivity.

An MCP server already exposed Agent.ai’s internally built agents. The platform also offered services such as Twitter API access and proxied model access through one API key. Access was free at the time because the speaker was funding it.

A domain-valuation agent demonstrates the specialist model. It finds published domain transactions with comparable words or top-level domains, then returns an approximate value, its rationale, and supporting transactions. The valuation remains a heuristic estimate.

A hypothetical startup-branding agent could reuse that specialist in a larger procedure: 1. Generate candidate startup names. 2. Find corresponding domains and asking prices. 3. Call the valuation agent to compare those prices with estimated values. The example imagines a domain estimated at $25,000 but listed for $5,000; it is a composition scenario, not a verified buying opportunity. The envisioned network would make thousands of such specialists discoverable, with reasoning models helping orchestrate their work.

At that scale, tool selection becomes a retrieval problem. An intermediate layer could use the prompt to select likely useful agents instead of presenting a thousand capabilities directly to a language model. The participants call this “RAG for tools”: retrieve relevant capabilities before choosing what to invoke.

A smaller example brings composition back to everyday work. One participant has built a Latent Space researcher on Agent.ai and imagines adding a scheduler as another component. The researcher exists; the scheduler is prospective.

Known steps, queued work

The closing discussion asks why Agent.ai’s builder uses a low-code sequence of static and variable-driven steps. The original choice was partly historical: reasoning models were not available at the time. It also reflects a design principle: when the steps are already known, letting a model choose them adds uncertainty without an upside. Deterministic execution preserves the procedure the builder already knows will accomplish the goal.

Part 1 ends by turning from execution to interaction. Agent interfaces need more attention, including ways to queue work without a continuous conversation. The coworker analogy begins: asking someone to perform a task need not mean sitting beside them while they work. The thought returns to the early email interface—express the request, then let the work proceed.