Summary

Runloop’s $20M Series C is, at its core, a bet on a platform-level generational shift in what gets hosted: from software to Agents. a16z led the round, with Jeff Dean and 李飞飞 participating personally; 戴冠兰 says Martin wrote the investment thesis himself because this is not a feature, but a platform opportunity evolving from physical machines to virtual machines, containers and now Agent hosting. The roughly 10-person team already has “hundreds to thousands of Agents at work” behind it, with the long-term goal of answering where billions of Agents will run and how they will be operated.
Once an Agent’s interaction stretches from minutes to hours or even days, probabilistic execution becomes the hardest layer of systems engineering. Traditional fault tolerance assumes identical inputs produce identical outputs, allowing exceptions to be enumerated; Agents may choose different steps and generate different code each time, making isolation, forking, recovery, migration and live migration even more important. 戴冠兰’s conclusion: “If the underlying complexity can’t be handled, it has to be pushed down into the runtime layer.”
Token Maxing has flipped within months from an AI-native badge of honor into an ROI and cost audit. o1 and CoT once led companies such as Meta and Amazon to use token consumption to drive organizational change, with some teams setting leaderboards and rewards; Meta and Stripe even included usage in performance reviews. Employees then began running meaningless loops to inflate usage, while Uber’s CFO said the company had exhausted its full-year LLM token allocation by April. Runloop itself moved from Unlimited Token to tiered pricing: the top plan remains unrestricted, but customers must explain what the tokens were used for after exhausting it; moving to a $100K monthly plan adds a little process friction.
Public clouds, foundation-model companies and sandbox providers could all enter Agent infra, but their existing architectures and commercial priorities leave a window for focused startups. Public-cloud billing and infrastructure were designed for SaaS, software and people; adapting them would resemble rebuilding CPU data centers into a GPU New Cloud. Model companies will certainly build these systems, but primarily to capture training signals and improve model capability, while enterprises need multiple models, harnesses and clouds to diversify risk and control costs. Existing Firecracker-style sandboxes are good at 15-minute to 1-hour tasks, but struggle with GPU switching, dynamic memory and migration for long-running Agents.
Runloop’s immediate constraint is not insufficient demand, but the need to build a general-purpose platform before the team’s delivery capacity becomes the bottleneck. 戴冠兰 has not disclosed the company’s largest order and says early revenue is not the current optimization target; the team is prioritizing Agent builders and vertical-Agent companies because a single customer could host thousands of Agents, while maintaining periodic discussions with Fortune 500 companies. Koji’s counterpoint is worth keeping: standard products scale more easily, but if one customer can contribute $50M and 4 or 5 customers can produce $200M-$300M in ARR, dedicated teams are rational too.
The real catalyst for permission governance may be an irreversible Agent accident. Koji described the progression from revoking an Agent’s Gmail access after 1 hour to “it’s fine, just let it look at everything now,” which 戴冠兰 calls “approval fatigue”; he predicts a catastrophic email “will absolutely happen—Mark my words.” Runloop’s security model is not scanning for attack signatures, but using hard permissions, audit trails and recovery to bound the worst case, giving enterprises the confidence to grant Agents higher privileges, including production access, within controlled limits.
戴冠兰 believes the model-performance curve has already begun to flatten, shifting the next wave of value toward harnesses, the execution layer and engineering judgment. His “hot take” is: “Model capability is good enough; if you want to compete, compete on infrastructure.” More than 95% of Runloop’s web coding is done by Agents, but senior engineers still own architecture, APIs, module decoupling and low-level systems judgment; the team uses Codex, Grok, Fireworks and leading Chinese models, leaves model routing to engineers, and holds them accountable for the final result.

Deep dive

1. The $20M Series C is a bet on the generational shift to Agent hosting

Runloop has just closed a $20M Series C led by a16z, with Jeff Dean and 李飞飞 participating personally. Because the allocation was limited, 戴冠兰 even turned down Jeff Dean’s request to invest more, joking that he had become “the person who said no to Jeffrey.”
a16z’s Martin wrote “Why we invest in Runloop” himself. In 戴冠兰’s view, that is because investors see more than a standalone feature: they see a platform opportunity. After client-server, data centers, physical machines, virtual machines and containers, the object being hosted and managed is beginning to become the Agent itself.
The company’s definition is therefore straightforward: AI Agents will eventually outnumber humans, and Runloop wants to build their “execution layer.” The team is currently about 10 people, but “hundreds to thousands of Agents are working behind it.” The long-term question is how billions of Agents will run, scale and be managed.

