The Quest for Autonomous Web Agents with Div Garg, Cofounder and CEO of MultiOn
Summary
MultiOn’s core claim is that agents are stalled by reasoning and grounding, not conversational fluency. Div G says GPT-4 can produce “seemingly good content” while “the actual deep work is not there”; websites are dynamic environments models were not trained to represent, so small mistakes compound across long trajectories. The discussion points toward execution data, environment-specific feedback and verification as important layers beyond chat.
The proposed path from 90–95% reliability toward nearly 100% is a fine-tuned base plus online reinforcement learning, not RL from scratch. Div G argues sparse-reward RL historically failed because agents began near zero; pretrained models now supply broad knowledge, while supervised tuning can create a roughly 90% starting point from which agents “explore and exploit the environment.” MultiOn was exploring DPO, imitation learning and live-internet experiments on reversible tasks, with explicit care not to “take down the internet.”
Commercialization can start before general agency because short, single-site workflows already form a usable wedge. Amazon cart assembly, DoorDash and Instacart orders, NDAs and meeting invitations were cited as current strengths; cross-site state transfer, recurring jobs and long tasks remain harder. At the time, Div G expected MultiOn could soon choose one task and execute it with “a crazy amount of accuracy,” pursuing adoption and research in parallel.
MultiOn optimizes for product economics alongside task completion: at least 10× human speed, compact context and cents-per-step inference. A simple task might require fewer than 20 steps and research around 100; Div G put the upper bound near $0.10 per step, with efficient hosted models nearer $0.02–$0.03 and a 100-step job potentially below $2–$3. Its average inference input was “not more than 5,000 tokens,” making compression, caching and model routing central margin levers.
The stack is deliberately model-agnostic because GPT-4 remained best for planning but too expensive to anchor a mass-market consumer product. MultiOn mixed fine-tuned open-source models with GPT-4, benchmarked alternatives “plug and play,” and designed its efficiency work to survive a GPT-5 capability jump. Div G attributed GPT-4’s edge to “the quality of the ingredients and the chefs”: experienced researchers, private data and a large human-labeling pipeline.
The roadmap moves from one-off actions to long jobs, composition, recurrence and eventually a hidden hierarchy of parallel agents. A user may see one chat surface while an internal scheduler distributes work across subagents, borrowing operating-system concepts such as processes, priorities and failure handling; a Voyager-style skills library would cache reusable procedures. Mobile access and authentication without storing the user’s password aim to deliver “what Siri could never be,” while the API is positioned as a natural-language abstraction over Playwright-like automation.
The labor thesis is augmentation first and substitution later, but trust may become the binding constraint on adoption. Div G expects agents to remove “digital chores” and “shitty jobs” as computers displaced typewriter work while creating new roles in teaching, programming and coordinating agents; near-term value comes from taking users from “zero to one” access to assistance. Nathan warned that malicious calling and capability jumps could create systemic risk, while Div G recommended moderation, execution-time verification, prompt-injection defenses and rapid behavior patches.
Deep dive
1. GPT-4’s fluency concealed an execution deficit
Nathan dated the conversation to January 2024, “GPT-4 plus 10 months”: agent enthusiasm had passed through a “trough of disillusionment,” but MultiOn kept iterating publicly. He described an example in which he asked MultiOn to read his last 10 tweets, find related news online and make more tweets; the task involved many steps, and he said he might soon check the performance of MultiOn-posted tweets.
Div G’s diagnosis was blunt: GPT-4 could sustain good chat and sometimes write code, but it was “really good at hiding logical mistakes.” Like an impressive paper whose mathematics collapses under inspection, the model generated “seemingly good content, but the actual deep work is not there.”
Nathan’s pushback — worth keeping — was that coding looked considerably better from his seat. When given an existing example and a target, GPT-4’s “coding by analogy” produced a major speedup; debugging remained necessary, but it did not consume all the saved time.
That disagreement sharpened the distinction: isolated transformations can work well, while reaching checkout through a changing website demands persistent state, planning and recovery. The agent’s weakness is not merely one bad prediction; it is maintaining coherent execution across many dependent decisions.
2. Grounding and feedback could close the last reliability gap
Div G argued that current models were never directly trained to represent the worlds in which agents operate—whether code, APIs or websites—so they are “not grounded in this environment.” Even humans confronting a new interface hunt through drawers, hidden dropdowns and navigation bars; he still found AWS confusing after visiting it “more than a thousand times.”
Humans compensate through rapid reinforcement learning: they try an action, fail or succeed, retain the experience and adapt. Div G’s proposed route from roughly 90–95% performance toward something “really, really close to 100%” was to let agents discover and optimize the techniques that work in each environment.
The live internet could itself become the training environment. Research and information gathering are reversible, while shopping or messaging tasks can be halted before the final order or send; this creates feedback without completing consequential actions. The caveat was explicit: MultiOn did not want uncontrolled online training to “somehow take down the internet.”
RL alone was not the answer. Div G said a model first needs fine-tuning good enough to reach perhaps 90%; starting RL from zero is too unstable and produces too few successes. MultiOn was exploring DPO and imitation learning, including work with DPO’s first author and academic collaborators, to combine pretrained knowledge, demonstrations and trajectory feedback.
3. Adoption and agent research can advance together
Div G rejected a choice between spending 2024 on research and competing for users. General agents have “an infinite amount of things they can do,” leaving enough low-hanging fruit to create everyday value while the company works on harder, longer and more compositional tasks.
His near-term benchmark was deliberately narrow: choose one task—“it could be any task”—and perform it with “a crazy amount of accuracy.” At the time, he expected MultiOn to reach that point by the end of the month, even though solving agents as a general category would take much longer.
The research unit should be the process, not merely the next token or next state. Div G described “action Transformers,” new loss functions and potentially backpropagating over an entire trajectory so that the generated process is optimized against the right execution for a particular environment.
That requires a “new breed of researchers” willing to move beyond supervised learning and think in trajectories, exploration and exploitation. His distinction was categorical but scoped: RL might not help language-model chat very much, yet could help agents substantially because execution is intrinsically a long learning process.
4. Short, single-site tasks are the initial product wedge
Nathan identified the onboarding problem: asking an agent to search Google adds little value, but ambitious branching workflows often fail. Because MultiOn’s frontier changed with each release, users also struggled to know what was currently reasonable to delegate.
Div G’s calibration was a “single website” and a short “to-do” task. He cited finding five books on Amazon and putting them in a cart, ordering through DoorDash, assembling ingredients on Instacart, sending an NDA, or booking a 2 p.m. meeting and inviting a specified person; cart assembly and checkout could already work well.
Composition was the next frontier: inspect a calendar event and call an Uber if it is in person, or find target profiles on LinkedIn and continue outreach through Gmail. Moving context between sites makes those flows harder; after that come scheduled instructions such as “order coffee every day in the morning.”
5. More context can reduce intelligence unless the agent manages memory
Div G had repeatedly seen GPT-4 and Claude lose focus when prompts accumulated unrelated material. Stuffing in user notes and historical context could impair logical decision-making; minimizing the context often made action selection noticeably better.
His conclusion was that context management was “one of the biggest levers” available with current models. MultiOn combined retrieval and external memory while trying to keep both prompts and latency small, rather than treating the advertised context window as an invitation to include everything.
Memory itself became part of the action space. Alongside clicking and typing, the model could decide to store current content or retrieve a specific item before continuing—“almost like a CPU” managing its own memory instead of passively receiving an ever-growing transcript.
That architecture supported the visibly longer tasks Nathan had tested, but Div G did not claim that raw context capacity solved reasoning. The important capability was deciding what information deserved attention at each inference step and discarding noise without losing task state.
6. Efficiency work is intended to survive GPT-5
Nathan invoked Sam Altman’s advice to a Y Combinator batch that founders should plan for GPT-5 or early AGI. His challenge was whether elaborate retrieval, delegation and memory scaffolding would become unnecessary if a new model handled long context cheaply and without confusion.
Div G’s answer was that “efficiency will always matter.” A representation that maximizes useful information and removes noise should remain valuable even if the underlying model becomes 10× better; competitors may neglect that layer once stronger foundation models make brute force easier.
MultiOn projected possible gains separately across context length, reasoning and speed—even considering the unlikely case of a 10× improvement on every axis. Its architecture could then substitute models rather than restart: fine-tuned open-source systems handled much of execution, GPT-4 still supported planning, and prompts trained in a GPT-4-like format preserved useful backward compatibility.
7. Dynamic websites make manual evaluation unavoidable
A web benchmark decays as sites change, which made a single standardized score unreliable. MultiOn maintained multiple scenarios, but Div G treated actual end-to-end behavior as the final measure: “Can you actually have it call an Uber?” or deliver a burger to the correct home?
Nathan strongly agreed that there was “no substitute” for remaining hands-on—reading raw logs and watching an agent work. The behaviors were too strange, and the environment too variable, for a tidy automated metric to expose every important failure.
Automated evaluations still covered information gathering and constrained shopping tasks. An instruction might specify shoe type and size or a complicated DoorDash order; another model would compare the resulting cart with the expected final state, regardless of the exact path taken.
The optimization target was broader than benchmark success because “we want it to be a product, not research.” MultiOn wanted a task done at least as well as a person but “at least 10x human speed”; Div G argued compression created a positive cycle, improving latency while also reducing the distractions that hurt accuracy.
8. Vision helps compression but does not close the action loop
Nathan saw screenshots as a major win over bloated, autogenerated HTML: he noted that a low-resolution GPT-4V image cost about 85 tokens, potentially an order of magnitude less than textual page markup, while presenting the interface in the form intended for human interpretation.
Div G agreed that vision was useful but said it “doesn’t close the loop.” Recognizing that an item belongs in a cart is different from locating the cart’s pixel coordinates and controlling a mouse; present vision models still needed segmentation or captioning that mapped useful elements into an executable coordinate space.
MultiOn therefore mixed images with language. HTML contributed metadata and enrichment that pixels alone omitted, while visual representations compressed layout; Div G said the average input at an inference step was “not more than 5,000 tokens.”
A simple workflow might consume fewer than 20 steps, while research could reach about 100. Div G put cost below $0.10 per step at the high end and nearer $0.02–$0.03 with efficient hosted models, potentially bringing 100 steps below $2–$3; caching, dedicated capacity and reusable skills offered further reductions.
9. GPT-4’s edge came from data operations as much as architecture
Nathan noted that GPT-4 remained roughly seven or eight MMLU points ahead of its nearest competitor and was still the common choice for planning. Div G’s analogy was baking: the result depended on “the quality of the ingredients and the chefs,” and OpenAI had unusually experienced model trainers.
The other ingredient was private, carefully filtered data. Div G described large pipelines of human labelers and testers converting expertise into training material: models are “a distillation of human knowledge,” so scaling quality requires collecting that knowledge while removing noise, not merely scraping more open-source text.
MultiOn nevertheless felt it had “saturated GPT-4 as much as we can,” leaving better models or fine-tuning as the next step. Keerthana expected an open-source model close to GPT-4 during that year, while Div G emphasized that GPT-4’s API economics—especially vision—were already difficult for a consumer product serving millions.
10. Longer reasoning may require new sequence architectures
Div G regarded attention’s quadratic cost in token length as a fundamental constraint. He argued that almost nobody used GPT-4 Turbo’s full 128K context in the way one might expect because the model became poor at that scale; making it work required tricks and approximations rather than full attention.
Architectures such as Mamba interested him because linear or subquadratic scaling could preserve attention over longer sequences. His most expansive example was biology: DNA sequences can span billions of tokens, perhaps even a trillion if representing the whole human genome, and better context efficiency could unlock models that reason over those structures.
Nathan proposed diffusion-style planning as an alternative to beginning-to-end token generation: first sketch the program or task, then fill in detail. Div G embraced the analogy—a five- or ten-step rough plan could become a refinement tree, with each pass translating abstractions into progressively more granular execution.
Voyager-style reuse addressed another dimension. MultiOn planned its own skills system and library so procedures discovered once could be recalled rather than regenerated daily, reducing inference, stabilizing execution and making repeated web tasks more cacheable despite gradual interface changes.
11. A reliable executor must precede a hierarchy of agents
Div G envisioned a top-level agent coordinating multiple subagents, which could themselves manage lower-level workers. Each agent would hold a narrower context while task specifications became more detailed down the hierarchy, allowing parallelism without forcing one model to carry the complete execution state.
Nathan had attempted recursive self-delegation while red-teaming GPT-4, tracking the original goal and its cascading subgoals. It “kind of” worked but not reliably; prompts became variable, token costs rose quickly and caching offered little relief.
Div G’s sequencing was execution first. If subagents fail half the time, the orchestrator spends its effort recreating and redelegating jobs; only after one agent becomes a dependable execution engine does parallel orchestration produce a net gain.
For later in the year, he pictured an internal MultiOn scheduler assigning and prioritizing tasks, handling failures and borrowing abstractions from operating-system kernels, threads and processes. The complexity would remain invisible: users would see one chat interface while “a bunch of agents” coordinated underneath.
12. Mobile access turns the agent from browser feature into assistant
The product roadmap ran from single short tasks to single long tasks, then combined tasks, recurring work and parallel execution. Div G wanted to release the less complex layers while continuing the research needed for the harder ones, rather than holding everything for a general-agent reveal.
Mobile was crucial because delegation should not require opening a laptop. Div G said he already had MultiOn using his LinkedIn account from a phone and sending connection requests without storing or knowing his LinkedIn password; the authentication mechanism had been validated for months but was not yet disclosed.
The desired interaction was “what Siri could never be”: speak a request while walking around, then have the purchase, invitation or connection happen seamlessly. Nathan’s imagined payoff was more time away from the computer and no backlog of small tasks waiting to be remembered later.
The API extended the same mechanism to businesses. MultiOn could return gathered information in a specified JSON schema or take website actions, serving as a “no-code abstraction” around automation or Playwright: provide an English instruction, and the system determines the browsing flow for tasks such as returning structured page information or unsubscribing users.
13. Labor substitution begins with unwanted digital chores
Executive assistants were natural early adopters because they already understood the workflows and did not need persuasion about their value. Div G nevertheless framed the near-term system as a complement: it would handle work people dislike or do poorly, while professional assistance could still remain complementary.
The immediate market included people who could not afford an assistant, taking them from “zero to one,” not merely making existing help cheaper. Nathan framed 2024 as complement and 2025-plus as possible substitution; Div G said full replacement of professional help might take longer and remained uncertain.
Div G’s typewriter analogy carried the labor thesis: many roles exist because “the technology is not there” and humans fill the resulting digital burden. Computers eliminated typewriter operation but created more jobs; agents could similarly remove “shitty jobs” and “digital chores” while changing rather than simply shrinking the labor market.
He expected new work in managing, improving, teaching and programming agents, just as computers created programmers. Demonstration data should be relatively easy to source because browser use requires little specialized training; MultiOn could record ordinary task completion while balancing its own data investment against improving foundation models.
14. Privacy and reputation shape the route to market
MultiOn did not intend to train directly on ordinary users’ authenticated accounts. Div G worried about cross-contaminating personal information—citing Gmail autocomplete as the kind of leakage to avoid—so the safer mix was public data, internal mechanisms and explicit testers or volunteers working on an experimental basis.
The business model was still guarded. Div G disclosed active API partnerships and contemplated a premium consumer version with a Pro subscription, but withheld specifics because the agent market was becoming competitive.
Website operators had barely begun adapting; outside Bay Area circles, Div G believed many people still did not know what agents could do. Yet businesses were already asking MultiOn about marketing, outreach, onboarding and automating poor CRM interfaces, suggesting initial demand was oriented toward reducing friction rather than blocking bots.
Reputation could eventually determine access. Div G wanted sites to recognize a MultiOn agent and conclude that “it’s fine” to admit it, while distrusting unknown agents; that required being seen as a responsible actor before phishing, spam, an “AI virus” or another high-profile failure shifted the ecosystem toward defensive restrictions.
15. Capability jumps make agent safety a system-design problem
Nathan’s warning came from an AI calling product that accepted an instruction to make a fake ransom demand, claim it held his child and request $1 million, with “zero guardrails.” His concern was a threshold effect: one model upgrade could abruptly turn unreliable demonstrations into scalable abuse, forcing the entire ecosystem into a new defensive equilibrium.
MultiOn had already built prompt-injection detectors, classifiers, site-specific behavior controls and mechanisms for rapidly patching harmful actions. Div G also recommended putting a moderation model in every production chain—even OpenAI’s inexpensive public moderation API—and adding explicit prompt instructions against harmful behavior.
Nathan’s pushback was that OpenAI’s moderation endpoint had failed to flag his overt criminal spear-phishing prompt, while adversarial-prompt contests showed that clever attackers could bypass simple instructions. Div G’s stronger answer was execution-time verification: inspect proposed browser actions after generation but before performing them, using another model or dedicated logic to reject unsafe or incorrect behavior.
Websites may also attack agents—Nathan imagined a page instructing MultiOn to “Venmo me $99” before submitting a form. Against that backdrop, Div G still saw planning and logical deduction as the larger capability gap: models can imitate conversation and fool average users, but cannot reliably play chess, solve complex puzzles or debate an expert because they have learned “the shallow parts” without the “deep work.”