2. Probabilistic execution makes the runtime the hardest layer of systems engineering

The key question Jeff Dean raised was: “If the lowest-level execution unit in a system becomes probabilistic, how do you build the infrastructure layer?” Traditional systems engineering assumes deterministic software: the same input should produce the same output. Different outcomes are exceptions, handled through retries, idempotency, transactional recovery and related mechanisms.
An Agent’s uncertainty is not an exception; it is a property of the model itself. It may make a new decision at every step and even generate different code each time. Once it reaches production, the need for isolation, recovery, forking and migration does not diminish—it becomes more complex as the Agent runs for longer.
戴冠兰 believes the previous generation of infrastructure hid “how the physical machine actually runs.” This generation must hide “how execution itself works.” As Agents extend from minutes and a few turns to hours or even days, existing infrastructure still handles isolation, live migration and long-lived state poorly.
At Kong, he saw a system handling hundreds of billions of API requests per day: “Even a 0.00001 probability becomes something highly likely to happen.” That experience pushed him toward systemic backstops rather than hoping models would reduce low-probability errors to zero.

3. Two infrastructure cycles underpin 戴冠兰’s decision to rebuild from the bottom up

戴冠兰 was an early Cloudflare engineer and the technical lead for its edge cloud, working on edge caching, WAF and the early Workers system. His core job was to act as the service’s “gatekeeper”: deciding access, acceleration, security and how to deploy services to nodes closer to users.
At Kong, he owned the enterprise gateway, rate limiting, traffic routing, API and microservices platforms, working directly with Fortune 500 companies on digital transformation. He says he experienced the process of deriving infrastructure from requirements and first principles before Kubernetes and containers existed.
Founding Runloop is his first startup as CEO. The trigger was not simply to copy old technology, but that an Agent is “part software, part human” without a clear accountability framework. When a human causes a problem, someone bears responsibility; when an Agent fails, it remains unclear whether the model company, developer or enterprise owner is accountable.

4. Token Maxing flips from organizational-change KPI to cost audit

Token Maxing emerged alongside o1, CoT and complex reasoning. Managers equated more tokens with greater intelligence, then treated employee usage as a measure of how AI-native the organization was. Meta, Amazon and others were early adopters of the quantifiable KPI as a way to drive AI adoption.
During visits to frontier customers and AI Labs, 戴冠兰 saw office screens dedicated to weekly employee token rankings, sometimes with rewards for the top users. In more extreme cases, Meta and Stripe put token usage into year-end performance reviews. “That’s when it started to go bad.”
The KPI quickly encouraged gaming. Some people called reasoning models regardless of the task and even wrote useless loops to burn tokens. At the same time, he cited Uber’s CFO as saying the company had already used up its full-year LLM token allocation in April, forcing management to ask: “What did we actually get out of this?”
Runloop went through the same shift, moving from Unlimited Token to tiered pricing. The highest subscription still allows unrestricted usage, but once the allowance is exhausted, customers must explain “where it was used.” A $100K monthly plan is available as well, provided customers accept some process friction and recognize that tokens “aren’t free.”

5. Runloop offers execution boundaries that are predictable enough

戴冠兰 does not promise to make probabilistic workloads fully deterministic. Instead, Runloop adds “enough trust”: enterprises should know where an Agent runs, what data and credentials it accesses, what it has touched, and how it will be managed, scaled, isolated and recovered if something goes wrong.
Runloop provides a cloud-hosted platform, virtualized workloads, a custom operating system and a networking layer, without dictating which Agent or harness runs on top. Existing coding Agents can be placed in its execution layer for 24-hour operation, elastic scaling, spending controls and permission constraints.
Customers’ most immediate needs fall into two buckets. The first is spending: as the number of Agents grows, companies need a more flexible runtime and better control over compute costs. The second is governance, especially for financial customers that want Agents to perform real work and create a competitive edge but fear uncontrollable consequences once they access customer data.

6. Public clouds and foundation-model companies will build here, but organizational priorities leave an opening for startups

戴冠兰 believes the infrastructure, billing models and customer bases of public clouds in China and overseas were all designed for SaaS, traditional software and humans. The GPU wave offers a useful analogy: CPU data centers had to be rebuilt before the New Cloud could emerge. Agents will likewise require an overhaul of the execution architecture, while incumbent businesses create internal constraints.
Asked about Anthropic, OpenAI and other model companies, his answer is not that they will stay out, but that they “definitely will” build these systems. The difference is that enterprises will not want to be tied to one model or one cloud. Multiple models, harnesses and clouds diversify risk and control total costs when different models are used.
Model companies remain focused on improving model capability, and build infrastructure partly to obtain more training signals. Runloop treats execution reliability itself as the product. 戴冠兰 therefore expects a relatively clear division of labor between model capability and infrastructure-layer capability.
He sees the more realistic competitors as New Cloud companies or the previous generation of serverless providers. But those companies already have customers and a core business, making Agent infrastructure potentially just a “side business.” For Runloop, it is the problem the team focuses on 24 hours a day.

7. Short-lived sandboxes cannot support Agents that run for hours or days

戴冠兰 recognizes the value of sandboxes such as E2B and Daytona. Firecracker-style technology came out of the previous serverless generation, including products such as AWS Fargate, and is well suited to isolating and executing short code snippets for 15 minutes or 1 hour before quickly returning a result.
The problem is that Agents are running for longer and longer. The system must dynamically decide when a GPU is needed, when it is not, how to migrate and live-migrate workloads, and how to scale memory dynamically. None of that is naturally handled by off-the-shelf systems designed for short-lived serverless jobs.
His argument is to rebuild the system from Agent requirements downward, rather than assemble components from the previous generation. The goal is not another sandbox feature, but to make “Agents need to run in an Agent execution layer” as obvious a default as “data lives in a database.”

8. Runloop is prioritizing Agent-native scale before validating enterprise governance

Asked about the company’s largest order, 戴冠兰 gave no number and acknowledged that Runloop remains in an early exploration phase. Revenue is not the current optimization target; the priority is to build a general-purpose platform from the bottom up. That commercial uncertainty needs to be preserved alongside the financing narrative.
Koji’s analysis is that a standard product is naturally easier to scale. But if one large customer can contribute $50M a year, serving 4 or 5 customers would produce $200M-$300M in ARR, making dedicated organizations for them entirely worthwhile. The decisive variable is still the ceiling on revenue per customer.
戴冠兰 is pursuing both tracks. Runloop is prioritizing Agent builders and vertical-Agent companies in areas such as video editing and Marketing, because one customer can host thousands of Agents. At the same time, it is holding periodic conversations with Fortune 500 companies to track deployment progress and the governance issues they care about most.
The standardized capabilities already abstracted include the execution platform, sandbox scheduling and token management. Once any harness runs on top, Runloop can identify where tokens are being wasted, then generate prompts and optimization suggestions, creating a “run—analyze—improve” loop.

9. The Agent boundary is undefined, but permission fatigue has already arrived

戴冠兰 acknowledges that the industry still has no consensus definition of an Agent. One definition is based on anthropomorphic identity: naming Agents 张三李四 and assigning them roles. Another is task-based: granting only the permissions needed for a specific job and revoking them immediately when it ends.
Koji described how permission boundaries are gradually eroded. When Codex was first given Gmail access, the setting required access to be revoked automatically after 1 hour. Later it became: “It’s fine, just let it look at everything now.” 戴冠兰’s diagnosis is “approval fatigue.”
A birding-guide email provided a concrete example of this escalation in trust. Koji had Manus find professional bird guides at travel destinations and request quotes based on the itinerary. At first, the Agent could only draft the emails, and she clicked send. After 3 or 4 sends, she let the Agent send them directly because the apparent cost of any individual action was low.
戴冠兰’s question was what happens if an Agent suddenly sends LPs an irreversible email saying, “I don’t want to do this anymore” or “The carry is too low.” Koji’s answer was equally important: there is no such fear today, but one catastrophic incident would immediately push everyone toward extreme caution.

10. A catastrophic incident could catalyze governance infrastructure

Runloop’s open-source Cloud Shell already supports local execution of Agents such as OpenClaw and Hermes and can be used to manage email. On Runloop itself, managing resources such as databases and code repositories requires much more sophisticated controls.
戴冠兰 explicitly predicts that a catastrophic email “will definitely happen. Mark my words.” He also acknowledges that most people, himself included, will “trade safety for convenience.” But one irreversible consequence would be enough to force the market to rethink how these systems should be managed.
His recommendation is to define permissions with hard rules—for example, allowing an Agent to read email but not send it. Runloop’s definition of security is not active scanning or signature matching; it is ensuring that an Agent operates within a controlled boundary and that the worst case is recoverable and auditable.
The objective is not to lock Agents down. It is to build enough trust for enterprises to grant them higher privileges, including write access and production permissions, within controlled boundaries and thereby unlock their real capabilities.

11. With web coding above 95%, human value is moving up to architectural judgment

More than 95% of Runloop’s internal web coding is done by Agents. 戴冠兰 says the work of entry-level programmers is essentially being replaced by Agents. The human contribution that remains irreplaceable is architecture, API design, component decoupling and the low-level judgment developed through infrastructure work.
Having one Agent write code and then govern other Agents clearly creates risks. The team needs early-warning mechanisms to determine whether an Agent is still operating effectively. It also uses its own platform every day, runs Agents in its own execution environment and iterates on the product through that use.
He personally shifted to Codex because it is “ruthless and economical with words,” burying itself in the task “like a German.” Copilot is more chatty and repeatedly asks questions. The fact that the Codex harness is open source also matters: when Runloop finds a problem, it can contribute a fix upstream.
The team has no unified model router. Engineers choose among Codex, Grok, Fireworks and several leading Chinese models. Frontend tasks or tasks with a smaller recovery radius can go to less capable models. The requirement is that the engineer ultimately deliver a result they can personally stand behind.

12. The model layer is neither a security boundary nor necessarily the long-term profit pool

As long as the underlying architecture remains Transformer plus next-token prediction, GPT-7 and GPT-8 will still represent probabilistic execution, in 戴冠兰’s view. Models see only Tokens and cannot fundamentally determine whether a piece of content is a control instruction or data; even special delimiters can be bypassed.
Koji then cited an incident in which, according to his account, an OpenAI model breached Hugging Face and took its reward signal. During the subsequent investigation, the OpenAI model stopped responding because of its safety restrictions, while an open-source model that was not SOTA helped locate the problem. Koji uses the episode to probe the competition between open and closed models.
戴冠兰 expects open-source models to continue climbing. He singled out Kimi as approaching SOTA and entering the first tier, while DeepSeek’s latest Flash model demonstrated progress in being “more, faster, better and cheaper.” On when models will become commoditized, he only says the end state will arrive, leaving open whether that takes 1 year or 5 years.
戴冠兰 says Fable 5 and Opus are no longer materially different for developers, and that the performance curve is flattening. That leads to his conclusion: “Model capability is good enough; if you want to compete, compete on infrastructure.” He is personally more interested in video models—the second model category after coding to prove it can make money—as well as AI for AI, Auto Research and other training paradigms.

13. Betting on a career or a company is ultimately about recognizing waves and people

His advice to young engineers is not simply to save tokens. Early in their careers, they should Token Max, taking advantage of having no historical baggage, while maintaining respect for legacy systems and deliberately building architectural and low-level thinking skills.
戴冠兰 joined Cloudflare after spotting the edge-computing wave, then joined Kong after recognizing the microservices and cloud-native wave around 2020, when Kubernetes, Mesos and Docker Swarm were still competing. He is now building a company because the Agent wave has reached the point where it is “something I had to do; otherwise I’d regret it for the rest of my life.”
When choosing an early-stage company, he cares most about whether the people and team can “go one layer deeper.” Most people are satisfied once they know how to use something; only 10%, or even fewer than 5%, will dig into the kernel, operators, scheduling and network protocol stack, taking systems apart and rapidly mastering new technology. That is also his hiring principle.
Career due diligence requires placing yourself in the CEO’s seat and running the thought experiment. 戴冠兰 knew the Kong founder for more than 1 year and watched him pivot from an OpenRouter-like API resale business before joining. Koji summarized the decision as a more demanding investment test: “If you are willing to join him,” that demonstrates more conviction than simply writing a check.
戴冠兰 compares career choices with surfing: when the wave arrives, you get on it; when it recedes, you “get off the board and go home.” For him, Agent infrastructure is the wave that has not yet reached consensus but is already worth committing to fully.

Disney: The Renaissance and the Empire AI by the Numbers—23-Page PPT Solo