LLMs require massive datasets because language is so varied and context-specific. Coding agents have to navigate the individual quirks of how engineers build software. Autonomous cars must learn to anticipate human errors and driving patterns.

That’s why synthetic environments only get you so far in fine-tuning LLMs. When human behavior is a key variable in the system, it’s hard to simulate reality.

Robotics is different. The hardest problems are not about humans but about physics. How a leg balances against gravity, a hand grips a wire cable, a body recovers from a stumble.

Unlike human behavior, physics is dictated by laws. Gravity, friction, and momentum can all be modeled and derived from equations.

That invariance is why simulated environments can go much further in training robots than in training LLMs.

Nikita Rudin is building a company off this insight.

Nikita is the CEO and co-founder at Flexion, a young startup building AI software for humanoid1 robots. His team is developing a general-purpose “brain” that can be fine-tuned and customized in simulated environments, then deployed into various different robot types across their customer network.

Before Flexion, Nikita and his co-founder David received their PhDs in robotics at ETH Zurich and worked together at NVIDIA.

Nikita also co-authored the original Isaac Gym2 paper, the breakthrough research from NVIDIA that established GPU-accelerated simulation3 as a viable way to train robots at scale.

Nikita and I talked about how robots are being built today, his thoughts on how the market will mature, and why the underlying tools in robotics are advancing so quickly.

He has a plasticity in his thinking that I love seeing in founders. Technical depth paired with creativity. A clear point of view earned by real experience, but held with genuine curiosity.

He even offered a prediction for when we will start to see lots more robots in the wild. (Sorry Melania, the robots are not here – at least not yet!)

01 | Days versus years

EO: You’ve been in robotics a while, before all the current hype. I’d love to hear your story and how that connects to the thesis behind Flexion.

NR: I was doing my PhD at ETH Zurich in reinforcement learning (RL) for robotics and also working part-time at NVIDIA. This was before AI took off, back when NVIDIA’s GPUs were mostly powering video games.

At NVIDIA, my co-founder David and I were on the team building Isaac Gym, Isaac Sim, and Isaac Lab.4 These are NVIDIA’s open-source simulation tools, which have since become foundational in the field of robotics learning.

During this time, we saw how fast the technology was moving.

In 2020, getting a quadruped, a four-legged robot, to take a few steps without falling was a big deal. By 2024, the same quadruped could jump and climb through collapsed buildings and piles of gravel, terrain I’d struggle to walk across myself.

Impressive, in four years…

The progress was amazing.

Over time, I got involved in some humanoid projects. If you remember Jensen’s NVIDIA keynote two years ago, where he first showcased robots on stage, David and I were heavily involved in everything shown then.

Working on humanoids taught us two things.

First, the same RL approach works across different robot form factors, whether you’re working with a quadruped or humanoid.

Second, and more importantly, policies5 learned on one robot transfer to others very efficiently.

What makes that transfer so efficient? I’d assume, incorrectly it sounds like, that in robotics, hardware and software are coupled too tightly for this methodology to transfer so easily.

Here’s how our pipeline works.

Each robot enters our digital simulation environment as a spec file, describing the hardware and its kinematics6 in a standardized format.

Inside the simulation, we train the robot’s control policy7 with reinforcement learning. The robot attempts a task many times, gets rewarded for progress, and the neural network gradually learns how to control the body.

Once trained, we deploy the policy to the physical robot, where it sends commands to the motors to navigate the real world.

So essentially, you’re feeding the simulator a description of the body, training the brain in a simulated environment to operate that body, and then dropping the brain into a physical system.

That’s right. And because the initial spec files are standardized, plugging in a new robot form is relatively straightforward. Also, everything around training the “brain” – the simulator, the general RL methods, our pipelines – is reusable.

The motor interfaces, which let us deploy a trained policy back into a robot, aren’t fully standardized across the industry yet. But they’re close enough that we can usually deploy without much friction.

In other words, the standards and system boundaries in robotics are pretty well defined. And that lets us deploy our training methods across many different robot types.

So you were observing the generality and scalability of these methods. What gave you that extra kick to start something from scratch?

Very quickly, we saw that we could run our software on other people’s robots, sometimes without ever seeing those robots in-person. And we could often do so more efficiently than their internal teams.

That gave us the conviction to build a company around this approach.

Can you quantify how much more efficiently?

Days versus years.

Okay, well that’s a compelling reason to start something!

Yeah. We developed this belief that simulation together with reinforcement learning should be used as much as possible.

I finished my PhD, we left NVIDIA, and started Flexion.

Give us a snapshot of the company today. Where are you in the R&D cycle?

We’re just a little over a year old. We have 45 people in Zurich, and just opened our SF office. We have multiple customers. Some are robotics companies integrating our software. Some are big industrial players deploying robots in their factories and warehouses.

I’d say we are as deployed as it gets in robotics, which, to be honest, is still very early.

02 | Becoming Android for robotics

One assumption behind Flexion is you can be competitive as the “Android for robotics” – a horizontal, hardware-agnostic system that can be trained to run on any humanoid.

A lot of smart people are making the opposite bet. Tesla and Figure, for example, are both vertically integrated. Do you think they’re missing something?

I don’t think they’re wrong. Vertical integration lets you control your own destiny. But only if you can do it more efficiently than partnering.

The market will probably support one, maybe two, vertical players. Tesla will probably be one of them.

But beyond that, you’ll have a huge ecosystem of others that will own their section of the supply chain. Because combining hardware and software, being excellent at every part of the stack, and then scaling it to thousands of robots, is extremely hard. Being world-class in one part of the chain is easier.

The self-driving car market is a good analog. Early on, everyone was vertically integrated. Most died. A few big companies survived. And now, traditional OEMs are increasingly buying third-party software from companies like Wayve and Mobileye to power their vehicles.

We’re seeing the same thing in robotics. Everyone started wanting to be vertically integrated. Now the ecosystem is shifting away from that.

That’s what our customers are doing. And you see companies like Boston Dynamics and Apptronik now partnering with DeepMind.

It makes sense. Otherwise, everyone has to relearn the same hard lessons of building AI software for robots from scratch.

I see. So unless you have extraordinary scale and capital, it’s too hard to own everything.

Absolutely. I think vertical integration is a story investors like to hear. Because it’s easy to envision the moat. But technically, in the majority of cases, it makes more sense to go horizontal.

Let’s assume, for a second, you have unlimited capital. Is there a technical case for why vertical integration will usually underperform?

Well, talent is still a limited resource. There are maybe 200 people in the world that can do this kind of work. Throwing money at it will not solve the problem.

It rarely does. But fair – let’s assume unlimited resources. Capital, talent, time.

I’m trying to isolate if there’s a technical rationale for this horizontal strategy. An edge you, your suppliers, and your customers have that vertical players can’t recreate.

Technically speaking, the limiting factor in robotics is data, and specifically, a diversity of data. You need to constantly collect new types of data and train on it to maintain a performance edge.

If you’re vertically integrated, you only learn from your own network. By partnering with other providers, you can benefit from a much wider network of robots and partners, all collecting more data and learning about what is working.

What’s a tangible way you’ve seen that play out?

There are three main types of actuators and gearboxes.8 These are the hardware components that move a robot’s joints. Every robotics company has to bet on one of the three types for their product.

Because our software runs on all three, we know the real trade-offs in production. We have the data, and can advise our customers on the best option for their specific use case.

03 | Most people get simulation wrong

At Flexion, you’ve made a big bet on simulation. What do you think about the sim-to-real gap, the argument that training in simulated environments won’t get us anywhere near commercial deployment?

We believe the point where simulation hits diminishing returns is much further away than most people think.

Throughout my PhD, everyone said simulators were limited. But we kept pushing the frontier with them, proving them wrong. We’ll keep doing that in the future.

Why is simulation so effective? I spend most of my time in software, where LLMs tend to improve fastest when they’re tuned on real production data. Synthetic environments only take you so far. That’s not the same in robotics?

Robotics is different. People make this same false comparison between robotics and self-driving cars too, but the analogy doesn’t hold.

In software applications and self-driving cars, anomalous behavior comes from humans.

In robotics, we’re solving actual, physical interactions between robots and objects – holding a certain weight, precise placement, things like that. Those are easier to simulate than human behavior.

At some point, simulated training will get advanced enough that we’ll need real-world data to push the frontier. But today, that’s not the bottleneck.

At what point do the “pessimists” think simulation will hit a wall?

Right now, there is a narrative that simulated RL can’t work for manipulation, how a robot handles and interacts with objects.

I agree manipulation is harder to train than locomotion.9 You’re asking the robot to interact with exotic materials – soft objects, cables, and liquids.

But simulation as a field is advancing very quickly. You can now train on those materials in a simulated environment in a way you couldn’t just a few years ago.

Will simulation continue to advance, or will progress start to decay?

It will keep advancing.

First off, simulation isn’t really a data problem. Many AI advances hit diminishing returns as datasets grow larger and harder to collect. But GPU-accelerated simulators aren’t trained on data — they’re just math and physics, encoded to run efficiently on GPUs. Companies like Google and NVIDIA are investing heavily to make these simulators run faster and capture the physics of the real world more accurately. That investment from Big Tech will push things forward.

Second, coding agents are a big accelerant. Good simulations need many intricate scenarios, with lots of variation. Building those used to be manual. Now, Claude Code can build whole simulation assets from scratch, interpolating from just a few examples.

That’s pretty amazing.

And third, there’s a lot of algorithmic progress happening, which is where we spend a lot of time at Flexion.

For example, RL works by trial and error. The robot tries random actions, stumbles onto solutions, and gets rewarded when they work. But manipulation requires a very precise sequence of actions. The space of “right” sequences is so narrow that you can burn a lot of calories in training and never land on one that works.

We solve this by bootstrapping10 the RL process with human demonstrations – either a person remote-controlling the robot through the task a few times, or video of a human performing the task from their own point of view.

In tuning LLMs, data quality often trumps data quantity. From what you’re saying, it seems like the same is true in robotics.

Yes. In coding and software, a few high quality examples plus RL beats large quantities of mediocre data. That lesson carries over into robotics.

04 | NVIDIA’s positioning

You’re pretty deep in the NVIDIA ecosystem. You and your co-founder worked there. They invested in Flexion. How do you think NVIDIA is positioning itself within robotics?

I can’t speak directly for the company. But remember, NVIDIA’s business is selling GPUs.

Their strategy is to create new ecosystems that need GPUs. They open-source just enough tooling to seed many companies on top, but not enough to solve the whole problem, otherwise they’d cannibalize demand for their own chips.

They ran this strategy successfully with LLMs. They’re doing it with self-driving cars. And now they’re starting something similar in robotics.

So far, they haven’t pushed toward actually deploying robots themselves.

So NVIDIA is seeding the ecosystem and pushing developers onto their chips. What role do you want Flexion to fill in the ecosystem?

Our goal is to standardize everything that goes into helping hardware manufacturers bring stable products to market.

We want to do that by bridging the gap between all the open-source research and tooling in the space, and actually deploying robots that do real work. NVIDIA is one player building open-source tools, but there’s an amazing ecosystem of researchers and academics pushing new methods all the time.

In practice, we end up building a lot of our own tooling in-house to support our customers, but we do try to leverage as much public work as we can.

What’s the biggest gap in the research right now? Is there a tool or capability that would remove a major R&D bottleneck?

The creation of what we call digital twins. Not a random simulated environment, but one that resembles a specific place. For example, if we need to train robots to operate in a specific factory, we need to create a replica of that in the simulator, in the digital world.

You can pay someone to build these assets today, but they’re very expensive. Coding agents are starting to build them for us, but it’s not zero-effort yet. Getting there will take time.

Where specifically do coding agents still struggle?

It’s hard to pinpoint. But wherever there’s more complexity and specificity.

Doesn’t that contradict the sim-to-real conversation we were having earlier? Isn’t the implication that simulation actually isn’t enough, that what we really need is more real-world data to get these robots ready for prime time?

That’s interesting. The way I think about it is – we should be using real-world data to improve the simulation environment, not to train the robot directly. Because if we can get the learning to happen in simulation, that is orders of magnitude more efficient and scalable than conducting training in the real world.

Simulation capabilities are advancing quickly enough that the cost-benefit makes it clear that’s where we should focus.

05 | To adapt, or not to adapt?

One of the challenges in robotics is real-time adaptation. The real world is messy. Should humanoids be programmed to course-correct on their own when they make a mistake? How do you think about that problem?

I have a controversial take. I’m not a fan of robots adapting live without human supervision.

When you deploy robots commercially, you have to think about risk. You have to certify these systems are safe, that they are statistically stable. If robots are adapting on their own, that’s very hard to guarantee. I don’t like the idea of robots changing their brain in the wild.

For a while, I expect robots will still require manual retraining around failure cases. We can recreate those failure cases in simulation, retrain on a combination of synthetic and real data, and run validation before deploying the update to thousands of robots.

But the humanoids you work with are general-purpose. They’re not specialized to run one task on repeat. I assume you can’t pre-program every permutation of reality a robot will encounter, even in a contained environment.

Doesn’t that imply a greater need to allow for adaptation?

That’s a good and hard question to answer.

Over time, as coding agents and LLMs improve, the whole loop – deploy, see what fails, have an engineer diagnose it, change your training code, retrain, redeploy – will become more automatic.

A human supervising that automated loop is probably safer and ultimately more efficient than letting robots adapt on their own. But only if we can get it more automated.

There’s also nuance around which part of the system you let adapt.

Our software has three layers – high-level understanding, local motion planning, and actual execution. I wouldn’t let a robot independently change the execution layer. That could get very unpredictable.

But letting it adapt the high-level strategy, like how it opens a door or moves around an object after one failed attempt, is much easier and safer.

For example, if a robot receives the task “make me a coffee,” the robot then has to plan – go to the kitchen, find the coffee machine. If it sees there’s no coffee machine, it needs to reason its way to a new plan. That kind of adaptation is safe.

What we don’t want is the robot independently changing how it physically moves.

So different parts of the stack get different levels of autonomy.

Exactly. And the high-level layer is primarily trained on real-world and human data, more like an LLM-style reasoning system. So we sometimes train that layer in simulation, but we don’t always have to.

06 | The year of the robot

When do humanoids get deployed at scale? Two years out, five, ten? I assume we’ll have commercial deployment before consumer…

Yes, I think commercial will come first.

Right now, deployment isn’t economical. But by the end of the year, I expect Flexion and others will prove that robots can deliver commercial ROI on specific tasks.

By 2027, you’ll see robots doing real work. They’ll be constrained to one specific task, trained to operate in one specific setting. But they will be fully deployed.

How do customers think about ROI?

It will be benchmarked to salary. Take a task done by three people across multiple shifts, tally what you’d pay them over a year for that work, and compare that to the amortized cost of a robot doing the same level of output that year.

Today, you can’t just bring a robot in a box and have it work. You need five engineers looking over its shoulder. We have to strip out the engineering oversight for robots to make economic sense for customers.

OK, so 2027 – The Year of the Robot. That’s a good prediction to end on.

This post offers an alternative framing of the next phase of software, and three startup ideas that follow:

A. AI-native e-commerce, rebuilt around a single intelligence layer

B. Dev tooling that translates product taste into code

C. Data and risk layer for physical AI

If you’re building in one of these areas, or something adjacent, I’d love to connect.

01 | The fog of AI

We’re three or four years into the AI cycle, and capital has rushed in with unusual intensity.

For the past couple of decades, the top 5 U.S. venture deals in any given year typically represented anywhere between 2-10% of total capital invested in the asset class.

In 2025, that number climbed to 24% of the total.

So far in 2026 – nearly 70%(!)

To put that in context... in real dollars, early AI companies have already surpassed the total lifetime equity raised by Google, Facebook, Apple, Amazon, Microsoft, Nvidia, Tesla, and 21 other leading tech businesses – combined.

Whether AI’s technical fundamentals support these deployment patterns remains an open question.

But this isn't the only way generational companies get built. Most of the defining companies of the last two cycles raised a fraction of what today’s AI leaders have, and they created extraordinary value.

Yes, times have changed. Capital markets are more competitive, timelines have compressed, and AI’s unit economics may not comp cleanly to past cycles.

But there’s a lesson in the data. Money isn't the scarce input in company-building.

Capital only amplifies a great product, it cannot create one.

Three or four years into AI, the fog is starting to lift. We understand more now about how this technology is built, what it can reliably handle in production, how it scales, and how it gets adopted. The surface area for innovation is much wider than where capital has pooled so far.

The AI story is far from written.

02 | Software isn’t dying

The evolution of software is essentially a long-term project in making computers easier to talk to.

Computer programming started at the level of bits (1s and 0s), then moved to machine code, then to foundational languages like FORTRAN, then higher-level ones like Python and TypeScript.

Each transition moved us up the ladder of abstraction, bringing programming closer to how humans think and hiding the technical friction of the layer below.

AI moves us up another layer – from code to intent. Instead of running pre-written commands, the user only specifies an objective, and the machine handles the rest.

More specifically, AI is changing software in three fundamental ways:

#1 Deterministic → probabilistic

Software will now produce a distribution of outcomes, rather than executing a pre-programmed path.

#2 Human-operated → agent-operated

A growing share of software interactions will be initiated by machines, with humans as orchestrators.

#3 Fixed → malleable

Software will be generated and customized on-demand directly by the end-user rather than the vendor.

Moats now have to come from what raw intelligence cannot recreate on its own. For example, accumulated memory and context, instrumentation that turns activity into a new type of data asset, or new distribution models that bypass one-to-many channels like SEO and app stores.

Software isn’t going anywhere. It's just abstracting upward, the way it always has. It’s taking a new shape, with new sources of defensibility underneath.

If AI makes software easier to talk to, I expect we'll see a lot more of it.

Below are three ideas that follow from this view.

This post is in part a broadcast, to find like-minded founders working on these problems.

But it’s also a creative exercise. A chance to set aside the “end of software” and “AI will commoditize everything” narratives for a moment and to imagine the products that could drive long-term value in this new paradigm.

Thesis A: An e-commerce brain

Shopify (NASDAQ: SHOP, $156B EV) and Amazon (NASDAQ: AMZN, $2.8T EV) represent opposing strategies in online commerce.

Shopify gives merchants full ownership of brand, customers, and data. Each shop runs independently, merchant data stays siloed, and discovery happens off-platform through SEO and paid acquisition. Shopify never aggregates shopper demand to put merchants in competition with one another.

Amazon does the opposite. They standardize the buyer experience, control the platform end-to-end, and use merchant data to optimize the marketplace. Merchants are inventory feeders, with little control over their brand and data.

Both companies have started retrofitting for AI. Shopify now lets stores syndicate products into ChatGPT and Gemini and recently launched merchant-side AI tooling to automate store operations. Amazon launched their AI shopping assistant Rufus for product discovery. Each has adopted standards like ACP and UCP1 to streamline agent-driven transactions.

But both are bolting AI onto an architecture that keeps buyer and seller context separate.

AI is only as smart as the information you put in front of it. You can stitch buyer and seller data together at the moment of inference. But product discovery and matching get sharper and cheaper when both sides live in the same ecosystem.

The opportunity is to build the first AI-native commerce platform where buyer, product, and merchant context live in a single, shared memory graph. One substrate that both sides read from and write to continuously.

This unlocks deep personalization and automation at scale – a personal shopping assistant for users, and a modern operating system for merchants:

• Merchant. A new shop owner types “Launch a new pottery store to sell my work.” The system runs structured onboarding to build the store, assembling the store with the best tools for each task – e.g., Lovable for storefront design; Gemini for creative assets; custom agents for BI, inventory, and customer support. Running the shop happens through natural-language commands – “raise prices on mugs 10%,” or “summarize sales this week.” The merchant focuses on brand, product, and strategy. The system handles the rest.

• Buyer. Each user is assigned a personal agent that learns the shopper over time – body type, fit, taste, brands they love, returns and why. The shopper profile deepens through natural conversation – e.g., “Buy from sustainable brands,” or “show me items in this color palette,” uploading a reference photo. The ecosystem becomes a destination, a place you go to connect with your digital concierge.

• Shared memory. Every interaction from shoppers and merchants – query, click, purchase, return, store redesign – writes to the same context graph, capturing rich semantic context for every entity in the ecosystem. With more data and use, the graph compounds into the most valuable asset in the network.

• Discovery network. After a shopper query, a retrieval layer narrows the catalog to a smaller candidate set. An LLM then reads buyer and product context and reasons to determine fit. The match is grounded in why this product works for this person, not in how similar buyers behaved.

This redefines the distribution and business model for online shopping.

Today’s half-trillion dollar digital ad industry is really just a workaround for siloed data – a guessing game that understands buyers and products separately, then tries to match them at query time.

When discovery is grounded in real fit and deep context on both sides of the market, the network can monetize satisfaction and loyalty – not ad placement or click-through rates.

Thesis B: Automating product taste

For fifty years, software was built to deliver certainty.

Developers wrote instructions in code, specifying exactly how an application should perform. The same input was designed to produce the same output every time.

Because of this predictability, we sliced the software development lifecycle into discrete, sequential stages – plan, write, test, deploy, monitor. Value accrued to the companies that owned the artifact produced in each step. Jira owned the ticket. GitHub owned the commit. Datadog owned the log.

AI-native software inverts this.

Uncertainty is a core property of LLMs. The same prompt to the same model yields a distribution of plausible responses. “Good” output is a moving target that shifts with new user behavior, context, and model improvements.

Today, developers try to impose certainty on AI by wrapping the model in scaffolding, using techniques like prompt templates, hard-coded guardrails, handwritten eval sets.2 Existing LLM observability platforms like Braintrust and LangSmith support this work by giving a window into model performance, but they rest on a faulty premise – that humans should still draft and run evaluation as a discrete step in a workflow.

In a world of model variance, where software “behavior” is constantly shifting, that becomes a bottleneck.

AI systems instead need a self-orchestrated loop – real-time, automatic evaluations that keep performance aligned with developer intent. Taste – the judgment about what “good” product performance looks like – has to be encoded in the system itself, not maintained by humans from the outside.

The target product is a gateway proxy between the application and its model providers. Prompts, responses, tool calls, and metadata flow through it. Behind the gateway are two components:

(1) Autonomous evaluation. The system generates its own rubrics from three inputs – the application design, live user behavior, and the full execution trace of each model call. Every call in production is scored against the rubric, which self-refines as the system learns which configurations correlate with successful outcomes.

Auto eval is difficult to build. LLM judges can already match humans on many evaluation tasks, but auto-generated rubrics still underperform human-authored ones. Closing that gap is the core technical bet.

The good news is this has become much more feasible in the last 18 months. For example, research on scalable rubric generation points toward a future where the data flowing through a product like this could continuously refine the rubric layer.

(2) Tiered remediation. When behavior drifts from intent, the system can take action – rerouting, retrying with different context, or alerting the developer with a natural-language explanation.

This product treats evaluation not as instrumentation the developer bolts on, but as something invisible, automatic, and always on. The product is working if the engineer never has to write the full rubric directly.

The moat is the data model.

In this product, each rubric criterion is a first-class entity that links to outcomes and refines automatically as the system learns which criteria predict success. Over time, the rubric becomes deeply attuned to the specific application. The result is a custom, self-improving evaluation layer that's difficult to rip out.

Building this is no small technical feat. But the team that gets it right will encode product taste, turning it from a craft engineers practice from the outside into a native property of software itself.

Thesis C: Risk layer for robotics

By 2035, autonomous systems are projected to represent a multi-trillion-dollar opportunity, with autonomous vehicles and robotics as the largest segments.

Commercial deployment of these assets demands a fundamental rethinking of how to analyze and price risk.

Traditional insurance assumes risk is a function of human behavior. Actuarial models analyze historical claims and demographic data, and assume behavior stays statistically consistent over time.

But when the “driver” is software, that breaks. Risk needs to be measured continuously, by technical inputs like software version, perception quality, the decision-making policy, and whether the system is operating inside the conditions it was designed for.

The incumbents – Verisk (NASDAQ: VRSK, $26B EV), Relx (NYSE: RELX, $72B EV) – have built their products and customer relationships around episodic claims. Analyzing risk from telemetry streams is a different problem entirely, and would require an overhaul of their infrastructure.

There’s an opportunity now to build something from scratch.

The target product is an API-first middleware layer. A lightweight agent installed on the autonomous asset ingests live telemetry (sensor health, perception logs, near-miss data), runs it through in-house AI/ML models, and generates dynamic risk scores for carriers and operational insights for fleet operators.

With a first-mover advantage, this platform can set the schema and actuarial foundation the entire category prices against, similar to the role ISO’s loss costs3 play today for property claims. Once a large enough dataset is amassed, multiple business lines follow – analytics to operators, revenue on claims forensics, licensed data to physical AI companies for training.

The winning product unlocks data network effects.

For example, if the platform learns that a specific LiDAR4 blockage pattern predicts crashes in delivery robots, it can price the same failure mode in farm equipment immediately, without waiting years for new claims. As more fleet types contribute data, underwriting improves, adoption accelerates, and the data edge compounds.

Autonomous fleets cannot deploy at scale without insurance, and carriers cannot underwrite without telemetry. The platform that resolves this standoff has the opportunity to establish itself as the de facto standard – and make our warehouses and factory floors safer along the way.

Many of these early AI titans are building extraordinary technology. Whether the capital flowing to them reflects durable value or cycle dynamics, time will tell.

But what I do believe is that the opportunity beyond them is enormous.

AI, after all, is not a product in and of itself. It’s a precondition. Raw material. And there’s still an enormous amount of shaping left to do.

The beauty of software is its near-zero marginal cost. Build one product, ship it to millions. But tailoring a product to each individual customer used to mean extra code and one-off integrations, expenses that grow linearly with each new client.

AI is upending this tradeoff. The marginal cost of customization is falling precipitously.

When software can reshape itself around each organization – learn its processes, adapt with user feedback – customization becomes the product.

Companies can now sell bespoke, at scale.

Surojit Chatterjee was early to this shift. He’s the founder and CEO of Ema, a platform that builds autonomous AI employees for large companies like Hitachi and ADP.

Before Ema, Surojit joined Coinbase as their Chief Product Officer through its 2021 IPO. He also spent over a decade at Google, scaling Shopping and Mobile Ads into multi-billion dollar businesses.

He and the team built Ema on two core technologies. Their Generative Workflow Engine (GWE) takes organizational goals, assembles specialized sub-agents to pursue them, and orchestrates execution in real-time. Underneath that sits EmaFusion, a routing layer that matches each task to the best model across 100+ LLMs.

Surojit has spent years helping large organizations deploy AI. As agentic systems move from demos to large-scale workloads, I wanted his perspective as someone who has seen the adoption curve firsthand.

What struck me in our conversation was how much traditional software has constrained our thinking. There are countless startups falling into the trap of running the SaaS playbook on top of a fundamentally different product and unit economic model.

Surojit left me with a clearer picture of how AI is actually being deployed today. And with some optimism that these systems, if managed well, can free people to pursue more meaningful work.

01 | “Custom experiences are the product.”

EO: One of the biggest bottlenecks in AI adoption right now is discovery. Customers know AI is powerful. But they don’t have a clear mental model for which tasks can reliably be handed to an agent or how to fold that agent into a preexisting workflow.

How do you handle discovery? Walk me through what happens when Ema sits down with a new customer.

SC: Customers typically come in with some preconceived ideas about how they want to implement AI. We try to get them to think more holistically, and so we rarely end up building their first request.

We start with what we call an Agentic Clinic, a half-day session with stakeholders to map their business processes and identify where AI can have an impact. At the end of the Clinic, we align around two or three high-priority opportunities.

Within 24-48 hours, we build a working prototype for one of those workflows, often with some ready-made components from our platform. That turnaround speed matters, because seeing AI work in practice is what customers usually respond to.

From there, we connect the prototype to their actual data and show them how the agents run in their environment.

So how do you get customers thinking beyond their priors, to think more broadly about what AI is capable of delivering?

Probably best to answer this with an example.

We were working with a Fortune 500 CHRO who wanted to rethink performance management. She had an existing software tool, built around collecting data and conducting reviews across the company. That process was onerous so they only ran it every six months.

At first, she asked us to build an agentic replacement. Same workflow, just automated.

We told her: “Don’t think about replacing your existing tool. Think about reimagining the entire process.”

With AI, you can now give employees feedback daily. You can read code commits live, to assess the productivity of the engineering team. You can give sales reps on-demand coaching by interpreting CRM data and call transcripts.

We were able to build and deploy this new feedback system quickly across 500,000 human employees. The company went from reviews every six months to real-time coaching.

That’s performance management reimagined with AI. Those opportunities exist across every enterprise function.

Performance management is an interesting example because it’s inherently bespoke. OKRs, performance criteria, review cycles… these are unique to each company’s operations and culture.

How do you make sure those nuances don’t get lost when you hand work over to agents?

This is a really important point. With AI, custom experiences are no longer services. Custom experiences are the product.

Think about it like this. In the past, if you wanted clothing that fit perfectly, you went to a tailor. It was expensive and took months, but the result was great. Then manufacturing brought ready-made clothes to market. Off-the-rack items don’t always fit perfectly, but they are instant and cheap.

SaaS is ready-made clothing. It doesn’t quite fit. So we layer on humans and custom builds to act as glue between what the product does and what the business needs.

Now, imagine tailor-made clothes that are instant and cheaper than off-the-rack. You’d never buy off-the-rack again. That’s how AI is changing software.

AI agents are becoming the glue between the tooling and workflows. You tell the AI – “This is how I want performance management to work. Pull data from these systems. Synthesize it this way.”

It takes weeks to build, not months. And once deployed, these systems continue to watch which suggestions humans accept and reject. So the software adapts. It gets more sticky to your organization over time.

So it sounds like one big difference between deploying SaaS versus AI is the degree of iteration. With AI, you start with a baseline, people use it, and the system improves through use.

As a product manager, how do you get the customer to go on that journey? How do you prevent churn, when full functionality isn’t apparent upfront?

You have to deliver impact right away. The customer needs to see the customization and ROI immediately.

Deploying Salesforce or Workday inside a large organization can take months because of all the required integration work. With AI we can deploy equivalent functionality in weeks.

But to drive retention in AI, the software needs to keep delivering magic moments. And it needs to do so on the customer’s timeline, not the vendor’s.

I’ll give you another example.

We have a customer with 250,000 employees across 65 countries. They use Ema for the entire employee lifecycle. Managing travel, employee verification, visa letters, tax forms, and so on.

Before Ema, employees were navigating over 100 SaaS applications for these workflows. I’m not kidding! Layers and layers of software to complete the simplest task.

All of that was instantly abstracted away into a UI that Ema generates on the fly. But we also designed the system to be extensible by the user. Our agents can generate new workflows using natural language.

So every few weeks, we’re seeing new capabilities added by the employees themselves. Not because we shipped an update, but because the users prompted the system to handle something new.

There’s a natural mechanism in the product – this extensibility – that keeps these magic moments coming.

02 | Don’t let agents go rogue

If employees can build new workflows on their own, that changes the role of the software vendor.

You’re no longer building all the features. But you are responsible for the system’s boundaries, so that the AI stays aligned with its intended purpose.

That’s a tricky product challenge. Because in any enterprise agents will have competing goals.

For example, a support agent needs to balance customer satisfaction with cost control.

You don’t want the agent going rogue, approving out-of-policy refunds willy-nilly. But you also don’t want it so constrained that it follows a rigid set of refund rules, and churns the customer.

How do you balance deterministic1 guardrails with the non-deterministic judgment that makes agents valuable?

We deploy a hybrid model.

Our AI systems are designed as a chain of specialized agents working together. Agent A completes a task and passes its output to Agent B, who passes to Agent C, and so on.

Broadly speaking, the handoffs between agents – which agent works on what, in what order – are coded rules. But what each agent does within each step is non-deterministic. Meaning the AI can exercise its own reasoning to deal with ambiguity and variation within its scoped task.

Source: https://www.ema.ai/blog/agentic-ai/generative-workflow-engine-building-emas-brain

This architecture lets us track which sequences work best. And when a given execution path works consistently – a human approves the outcome, a ticket resolves cleanly – we feed that pattern into what we call procedural memory, part of the company’s long-term memory layer.

So the deterministic components – the order of operations, which agent handles which step – provide the guardrails. But within each step, the agent is still reasoning independently.

As model capabilities improve, the boundary between what should be deterministic and non-deterministic is constantly shifting.

How do your developers stay current, to continue to strike the right balance between determinism and non-determinism in the product?

That’s a very evolved question, a very important question that gets into the crux of building AI-native products.

Our goal is to build less determinism in the system over time. Every hardcoded step means more maintenance. We’d rather hand off a decision to an LLM – if we are confident it can handle that decision reliably – than rewrite the code as new edge cases pop up.

We have a small model called EmaFusion that helps us calibrate how much determinism is needed at any point in time. It dynamically assesses the capabilities of every major LLM. When a new version of Claude or Gemini drops, or a new open-source model appears, EmaFusion experiments with different model combinations to see which performs best on a specific task.

This gives us good visibility into what types of work models can reasonably handle and where they fall short and need more hard-coded logic.

03 | The model wars

What’s cool about EmaFusion is you have unique visibility into the relative performance of all major AI models, in real production environments.

Play the model wars out a year or two.

What do you think the landscape looks like? For example, will models converge2? Will open-weight models gain or lose market share?

I think the frontier models – Gemini, Claude – will asymptotically converge in terms of raw capabilities and price. On a benchmark like HLE3, everyone will score about the same.

But on actual enterprise tasks – accounts receivable optimization, policy document synthesis – you’ll see real differences among models. App builders will need to factor those in.

We’re at an important moment in model development.

As production scales, models will optimize further around the tasks they’re already good at, the data their customers continue to give them access to, and the business models they see working.

From what I can see, ChatGPT skews toward consumer. Claude skews enterprise. Gemini wants to play in both, and Google has a ton of data to let them do that. And those starting points may influence where capabilities move over time.

At Ema, our product is built on the premise that there will always be a complex ecosystem of models, each with their own tendencies and capabilities.

One model might be more encouraging, another more cautious. One stronger at coding, another at summarization.

By routing across many different models, we can average out those individual quirks. So the system isn’t overly influenced by any single model’s biases, and the enterprise gets consistent output.

In your data, anything you’re seeing that defies market consensus, that goes against what most believe about these providers?

When I look at the dynamic trace – which models EmaFusion selects for each subtask – there is no “winning” model it consistently favors.

And often, the cutting edge model is not the best choice. For example, for parsing a 30,000 page PDF, a small OCR4 model we built internally outperforms Claude.

04 | Sell simplicity

Today, there are hundreds of vertical AI startups — legal AI, healthcare AI, accounting AI.

The thesis for these companies is that sector-specific regulation, distribution, and data taxonomies create a unique set of requirements. And so generalist platforms can’t compete.

You’ve made the opposite bet. That the underlying tasks AI performs – parsing, research, writing – are fundamentally content-agnostic. And that well-coordinated agents, specialized for these different subtasks, can handle most enterprise workflows, regardless of sector.

Why do you think horizontal AI represents a more durable product strategy?

Before transformers5, the industry assumption was that AI had to be very specific. In early image detection, for example, we had different models for identifying cats versus dogs.

But as we built and scaled LLMs, it turns out that training on a variety of information makes general reasoning more robust.

It’s like the human brain. If my kid only studies math and never learns language or music, they won’t actually be better at math.

Diversity of input strengthens the underlying reasoning capability.

That same principle applies to AI systems. The core operations – parsing, research, synthesis, execution – are the same across domains. Sure, we need to do some extra work to train on the specific vocabulary of HR or finance. But fundamentally, the tasks are the same.

A horizontal platform sharpens that reasoning across every domain it serves. A vertical company only learns from one. That’s why, maybe counterintuitively, a horizontal platform actually lets us build vertical-specific AI products better and faster.

I also think a lot of AI startups copied the SaaS playbook as the default without interrogating how the underlying product economics have shifted.

That’s right. In traditional SaaS, every workflow and integration has to be explicitly coded. Expanding scope means increasing your engineering spend.

So vendors specialized. They built separate apps for different sectors and corporate functions, each with its own data model, team, and sales motion. Over time, those applications got bolted together. They turned into monster apps like ServiceNow, with endless configuration knobs and months-long setup.

Then AI came along. The first instinct was to apply these new AI capabilities to the same specialized workflows. So we get legal AI, healthcare AI, finance AI. But that specialization only exists in the first place because customized SaaS tools were usually too expensive to build and maintain.

AI doesn’t have those constraints. So we don’t have to build products for these silos any longer.

AI seems to challenge the assumption that sector is the right organizing principle for software.

The way I think about it for an enterprise buyer – they just want simplification.

We’ve over-rotated on specialized software. Right now, one organization might have five apps that do roughly the same thing. And now we’re bolting hundreds of agents on top of those five different systems. That’s a lot of unnecessary complexity.

I spent 15 years at Google. There was a time when people thought separate, vertical search engines would win. We talked about it a lot internally. Turns out, people just want one place to go.

It’s the same for enterprises. Complexity is killing the enterprise.

So if simplification is what enterprises are principally buying with AI, that raises a product question – simplify what?

And what I’m hearing you say is that AI-native companies need to conceptualize work at the goal level, not the task level. Start with the outcome, not the existing tooling.

If you’re solving for performance management, the question isn’t, “how do we automate data collection for our HRIS?” It’s – “what do our employees need to improve?” The former automates semi-annual reviews. The other gets you real-time feedback as people work.

Goal-level framing doesn’t fit inside one software category. “What do our employees need to improve?” pulls from HR, IT, finance – all at once. That’s what pulls you toward a horizontal product.

And it also simplifies things for the customer. You end up with one system organized around the employee, not five organized around departments.

Exactly. And right now, there’s a leapfrog happening. Large enterprises can go from very old legacy software to an agentic solution, and skip over using the modern cloud tools with prescriptive workflows.

05 | The great displacement?

Worker displacement is an important topic right now.

Optimists point to prior technology cycles. There will be some displacement, but on net AI will take away tedious work and create new types of jobs.

Doomers say this time is different. That the speed and breadth of AI will break the historical pattern and cause mass displacement.

You see firsthand how enterprises are deploying AI, and how humans interface with the technology every day. Where do you come down?

Right now, large enterprises are not radically displacing people.

Most employees are overworked. Think about a nurse at a hospital, or an HR team buried in tickets. In my experience, AI is mostly freeing them from administrative tasks – clearing a backlog of work, and making employees more productive as a result.

In the near term, I think that trend will continue. And as a result, people will shift more of their time to core, higher-value tasks.

Ten years out, major re-skilling is probably needed. And within that time frame, some will feel the impact faster than others. Customer support reps and software engineers, for example.

But even those roles won’t just disappear. They will look different. Workers will have to reconfigure their jobs around AI.

Software engineers, for example, will have to learn to work with agents to build software, rather than actually writing software themselves. They’ll still be responsible for building and maintaining systems, even if they are not primarily doing the coding.

I’m mostly going off intuition, but I think there’s a lot of latent demand in the economy right now. Backlogs everywhere. Employees are overloaded. Managers are getting increasingly overwhelmed, which leads to short-term thinking and risk-aversion.

If AI clears some of that backlog and lets teams get to the work they’ve been deferring, the floor rises for everyone. With less overhead, small businesses can now compete with larger companies. The economy expands around a new baseline.

I think you will see a lot more companies in the economy, but they will run leaner.

06 | Your code is my opportunity

You have a unique seat. You’re deep in the cutting edge of AI capabilities. You also serve legacy companies and see how this tech gets adopted in practice.

How does that inform your own angel investing? Where do you see durable product value in AI?

I think quantum computing and AI together will open up interesting opportunities.

Also, with so many agents everywhere, agentic security is an area of interest. I like talking to companies tackling governance and safety.

At the product level, I have a simple framework – is it solving real problems, and can it work at scale? There’s so much hype in AI. I need to see that the product works in production.

Also, speed and execution were always important in startups. But the time window is getting dramatically compressed.

We were at an HR conference recently. One of the other exhibitors, a legacy company, was describing their product. One of our solution architects was listening, and built a working version of their entire product. In 15 minutes, on top of Ema.

Trust, security, enterprise viability are going to matter a lot in a world where you can vibe code anything in 15 minutes.

Jeff Bezos famously said, “Your margin is my opportunity.” Well, now your code and people are my opportunity. The more code or bureaucracy you have, the slower you are going to be.

I think many of the fundamentals still hold. Network effects, unique data – those still matter. Even if AI means you’re building those into the product in new and different ways.

For us, we get more defensible the more we learn about our customers. Once we have a good context graph and procedural knowledge, the next deployments become easier and easier.

That’s also part of why we went horizontal. If our compounding asset is knowledge of the customer, then it gets easy to build different agentic systems on top of that, across different functions.

Great stuff, a lot to think about. Thanks for doing this, Surojit.

Thanks for having me.

01 | The dark matter of work

Right now is a difficult time to build and invest in new technology. Model capabilities are improving so fast that many AI-native products, even those with real utility and traction, are quickly becoming obsolete.

In my own diligence, I’ve had to think very, very hard about this question…

To reason through that, I start with what models are fundamentally good at.

Today’s models transform unstructured inputs into outputs. They do three things extraordinarily well: (i) understand and generate language, code, and images; (ii) reason through multi-step problems; and (iii) execute commands within software systems. They’re getting better at these tasks every day.

If your product’s value prop hinges exclusively on enhancing the AI along these dimensions – smarter reasoning, better retrieval and context management, deeper domain expertise – you’re one model release from obsolescence.

Durable product value has to come from somewhere else. Not from patching short-term gaps in intelligence capabilities, but by creating entirely new inputs for the AI to work with.

Put differently, the best product strategy isn’t about making AI smarter – it’s about expanding what the AI can see. After all, any model, no matter how powerful, can only reason over what it observes.

This turns out to be an old concept.

In 1991, Ikujiro Nonaka published one of the most cited management papers in history – The Knowledge-Creating Company. His thesis is that organizations run on two kinds of knowledge.

Explicit knowledge is easily codified – a process, a policy document, a decision tree. Tacit knowledge is craft. It lives in human intuition, practice, and judgment. It’s the customer success manager who knows which clients need a preemptive call. Or the engineer who senses which parts of the codebase are fragile before the logs pick it up in production.

Tacit knowledge is the “dark matter” of work – the invisible reasoning, intent, and institutional memory that connects raw information to action. It doesn’t live in any system of record. It expresses itself ephemerally, through human behavior, in the course of day-to-day work.

That is, until now.

A new class of AI products is starting to capture this invisible layer – not by asking people to document what they know, but by directly observing how they work…

…vision models that perceive user activity inside applications across thousands of daily sessions…

…language models that extract reasoning from employee conversations scattered across Slack and email…

…code provenance tools that trace every AI-generated function back to the prompt, the agent’s chain of thought, and developer corrections.

These products aren’t bolting AI over a preexisting database. They’re producing a fundamentally new kind of data asset – a dynamic, contextual layer that never existed before.

02 | Making the invisible visible

What does this look like in practice? The strongest products in this category share four properties.

1/ They generate a fundamentally new kind of data asset. One that has never appeared in any system of record.

2/ They don’t just capture what happened – they encode why. Raw behavioral data gets translated into a representation of meaning, one machines can read and act on.

3/ Their observation is continuous and self-reinforcing. The system quietly observes how people work, distills patterns, and feeds that back into the product to improve accuracy and automation. This in turn drives more usage, and therefore generates more data to learn from.

4/ They create a data primitive that others build on. Structured context that third-party agents and products have an incentive to integrate with and consume.

A couple early products are already building in this direction:

EXAMPLE #1: DEV TOOLING // ENTIRE.IO

Entire is building a new storage and provenance layer for code.

The founding team came from GitHub and saw firsthand the limitations of git1 in the AI era. Specifically, git stores code as text files and tracks version history, but has no mechanism to capture what the code means or why it was written.

That was fine when humans wrote every line and held the design in their heads. It breaks when code production is outsourced to AI agents.

Entire solves this by making this invisible layer – the history and meaning of the code – explicit.

Their first product, Checkpoints, automatically captures the full agent coding session from the IDE2 — all prompts, agent output and reasoning, and developer corrections. When the developer commits3 to the repository, that context is permanently linked to the code as a structured, queryable asset, available to every future agent and engineer who works on the project.

Sample session summary for a single commit, showing the developer’s original prompt, the agent’s tool calls and reasoning, and the resulting code changes. [source]

Here, every coding session contributes to the system’s understanding of the code, its interdependencies, and how it came to be. Over time, this turns the code repo from a static storage archive into a living record, one that gets more robust with every commit.

And better models only amplify that advantage, because as smarter agents come to market, they can extract more and new types of value from the full context and history.

EXAMPLE #2: HORIZONTAL SOFTWARE // WORKTRACE.AI

Worktrace is building a next-generation RPA4 product. The founder came from OpenAI and saw that the biggest bottleneck to enterprise AI adoption isn’t the technology – it’s knowing what workflows to automate, and how to do so.

Today, figuring out what to automate is manual and slow – teams either map processes by hand or rely on software tools in UiPath or Zapier that capture surface-level behavior like clicks and data flows.

Worktrace replaces that.

The product integrates with existing tools like Slack and Linear, quietly observing how employees work. But it goes beyond surface-level process mapping – it parses intent, capturing why employees take certain actions and how they complete the same task in different ways. Why does a coordinator skip certain steps under time pressure? Why do two people follow different paths to the same outcome?

The output is a prioritized map of automation opportunities, ranked by potential impact, with a spec that outlines the right AI model and agent design for each task.

Sample discovery dashboard, ranked by automation impact (hours saved), with the applications involved and number of steps for each. [source]

Rather than competing on “better automation,” Worktrace owns something far harder to replicate – a nuanced and dynamic understanding of how employees actually work and where AI can have the most impact.

As models improve, two things happen: (1) the live observation captures richer, more complex workflow patterns, and (2) Worktrace can revisit its accumulated history to surface automations that earlier models couldn’t detect.

In other words, the product only gets more valuable as AI accelerates.

03 | The anatomy of a durable product

There are a number of other products – across productivity, vertical SaaS, and developer tools – developing a similar architecture. Each looks different on the surface. But underneath, they share the same product template.

Step 1: A perception mechanism

These products need a way to observe activity and behavior that was previously invisible to software, by watching activity inside and across applications.

This capability is distinct from a knowledge or context graph, which organizes relationships between data artifacts that existing systems already produce. For example, a knowledge graph might map the relationship between a support ticket, the customer's account history, and the agent who escalated it. But all of that data already lives in a database somewhere. An observation model, on the other hand, captures what doesn't – the Slack side-channel that explains why the ticket was escalated in the first place.

A few tailwinds are making this observation capability viable and more efficient.

Techniques like distillation5 and quantization6 now allow small, purpose-built models to run locally on phones and laptops, enabling simple tasks in the observation flow like data capture and entity extraction to happen at the edge. This can deliver a cheaper and more secure architecture, since raw data doesn’t need to leave the device.

Additionally, multimodal models can now process vision, audio, and text simultaneously, rather than requiring separate models for each. As multimodal capabilities improve, this dramatically expands the range of behavior that software can perceive and analyze.

Step 2: Converting raw inputs into meaning

Most of the product value – the “secret sauce” – lives in how these systems convert perceptions (from Step 1) into structured, semantic data.

The exact tactics and implementation varies, depending on the product and category. But there are a few things to look for when evaluating whether a product is doing this well:

• Is the output schematized into defined entities, fields, and relationships? Is it something a machine can read?

• Is the output transferable? Can it be plugged directly into a third-party agent builder, API, or automation pipeline with minimal transformation?

• Does the output encode intent and decision logic (“why” something happened), in addition to behavioral telemetry (“what” happened)?

• Can the system successfully handle edge cases and variability, recognizing when different actions are targeting the same end goal?

Step 3: Setting up the feedback loop

Output from Step 2 flows back into the product. This is typically done through either: (i) context enrichment (prior data and observations are stored and organized in a way that helps agents easily find and access in future sessions), or (ii) model adjustment and fine-tuning (interaction data and output is used to retrain the models doing observation in Step 1 and conversion in Step 2).

04 | Externalization, industrialized

Nonaka understood that a company’s real competitive edge comes from externalization – the ability to convert human intuition and craft into something others can use. In 1991, this was done through language and human dialogue.

For Nonaka, externalization was always gated by human bandwidth – the slow work of conversation, management, and mentorship.

But AI removes that constraint. The products discussed in this piece take the raw, unstructured mess of how people work and convert it into semantic meaning.

It's externalization, industrialized.

The products that win today won’t succeed with "better AI" or "better agents." They will develop a new sensory layer for work – one that observes what no system has ever recorded, translates it into meaning machines can read, and allows that knowledge corpus to build organically over time.

The companies that get this architecture right won’t just survive the next model release. They’ll get stronger from it.

They'll bring the dark matter of work into the light.

Overall, public SaaS is down 15% year-to-date. But the pain isn’t evenly distributed. Companies built around UIs, forms, and human workflows are feeling it the most.

The markets are pricing in a “SaaS-pocalypse.”

Agents, the story goes, will execute workflows on demand, spinning up interfaces and interacting directly with data. In that world, the only enduring value in software are (i) agents – and (ii) the data and infra layers that feed them. Pre-built software applications will become obsolete.

That story assumes agents will work reliably. Right now, most don’t. They’re still brittle. They lose context. They don’t recover well from mistakes.

There’s a branch of computer science called embodied AI1 that offers a different way to think about how agents should be built, and the infrastructure they need to operate effectively.

Embodied AI is built on the insight that intelligence can’t exist in a vacuum. Brains don’t connect directly to their surroundings. They need a body to mediate between raw cognition and the external world. Intelligence, in this view, emerges from continuous-loop interaction between an agent, its physical form, and its environment.

Dhruv Batra is a leader in embodied AI, with a deep understanding of how machines can be built to navigate complex, dynamic environments.

Dhruv was previously a Research Director at Meta’s FAIR (Fundamental AI Research), where he spearheaded the development of Habitat (the fastest 3D simulator for training virtual robots) and the team that built the AI assistant integrated into Meta Ray-Ban SmartGlasses.

Before that, he was an Associate Professor at Georgia Tech, working at the intersection of computer vision, machine learning, natural language processing, and robotics.

Today, Dhruv is co-founder and Chief Scientist at Yutori, a new startup rethinking web agents from the ground up.

Alongside a team of researchers from Meta, Tesla, Palantir, and Google, his bet is that the web should be treated less like a database to parse and reason over, and more like a physical environment – chaotic, visual, dynamic.

I sat down with Dhruv to explore the future of agentic software through the lens of embodied AI – how these agents need to be built and the gaps that remain if these products are to fulfill their promise.

01 | Bits move faster than atoms

EO: You spent a good chunk of your career in embodied AI, teaching machines to perceive and act in real-world environments. Now, you’re focused on web agents that live, at least today, in the digital realm. Tell me about that journey.

DB: I actually started my career in computer vision and machine learning. A decade ago, I co-authored a paper that outlined early methods for chatbots to answer questions about images, which won the Everingham Prize last year for stimulating a new strand of vision and language research.

But five or six years ago, I grew dissatisfied with chatbots. I wanted them to do things in the world. That took me into reinforcement learning, then robotics.

I’m not a roboticist by training. So I earned my credibility, doing things like supervising PhD students in the field and winning a best paper award at a robotics conference.

I don’t see physical robots arriving before digital agents.

Bits move faster than atoms. They’re easier to clone and iterate on. So I took all that learning and started Yutori.

Why did you land on web agents specifically?

Our thesis is that the web is going to fundamentally change. Over the next decade, probably sooner, no human should have to operate a browser. Why click buttons or fill out forms when machines can handle it?

In 2025, we saw real progress with coding agents, but no digital assistants that could automate entire browser workflows. The models weren’t there yet, but we knew it was coming. We saw a window of opportunity.

So where do current web agents fall short? In my experience, Claude’s computer use and OpenAI Operator are getting pretty good.

They are improving. But our browser-use model, n1, outperforms Opus 4.5, GPT 5.2, and Gemini 2.5.2 (Gemini 3 computer use benchmarks aren’t out yet, so that comparison isn’t possible.)

Why is our model outperforming? Better perception-action feedback loops3 – something I learned from robotics.

Historically, most AI models were pre-trained on static data – text and images from the web. That’s a good foundation, but it doesn’t teach the model how to act or recover when things go wrong.

This is a known problem in robotics. Mistakes compound. If your robot slips on ice, it’s now in a body configuration it hasn’t been trained on, and things can spiral. And when there’s hardware involved, compounding mistakes are costly. So we train robotic systems to course correct when an action doesn’t produce the expected result.

When we started Yutori, that kind of perception-action feedback data was underrepresented in how most web agents were trained. Without that, agents don’t learn to recover.

So how do you train agents to recover from mistakes, to fail better?

Through post-training – supervised fine-tuning (SFT)4 and reinforcement learning (RL)5 on both synthetic and real websites.

In robotics, you have to choose your training approach depending on the task. For locomotion, RL works well because the physics relevant to the tasks transfer over. An angle is an angle – a robot’s leg should bend the same way in simulation as in the real world.

But for vision-based tasks like picking up objects, camera input is tied to the environment. Every room has different lighting, every surface reflects differently. You can’t simulate all of that, so you rely on human demonstrations that the robot learns to copy.

Web agents don’t have those constraints. The sim-to-real gap6 is small in the digital world, and training on live websites is safe and low risk.

That means we can do SFT based on demonstrations, showing the agent what to do when a button doesn’t load or a page renders incorrectly. And we can do RL on real websites, rewarding successful actions and recovery.

That combination teaches our agents resilience and persistence.

Is there something in your approach – like your multi-agent orchestration – that big companies like Anthropic won’t replicate, because they think differently about how agents should work?

First off, the foundation labs absolutely can deploy these techniques. In AI, there are no secrets that can be kept forever. The question is – will they? They’re fighting so many battles at once. The advantage we have as a startup is focus.

That said, our agents are very specialized for navigating the web.

Our first product, Scouts, is essentially Google Alerts for the AI era. You tell it “let me know when X happens” – a price drop, a reservation opening up, a company announcing a raise – and it monitors for that continuously.

A key design choice we made is that users shouldn’t have to specify sources, to tell the AI where to look. The system needs to search wide and deep on its own, which means training them to integrate with APIs and third party tools across the web.

​​But here’s the problem – if you give a single agent more than 100 APIs to call from, it starts thrashing.7 It loses track of what it’s doing.

So we use a hierarchical structure. There’s an orchestrator agent, with access to the full user prompt. That orchestrator directs sub-agents, each specialized for different tool categories. For example, we have a sub-agent for social media, one for news sources, and so on. Each manages a smaller context.

Claude Code and Manus have announced something similar. Teams are arriving at the same discovery – without careful context management, performance degrades.

You mentioned the need to train agents to “integrate with APIs across the web.” But most sites don’t have APIs. How do you program your agents to handle this long-tail of the Internet?

Right. Most websites do not have APIs agents can read from.

For those, we found it’s better for our agents to interact with pixels rather than parse the underlying HTML or JavaScript.

We first approached this as a coding problem. Websites are just code, and so we thought the logical approach is for agents to parse the back-end. But we quickly learned that websites are too heterogeneous. They’re programmed in wildly different ways, with hidden hacks on the back-end.

It turns out the best source of truth is what the human actually sees, the pixels.

That’s counterintuitive, since the back-end contains more information than what’s displayed on the screen.

There’s an analog here to Waymo versus Tesla.

Waymo uses cameras, radars, and LiDAR8 to create a rich, 3D map of the environment. Tesla uses cameras only. Tesla’s argument is that vision is sufficient and scales better, since roads were already designed for humans to navigate visually.

We’re taking the Tesla approach. For them, it is largely about being more cost effective. For us, it’s about managing the litany of edge cases that appear across the web.

Parsing the back-end seems like more information, but it creates more problems than it solves. What’s rendered to the screen follows visual conventions that humans expect, and those are far more stable.

In this case, the right representation matters more than the one with the most data.

02 | Context is everything

Can you touch more on persistence? Your agents are designed to run continuously, for months. I imagine that could get unwieldy if not designed well.

Our product Scouts is unique in that it is “always on,” built for proactive monitoring. That comes with trade-offs. If agents are constantly going out into the world, your costs go up. And you can ruin the user experience with too many or repeat notifications.

The agent needs to know whether it’s already told the user about something. That means remembering everything you told the user in the past.

Five or six years ago, you’d solve that problem with embeddings.9 But we saw how fast model capabilities were evolving, and designed around retrieval instead. We write everything we’ve told the user into a file system, and have a custom agent that runs searches against those files.

Models are good enough to now grep and diff10 against previous reports. It’s easier to hand context retrieval over to an LLM rather than trying to architect a vector database.

How do you manage that at scale? If a Scout has been running for a year, that’s a lot of context.

This is genuinely new territory. I’ve had agents running for ten, eleven months. Such long-running, always-on agents have never been built before.

We built our memory architecture in-house. No open-source frameworks.

Model capabilities are improving fast enough that these frameworks end up crippling the product. A key part of our product value boils down to very careful context management.

How do you think about the right way to design a context graph,11 one that scales and that both meets the capabilities of where agentic systems are today, but also will evolve as models improve?

This is something we think about a lot at Yutori.

Today, context windows12 are the main constraint dictating how AI systems get built. For example, a common failure with MCP13 tool calls is if the response is too verbose, it floods the context window and the agent can’t perform its task. Some harnesses14 now write longer responses to a file for later reference, instead of consuming them directly.

But that problem compounds for agents running 24/7 for months.

File systems are the best we have right now – write context to files, let the agent search and summarize as it goes.

The naive view is that context windows will just keep scaling. But biological systems suggest another path.

What do you mean?

I’ll caveat that biological systems are not perfect analogs for agentic systems.

But what I mean is – mammals don’t have infinite context. When they sleep, they’re compressing memory. Distilling the day’s experience, converting System 2 into System 1 thinking.15 There’s a reason beginners in sports are told to get sufficient sleep. They’re converting new techniques into muscle memory.

I don’t think simple scaling of context windows will get us to years of runtime context. We’ll have to conduct new research around distillation and continual learning. It probably looks like new mechanisms for automatically updating model weights, converting accumulated context and experience into more efficient representations.

Unfortunately, I don’t yet know how to build systems that anticipate that solution.

Maybe there’s a startup opportunity somewhere in there.

03 | The fate of the application layer

Today, the market is betting that agents will render the application layer obsolete. When an agent can generate a workflow on demand – pulling in the requisite data, executing the task, building the interface that lets humans read the output – workflow SaaS products like Salesforce or Adobe lose their reason to exist. How do you see the software stack evolving?

I posted a tongue-in-cheek tweet recently where I wrote that maybe coding is just caching for LLM inference.

What I mean is, when you write a software program, you’re really saving down a solution – a codified way to solve a problem. Code is therefore a stored solution. And if intelligence is the ability to solve problems, then, in the AI era, code is just stored intelligence.

Historically, we built generic apps like Salesforce or Fitbit because it was expensive to solve each person’s problem individually. You build one solution and ship it to millions.

But if LLMs make it cheap to read and reason over code, you can generate custom solutions on demand – hyper-personalized apps, built on the fly.

Does that imply we are heading toward the collapse of business and consumer apps?

It’s possible. The models will get good enough. But the tradeoff comes down to two things.

First, efficiency. It’s wasteful to regenerate the same code for millions of people. It’s economically efficient for someone to own the shared layer, shared libraries and components.

Second, design. Not everyone has product taste. Good software encodes good design decisions. That expertise gets packaged into specialized apps – tools that do something well, presented clearly. You can’t generate everything on the fly. Humans still need curation.

Can I offer a third? Network effects. You’ll still want users collaborating across the same plane of data, context, and reusable functions. Complete customization, all the way down the stack, makes that hard.

Yes. Any one user may not have the autonomy, full picture, or authority to take the software in arbitrary directions.

And if that’s the case, it seems like context management – especially shared context management – becomes the next layer of value.

Maybe the “application layer” becomes middleware for agents – something that stitches together system state, builds a context graph for how work gets done, encodes valid operations, and provides a control plane for human oversight.

Not the agent itself, not the data layer. But specialized software that helps agents traverse and collaborate in specific digital environments.

That framing makes sense to me.

04 | AI’s novelty problem

Do you think there will be two categories of agents? One for constrained environments like enterprise software, and one for the open web?

I lean toward no. The open web is the harder problem. If you can handle that, a constrained environment is just a narrower, more specified version. You tell the agent the rules and constraints, and it should be able to adapt.

You see this with coding agents. If you can operate across many different coding environments, specialized ones typically aren’t a problem – as long as they’re represented in the training data.

That caveat – “as long as they’re in the training data” – seems important.

Yes. The AI field has basically decided we don’t need to solve generalization.

What do you mean?

In machine learning, generalization means the system is capable of running inference on information outside the training distribution the AI has been exposed to.

When I taught Intro to Machine Learning, I introduced generalization as the goal of AI systems on day one. The whole point was building systems that could extrapolate beyond their training data.

But as the field commercialized, we moved away from that. We’ve implicitly decided we will just make the training distribution wide enough that everything we will see at inference is something we’ve already seen in training.

Do you think that holds the field back?

Not necessarily. Scaling up has led to commercial success of AI models, which funds investment and progress. But I do wonder about the implications.

If you give up on generalization, can AI ever develop truly novel solutions? Can it solve problems that no human has ever solved before? Because by definition, those solutions won’t show up in the training data.

That seems like it could be a limitation.

I don’t know the answer. It’s possible that wide enough training data effectively gets us there. Maybe we’ll find out soon, it’s an exciting time.

05 | Bots aren’t all bad

Open standards like TCP/IP, HTTP, OAuth were the connective tissue of the old web. They let disparate software systems communicate. We’re now seeing the first agentic standards emerge – MCP for tool access, UCP for commerce. Are there any gaps you still see?

From an advancement of science perspective, I’ve generally been a proponent of building as much in the open – open weights, open standards – as your economic constraints allow.

At Yutori, for example, our n1 model is post-trained from the Qwen16 family of models. I’d love to see more American open weights and open-source models out there.

But one open standard I’d like to see is a permission layer for agents.

In the future, I imagine everyone will have one or several digital assistants that shadow them, with read access to most things and configurable limits on write access – i.e., don’t purchase above this amount, don’t reach out to these people directly.

Today, it’s mostly all-or-nothing. You either give an agent full access or no access. OAuth exists for users, but there’s no equivalent for agents.

What about agent-to-agent coordination? In closed environments, MCP and A2A are making real progress. But when it comes to decentralized or trustless environments like the open web, is there a gap?

Right now, many website owners still operate from the mindset that automated traffic is bad. As a security measure, if they detect automated traffic, they try to block it.

The web needs to get more nuanced. The world is moving toward agents being the primary drivers of digital action. When an agent makes a request, it should be able to declare – here’s who I am, here’s who I’m operating on behalf of, here’s my intent.

There are commercial questions to sort out too. Is the agent paying for access? Or is the website advertising to the agent? But those are secondary.

The first step is a mindset shift. We need to move past the assumption that bots are bad and toward a model where agents can identify themselves and transact legitimately.

06 | The AI-human interface

Right now, users consume the outputs from your web agents through traditional channels like a web browser or email. In 5-10 years, what do you think the human-AI interface will look like?

My perspective on this question is heavily influenced by my time at Meta.

The team I led there was called FAIR Embodied AI. One of my teams built an image question-answering model that shipped on Ray-Ban Meta glasses, in collaboration with the product team.

I think there are a unique set of constraints that point to glasses as the right form factor.

They’re socially acceptable and lightweight. The world is already laid out for humans, so that’s the vantage point you’d want. And the experience I imagine AI should deliver is – a superintelligent assistant, watching me live my life, proactively and discreetly intercepting when you need it. Glasses fit into that.

Of course, there are a lot of ways that can go wrong. Too proactive, and you end up annoying the user. Not careful about privacy, and you end up in nightmarish scenarios; too careful, and you cut off necessary context.

But there is a magical balance great products can strike.

Is there a form factor that you would short?

Earbuds with cameras. I always found those a bit amusing. I never saw that working.

The eyes don’t belong where the ears should be?

Yeah, but also, you know, people have hair that gets in the way. It’s just not going to work.

For all the folks building in AI wearables, remember – people have hair. We’ll leave it with that insight. Thank you Dhruv.

Thanks for having me.

The industry celebrates contrarian thinking. Yet so often, the underlying mechanics – social proof, the pace of capital deployment, the pull of the power law – bias toward consensus.

Benny Chen strikes me as an exception. A founder who reasons from first principles and follows his conviction, independent of market sentiment.

Three years ago, Benny and several members of the team behind PyTorch – one of the most widely used frameworks for building neural networks – left Meta with the insight that enterprises would want to own their AI, not rent it.

In 2022, most did not see the world this way.

The prevailing wisdom said frontier AI capabilities required incredible scale and deep pockets. Most assumed the next generation of AI applications would be built on closed, general-purpose models from labs like OpenAI and Anthropic.

Benny and the team believed something different, that companies would want AI they could more directly customize and control.

So they built Fireworks, a platform that lets companies take open-source AI models,1 train them on their own data, and deploy them with speed and efficiency.

The world is now catching up. DeepSeek proved open-source models could compete at the frontier. Today, open models deliver ~90% the performance of closed-models — at one-sixth the cost.

Fireworks is riding this wave. The company processes 13T tokens daily (the same scale as Gemini’s developer API) for over 10,000 customers, including Uber, Shopify, and Notion. This October, three years after launch, they crossed $280 million in annualized revenue.

I sat down with Benny to discuss:

• Why he believes demand for open-source AI is about to hit an inflection point.

• How enterprises can exceed frontier model performance – with only 100 rows of data.

• Predictions for AI in 2026.

01 | Frontier models ≠ frontier capabilities

EO: Tell me about the decision to launch Fireworks.

Back in 2022, many people assumed that the future belonged to the big, closed model labs. Billion-dollar investments in training and compute were considered the price of admission.

What gave you the conviction to go the other direction, to build a company around open-source?

BC: Focusing on open-source and inference2 may have been contrarian to others. But to us it was very clear.

When we started, there was no ChatGPT. But we’d supported a lot of internal AI models in production at Meta, making sure workflows scaled economically.

Because of that experience, we believed most value in AI would come from inference.

We decided to build a company that helps developers deploy best-in-class AI profitably, and then we take a cut. That, we believe, is a more sustainable business model than raising huge amounts of money to come up with frontier models.

I think Sam Altman once said artificial general intelligence (AGI) could capture the “light cone of all future value” – that OpenAI is playing to capture all of humanity’s future economic value.

That’s an interesting proposition – that if you have a monopoly, no one else can ever figure out how to take it. I don’t think that’s ever been true in the history of capitalism. If there’s enough profit, someone will figure out how to compete.

But the predominant narrative is you have to raise a lot of money to stay at the frontier, and that developers will always demand frontier capabilities for their products to stay competitive.

It sounds like you believe something different.

I think “open-source” is just a fancy term for “sharing the burden” – a bunch of people opening up what they did so others can replicate it without making the same mistakes. And if you have tens of thousands of GPUs running in the background, mistakes are very costly.

Eventually, we believe people will act rationally. And sharing the burden for these costly endeavors is normally the rational thing to do.

By “act rationally,” you mean stop focusing as much on model capability, and more on cost?

Absolutely. One day, reality will hit. Cost will eventually become important. Everyone will have to figure out how to stay in business under those constraints. If you’re honest about that on day one, your business model will be much cleaner in the long run.

The other part of your question was whether enterprises will demand frontier capabilities. Yes, they will. But just because they need frontier capabilities does not mean they need frontier models.

Fireworks works with startups like Genspark to build custom evaluation suites,3 then use our training platforms – we call them reinforcement fine-tuning (RFT)4 platforms – to plug those evaluations in. This gives our customers frontier AI capabilities, but with open-source models.

When we do that – when we set up the data flywheel properly – “frontier model” and “frontier capability” are decoupled.

We believe that’s more sustainable. Because even if frontier models can see the traffic you’re sending them, they don’t know how the developer defines success for their specific use case.

That production data feedback loop — knowing what success looks like and how your product performs against that — that’s something application developers have that the model labs never will.

We are helping the builders who have that data.

02 | “Open-source models are about to take over.”

Help me make sense of the market as it pertains to open- vs closed-source.

On the one hand, open-weight models offer near parity on raw performance, at a fraction of the cost. For example, customers who move to your platform see an 8x average cost reduction.

So the value is there, but adoption less so.

In aggregate, these models only power 11% of total workloads – and that’s down from 19% last year.

How do you interpret all this?

Let’s break it down, around specific capabilities.

When it comes to software engineering, closed models are way ahead. You may not see that in benchmarks. But if you use these coding tools on a daily basis, you can tell – closed is much better. Within coding, Anthropic is the undisputed king.

Coding was the first killer use case for AI, and still represents a significant portion of total spend. Which is why closed models still dominate overall.

Open-source is also behind in multimodal understanding. That’s where Gemini is amazing, much better than everyone else at image recognition and video understanding.

Aside from those two domains — coding and multimodal — open and closed models are pretty close. Right now, there’s a level of performance that closed models deliver. But open-source models are catching up to that.

A lot of companies are considering both. They may be using closed right now, but open is very close in terms of capability. And when it flips, it will flip very quickly. I think open-source models are about to take over.

That’s a big statement. Why do you think that?

We work with a lot of application developers. And for non-programming use cases, the open models are already very close or better.

And by “non-programming use cases,” you mean tool calling and multi-step workflows?

Yes exactly.

A good way to understand it… For tasks where models aren’t yet 100% reliable – for example, software engineering, which is maybe at 20-30% today – you’ll always want the latest and greatest model. You want every advantage you can get.

But for workloads where there is a way to hit near-100% accuracy – and open-source models are starting to saturate those benchmarks – it’s more about usability, quality, and cost. That’s where open-source will win every time.

Is there a reason why the frontier labs are so much further on coding and multimodal understanding? And how sustainable is that paradigm?

With coding, Anthropic’s leadership is focused on programming use cases. The money they spend on acquiring data, environments, and evaluations are all very directed at coding. I respect that, focus is everything.

For multimodal, Gemini has YouTube. No one else has access to that kind of data.

Whether they maintain this edge is up to execution. It’s very hard to predict that, but my guess is they continue to do those very well.

So is there a scale or threshold where open-source starts to become more interesting for an enterprise customer?

Scale is one aspect. At Fireworks, we can deliver lower total cost of ownership5 with open-source.

The other aspect is self-sufficiency. The founders at these model labs have ideologies and constraints they impose on their model behavior. And so self-sufficiency is a big reason why people come to Fireworks.

By self-sufficiency, you mean they demand a level of customization they’ll never get with closed models?

Yes. With their own evaluations and model customization, they can control their own destiny.

One way to think about it… imagine if every business only had one supplier. That makes no sense. You want multiple suppliers throughout your supply chain. So companies see that risk, and they want to mitigate it.

Self-sufficiency through open-source keeps all partnership and M&A exit doors open for your company.

03 | Opening up the playbook

Fireworks RFT is a managed service that lets enterprises fine-tune open-source models, using reinforcement learning.

Fireworks describes it as giving developers “the same playbook frontier labs guard so closely” – but now applied directly to their own workflows and data.

How exactly does RFT deliver performance that can match or beat frontier models, like Claude or Gemini?

RFT is effective because of sample efficiency. You can customize a model with only 100 rows of data.

Developers are busy. If you tell them they need 10,000 rows of clean data to get started, they know that’s a day job for ten people to label the data, run quality control, etc. No one will do that.

But these developers are already collecting failure cases as they build their applications. They are constantly comparing new versions of Gemini, Claude, and GPT in their software. This means they often already have evaluation suites with 50-100 examples. Moving those directly into reinforcement learning is very straightforward.

On top of that, Fireworks offers a managed service that handles the correct defaults6 for developers – numerical consistency, tokenization, GPU failure recovery, etc.

How do you scale that service across such a diverse customer base?

Developers are building agents in different languages, frameworks, and environments. RFT only works if we can connect to all of these different agents without asking developers to rewrite their code. As a general principle, if you want to help everyone standardize around a particular methodology, it has to be built in the open.

So we released Eval Protocol (EP), an open-source framework that standardizes how any agent connects to RFT for training and evaluation.

Last March, Andrej Karpathy tweeted that there’s an “evaluation crisis,” that the standard industry AI benchmarks are no longer a good predictor of real-world performance.

EP seems designed to address this, to help developers run evaluations on their actual workflows.

For example, one core concept in EP is separating evaluation criteria (what constitutes “good” behavior) from the model producing it. That lets teams swap and compare how different models perform on the same, real-world tasks.

Can you walk through how you designed EP – and why?

First, some context. The closed model labs pay millions of dollars to buy simulated websites – perfect mocks of an e-commerce or airline ticketing system – to develop and test their models.

We don’t believe in that approach. These isolated environments rarely match what’s happening in production. Test databases might be incomplete, or the UIs behave differently.

At Fireworks, we help developers build evaluation suites that work with their existing agents, so their RL training environment matches production. This ensures consistency – across training, environment, and inference.

We also designed EP for developers without any machine learning backgrounds. For TypeScript and Rust developers, who had never touched Python and had built their agents in isolated, hosted environments.

We realized the only clean way to build evals for them is through observability – tracing agent outputs in production, labeling successes and failures, and feeding that directly into training. No need to package a working TypeScript agent into a Python container.

This “tracing-first” design means developers can build their agent however they want. We adapt to them.

Do you think EP grows demand for your own product? The theory being – as developers better evaluate how a model is performing, they demand more customization, then they turn to Fireworks to enable that.

Absolutely. I see buyers get more sophisticated when they run proper evaluations.

The more sophisticated the buyer, the more rational the buyer. And we believe open-source offers a more rational unit economic model.

Are there any new, cutting edge techniques you’re excited about?

Some, like Google’s new family of architecture Titans, which allows models to learn in production, on the fly.

But I’m honestly more excited about better data, rather than new techniques.

Before Fireworks, I was at Meta, moving ad models onto ASICs and GPUs for faster inference. I experimented with lots of new techniques and model architecture. My takeaway: better techniques only give you 20-30% of the gain. Most improvement comes from better data.

What are the gaps around data you still need to solve for?

Representativeness. In other words… Does your evaluation reflect what your customers care about?

Developers tend to over-index on things they personally notice, or failure cases they hit early on. Their evals rarely match exactly what their customers care about. And if your evals aren’t representative, you don’t get much value from RL.

The gap is translating what their customers want into concrete rubrics a language model can judge against.

So where are developers struggling? If they know what users want and can articulate their business model, why can’t they translate that into something a language model can interpret?

The hard part is moving developers from cardinal judgment (rating output on an absolute scale) to ordinal judgment (comparing several outputs on a relative basis).

For example, I’m a terrible judge of art. If you give me ten pieces and ask me to score each on a 1-10 scale, I can’t give consistent answers. But if you repeatedly show me two pieces and ask which I prefer, I’ll be much more consistent. I may not be able to articulate my internal rubric for scoring, but I can make reliable comparisons.

Language models work the same way. Setting up evaluations under a comparative framework is a big improvement.

Another place developers struggle is writing airtight rubrics. If you now force me to judge art on a 1-10 scale, I need to create a rubric without any loopholes.

That’s because LLMs are very creative. If you leave any ambiguities in your system, especially in production, they will exploit that. Writing evaluation criteria that close all those gaps is genuinely difficult, and that’s where we try to help developers.

04 | AI predictions in 2026

As we wrap, I’d love to do some rapid-fire questions.

Shoot!

Context management7 and state8 come up often as pain points in building AI applications. Are there any trends you’re excited about that solve for this?

As for context management, there have been a few recent papers around using images as a way to compress information, what’s called “contexts optical compression.”

Also, in production, we’re seeing agentic retrieval replace traditional RAG.9 This is a much more effective approach. Just like a human would say “I need the Q3 sales data” and then retrieve that information from the right file, the agent asks itself “What information do I need?” and retrieves it on-demand. This is aligned with what Claude is pushing with Skills – organizing tools into folders the agent can navigate, instead of shoving 200 tools into your context.

So agentic search is picking up, and I expect that will be a growing trend in 2026.

State, on the other hand, is more nuanced and application-specific. Sometimes “state” refers to whether you can replay an agent from the same point for error recovery. Sometimes it’s about how to do hand-offs between agents.

Agentic retrieval is happening everywhere, but state looks completely different across applications. My guess is there won’t be consolidation around state any time soon – it’s too context-specific.

What’s something in AI you think most people get wrong?

A big debate in Silicon Valley is around humanoid robots. Everyone agrees AI agents in, say, customer service and coding will make money. But people are 50/50 on whether humanoids will succeed.

I think it will be incredibly difficult for companies focused on humanoids to make money any time soon. There’s too much real-world complexity. And humanoids face competition from both actual humans and task-specific robots, which have much more efficient form factors for particular jobs.

What startup categories in AI are you most excited about over the next 2-3 years?

Without getting too self-promotional, AI infrastructure. There’s still so much to build.

Where in the infra stack specifically?

Companies doing semi-services, semi-evaluations. Those that can help businesses in a particular vertical digitize their processes, set up evaluation suites, and connect those to fine-tuning to improve models.

I like startups that don’t shy away from the fact that they do some services. That’s the right attitude. Customers are adjusting to it more because of the success of Palantir and their forward-deployed engineers.

Fully embracing that service component in order to help your customers solve a real problem – that’s critical.

Do you think those services will always come from a third-party, like Fireworks? Or for some segments, do see application providers offering this themselves, as part of their offering?

Third parties provide huge value today, but it depends on the vertical. In San Francisco, everyone says, “Of course you need evaluations.” But if you leave SF, it’s a completely different world. Most companies with the data – that could own their custom AI stack – have no idea how to get started.

There’s going to be a new BCG/McKinsey emerging from this. They’ll sit between infrastructure and applications, understanding intimately how agentic workflows should be evaluated, and helping customers build trust in the outputs from their own AI agents.

Trust is incredibly hard to build. New players who crack that trust layer can charge a lot of money for it.

This has been awesome. Thank you for the time.

Thank you for having me.

Gemini surpassed 650 million monthly active users and now leads on most performance benchmarks. This progress reportedly triggered a “code red” at OpenAI, a renewed push to compete and improve ChatGPT, and the release of GPT 5.2 last week.

To make sense of this moment, I spoke with someone who’s worked inside both of the companies that now sit at the center of AI’s biggest rivalry.

Logan Kilpatrick is a Product Lead for Google’s AI Studio and the Gemini API, helping translate Google DeepMind’s AI research into tools used by millions of developers worldwide. Before Google, he ran Developer Relations at OpenAI. He is also an active angel investor in AI-native companies, including Cursor and Cognition.

In our conversation, we dig into:

• Where Google sees its edge in the model race.

• How code generation is unlocking product extensibility – and why every startup now needs to be “code-adjacent.”

• Where token economics actually favors startups over big tech.

  

01 | “We want to be everywhere.”

EO: The latest Gemini release highlights two present advantages for Google – (i) model performance, especially in complex reasoning and multimodal understanding, and (ii) distribution — which is arguably more important.

You all have done a phenomenal job integrating Gemini across existing products like Search, Workspace, and Cloud, plus new ones like your developer studio and API, and the new IDE and agent builder Antigravity. It’s an elegant experience working across them.

Looking at the next 2-3 years, how does Google want to position itself against competitors like OpenAI and Anthropic, especially within developer networks?

Will this remain a direct, head-to-head competition across almost everything? Or do you see some natural specialization over time?

LK: I think there’s definitely things we’ll do that are unique, at least from a model perspective. Multimodal is a great example of this. It’s been a focus since the first Gemini release, and it’s where we really have state-of-the-art capability.

For example, with Gemini 3 Flash we now have something called visual thinking. We’ll talk more about it in January. But it lets you use code execution with multimodal understanding to preprocess images – before analyzing them.

So if you upload an image with poor contrast, and the model is struggling to interpret it, the model can automatically write Python code to adjust the hues or lighting, then re-interpret that corrected version.

That’s one example. But there is an interesting set of things that stem from multimodal, which have been a core advantage for Gemini. That’s all now amplified.

We’re also getting really good at code and agentic tool use. And many other things.

But what about competition with the other model labs?

These foundation models are inherently general. Because of that, you will continue to see head-to-head competition.

Companies are maybe carving out some niches as they go. The Anthropic models have historically been good at code. The OpenAI models have been good at chat. The interesting thing for Google is that we have such a wide set of products. The same model we build for Search is the same model we build for Google Cloud, which is the same model powering parts of the Waymo experience.

A wide range of products means a wide range of customers. And my hope is that we lead in generalization.

You’re seeing that today, and I think you’ll continue to see that in the future – especially as we sim-ship these models across more and more products with each new release. That strategy of tight product integration works well for us.

I was talking to Koray [DeepMind’s CTO] earlier today about this… we’re now seeing much deeper collaboration between our products and models. Historically, DeepMind was mostly research. But we’ve turned a corner. There’s now a lot more collaboration between DeepMind and products like search, the Gemini app, etc.

That was the most impressive part of the launch, for me. The intelligence capabilities felt very native. They enhanced the products I use every day, without changing the overall experience. I’m excited to see how that evolves.

But if I’m hearing you right, it sounds like it will be direct competition across the board. You don’t see a narrative where, say, Anthropic starts to own the enterprise segment, and Gemini owns consumer, because of the full-stack integration with Search and G Suite. You don’t see any of that?

Not for us. We want to be everywhere, and show up for everyone. That’s the challenge for Google, given our breadth and the number of use cases we touch.

Just take the developer use cases. AI Studio and the Gemini API have grown 20-30x over the last year. It’s becoming a substantial business.

The same is true with Cloud. Google Cloud is the sixth largest enterprise business in the world. We’re not ceding enterprise to Anthropic.

What I’d love to see – and Nano Banana [Google’s AI image generator and photo editor] is a great example of this… you can start to see how that underlying edge in multimodal understanding translates into new, state-of-the-art capabilities like image generation and editing.

There’s this cool interplay as you let an advantage like that play out, and see how it manifests into new capabilities and new products.

02 | “Every startup is now code-adjacent.”

I want to test a hypothesis with you. That we’re shifting from a phase of experimentation to one of inference… from “can AI do this?” to “how best to architect these AI systems?”

For example:

• Developers are moving from using AI for supplemental tasks (query-response code generation, single API calls) to systems design (building agents with more persistent context and multi-step planning).

• Backends are now optimized for AI agents as users, not just serving human-facing applications.

• Autonomous DevOps is creeping into the conversation – engineers want to delegate more configuration and deployment decisions to AI (though still early here).

Does that match what you’re seeing? How would you characterize this moment? Anything in your data on developer trends that is especially counterintuitive or surprising?

One top-level trend – we are in what I call the “LLM 2.0” era. If you look at how early-stage startups were building products a year and a half ago – versus the last six months – it looks fundamentally different.

Historically, to get the models to be useful, you had to do all this scaffolding work to ensure that the model had the right guardrails and configuration.

But now lots of companies – especially startups – are ripping out the things they built a year ago and starting from scratch. The model capability is now so good that what you need, what success looks like, and where you’re eking out the performance gain over the base model – that’s all fundamentally different than before.

So at the meta-level, that’s the largest transformation I’m seeing.

But what specifically is different, what’s driving companies to rip-and-replace?

Our customer base in AI Studio and the API is predominantly startups. With those companies, everything is now agent-first.

The other big shift is code. Startups outside of developer tools are now making code generation a core capability, a key value driver inside their product. There’s this interesting trend where almost every startup needs to be “code-adjacent” – because the capability of writing code is so foundational, so applicable across every use case.

When you say “code-adjacent,” what do you mean?

I’ll use a random example. A year ago, a product for financial planners wouldn’t involve any code generation. Today, if you’re building that product from scratch, there’s code being generated behind the scenes – agents writing custom scripts for each planner, each workflow.

And consumer is next. You wouldn’t expect consumers to want code. But actually, cutting-edge consumer products are now generating software on demand, based on what the user wants.

You’re already seeing this behavior in the Gemini app, with generative UI. Code is becoming the underlying mechanism for delivering personalized information and experiences across every product category. That wasn’t true 12 months ago.

So you’re saying the extensibility of products is orders of magnitude better now, and code generation is what’s enabling that?

Exactly.

03 | “We’re going after foundational capabilities.”

Two years ago, people dismissed LLM “wrappers” as too brittle to create real, lasting value.

Today, the consensus is that AI applications actually need proprietary architecture on top of foundation models to work – subsystems for reasoning, perception, memory, and execution.

Across these different subsystems, what are the biggest tooling or middleware gaps? Where are developers hitting walls that suggest the infrastructure just isn’t ready?

For example, I’m still hearing about friction in observability and traceability, weak context management, and limited support for cost control.

Of these, are there any big opportunities for third-party or open-source tooling, things that companies like Google won’t or can’t build themselves?

The observability piece is interesting. There’s been a lot of investment and companies taking a swing at solving that problem. Maybe none of those products have solved the problem yet, but there are a lot of people trying.

Well the hard thing is these models are non-deterministic. There’s no easy way to trace why they made a particular choice. It’s inherently hard to see what’s going on under the hood.

That’s true. And for us, the question of where we will and won’t go… we’re trying to raise the floor for everyone. We’re going after foundational capabilities.

RAG is a good example. In 2024, every developer was spending tons of time on RAG. It was top of mind. So about six weeks ago, we launched a tool that lets developers upload files and query them instantly, no need to build a RAG pipeline yourself.

That works for 90% of developers. Of course, there will always be advanced scenarios where you need to customize and turn every knob. But for most use cases now, you don’t.

That’s emblematic of the categories we’ll go after – foundational components, where Google has a unique advantage from a scale perspective, and we can raise the floor for everyone.

You also mentioned context management… I think there’s something really interesting there. Deep Research is a good example of how we’re starting to address that.

Part of why I love that product (and we have it in the API now for developers who want to build on top of it) is it handles a lot of context engineering for you.

End users don’t want to think about how to get the right information from Point A to Point B, so the model can answer their question. They just want to ask a vaguely-formed question and have the model go find the right context to answer it intelligently.

That’s what Deep Research does. It searches the web, but it also connects to Drive and other services. The user doesn’t have to think about framing the question perfectly or making sure the model has enough context. The agent figures that out.

That’s what I’m most excited about, and I think there are a lot of unique opportunities to make that work better across more products.

04 | “There’s a real advantage to being small.”

You’re an active angel investor in AI-native startups. What’s your theory for where value will accrue for new companies (versus incumbents) as the AI stack matures?

Maybe said differently, if you had to focus capital on one or two startup categories you think will outperform the broader early-stage market, what would they be?

I’m most curious about the underlying rationale. What do you think gives a startup a product edge in those domains over big tech?

I’ll note that I invest outside my capacity as a Google employee.

But the underlying truth of startups – and this isn’t a unique perspective – is that value accrues at the frontier. Larger companies are complex systems, focused on many different things. The advantage startups have in the AI era is the ability to move as fast as humanly possible and go after use cases that don’t quite work yet.

I was on a show earlier today, and the guest before me was the CEO of Wabi, a personal software creation platform. Six months ago, you couldn’t build that product. The models weren’t good enough at generating code. Now they are. This company was taking shots on goal, but now, all of a sudden, their product works and they can bring it to the world.

But is there a category that stands out for this moment? Over the next three years, for example, are you most excited about vertical AI, horizontal workflow automation, creative tooling, etc. What do you think is the frontier right now, given model capability?

I like the Wabi example because the new ways of generating code to solve bespoke problems is fascinating.

There’s another point I want to make, which is that in many AI-native companies, where there’s deep product customization, the economics actually favor startups. Can Google reasonably afford to put personal software into every product, for every customer, all at once? Maybe technically. But at our scale, it’s hard to deploy something that token-intensive across hundreds of millions of users.

Startups get to start small. You have 10,000 users, you build something great for them, you build momentum, and keep raising to fuel that growth. For expensive use cases like personal software – where you’re generating a lot of code per user – there’s a real advantage to being small. You get to take shots on goal without needing massive infrastructure from day one.

I hadn’t thought about the cost structure advantage that way, that’s interesting.

I’ve been most excited about the moment when non-technical users can build complex software.

There have always been two separate categories – users who know what they want, and then the people who can build it for them. Once those categories dissolve, the innovation potential feels very big.

I think it’s happening right now, which is exciting.

We’re on our way! On that note, I’ll let you hop. Thanks for your perspective.

My pleasure.

00 | A dynamic tracker

My last post analyzed whether investment in AI is exceeding demand. A couple readers requested a more regular pulse on how this is trending. I created this tracker, and will update periodically (around earnings calls) as new information becomes available.

01 | Open standards unlock trillion dollar markets

Even if AI goes through a correction in the near-term, demand will eventually catch up. After the dot-com crash, it took a decade for bandwidth utilization to match installed capacity. AI could follow a similar path, with intelligence steadily diffusing into software workflows over the next 5-10 years.

But to realize that promise – to turn raw model capability into real usage – AI agents need a more reliable way to coordinate.

In software, that coordination comes through open standards — shared, public specs that define how systems exchange data.

These standards are the precursor to network effects. They establish a shared language that binds applications and workloads into one, cohesive system.

Open standards unlock trillion-dollar markets, but capture none of the value. The biggest wins in venture capital capitalize on this paradox.

Early products from companies like Google, Stripe, Snowflake, and Databricks achieved dominance by commercializing the essential services that allow foundational protocols to reach users.

For example:

|| Google and the Web: In the 1990s, HTTP and HTML created a universal standard for fetching and serving documents across the Internet. These protocols connected web pages, but offered no way to navigate them. As the number of pages multiplied, discovery became the bottleneck.

Google’s PageRank algorithm solved this by ranking pages by the quality of their inbound links, rather than just keyword matching. This made the web searchable – turning HTTP from a document transmission protocol into a navigable information network.

|| Databricks and Big Data: In 2010, UC Berkeley released Apache Spark, an open-source framework for efficient, real-time data processing. Unlike earlier frameworks that ran jobs sequentially (read data → process → write to disk → repeat), Spark planned each job upfront, which let workloads run in memory and in parallel across machines. Within 2 years, Spark was 20x faster than its predecessors – far more efficient for big data pipelines.

But Spark was complex to implement. So the creators launched Databricks to handle the operational headaches (cluster management, job scheduling, and failure recovery) that kept Spark from mainstream use – turning an academic framework into the backbone of the modern data stack.

The biggest platforms in tech follow a consistent pattern: identify an emerging open standard → find the friction points preventing adoption → build the platform to eliminate them.

Today, AI is primed for that playbook.

02 | The landscape of agent protocols

There’s still no unified set of protocols that allows for seamless collaboration between humans, agents from different providers, and third-party tools.

Over the last few years, a patchwork of AI-native protocols has emerged — representing the youngest and least developed layer of the ecosystem.

Source: https://arxiv.org/pdf/2504.16736

The 2x2 chart below maps the landscape of agent protocols, across two dimensions:

1. what connect agents to (third-party tools vs. other agents)

2. the domains they operate in (general-purpose vs. domain-specific environments).

Each color indicates the entity that maintains the protocol: commercial vendors like Anthropic and Google (blue), open-source foundations (gray), and academic research groups like Oxford and CMU (red).

A few insights after spending time in the white papers and talking with developers building with these standards:

(A) The developer ecosystem is beginning to coalesce around three standards.

AI agents are digital assistants that can work independently to get things done. Three new standards are “rising to the top” to help these agents connect with apps, access data, and collaborate with one another.

• MCP (Model Context Protocol) connects AI agents to your apps and data

• A2A (Agent-2-Agent) allows agents to coordinate within organizations

• ANP (Agent Network Protocol) enables agents to transact across the open internet

Some real world examples:

• MCP would allow your personal AI assistant to query your Excel budget or dispatch emails via Gmail.

• A2A would allow your company’s expense agent to flag unusual spending, coordinate with your compliance agent to verify policy, and escalate to your finance agent for approval.

• ANP would allow a personal shopping agent to purchase clothes online from a Shopify store that you’ve never interacted with before.

Each of these standards are complementary – in theory, one agent could use all three (MCP to access your company’s tools, A2A to coordinate with coworkers’ agents, and ANP to interact with external services across the internet).

Sources: MCP 1 2 3 4 5 || A2A 6 7 8 9 || ANP 10 11 12

Today, MCP and A2A are the most widely used, although neither has been fully embraced by the developer community.

Both of these standards work best inside companies or between trusted partners because they:

• are designed for environments where everyone knows and trusts each other (i.e., security is not inherent to the protocol itself).

• work best for predictable, repeating tasks.

• connect through known addresses or approved lists – not open discovery.

A2A supports more complex workflows than MCP. Instead of simple one-and-done requests (like MCP), A2A lets agents have ongoing conversations. They can pause a task, share progress updates with one another, and hand off work to another agent. However, A2A has limitations. Today, only two agents can coordinate on a task at once, and it requires careful setup to run smoothly.

ANP takes a different approach. It’s built for agents to collaborate securely anywhere on the web, even with parties they don’t know or trust. However, it is a newer standard – very early in the adoption curve, complex to implement, and computationally heavier to run than A2A or MCP.

(B) There is no dominant protocol – yet.

We are probably 12-18 months away from any of these standards reaching critical mass.

MCP has seen the fastest adoption of the three, driven by: (a) marquee early adopters (Square, Apollo, Replit, Sourcegraph), and (b) low network dependence (one client and one server are enough to start delivering some value).

A2A has some buzz, but faces hurdles. Over 50 partners were announced at launch (including Box, Salesforce, SAP, and MongoDB), but adoption has slowed because it’s complicated to set up and lacks good tooling for fixing bugs.

I could see the ecosystem evolving in one of two directions:

1. Specialization: MCP becomes the go-to for connecting to tools, A2A dominates inside companies, and ANP handles the open web. This would be similar to how the early internet developed – TCP/IP, HTTP, and DNS each solved different problems and worked in tandem to make the web possible.

2. Consolidation:An enhanced version of one of these protocols – or a new one altogether — becomes the “universal handshake” for agent communication, eliminating the need for multiple standards.

(C) Key building blocks are still missing.

Several components still need to be built for these open standards to scale:

(i) Native security. Right now, both MCP and A2A depend on external security – they assume the environment they’re running in is safe. ANP encrypts data in transit, but the data becomes vulnerable once it’s decrypted for use. To safely handle sensitive workloads in domains like healthcare, finance, or law, these protocols need stronger, built-in safeguards.

(ii) Better multi-agent coordination. Current protocols mostly support one-to-one interactions between agents. This works fine for smaller networks, but breaks down at scale.13 What’s missing are communication primitives that let agents have better group coordination — i.e., ways to broadcast updates to relevant subsets, route messages through intermediary agents, and manage network membership natively within the protocol.

(iii) Shared memory. Current standards still treat memory as local. MCP and ANP have no memory function in their protocol design (though individual agents can use tools like LlamaIndex or Mem0 to remember things on their own). A2A allows two agents to share state14 data while collaborating on a task, but this isn’t accessible to other agents or reusable later. This means agents often redo work that others have already done.

03 | The investable opportunity

Breaking down these protocols reveals where new platforms can be built. Two opportunities stand out today, with more likely to surface as these standards evolve:

(A) Agentic search

ANP imagines a future where AI agents can find and work with each other across the entire internet.

Here’s how it’s designed to work:

Every service agent publishes an “Agent Description” (AD) – essentially a resume in a standard format (JSON-LD) that lists what the agent can do, what data it has access to, and any limitations. In aggregate, all these descriptions form an “Agent Discovery Network” (ADN), a distributed directory that lets agents find the right partner for any task.

Client agents can search this directory in two ways:

• Active search: directly querying specific domain addresses to find known agents

• Passive search: using specialized “Search Agents” that constantly crawl the ADN, finding and indexing these Agent Descriptions

In practice, this agent discovery network and search agents have not been built yet.

This represents an enormous opportunity.

If ANP (or a protocol with similar primitives) becomes widely adopted (still a big if!), there’s an opportunity to build the discovery layer on top, creating a new type of search engine for the agentic web.

Unlike Google’s index of static pages, agentic search would rank agents on more real-time data:

• Identity: Who is this agent, who runs it, and how do I verify it’s legitimate?

• Capabilities: What can this agent actually do? (chat, analyze data, control systems)

• Connection details: How do I send and receive requests?

• Security requirements: How does it prove who it is, and what permissions do I need to work with it?

• Support contact: Where do I go if something breaks or I need human help?

Because ANP supports blockchain-based identity verification, this search layer could seamlessly connect traditional web services (web 2.0) with blockchain-based services (web 3.0) – routing requests to whichever option performs best at the lowest cost.

Instead of a static directory, you’d have a dynamic, machine-readable index where agents connect based on current needs and conditions. This creates new business models – agents could pay for better placement, or earn reputation through successful collaborations.

Over time, this evolves into a self-reinforcing marketplace for machine intelligence, where the most effective agents attract more use, improve through feedback, and rise in visibility – a classic network flywheel, built into the fabric of the protocol.

(B) Shared memory

Today, agent memory remains siloed. Individual agents can remember things locally, and A2A enables temporary context sharing between two agents. But there’s no persistent, collective memory that multiple agents can access and build upon.

A shared memory system would give agents a common space to store and access reusable knowledge – summaries of past work, intermediate calculations, and learned patterns.

Think GitHub for agent knowledge, where every interaction contributes to a growing repository of reusable intelligence agents can draw from.

This would complement (not replace) an agent’s local memory. And it would connect naturally with existing standards, using A2A and ANP identity standards to keep everything organized.

The first version of this product would be a good fit for companies running their own internal agent networks, where security and access controls are already in place. Over time, it could expand into a shared knowledge layer across organizations – where each agent’s work makes the entire network smarter, faster, and cheaper to operate.

The winning product will need to balance:

• Versioning: Ensuring past results remain reproducible even as knowledge evolves

• Retention: Balancing what to keep versus what to discard as data accumulates

• Access and security: Keeping sensitive information isolated while sharing general knowledge

• Performance: Doing all this without slowing down real-time agent interactions

If done well, this shifts agents from ephemeral, stateless tools to a collective intelligence that improves over time. It would give the agentic web its first true substrate for memory.

Over the last three years, the AI conversation has been dominated by big tech and the model labs. There will no doubt be a ton of value creation (and destruction) as the model and hardware layers find equilibrium.

But however that shakes out, there’s another story unfolding further up the stack – how do agents discover each other? Share context? Collaborate across organizations?

In this story, the bottleneck isn’t intelligence – it’s coordination.

The open standards addressing this are still in their infancy. Startup value won’t come from building bigger models, but in the bridges that connect them.

We’ve seen this before: Open standards lay the foundation for new markets, then commercial platforms make those markets real.

→ HTTP created the web… Google made it navigable.

→ Spark democratized big data… Databricks made it usable.

Agent protocols are up next.

UPDATE - NOV 2025

I’m now tracking AI token consumption in real time. View the live tracker here →

For updates on this tracker and fresh analysis on other emerging technology trends, subscribe below.

Subscribe now

01 | The rhythm of exuberance

In 2000, the Internet looked unstoppable.

Telecom carriers poured over a quarter of revenue into fiber networks, betting Internet traffic would double every three months. Market concentration spiked, as investors believed control of infrastructure would cement long-term advantage. The Shiller CAPE ratio, a measure of how expensive the stock market is relative to historical earnings, hit an all-time high of 43.8 (more than double the average of the prior 15 years).

Then the dominos fell.

Network utilization lagged. Prices collapsed under excess capacity. Telecom carriers, who had booked revenue from leasing unused fiber to one another, were forced to write down these receivables as losses. Defaults rose. Equity values deflated.

By 2002, only 2.7% of installed fiber was in use.

The modern Internet – cloud, streaming, big data, mobile – eventually arrived. But not fast enough to prevent a correction.

History doesn’t repeat itself, but maybe it’s starting to rhyme. Big Tech is investing big in AI infrastructure, and investors are buying.

On inflation-adjusted basis, capital expenditures are now roughly twice the level at the 2000 peak. The six largest tech firms now make up over 30% of the S&P 500, double the concentration we saw in 2000. The CAPE ratio is the second highest it has ever been.

Footnotes: 1 2 3 4 5 6 7 8 9 10 11 12

Of course, comparing 2000 to 2025 isn’t apples-to-apples.

In 2000, investment went into networks of fiber and routers, long-life assets financed mostly with debt.13 Today’s infrastructure – GPUs and servers – depreciates faster, and is funded by cash-rich tech giants (though some leverage is making its way into the system). And unlike in 2000, today’s market is concentrated around firms with real, 15+ year moats in distribution, data, and developer ecosystems.

Still, it’s hard to ignore the parallels:

Big Tech is investing ahead of demand, on the premise that:

• demand for AI will soon rapidly permeate the real economy

• scaling compute is necessary to maintain a competitive advantage in AI (new MIT research disputes this, showing steep diminishing returns to additional compute and convergence of model capabilities over time).

Market power is highly concentrated.

Circular financing is back: Chipmakers, cloud providers, and model labs are funding one another through prepaid deals, minimum-spend guarantees, off-balance-sheet projects, and direct debt and equity positions — arrangements that can inflate real demand.

AI Ecosystem Capital Flows14

Fundamentally, both cycles rely on the same underlying premise → real demand will surge before the bill comes due.

02 | Can demand keep up?

This context raises two important questions:

1. How much – and how fast – must AI usage grow over the next several years to justify today’s investment?

2. Is current demand roughly on pace?

I built a simple model to answer these questions. (Take the results as ballpark figures, not precise forecasts.)

For this analysis, I measure AI demand in inference tokens.

A token is the basic unit a model uses to process data – think of them like kilowatt-hours for electricity. Inference refers to tokens used to generate a response to a new user prompt, as opposed to tokens used for training or model development.

To estimate how much AI usage must grow to justify current investment, the model links infrastructure spending to inference token demand in four steps:

1. Direct CAPEX spend. The projected spend on GPUs, servers, and compute hardware – assets that directly power AI token consumption. This excludes indirect inputs (e.g., investment in real estate, site development, and energy systems). I run these projections in two scenarios – (1) an aggressive buildout, based on analyst estimates, and (2) a conservative “boom-and-bust” case that mirrors the dot-com-era investment cycle.

2. Requisite revenue. The annual customer revenue needed to generate a sustainable return on investment for each scenario. This assumes industry norms around overall asset and inference utilization, depreciation, and CAPEX-to-revenue hurdle rates.

3. Blended token price. Estimated from OpenAI, Anthropic, and Gemini list pricing, factoring in standard input-to-output token ratios, how prices have scaled over time, and patterns around how users upgrade to the latest model.15

4. Token volume. Dividing the required revenue by the blended token price yields an estimate of how much AI usage would be needed to justify the build-out.

Based on this, an aggressive, $3.1T buildout over the next 5 years implies AI usage must compound at 2.8x every year through 2030. A more conservative $1.3T path still requires 2.5x annual growth.

Footnotes: 16 17 18 19 20 21 22 23

To put this in context, both scenarios would require a steeper adoption curve than any prior tech cycle, including the early internet, mobile, and cloud.

Footnotes: 24 25 26 27

Yes, this would be unprecedented growth. But it is not impossible to imagine when you consider the maturity of our digital landscape.

Today, AI can be shipped through existing products – SaaS, app stores, browsers – that billions of people already use. It can plug into workflows with a simple API call, running on cloud infrastructure that abstracts away hosting and scale.

With distribution this wide and deployment friction this low, adoption certainly could happen faster than we’ve seen before.

03 | A question of timing

So far, AI consumption is tracking well against these curves.

Both modeled scenarios require a ~9-12% cumulative monthly growth rate in inference token consumption over the next couple years. Microsoft is currently tracking to 14%,28 and Alphabet saw 15% per month from August to September (although that is down from 31% CMGR in the prior ten months).29

It is still too early to know for certain whether we are on the right trajectory. I’m monitoring three developments that could indicate an impending correction:

(1) Token growth. On an absolute basis, inference token demand is still within target. But over the past couple months, there’s been a deceleration. Watch the next few earnings calls. If monthly token processing falls consistently below 9-10% growth, or if companies stop disclosing the metric altogether, it may suggest the market is over-committed.

(2) ROI in the real economy. AI still needs to prove wide, durable value beyond chatbots and coding assistants — and fast. Many enterprise deployments aren’t yet showing measurable ROI. On the consumer side, usage is heavily subsidized (only ~5% of ChatGPT’s users pay). These dynamics aren’t unusual this early in a tech cycle. But risk will build as more capital piles into the hardware layer – especially into assets whose economic life may be shorter than what is being reported to shareholders.

If model labs keep emphasizing new releases, benchmark scores, and pilot announcements while remaining quiet about large-scale production deployments and customer renewals, it could signal that adoption in the real economy is lagging behind the hype.

(3) A break in scaling patterns. This analysis assumes model performance scales in tandem with compute and data. A step-change in AI efficiency could break this pattern – e.g., if an entirely new model architecture emerges that requires far less compute to achieve the same performance, or if smaller/open-source models prove more effective than large-scale proprietary ones for specific use cases.

Today, 13% of AI workloads run on open-source models. Whether that share rises or falls will be telling.

I’m also tracking platforms like Fireworks and DeepInfra, which simplify deployment of smaller and open-source models. If those platforms grow faster than the overall inference market and capture developer mindshare, it would suggest that near-term demand can be met with lower-cost solutions — thus reducing the need for major new infrastructure spending.

Netting it all out, I think we are likely in an over-investment phase.

Inference token consumption is growing well, but there are signs it’s starting to slow. Most AI-native products are good for individual productivity in coding or writing, but fall short on full workflow automation or enabling real collaboration. If that persists over the next 12-18 months, it could cap near-term demand.

This view tracks with researchers like ex-OpenAI’s Andrej Karpathy, who argues reliable, agentic systems “just don’t work” yet, and will arrive through a steady, multi-year build — not overnight.

If there is some over-investment today, that might be good news for startups. Historically, when infrastructure supply runs ahead of demand, the next wave of value usually comes from networks and coordination that can be built on top.

After the 2000 fiber glut, TCP/IP and HTTP standardized communication over the internet, turning surplus bandwidth into the interconnected web. In the big-data era, open frameworks like Apache Hadoop enabled more efficient coordination between data storage and compute workloads, unlocking idle server capacity.

AI could be on the cusp of a new coordination layer.

Right now, there’s a quiet wave of new interoperability standards coming to market. These frameworks have the potential to translate raw model capability into cohesive, multi-agent systems – creating new ways for agents to communicate, share context, and compose workflows together. Startups that can commercialize and scale these protocols have a chance to build the control layer for networked intelligence, turning individual agents into a functioning economy.

Next post, I take a closer look at emerging multi-agent standards – what they are, how they work, and the market and network dynamics they could unlock.

01 | “Walled gardens” are a relic.

Something’s shifting in how people are talking about AI. Early excitement seems to be giving way to tacit skepticism – especially from users implementing these tools in their day-to-day workflows, and developers who understand what’s going on under the hood.

This skepticism stems from a fundamental problem: today, most AI tools are only creating the illusion of productivity.

AI generates content quickly, completing tasks in seconds. But the quality is inconsistent. Without strong fine-tuning, robust memory architecture, and a clear scope around what the system should and should not own, the output can get mediocre. AI tools introduce subtle errors – inaccurate references, hallucinations, polished UIs hiding fragile back-ends – that humans have to fix. This leaves users underwhelmed and less efficient.

That gap – between how effective AI feels at first and how it actually performs over time – is a material risk, and one I don’t see many investors pricing in. Given where the technology stands today, we may have overestimated the staying power of many AI products, especially those that promise to automate entire workflows or think on our behalf.

A recent MIT study found that overreliance on tools like ChatGPT can impair memory and reduce our capacity for independent thinking. That’s not just an ethical concern, it’s a product risk. When tools take too much control, buyers stop paying attention. They check out faster and are more likely to churn when the results don’t hold up.

So why are so many of these tools falling short?

In part, because of how they’re designed.

Most AI products today are built on closed, proprietary architecture. These “walled garden” products resemble traditional SaaS and consumer apps – only now with autocomplete.

Closed applications predefine the logic, features, and data flows. End users (or agents) can tweak inputs, but they can’t rewire the underlying source code. Interaction is limited to a UI or managed endpoints that abstract away the nuts and bolts of how the system actually works.

That abstraction made sense in the SaaS era, when building software required a large team of expensive developers, and when users favored simplicity over control.

But today, code is cheap to produce and software can be written with natural language. This means users and agents can now inspect, rewire, and extend product capability themselves, a trend that will only accelerate over the next 2-3 years.

In this new paradigm of flexible, participatory software, abstraction from source code creates unnecessary rigidity in the product experience.

And that rigidity is a competitive liability.

AI startups building on closed foundations are vulnerable. It’s easy for incumbents – who are also built on proprietary stacks, but with broad distribution and deep pockets – to integrate AI into existing workflows and feature-kill startups overnight.

And the usual startup defense – amassing a data moat as the company scales – is no longer a reliable strategy. With the right training methods, models do not need a large dataset to generate tailored output.

As a result, many of today’s AI startups, even those with fast initial growth to $10M or $20M ARR, may struggle to sustain themselves over time.

02 | Orchestration is the new moat.

So where can startups build a competitive advantage?

Increasingly, at the orchestration layer. This is the part of the stack that governs how software behaves — how inputs are routed, components are selected and sequenced, workflows are modified, and network incentives are managed.

Startups can win by building products that users can customize and shape themselves.

This follows a familiar pattern in software: when a component of the software stack suddenly becomes cheap and widely accessible, value shifts to controlling how that component is then manipulated and used.

In the cloud era, data storage became the commodity. Value moved to building large, unique data sets, and building systems that could manipulate that data in ways others couldn’t.

Today, AI is making code the commodity. Anyone can generate features, and data matters far less. So the value is now in product customization and flexibility – how users can build and manipulate the code to meet their objectives.

In a world where orchestration is the moat, open-source companies have a structural advantage over their "walled garden" counterparts.

Here’s why:

1. Open-source products are directly programmable.
By exposing core components — like the code, model weights, or data — open-source systems let developers directly modify how the product works. This enables far greater flexibility and customization than closed systems, which only allow for configuration within predefined boundaries set by the vendor.

2. Contributor networks will amplify open-source advantages.
Open-source ecosystems benefit from global contributors who extend functionality, add integrations, and patch issues in real time. This speeds up development and keeps the product aligned with the latest tools and use cases — a key advantage when orchestration and flexibility matter more than ever.

3. Incumbents must self-cannibalize in order to compete.
Open-source startups win by offering free, flexible alternatives to expensive, closed products, then monetizing through add-ons. Incumbents can’t follow this open-source playbook without exposing their code or allowing self-hosting, moves that would erode their margins and undermine their business model.

4. Better alignment between usage and revenue.
As orchestration becomes the core source of value, companies need pricing models that scale with usage and integration. Traditional software is sold as a fixed-cost product – priced per seat or per tier – which breaks down when value comes from ongoing customization and system-level control. Open-source flips this. It moves both costs and revenue to a variable structure. Teams start with a free, self-hosted product, pay only for the infrastructure required to run it, and adopt paid add-ons like hosting, tooling, or support as the product becomes more deeply integrated into their workflow. This creates a more flexible cost structure and better aligns revenue with value creation for the customer.

03 | How to make open-source work.

Open-source software is well-suited for a world where orchestration is a key differentiator. But without thoughtful design, these systems can become brittle and hard to manage.

Winning products strike a careful balance… flexible enough to customize, stable enough to scale.

The best open-source products start with strong default configurations that simplify setup and deployment. They need to work out of the box for teams that never customize a thing.

At the same time, these products need to offer clear extension points that guide users on where and how to modify the product without breaking its core logic.

They must also support portability, giving users control over their data, the freedom to deploy across environments, and easy ways to connect into external systems.

In open-source, every new contribution can introduce bugs or security risks. These systems need strong quality controls. CI/CD pipelines must go beyond syntax checks to ensure code changes behave as expected and come from trusted sources. AI can help automate this, but only if the vendors define what “safe” and “correct” mean, and bake that into the system design.

In open-source, the core product is usually free, and companies make money by selling add-ons. As value shifts to orchestration, the most valuable add-ons will be the ones that help teams run, manage, and extend the system more effectively. That includes:

• Agentic companions. AI agents that automate tasks, trigger workflows, and coordinate across components.

• Monitoring and alerting. Dashboards to trace system behavior, with automated alerts to detect and debug failures.

• Enterprise integrations. Prebuilt connectors that reduce integration risk and speed up deployment.

• Network access and transaction fees. Connecting to live systems — like payment networks or third-party services — and taking a cut of financial or data transactions.

• Collaboration and governance. Shared templates, usage analytics, and role-based access controls for multi-user teams.

Finally, great open systems are observable. They help users understand system behavior, debug issues, and ensure modified deployments are running predictably.

The best AI products going forward will be the ones users can shape directly.

You can’t just wrap a black-box model in a closed app and expect to beat billion-dollar incumbents. They can do that too, and distribute it faster.

What they can’t do is open up their systems, at least not without cannibalizing their existing business.

That’s where open-source has an edge. These products put users in the driver’s seat, giving them the power to inspect, remix, and extend the system to fit their needs. This level of participation builds trust, drives retention, and keeps users engaged.

It’s a hard product challenge. But it’s the best path to defensibility. And frankly, more exciting category to invest in, and help founders – and now users – build together.

01 | A new economic paradigm

I’ve spent the past few weeks trying to make sense of the shifting economic landscape, and what it means for technology markets. Bridgewater’s recent newsletter, “Adapting to a New Reality,” offers a bold take on this moment:

To state the obvious: we are now facing a radically different economic and market environment that threatens the existing world order and monetary system... This new macroeconomic and geopolitical paradigm is turning past tailwinds into headwinds and reshaping global flows of capital.

If you were to list the defining characteristics of recent decades and compare them to today, you’d struggle to find much overlap. We have been through many big economic shifts over Bridgewater’s 50-year history, so we don’t speak lightly when we say that this looks like a once-in-a-generation one.

There is still a lot of uncertainty around the degree and pace of change. But the trajectory is becoming increasingly clear – we’re entering a new environment, unlike anything most of us have invested or operated in before.

For technology and venture investors, I don’t think this requires a full reset. But it is a moment for first-principles thinking:

→ How is the macro environment changing?

→ Where are we in the technology cycle?

→ And therefore, how does the venture playbook need to adjust?

02 | How is the macro environment changing?

Two fundamental shifts are currently underway in the political economy:

1. Fragmentation of global alliances and supply chains, which could drive down U.S. equity prices.

2. Growing risk of U.S. stagflation.

Both will fundamentally redirect capital flows and reshape overall demand.

A | Globalization → balkanization

For the past decade, U.S. stocks have soared, lifted by decades of global trade and easy, cross-border investment. Today, U.S. equities trade at a 70% premium to the rest of the world — meaning they need to attract about 70 cents of every new dollar invested in global equities just to maintain their current value.^[1]

This is an extreme requirement, a higher bar than we’ve seen at any point in the last half-century.

Source: Eaton Vance

For U.S. equities to sustain these valuations, two factors must hold:

1. A large and persistent capital surplus, meaning foreign investment into U.S. assets must continue to significantly exceed U.S. investment abroad.

2. Continued access to global markets. Today, foreign demand is driving a meaningful (and growing) share of U.S. company’s revenue and earnings.^[2]

Trump’s agenda — reversing trade deficits, U.S. self-sufficiency, and tighter government control over industries like energy and defense — poses a significant threat to both. The recent U.S. Treasury sell-off and rising yields are early signs of this strain taking hold.

To be clear, Trump’s policies are simply the latest (and unnecessarily chaotic) expression of this trend. But international decoupling has been building for years. Global trade restrictions have tripled since 2018. And even Biden-era policies like the CHIPS and Inflation Reduction Acts reinforce a broader trend toward reshoring and national self-reliance.

As globalization fractures, expect a compression in U.S. asset prices. The biggest impact and pain will be felt in the most concentrated parts of the market: (a) public tech megacaps, and (b) exits for late-stage private tech companies, especially those with stretched valuations, additional scale requirements to hit profitability, and cash reserves that can be traced back to foreign investment.

B | The risk of stagflation

Over the past decade, U.S. equities were buoyed by strong growth and earnings, fueled in part by government borrowing. Modest growth in tax receipts, rising expenditures, and strong foreign demand for Treasuries allowed the U.S. to run large deficits without major consequences.^[3]

This borrowing injected liquidity into the economy, boosting household demand and, in turn, driving steady growth in corporate revenues and profit margins.

Source: Bridgewater. “The Growing Risk of U.S. Assets.” Mar 6, 2025.

Today, that dynamic – which American workers, consumers, and investors have long taken for granted – is under threat.

Rather than expanding the tax base, the current administration is pursuing aggressive spending cuts through DOGE, the upcoming tax bill, and a commitment to public sector deleveraging.

If government borrowing falls, household demand and business performance will likely weaken. And unless private sector borrowing rises sharply to make up for the gap — unlikely given tighter credit and waning consumer confidence — economic growth will slow. At the same time, new tariffs (both U.S.-imposed and retaliatory) are adding inflationary pressure.

If these trends hold, there’s a real risk of stagflation, which would leave the Fed constrained, unable to stimulate the economy without worsening price pressures.

This isn’t a comfortable diagnosis. But I do believe a more clinical understanding of these dynamics, combined with a clear sense of where we are in the tech cycle, can help investors navigate the road ahead — and capture value while others hit pause or cling to the old playbook.

03 | Where are we in the technology cycle?

Technology innovation evolves in 10–15 year cycles, usually somewhat independent from broader macro forces:

Phase 1 Each cycle begins with a breakthrough that creates a step-change in capability, followed by a short-term surge of excitement, over-investment, and an eventual crash.

Phase 2 New, open standards emerge, enabling broader distribution and sustainable adoption. Commercial applications are built on top of those standards, organizing users, data, and transactions in new ways to capture value, and entrenching themselves through network effects and scale.

Phase 3 As adoption matures, the underlying technology hits market saturation. The marginal gains of using the technology shrink, and asymmetric upside fades. A new breakthrough is needed to restart the cycle.

Each cycle builds on the infrastructure of the last, so the opportunity for value creation grows larger with each subsequent wave.

Today, we are entering a new era of intelligent compute, somewhere between Phase 1 and Phase 2.

The transformer model triggered a step-change in machine intelligence, catalyzing early excitement and a surge of investment. But most AI startups today still rely on proprietary models they don’t control, and cloud infrastructure built for static data and human-centric workflows.

Going forward, durable innovation will require new, open standards that can scale AI natively across industries, not just patch it onto legacy systems.

Today’s moment in technology evolution parallels the late 1990s, before the dot-com bubble. But the financial and competitive conditions are meaningfully different, suggesting history won’t repeat itself in exactly the same way:

The opportunity is larger. If historical patterns hold, the total addressable surface for new AI applications should be multiples larger than last cycle, as AI unlocks broader capabilities and pushes software deeper into workflows that were previously out of reach.

The incumbents are stronger. They are software-native, not legacy industrial models. Big Tech still owns distribution, compute, and capital. These incumbents can iterate faster and absorb innovation more efficiently than what we’ve seen in prior cycles.

Private markets are more robust. Illiquidity, dry powder, and momentum-based psychology have delayed the normal flushing out of risk, making a sharp “crash” less likely.

04 | How does the venture playbook need to adjust?

To summarize, U.S. technology markets are facing the following dynamics:

• As the U.S. pulls back from the global economy, asset prices, especially in late- and megacap tech, are likely to fall. Expect a lower ceiling on valuations going forward.

• The U.S. economy is slowing, with businesses and consumers facing higher costs, weakening demand, and early signs of waning access to global markets and capital.

• We are in the early phases of a new technology cycle. As AI permeates the economy, it will unlock entirely new markets and power economic growth. But in the near-term, private market dynamics may continue to mask fragile business models. Early-stage investors who see this clearly will avoid the worst excesses.

• Startups today are competing against software-native incumbents. Without structural product innovation – new architectures, new data sets, new methods for interoperability – it will be difficult for startups to maintain a durable edge.

All that said, early-stage venture remains an attractive category.

It has always been more insulated and idiosyncratic than other alternative assets. It usually represents only a small slice of portfolios and the broader economy. It is long-duration and deflationary by nature. And historically, it is a source of outliers, even in turbulent times.

But in this new environment, delivering alpha will require a reset, building portfolios that are even more uncorrelated – anchored by companies with structural product advantages.

Early-stage investors today should focus on a few key principles:

A | Centralized distribution → open-source diffusion

In the last cycle, the dominant path to value creation was achieving scale quickly — one product, everywhere. Today, as globalization fractures, technology must be as flexible, permissionless, and adaptable to local needs as possible.

Open-source and public architecture is best positioned to power this shift.

In a world of ever-changing trade restrictions and rising geopolitical conflict, users and businesses will favor software that is easiest to deploy, modify, and control. Open-source offers the most convenient and frictionless path – minimizing adoption barriers, maximizing local flexibility, and allowing users to extend functionality without waiting on vendors.

There’s historical precedent for this. In the 1990s, open-source encryption moved across borders freely, despite government resistance. Developer collaboration and free distribution outpaced export controls and outperformed centralized, government-sponsored encryption standards.

The same forces are at play today, amplified by AI-driven development, which makes it easier than ever to customize and monetize open-source applications.

Code doesn’t stop at customs. And in a more fractured world, open-source will be the default engine for technology diffusion.

B | Portfolio diversification → portfolio concentration

In the last macro cycle, broad, early-stage indexing could work. You could hold a wide portfolio, and a handful of moderate winners would be enough to drive acceptable returns. Capital consensus could support mediocre products – companies could survive longer by raising the next round, keeping valuations and portfolio marks afloat.

In the new macro, these dynamics are unlikely to hold.

Expect failure rates to rise as underperforming companies lose access to capital. And if foreign investors walk away from U.S. assets, yields continue to rise, and public debt crowds out private investment, allocators will demand even higher returns in venture capital to justify illiquidity and risk.

Without high, concentrated ownership at exit, moderate exits won't move the needle on fund-level outcomes.

Portfolios must concentrate capital earlier and position themselves to be even more uncorrelated — or risk getting sucked into unacceptable mediocrity.

C | Vertical integration → composable architecture

The last generation of software companies won by building proprietary, vertically integrated products. Salesforce, for example, became a $250B company by centralizing customer data, controlling integrations, and expanding its own feature set across a single, standardized platform. This was the fastest path to dominance — both technically (ensuring reliability and control) and commercially (scaling a single platform across rapidly integrating markets).

Today, that model no longer fits.

Customers need software that: (i) flexes to local requirements, (ii) integrates seamlessly into preexisting networks, (iii) enables user-led customization, and (iv) automates workflows across disparate systems. Advances in encryption and AI now make this possible.

On this dimension, the incumbents are trapped. Their economics depend on locking in users and data. They can bolt on integrations and AI automations, but they can't truly open their architecture without cannibalizing the lock-in and rigid product formats that sustain their business models.

In this new cycle, value will accrue to startups built on open, composable systems — architectures that allow users to adapt and orchestrate their own workflows.

This changes how early-stage investors must underwrite companies. It’s no longer enough to evaluate static feature differentiation, data moats, and product roadmaps. They must evaluate the underlying architecture:

• Can the system adapt and operate across fragmented environments?

• Does the product gain strength as users customize and extend it?

• Is there value at the orchestration and coordination layer?

• Does the architecture naturally align incentives between users and the broader network over time?

The next $250B software company won't scale by perfecting control and ownership. It will scale through flexible architecture.

The terrain is shifting, but the fundamentals of good investing remain intact. In times like these, clear thinking, and a willingness to interrogate old assumptions and adapt, are the ultimate edge.

Endnotes:

^[1] This dynamic is especially pronounced in large-cap tech. Today, the top 10% of S&P 500 companies — led by Apple, Microsoft, NVIDIA, Amazon, Meta, and Alphabet – account for more than half of the total U.S. equity market value. That’s an historic high.

^[2] Today, U.S. companies capture ~40% (and growing) of global corporate profits, despite making up less than 20% of global GDP. And ~40% of Magnificent 7 revenue in 2024 came from overseas.

^[3] Since 2008, the federal deficit has steadily widened due to slow revenue growth (modest GDP expansion, major tax cuts) alongside rising expenditures (aging-related entitlements, crisis-driven spending, and growing interest payments).

Source: CBO

Benedikt is an LP in emerging venture funds and author of Embracing Emergence, a blog I love for its refreshing, first principles take on fund investing.

It’s no secret that we're in a different environment for new venture funds. In 2024, total fundraising declined 21%, and three-quarters of all those commitments concentrated in just 30 large firms. The market is still recalibrating from the 2020-2022 bubble, and liquidity constraints and macro uncertainty continue to extend these dynamics.

At the same time, we’re seeing a profound technology shift, with AI reshaping every industry. And there's growing evidence that smaller, emerging firms are a more reliable source of alpha, especially in moments when market instability intersects with rapid technological progress.

Storied firms are born in times like this, when incumbents rest on the old playbook, prices reset, and market shocks shake up the marketplace of talent and ideas.

If a renaissance is somewhere on the horizon, perhaps now is the time to reframe the value proposition of new firms, and to refine the playbook for how to evaluate them. I wanted Benedikt's take, and to put the LP and GP perspectives into a more candid conversation.

01 | “Everyone has a track record.”

EO: I want to start with what you look for in emerging managers. You’ve written about concepts like proximity, magic, linguistic consistency. I like those frameworks, more than traditional heuristics, like a manager’s “right to win” or “unique sourcing.”

Could you distill the 2-3 things you center on when figuring out if an emerging manager has what it takes?

BL: At the family office, we primarily look for a GP’s ability to invest in people. This is especially relevant in venture.

There’s a concept I love from Thomas Merton, a monk and writer. He wrote about the false self. It’s what we tell ourselves about who we are, and then in turn what we tell the world about who we are. But that sense of self is never completely accurate – it’s a false narrative we all carry.

VC as an industry is more prone to the false self.

For people building a startup, who dream of changing the world – they tell themselves a story that is very unlikely to come true, because the big outcomes so rarely materialize. So there’s a heightened need for venture GPs to see through the false self, to pinpoint this discrepancy in the founders they invest in.

Personal self-awareness is one of the clearest signals of a GP's ability to do this. The more integrated someone is themselves, the more clearly they can see where others are headed.

EO: And what else do you look for?

BL: A balance between thoughtfulness and conviction. Too much thoughtfulness, and you never get anything done. Too much conviction, and you end up running in the wrong direction.

I can usually get a sense of this quickly, on the first call. When a manager describes how they think about their fund, why they picked the strategy, and what they believe the world will look like in 5-10 years, I get a window into how thoughtful they are — what they care about, how they’ve developed their taste, what motivates them.

And when we talk about how they’ve executed in the different seasons of their life, I can assess their conviction and how they reach decisions.

How do you validate those attributes? Some people are great at marketing and lack substance, and vice versa. It feels like there’s a lot of room for LPs to make Type I and II errors if they’re not evaluating this well.

I think this ties to what a few LPs might be doing wrong. LPs invest according to what they think they should be doing – not what they’re actually good at.

For example, I’m a pastor, and the son of the family I work for is also a pastor. We’ve seen people go through all sorts of stages in their life, including marriages ending and businesses falling apart. We’ve seen how people say certain things and don’t live up to their word, or how they do.

Our strength is assessing people. We trust our discernment there.

We get under that by asking GPs about their upbringing and their friendships, to understand their story and if their past is reflective of what they’re saying in the present. The key is to ask questions that reveal value in hidden places, answers you otherwise wouldn’t hear.

Can you give an example?

Yeah, we’ve asked GPs about their insecurities quite a bit, and that opens the conversation.

It’s really about second-order questions. We’ll ask – what do you look for in founders? You nearly always hear the standard attributes – grit, humility, etc. But the moment you ask – how do you assess humility? – most people stop having answers. If a GP has a strong, specific answer about what humility looks like in a founder, it tells me they’ve really thought about it. They’ve likely seen it firsthand, and they’ve probably reflected on what humility looks like in themselves too.

That kind of self-awareness and applied insight is what we’re looking for.

It’s interesting — as a GP, I’m rarely asked deep, personal questions. But as you're talking, I'm realizing those are often the clearest windows into my judgment and thinking patterns.

If these questions get skipped or glossed over, there’s risk of missing the experiences and traits that can predict outperformance in the context of a new venture: clarity under pressure, adaptability, lateral thinking. The things you can’t see in a deck or data room, but that determine how someone will show up when they're bringing a new vision to life.

Exactly. That’s the stuff that matters.

So why do you think LPs aren’t diving enough into those signals?

It’s a misunderstanding of what is provable. Everyone says, “Fund 1 managers don’t have track records.” But of course they do. Everyone has a track record.

Are GPs well positioned in their thesis area? Have they been scrappy? Have they built long-term relationships? Those threads are more predictive than crunching the numbers on a track record from a prior firm, which doesn’t map to the new context a GP is operating in.

I learn the answers from stories, references, and listening closely.

For example, if a GP tells me – “This founder said, ‘I need you in this round,’” or “I took a bet on this founder before anyone else saw it,” — and if the founder validates that — that says something about how you build long-term relationships. I can’t skip over that.

I can also assess a GP’s general thoughtfulness — whether they have a perspective about where the world is heading in 3, 5, 10 years. I can gauge their ability to raise capital by watching how they pitch. I can assess whether they’re commercially minded by seeing how they think about building a generational firm, not just a personal brand.

Most LPs don’t ask the right questions on Fund 1 calls because they haven’t re-defined or thought differently about what is actually provable.

02 | “Can a new context lead to even better performance?”

Correct me if I'm wrong, but there seems to be a bias for GPs that have “done it before.” LPs like the same strategy, from the same team. The logical extreme of that is defaulting to wait for Fund 2 or 3, when there’s more certainty – or maybe, more perceived certainty.

This is very, very different from how I evaluate founders and startups.

I’m looking for raw capabilities in people – non-obvious, future indicators. I try to look beyond the common signals of success. Because if something is a known quantity, that means there’s consensus. But consensus isn’t where you find alpha. The return profile of your average venture fund makes that concept pretty clear.

Is this LP orientation around certainty a structural problem in how capital gets allocated? Or simply a rational reflection of the different risk/return profile between a startup versus a fund?

It might be both.

There is a difference in what LPs and GPs are underwriting. When GPs evaluate a founder, they only need them to be successful once. If a founder hits a home run, they did their job. But when I bet on a GP, I need them to pick the right teams and products with consistency. I need a different level of repeatability.

But I do agree there is an unnecessary bias toward waiting for more information, which can lead LPs to miss out on great Fund 1 returns, or lose downstream access.

By Fund 2, you’ll know if the GP has executed against their strategy, if they did what they said they were going to do. But you won’t have much more certainty around outcomes. Even at Fund 2 and 3, you’re still backing potential.

I think what also gets missed is how much context matters. It is very different to operate inside someone else’s machine versus building your own.

LPs focus on the risk of that. They aren’t sure how a GP will fare managing their own firm. So they punt.

But what about the upside potential?

I don't have data here, but I'd argue the best founder-GPs – once they have the resources to self-actualize – usually shine so much brighter running their own strategy, in their own context, than what they achieved inside someone else’s shop.

And you’d miss those returns if you’re only asking, “Have they done this exact thing before?”

I agree. At established firms, you have brand recognition, infrastructure, resources, a set culture, even a different financial cushion. That’s a completely different way of investing. It changes everything.

And LPs have to think about not just what could go wrong, but can a new context lead to even better performance?

03 | "Managers need to embrace the productivity that comes with inefficiency."

I believe one of the biggest asymmetries in the emerging GP-LP dynamic is a vastly different discount rate on time.

LPs have long relationship-building timelines. But emerging GPs need money yesterday. Emerging GPs can easily get caught in the chicken-egg problem – asked to show proof points before they are afforded the capital or resources to generate them.

What do you think about this? Do you think the best emerging GPs or LPs manage or value their time differently than others, in a way that is more aligned?

One GP comes to mind. She was very deliberate about her follow up cadence, and accelerated fundraising by dropping LPs quickly, instead of keeping up with everybody.

It also depends on the type of LP. Family offices will always be slow, since mostly they’re optimizing for not losing money. Fund of funds might be more aligned with a GP’s pace.

Maybe another way to think about this — LPs, like venture capitalists, rely on proxies to save time. For example, if a GP is coming out of a name-brand firm, or you get a warm intro from someone you trust, those signals drive momentum.

Are there any creative or nontraditional signals you’ve seen LPs rely on that help you get to a deeper sense of a manager, more efficiently than the usual path?

I think there are a lot of shortcuts LPs take that don’t end up working.

For example, a lot of LPs rely on aggressive personal branding or a large following to indicate that a GP attracts founders. But I’m not convinced that will lead to performance. It’s a red herring.

One analogy that might help – a lot of wealthy people contract artists to create custom pieces, or they hire the same interior designers for multiple projects. The artist becomes their conduit to the creative world, their way to access a space they otherwise wouldn’t have the ability or time to pursue.

Fund 1s are the artists for these LPs. These GPs let them participate in new technology, to be at the frontier. So if you manage the relationship in a way where LPs feel that, it can create a connection where they want to be on this journey with you.

I love this analogy. I started my career at Bridgewater. And Ray Dalio was brilliant at building these types of connections with his early capital partners.

Unlike venture, redemption is a real risk in hedge funds. As soon as performance dips, LPs might want out. Most firms manage this contractually – through lock-up periods and notice requirements. But Ray flipped the script. He made sure his capital partners understood macro through a long-term lens, through advisory work and the Daily Observations newsletter. He cultivated a much deeper LP-GP dialogue.

Trust became a tangible asset, and led to a more durable capital base. This powered a long-term investment strategy.

One of the reasons we launched Timespan is because we believe the LP-GP relationship in venture can be done better. There are still all sorts of perverse incentives in VC. Valuations are opaque, long-term decisions are made off short-term data.

But to your point — if LPs, especially in a Fund 1, want to be part of the artistry of technology, maybe there’s room to innovate around how that gets done.

Yes, although this goes back to your question on how LPs value time differently than emerging managers.

Investing in relationships takes time, wisdom, and discernment. Managers need to embrace the productivity that comes with inefficiency. The best relationships aren’t easy to build. The Bridgewater example proves that out.

One tactic is to systematize your touch points. A good analogy is Toast — the POS system restaurants use now. Before Toast, waiters had to write everything down on paper, which broke the flow of conversation with customers. But with technology, they can take your order while continuing the conversation. They check you out on the spot. The system didn’t take time away from the customer — it gave them more of it.

And how would you advise LPs and GPs on how to decide who to spend time with? You can spin your wheels courting someone who will never be the right fit. Or pass too quickly and miss the perfect partner, all because of one awkward call.

Some LPs value those relationship building moments more than others, that inefficient expenditure of time. You and I could probably spend time on calls like this over and over, and it would keep compounding the relationship.

But some LPs who just need to deploy, or keep relationships warm until they are ready to deploy. More of a utilitarian approach.

It’s hard, but just know who you’re dealing with and what they want.

I want to go back to transparency, because I think there may be something more structural at play than relationship building.

Venture is an idiosyncratic asset class. Valuations can get divorced from fundamentals quickly. Technology is moving at a fast clip. I fear many GPs – and LPs by extension – don’t use or try the products they’re investing in.

Is that depth something LPs are dialed into, or would even want to be more dialed into? Have you seen GPs successfully bring LPs into the fold, so they better understand the products their capital is nurturing, and understand the nuanced ways those products create value?

I have to believe there’s a way for GPs to build in a faster feedback loop – way ahead of DPI – so LPs can improve their decision-making and processes?

That’s a very good question, and one I haven’t thought about much, which might be proving your point.

The quick answer is yes, venture is more obscure than other asset classes. But I only know the relationship I have with my GPs. We text, we go out to dinner, we have personal conversations. This opens the door to getting more under the hood.

I haven’t seen a systemized way of doing that differently, but one underutilized resource is the quarterly update. I recently surveyed LPs, asking them how important the quarterly update is. Nearly everyone ranked it as highly important. I was surprised by that, since most GPs feel like nobody reads them.

I think these best practice communication channels could be modernized, and lead to better transparency. But I need to ponder this more, it’s a good question.

From the GP perspective, I feel like too many of us succumb to fear. Startups are volatile, products don’t evolve linearly. It’s scary to tell an LP, when you're a new firm trying to prove yourself, that something’s not working, especially if you know they probably aren’t hearing that from your peers.

But there’s a serendipity and connection that can happen if you lay it on the table, assuming both parties are thinking long-term.

That’s a good point. You’re incentivized to keep things positive. Every existing LP is a potential partner for your next fund. That’s a very unique dynamic, and not every industry has it.

04 | “Linguistic consistency sparks the imagination.”

Let’s talk about manager differentiation.

There’s a quiet debate among GPs – is differentiation mostly a marketing exercise, or does it truly drive performance?

The argument goes – the best firms historically didn’t start with a one-of-a-kind thesis or sourcing engine that was impossible to replicate. Their success wasn't because they had something that no one else could tap into.

It was because they just showed up differently. They were more curious, more tenacious, more willing to adapt and take risks when others didn't. They had a clear, directionally accurate point of view on where to find value in technology, but it wasn’t a radical departure from other investors. And they backed it with good, old fashioned hard work.

What’s your take? Do the best emerging GPs have a real, structural differentiator? Does differentiation matter more now than in the past?

Or is the market getting distorted – are LPs creating artificial distinctions to make sense of a crowded market?

The other day, I reviewed 30 emerging GP pitch decks. They were all effectively the same. There were some great nuggets. But the storytelling wasn’t clear.

Put yourself in an LP’s shoes – ideally they’re looking at 500 to 1,000 managers in a year. I know you probably look at more startups than I do funds, but funds blend together very, very quickly. And some GPs really lack the ability to communicate what it is they’re doing and why it matters.

There are some real assets GPs underutilize. For example, most GPs don’t articulate why they chose their fund name. Can I ask, why did you pick the name Timespan?

My co-founder and I like to nerd out over tech history. To think about technology on a timeline – so we can spot patterns and filter out legacy software.

Thinking this way keeps us focused only on the products that are truly novel, that structurally could not have been built just a few years ago. And it's a repeatable and adaptive way to build an investment mandate, so our firm can remain at the forefront and endure over a long period of time.

See, that communicates a lot. It says that you value analyzing the past, that you have a general understanding of cause-and-effect, and that you will most likely apply that same thinking to markets and people. And that will carry through on the big and small things you do.

Differentiation is important, because (1) GPs are generally not good at communicating it, (2) we’re in a very crowded market, there is a lot of noise, and (3) LPs don’t always ask the right questions to discern it themselves. We lack the attention span to really pinpoint differentiation. We move on quickly. One bad, 30 minute intro call, and the probability your fund gets dropped is very high.

I believe there’s a famous clip of someone asking Steve Jobs what he learned at Apple after his first stint. And he said he now takes the long view on people.

I think as LPs, we may have lost sight of that. We don’t get close enough to people, and so we substitute by relying on a pitch deck, on LinkedIn or Twitter.

But if we look at the generational firms, they did signal something. Maybe it wasn’t in their thesis, or in the exact vision for the firm they were going to build. But they could articulate who they are and what they stand for. Maybe it’s less important to communicate your thesis in some differentiated way, and instead to communicate who you are in a way that leaves an impression.

I think that’s right. If GPs think of it as a marketing exercise, as wordsmithing, then that’s what it becomes. But as a GP, you have to stand out, however you can. That’s on you.

And the good LPs, that are a fit for your specific fund, will move on that when they see it. They will take the time to peel back the onion and validate that, and come up with an independent thesis on the qualities that make an emerging GP worth the bet, or not.

I really agree.

J.R. Tolkien wrote one of the best, most recognized books in the English language, Lord of the Rings. He was a linguist at his core. When he was a kid, he studied old languages. He came up with the elf language and the names of people and places.

That linguistic consistency sparks the imagination. It can set great funds apart.

One GP I reference a lot is Erica Wenger. She compares the founders she invests in to elephants. They are communal animals. They have bigger ears than mouths, meaning they listen more than they speak.

This is not a concrete play-by-play of her diligence process. But it takes me into her world of assessing founders. I get a sense of where she spends time when she meets a new entrepreneur. Sure, there’s some marketing to it. But it goes beyond that. It positions her a little bit differently, and lets me into her process.

05 | "Don't fall into the trap of reductionism."

Last question – what advice would you give LPs investing into emerging managers?

Don’t fall into the trap of reductionism. This is not a business of clear recipes, of completing a checklist. Be as holistic as possible.

And what about advice for emerging managers just getting started?

Think deeply about why you want to do this. Don’t do this for financial reasons. It’s too hard. On a probability-weighted basis there are more lucrative paths. There has to be a ton of motivation and purpose behind doing it.

That’s so true. And that same advice extends to founders building companies as well.

Last week, a Harvard Business School paper was circulating, reigniting conversation about the commercial potential of open-source software (OSS).

The authors of the paper estimate that OSS has created roughly $8.8 trillion in economic value.

That figure came from scanning the codebases of tens of thousands of companies, identifying OSS components, and estimating what it would cost to rebuild them from scratch.

The research also highlights just how prevalent open-source is:

“[OSS] appears in 96% of codebases, and some commercial software consists of up to 99.9% freely available OSS.”

OSS is clearly integral to the digital economy. But that hasn’t always translated into commercial success.

There have been a few venture-backed winners. MongoDB hit a $1.9B market cap six months post-IPO. Red Hat sold to IBM for $34B (bigger than Wiz!). Still, the vast majority of OSS projects have struggled to grow into venture-scale companies.

I first explored the HBS paper and questions around monetization a couple months ago. But with the cost of writing code collapsing, and software economics shifting fast, it feels like a good time to take a closer look.

02 | The old OSS playbook

Over the past two decades, 95%+ of all venture dollars went to non-OSS software products built on proprietary, closed architecture. These products create value by owning the code, controlling the data, and locking in users through polished UX and tightly managed integrations.

Open-source projects, on the other hand, give code away for free. These projects typically monetize by charging for extra features — hosting, customer support, and other premium services like enterprise controls and advanced security.

MongoDB is a classic example. Mongo’s core NoSQL database is open-source, free for anyone to deploy and host in their own environment. But customers can upgrade and pay for Atlas, MongoDB’s fully managed cloud offering. Customers will pay for convenience and support — in Q4-2024, Atlas generated a $1.2 billion run-rate, up 34% from the year prior.

This model works – but only under certain conditions.

To succeed, OSS companies have to convert usage into reliance, and reliance into revenue. That usually means becoming essential infrastructure (e.g., databases that become the system of record), a network with very high switching costs, or a central hub that integrates multiple third-party systems.

However, most OSS projects are lightweight and easy to swap out. If your core asset is free and replaceable, building up that defensibility is tough.

But today, that’s changing.

03 | Three new OSS business models

New technical shifts — like AI automation, modular backends, and blockchain systems — are unlocking new ways for OSS to capture value.

There are three commercial paths I see for OSS over the next several years.

A. Open-core (the familiar model, now upgraded)

The classic model – offer the core product for free, charge for premium features – will get supercharged by AI.

Paid tiers will move from static add-ons, like dashboards and hosting, to more intelligent (and valuable) automation – self-healing systems, agents that manage entire workflows, and adaptive interfaces.

For example:

• A free documentation generator can offer a paid AI tier that answers developer questions in plain English, citing relevant sections from your own docs and enriching answers with best practices distilled across its entire user base.

• An open-source security scanner offers a paid tier where AI automatically flags risky code and makes the fix.

OSS still benefits from community validation and wide distribution. But with AI, the commercial scope of OSS is expanding. In the future, I expect more projects will scale from useful tools to venture-backed platforms.

B. Network management as the product

In the coming years, AI agents will become the primary users of software.

As they take on more tasks — like sending messages, retrieving data, or executing transactions — they’ll need infrastructure to decide which third-party APIs to call and how to route and negotiate those requests.

Take travel booking, for example. An AI agent might query airline APIs, compare prices, email an itinerary, and complete a transaction — choosing different providers based on real-time prices, availability, and user preferences.

This creates a new kind of software marketplace, one where agents navigate networks of interoperable, third-party services.

Open-source can define the standards for these networks — the open protocols, SDKs, and connectors that make them accessible and interoperable across service providers and agents. This open access layer enables broad participation and rapid ecosystem growth.

But the commercial opportunity lies in managing the network — shaping how agents select services, requests are routed, and providers compete to serve agent demand.

Startups building this layer can monetize through:

• Paid tools that help service providers manage agent traffic, configure access rules, or target specific types of agent requests.

• Fees on transactions between agents and third-party services

• Priority access, where providers pay for better placement based on performance guarantees.

In some cases, decentralized infrastructure, like blockchains with smart contracts, may be especially well-suited to this model – enabling more automated network management, pricing, access, and security without the overhead of a central intermediary. These systems offer transparent, programmable, and permissionless access, a natural fit for more automated, agent-driven workflows.

This is a big shift. It moves the OSS business model from selling features to managing networks.

Here, OSS lays the groundwork, creating open access to the network. The business is in orchestrating its flow.

C. Open-source as a data engine

In this model, open-source software becomes a way to collect valuable data.

It works like this: A startup releases a small, free tool (like a code library or SDK) that solves a specific problem for developers. Because it’s useful and free, lots of developers add it to their projects.

Every time a developer deploys the tool, it quietly collects useful information — like how a system is running, or how users are engaging. Over time and across multiple applications, this adds up to a unique, dynamic dataset that customers pay to access.

Langfuse is a good example. Their open SDK that captures LLM performance data, which flows into an observability platform users can pay for.

This model is especially well-suited for the current market. Demand for this type of data is growing, because AI systems need constant feedback to improve. And advances in encryption now make it safe to extract and transmit this data from private environments.

In this paradigm, OSS is the sensor that gets embedded. The business model is in the signal it sends back.

04 | Open-source is eating software

At Timespan, we believe open systems are the next paradigm of software, and we specialize in applications built on these new, open protocols.

Today, coding automation is driving the marginal cost of software development to zero – lowering barriers to OSS adoption and unlocking new distribution and business models where open-source has a natural edge.

Two of the fastest-growing startups today, Cursor and Lovable, started as open-source.

Cursor launched on Github in 2023 as a fork of VS Code, using its open-source base to fast-track adoption and layer in AI workflows – scaling to $100M ARR in under a year. Lovable began as “GPT Engineer” in mid-2023, an open-source app generator that built early traction and evolved into a full-stack paid platform with hundreds of thousands of active users.

I expect to see more open-source projects evolve into venture-scale businesses, powered by intelligent services, agent-based execution networks, and application-native pipelines that generate unique data.

In all three cases, OSS provides a structural advantage. It reduces unnecessary costs, increases transparency, and drives adoption through large, engaged developer communities.

Open-source is eating proprietary software.

Soon, $8.8 trillion will look small.

01 | Lessons from the Cypherpunks

The Cypherpunks – and their fight for open encryption – offer some timeless lessons about technology adoption:

01/ Foundational technologies tend to move toward open access and standardization – especially when their principal value hinges on interoperability.

We saw this with open-source encryption and protocols like HTTP. Because they were free and accessible, they scaled faster than proprietary alternatives. And this broad adoption was essential for their utility – adding value across an entire network, not just isolated cases.

02/ When a new technology standard gets in the hands of developers and delivers value to end users, attempts to centralize or suppress it tend to fail.

Government efforts to control encryption through (a) international export restrictions and (b) a “backdoor” with the Clipper Chip didn’t work – developer collaboration and free distribution outpaced these measures.

03/ Once a technological breakthrough becomes a foundational standard – and costs asymptote – value accrual moves to the application layer.

In the 1990s, open-source encryption enabled secure transactions at scale, which laid the foundation for commercial applications that could channel and monetize users, transactions, and data.

02 | Applications come in waves

Technology breakthroughs like TCP/IP and the first transformer model are unpredictable.

Research and developer forums hint at what's mathematically possible; but step-function improvements remain hard to forecast until the prototype is built, computation is run, and benchmarks are tested.

But new breakthroughs in software often lead to a follow-on wave of open standards, which help get technology into the hands of users.

As the most commoditized parts of the stack, open-source protocols and standardized frameworks serve as the “plumbing and wiring” of digital products – setting a baseline for performance, guiding how data flows, and shaping how systems interact in any given technological moment.

They inform what’s possible – and what isn’t.

For example, early Internet protocols like TCP/IP, HTTP, and SMTP enabled basic digital communication for the first time. But these protocols handled data in a static and siloed manner. Applications were limited to basic content delivery. Interoperability required developers to build custom middleware.

In the early 2000s, commercial-scale virtualization – the ability to abstract computing resources from physical hardware – ushered in the cloud era. A wave of new, open standards – RESTful APIs, containers, and open-source databases – streamlined software integrations and scaled complex data processing. This directly enabled platforms like Shopify, Uber, and Netflix.

But these new protocols lacked inherent mechanisms for security, identity management, quality assurance, and distribution. And so proprietary platforms – like AWS and iOS – filled those gaps with managed services, cloud infrastructure, and app stores. (Even today, security, authentication, and performance monitoring are the most purchased SaaS tools – reinforcing the limits of open standards in the cloud era and and the ongoing dependence on proprietary solutions for these critical functions.)

By studying the open protocols that follow each breakthrough – their specific capabilities and limitations – entrepreneurs and investors can anticipate the the business models, distribution vectors, and product primitives that will win.

And history shows that each wave of open standards builds on the last, increasing the total value of the application layer with every new technology cycle. (A rough analysis suggests a 13-15x increase in the value of the application layer from the early Internet to the cloud era.^[1])

If this pattern holds, the next wave – driven by autonomous software – will introduce new open standards that radically expand the scale and scope of value creation for new startups, beyond what we’ve seen in prior technology cycles.

03 | Open protocols for the autonomous web

Gradually, over the next several years, we expect AI agents to become a core component of the software stack.

Unlike traditional workflows that rely on human input and predefined rules, AI agents are autonomous, performing tasks and interacting with applications, services, and data with minimal human oversight.This introduces two key vulnerabilities that existing standards fail to address:

1. Unbounded data manipulation: AI agents autonomously query, generate, and transmit data across systems, often combining information in ways that were not explicitly designed or anticipated.

2. Static access controls: Existing permissioning frameworks are static and rule-based, designed for human users rather than adaptive AI agents. Without more dynamic, context-aware protocols, there's a risk of over- or under-restricting access – leading to data leaks, misuse, and slow performance.

Addressing these challenges requires rethinking our existing protocols. From my conversations with early-stage companies, I'm seeing a fresh wave of open standards coming to market that can support AI-native applications and drive real agentic autonomy. Specifically:

• Context-aware permissioning and authentication: Universal frameworks to verify agent identity and intention before granting access.

• New, privacy-preserving computation: Decentralized methods like homomorphic encryption^[2] that allow agents to process encrypted data without decryption or exposing raw inputs.

• Automated communication protocols: Frameworks that enhance data with universal schemas, enabling deeper cross-platform interoperability.

• Transparent decision logging: Tamper-proof logs of agent actions and decisions, for auditability and accountability. These can be complemented with tools that auto-detect anomalies and restrict operations in response to unexpected agentic behavior.

• Open-source models:^[3] AI models with open architectures, weights, and training code, which provide more flexibility, lower costs, and reduce lock-in with proprietary systems.

• Automated observability and remediation: Open frameworks for real-time monitoring, enabling automated anomaly detection, response, and recovery.

Achieving the above objectives will require a major redesign of data standards — those that replace convenience for humans with interoperability for machines as the primary success metric.

The Crypto Wars taught us a vital lesson – during major technological shifts, open standards consistently outpace closed ones. Markets reward applications built on open, cost-efficient protocols and punish those that try to lock them down.

We're at the start of a new wave of open standards, as automation and decentralization become the new paradigm.

The entrepreneurs who understand and adapt to this shift will be the long-term winners in this next cycle. That’s where I’m placing my bets.

Endnotes:

[1] This analysis estimates the comparative value of the application layer across two key technology eras: the early Internet era (1985-2001) and the cloud era (2002-2020). To do this, I identified the top 15 public technology companies by revenue in each era (excluding companies that did not generate meaningful revenue from software applications). For each company, I examined the 10-K from the year in which its revenue peaked within the era and isolated the portion derived from application-layer products. Revenue from other business lines, such as hardware, consulting, and infrastructure, was excluded. The total application-layer revenue across these 15 companies was then aggregated and compared between the two periods – 14.1x greater in the cloud era than the early Internet era. This analysis is designed for relative comparison rather than absolute measurement of the application layer's total market size. There are several limitations here: (i) company selection is based on revenue rather than market cap or other measures of industry impact; (ii) financial reporting varies across companies and time periods, making precise revenue isolation imperfect; (iii) the long-tail of application-layer businesses are underrepresented due to lack of information or accounting constraints; and (iv) the definition of the application layer evolves, making cross-era comparisons inherently approximate. Despite these limitations, the approach provides a directional sense of how the application layer's relative value has shifted over time.

[2] Open-source AI models make their architecture, pre-trained weights, training code, and inference code freely available for use, modification, and redistribution. Unlike proprietary models, which restrict access through APIs, open-source models provide the raw components developers can directly integrate, fine-tune, and deploy within their own applications.

[3] Homomorphic encryption is an advanced encryption technique that allows computations to be performed directly on encrypted data without decrypting it, preserving privacy and security in data transmission.

[4] Secure multiparty computation refers to a cryptographic technique that enables multiple parties to jointly compute a function over their inputs without revealing the inputs to each other.

[5] JSON-LD is a lightweight format for linking and structuring data using JSON, designed to make data machine-readable across disparate systems while maintaining human readability.

01 | Decoding the emails that shaped the internet

At Timespan, we study historical patterns to anticipate how technology will evolve.

The Crypto Wars of the 1990s offer a fascinating lens into how transformative technologies emerge despite regulatory resistance. (Note: “Crypto” here refers to cryptography, not cryptocurrency.)

Strong cryptography – the mathematical practice of encoding information for privacy – became the foundation of our modern digital economy. Without it, the basic operations we take for granted would be impossible: online banking, e-commerce, secure messaging, digital signatures, and virtually every sensitive online interaction.

In the early 1990s, the U.S. government classified strong encryption as a “munition” under arms trafficking laws, effectively making it illegal to export this technology outside the U.S. This classification threatened to splinter the emerging internet into a two-tier system: weak encryption for international users and strong encryption for domestic ones.

Enter the Cypherpunks – a group of technologists, mathematicians, and privacy advocates who believed privacy and encryption were fundamental rights in the digital age. Notable Cypherpunks include Hal Finney, Adam Back, Julian Assange, Marc Andreessen and (possibly) Satoshi Nakamoto.

ID: <9210050721.AA01865@soda.berkeley.edu>^[1]

From 1992 to 1998, over 100,000 messages were exchanged across a range of topics on the Cypherpunk listserve. A decade ago someone preserved these emails in eight raw text files^[2] that were unstructured and difficult to read.

To make these emails accessible, I used custom parsing algorithms to transform the raw text files into an interactive digital archive:

cypherpunk.timespan.vc

These archives serve as a unique, digital time capsule of the movement that was the precursor to the modern internet. We have the opportunity to study these archives and derive valuable insights into patterns of technology adoption during periods of significant innovation.

In Part I of this blog post we’ll dig into the history and context of the Crypto Wars, particularly around technology adoption cycles. Part II will break down how we apply the learnings from the past to identify investment opportunities today.

02 | Major technology transformations coalesce around open standards

Early Cypherpunk emails underscore a timeless principle — new technology requires open, shared frameworks to facilitate developer collaboration and achieve widespread adoption.

The evolution of two different encryption standards – RSA and PGP – reinforces this concept.

Developed in 1977, the RSA standard (named after its creators Rivest-Shamir-Adleman), marked a breakthrough in public key cryptography. It introduced a method for secure data transmission over public networks, laying the groundwork for encrypted communication over the internet.

However, RSA’s initial patent restricted the technology’s widespread use, limiting adoption.

In contrast, PGP (Pretty Good Privacy), created by Phil Zimmermann in 1991, democratized encryption by offering an unlicensed, freely available implementation of RSA. Zimmermann published PGP’s source code online, giving anyone the ability to encrypt their emails, files, and messages.

ID: <9211161902.AA08397@newsu.shearson.com>

The openness of PGP was the catalyst needed to fuel rapid adoption of the RSA cryptography standards.

The tension between RSA and PGP was frequently discussed on the Cypherpunk listserv, and there was general consensus that foundational technology breakthroughs only become useful if they are open and accessible.

ID:<2.2.32.19960409153328.0075c2c0@panix.com>

The Cypherpunks championed cryptography and encryption not for secrecy, but as a trusted tool for securely sharing private information – like credit card data – which was essential to the new digital economy.

They pushed back against U.S. policy, which made it illegal to export strong encryption overseas. For them, these bans hindered the growth of the internet and hurt U.S. global competitiveness.

ID:<199409220341.UAA02254@jobe.shell.portal.com>

The Cypherpunks, as the early advocates and builders of encryption, emphasized distribution and championed this technology as a fundamental right, likening it to public infrastructure – open, essential, and unstoppable.

03 | How openness outpaces regulation and drives economic growth

Until 1996 sending strong encryption overseas was considered a federal crime, the equivalent of exporting weapons to foreign adversaries.

This became the foundational issue of the Crypto Wars.

Phil Zimmermann became a central figure in this battle when he released his open-source version of PGP in 1991 and was accused by U.S. officials of violating federal law.^[3]

ID: <9302132122.AA13118@nexsys.nexsys.net>

Zimmerman and associates, including many from the Cypherpunk community, were subject to a 3-year investigation that included subpoenas, Senate hearings, and threats of jail time.

However, by 1993, the U.S. policy of regulating encryption as a weapon began to unravel, given the rapid adoption of open encryption globally.

The Clinton administration made a few final attempts to control this technology. First, through a massive PR campaign, portraying encryption and cryptography as a tool for, “pornography, terrorists, tax evaders, and criminals.^[4] Second, through a centralized alternative. The U.S. government announced the Clipper Chip initiative, a public-private partnership between the NSA and AT&T, where chips in AT&T’s devices would use cryptography co-developed with the NSA, giving the government “back door” access to private communication.^[5]

The Clipper Chip initiative never took off, and by the mid-1990s, the Cypherpunks had won the Crypto Wars in the court of public opinion.

In 1996, President Clinton signed Executive Order 13026, which shifted the regulatory framework of commercial encryption from munitions to commerce. The investigation into Zimmerman was dropped, and export controls on encryption were dismantled.^[6]

This history shows – new technology, especially when cheap and widely accessible, does not conform to policy frameworks that try to suppress or control.

Regulatory attempts to limit or slow new innovation ultimately hurts domestic economic interests, and over time governments are forced to change these policies as the consequences become too significant to avoid.

ID: <9310091757.AA04856@columbine.cgd.ucar.EDU>

While U.S. policymakers focused on regulating cryptography as a weapon that could be used for criminal activities, the Cypherpunks knew cryptography was needed in order to unlock new markets on the internet – e-commerce, email, cloud computing, data storage, and more.

This lesson – that open-source, foundational technologies typically outpace regulation and centralized alternatives – is relevant today.

When new innovations provide solutions that are better-faster-cheaper, they drive mainstream adoption, making it prudent for governments and businesses to adapt, rather than suppress.

04 | Cypherpunk cypherbites

While the Cypherpunks were pioneering internet privacy, their mailing list wasn't all cryptographic algorithms and policy debates – the archives reveal the Cypherpunks were just like us.

Here are some cherry picked emails for your amusement.

Julian Assange is very particular about his parties

ID:<199512300046.LAA16884@suburbia.net>

Marc Andreessen was responding to internet trolls back in 1994

ID: <199412112227.WAA23971@neon.mcom.com>

Clinton’s first email address: 75300.3115@compuserve.com

ID: <9302032358.AA00498@xanadu.xanadu.com>

Bitcoin was almost named CRASH

ID: <9312070630.AA28857@jobe.shell.portal.com>

Sung to the tune of “Santa Claus is Coming to Town”

ID: <199712251031.LAA09046@basement.replay.com>

Please explore the Cypherpunk archives and let me know what you discover!

email: maaria@timespan.vc || twitter: @maariabajwa || linkedin: @maariab || github: @iloveburritos

I’ll repost my favorite replies.

Endnotes:

[1] To read a message in its entirety, search “ID: <9210050721.AA01865@soda.berkeley.edu>” in the search box on https://cypherpunk.timespan.vc/

[2] https://cypherpunks.venona.com/date/

[3] A recent appeals court decision ruled OFAC sanctions against privacy protocol Tornado Cash were unlawful because open source code and immutable smart contracts cannot be considered legal property because they are not capable of being owned. While these legal decisions will take many years to finalize, they are indicators of the changing regulatory landscape in a technology market that is changing rapidly. https://storage.courtlistener.com/recap/gov.uscourts.txwd.1211705/gov.uscourts.txwd.1211705.99.0.pdf

[4] More recently we have seen similar claims made against cryptocurrencies and blockchain technology. "At a hearing of the Senate Banking, Housing, and Urban Affairs Committee, U.S. Senator Elizabeth Warren (D-Mass.) called out crypto’s use by terrorists, ransomware gangs, drug dealers, and rogue states to launder funds." https://www.warren.senate.gov/newsroom/press-releases/icymi-at-hearing-warren-warns-about-cryptos-use-for-money-laundering-by-rogue-states-terrorists-and-criminals

[5] The UK government recently ordered Apple to create a back door allowing them to retrieve all encrypted cloud content, for users around the world. This order would apply to users who have opted into Apple’s end-to-end encrypted cloud service. https://www.washingtonpost.com/technology/2025/02/07/apple-encryption-backdoor-uk/

[6] https://www.govinfo.gov/content/pkg/WCPD-1996-11-18/pdf/WCPD-1996-11-18-Pg2399.pdf

Deon’s company Forethought builds advanced AI agents for customer support teams. Today, the company handles over one billion customer interactions each month for companies like Airtable and Upwork.

Before Forethought, Deon built infrastructure and products at Facebook, Palantir, and Dropbox. He’s been featured in Fast Company, CNBC, and Bloomberg. And – my favorite part of his bio – he’s a world finalist in competitive programming.

I was lucky to back Forethought early in 2020. I’ve loved watching Deon scale both the company and his vision ever since.

I hope you enjoy the conversation.

01 | DeepSeek

Let’s start with what’s on everyone’s mind — DeepSeek. You recently shared your perspective on Bloomberg, and here’s what I took away:

• New engineering techniques are making it much more efficient to build and run AI models.

• This challenges the cost structure and defensibility of closed-model providers like OpenAI and Anthropic.

• Over time, model costs will shift from training to inference.

• As models get cheaper and more flexible, this will drive more value to the application layer.

Do I have that right? What do you see as the biggest implications from DeepSeek’s release?

The first part, around technological advancements, is the most interesting.

DeepSeek achieved some real engineering breakthroughs, leveraging chain-of-thought and reinforcement learning. Nothing fancy, just extreme optimization – and they were able to unlock emergent reasoning capabilities on par with OpenAI's o1 model.

I've been a fan of reinforcement learning for years – my first AI internship at the Alberta Machine Intelligence Institute was in reinforcement learning. I’ve been waiting for it to make its debut in LLMs, and with advancements like AlphaGo, it's all converging in an exciting way.

Things are directionally becoming more efficient. But, in reality, it took hundreds of millions of dollars in research to achieve o1 level reasoning – and only after that could DeepSeek achieve similar performance with the reported $5M investment in training.

So the market selloff was probably an overreaction.

Jevon’s Law still applies – greater efficiency will only drive more consumption. Sure, we’ll spend lessper unitof compute. But, overall spend will grow as we run more and more computations. There’s just so much more progress to make.

But how does this change the incentives for closed-model providers? NVIDIA is one thing, but closed-model research labs are pouring billions into building the newest model. If new models can be easily distilled and replicated, does that reduce the incentive to keep innovating?

I agree. NVIDIA is safe for now – we're not moving away from their hardware anytime soon.

The bigger question is whether this erodes the moat of closed models like OpenAI and Anthropic? I’ve said for years that OpenAI has no real moat – once a model is out, replication is relatively easy.

That said, they still have lots of room to keep innovating.

Right now, it's language models, but there’s Sora and video models – there's always something new. Their lead won't disappear, but competitors will always be nipping at their heels.

Long-term, open source might win.

I don’t see OpenAI becoming a fairly valued, trillion-dollar company based solely on its models. Maybe they’ll generate massive revenue, but obsolescence and the need to constantly innovate will compress margins.

The real question is whether OpenAI shifts more to building application-layer products. Let’s remember, ChatGPT’s real success came from being a consumer product. Long-term, I think the application layer is where most value will accrue.

But what do you think about the incentive structure?

I've been thinking about the open-source versus closed debate for a while. We’ll get more into that. But one thing seems clear – raw model performance alone feels like a tenuous moat.

I’d also expect OpenAI to shift toward more applications and tooling, leveraging its very real distribution edge and the ability to build a tight feedback loop between usage / input data and model development.

But if a closed-model provider built, for example, a new coding automation tool on top to try and monetize, I think a new startup with a superior product and deep focus could...

Grow to be competitive. Yeah, I agree.

02 | Open-source vs closed models

The open-source versus closed model debate has been around for a while.

In 2023, the leaked Google memo “We have no moat and neither does OpenAI” argued that open models are faster, more customizable, and will catch up. New research shows open-source is now only months behind closed models.

So what’s your take – does DeepSeek change the game? Or is this just more proof of the writing that’s been on the wall?

DeepSeek certainly did a lot of clever research. But now that’s all open-source. It’s available research. It’s stuff OpenAI and others will take and incorporate.

But it’s important to keep in mind – DeepSeek is not matching OpenAI’s o3, which is the closest we've seen to AGI. So OpenAI is still 6-12 months ahead.

The question is – will that lead matter? Or will success come down to something else, like distribution or brand?

Closed model providers still hold a lot of brand value, especially with stodgy companies that are still on IBM or work with Accenture or Bain to incorporate AI. There’s a big enterprise business to be built purely on that recognition. OpenAI is positioned as the world’s best AI expert, and can charge millions to implement their models or fine-tune custom models for the enterprise segment. Big companies are already paying OpenAI for this.

But when it comes to mid-market adoption, that’s a different challenge. Competing there requires strong UI and product expertise. The mid-market will demand products that are more specialized.

Let me paint two extremes. The first scenario is an oligopoly of 3-4 closed-source models powering everything.

The other scenario is a completely commoditized model layer – cheap, open-source models that everyone can fork and build on.

Where do you think we land on that spectrum – and more importantly, why?

Models will inevitably get commoditized.

The concept of language models – predictive systems fulfilling prompts – has existed forever. But what few predicted, despite it being mathematically provable for a long time, is that a model could encode enough logic to power a new computing paradigm. That’s what ChatGPT revealed, why it broke the internet.

Language completion costs will likely trend toward zero over time. Over how long? Who knows. But open-source models like DeepSeek accelerate that downward pressure.

But language is just one model of computing – there’s image and video. Video models, for example, must create a whole new way to encode physics, just like LLMs embedded linguistic logic and reasoning. Protein folding is its own language, meaning genomics will have its own billion-dollar model.

How many domains will follow?

Does OpenAI stay ahead just by being 6-12 months in front? Each breakthrough – language, reasoning, protein models, AGI – is worth billions.

Maybe one way to think about this is – will the pace of model performance soon plateau?

If it does, then that probably lends to the open-source paradigm, since any further research would only yield incremental gains that get quickly commoditized.

But if we expect performance to keep accelerating over the next 3-5 years, this would favor research labs with capital, scale, and data, since the potential rewards from continuous investment are huge. The payoff is there if you can stay ahead.

I don't have a crystal ball, but my intuition leans toward the idea that we’re still at the beginning. We thought we'd reach AGI soon after GPT-3 and GPT-3.5, but we're still not there – although maybe OpenAI has reached AGI in private.

The challenge is that building these models still takes millions in R&D, and then they quickly get commoditized. So, is it worth the investment? Will OpenAI ever be profitable as a research company? Probably not.

But it's still a paradigm-shifting business, generating revenue, and creating value. They can expand into many domains – video, protein modeling, genomics, energy – which buys them more time, more brand recognition, and new opportunities.

03 | The pace of AI innovation

Regardless of which paradigm wins, AI performance is advancing fast. OpenAI’s o3 just hit 87.5% on the ARC-AGI benchmark – up from 55% just months ago.

When you fast forward 2 years, what type of performance do you think we’ll see?

We haven't seen AGI yet – maybe within the next 5 years, maybe sooner. So what does that do?

You can argue we get to a singularity, and then human-led innovation is done. But that seems unlikely.

I think each new model breakthrough will open a whole bunch of new applications. For example, we still don’t have a universally applicable AI tutor. While we have self-driving cars, we need further advancements in robotics. The pace of innovation won't stop as capabilities grow – if anything, it will accelerate.

Intelligence could follow Moore's Law, doubling every year or year and a half. And each breakthrough will give rise to new billion-dollar industries.

We've talked about model performance, but there are also a lot of other constraints around adoption – energy, cost, human desire to use these tools. Where do you see the biggest challenges to adoption today?

Maybe this sounds strange, but I think the biggest bottleneck is creativity, imagination, and focus.

Take customer service. The biggest issue is that there are many, many “AI” solutions, and so many are ineffective. At Forethought, we have a fully agentic model that our customers think is magic. But there are hundreds of low-quality solutions out there – outdated decision-tree chatbots or GPT-based systems that just scrape knowledge articles.

These dilute the message, and it takes time to break through the noise.

Most customers don’t even know what’s possible. They’re 1-3 years behind on what they think is achievable.

Remember, building an AI company is hard. It’s like “NP-complete” in computer science – this concept that verifying a solution is quick, but finding the solution is computationally intense and difficult.

It’s like a “startup-complete” problem – a successful AI company requires not just good technology but also distribution, marketing, and product packaging. It takes time to get enough iterations and reach enough people to make an impact. Many startups overlook this.

04 | The application layer

As foundation models improve and software is able to handle increasingly complex tasks, how do you think about the role of the application layer?

If I'm an entrepreneur developing my product strategy, what can I build at the product level – before any real customer traction – that could create durable moats and differentiation?

My answer is simple – does the product work?

Take AI sales development representatives (SDRs), for example. There are probably 50+ companies in this space trying to automate outbound sales, but how many actually generate pipeline and book qualified meetings? Most solutions just regurgitate knowledge or craft basic emails.

But a truly autonomous AI agent can handle tasks like LinkedIn research, objection handling, follow-ups, and meeting scheduling – executed with context and proper timing.

This requires a lot of agentic capabilities that most companies fail to build. It’s so easy right now to just build RAG on your emails. The barriers to entry are so low, many default to the lowest common denominator.

I’m an angel investor in a handful of application-layer companies. I always ask how they're using agentic infrastructure? What orchestration frameworks have they tried? Have they implemented new training techniques from esoteric research papers? Can the product independently initiate tasks and complete long-running actions? If they’re just building with GPT, that’s a red flag.

The top 5% of teams get this right. They have the research chops and the product instinct to package technology for users.

But at the core, it always comes down to – does the product work?

05 | New distribution models

Maaria (my partner at Timespan) and I believe the best products are designed for distribution from day one – where the growth strategy is deeply embedded in how the product is used. That principle guides a lot of our investment thinking. It seems even more important as the field becomes more crowded.

What new distribution methods do you see as software becomes more autonomous? How will AI-powered products reach users in ways that weren’t possible before?

Boring answer, you’ve probably heard this a thousand times – pricing. Don’t even talk about selling seats. Quantify the outcome your product delivers, and price based on that.

I invested in Recraft, an AI image generator, and when the founder wanted to use a monthly pricing model, I suggested charging per image generated instead. They went that route and are seeing incredible growth.

In B2B SaaS, selling to enterprises or mid-market is challenging because you often need to sell before gaining access to data, making it hard to really prove value.

The sales process is still sequential – pitch the value prop, run a trial, prove it, then deploy. I’d love to see this whole chain disrupted.

Are there new ways to integrate AI to prove the value prop more quickly, to reduce friction in adopting these tools?

I completely agree. At Forethought, one of the big changes we made to distribution last year was launching a free trial version for everyone, whether it’s for knowledge-based RAG or agentic workflows. It takes less than 24 hours to integrate, about 8 hours on average.

Our win rates went up when we started doing this.

Speed of deployment is a huge advantage in AI. It all comes down to one question – does it work? If you can prove it works quickly, in a simple, fun, or clever way, you'll be ahead of your competitors.

Maybe there’s an idea here – an agentic sales motion where AI-driven systems integrate with APIs and data in real time, delivering value as part of the pitch itself. In the sales pitch, you talk about the value, and by the end, you’re proving it.

Oh, man! I actually did something similar today, but not with APIs. I used web scraping. I told them, "We can launch a bot for your website now, just off your site." And actually pulled it off in the meeting with our technology.

06 | Building trust through UX

Another aspect of the application layer I’ve been thinking about is how UX will evolve.

For any technology to scale, users need to trust and love the experience. Even if AI agents can handle tasks, people won’t fully hand over the keys without confidence in the system.

Forethought has been great at this. Your product is really nuanced in how it prioritizes trust, how it augments the end users – customer support agents. It integrates seamlessly into their workflows, rather than replacing them.

Do you have any frameworks for thinking about how UX will evolve? Where will the line be between tasks we want to keep human and tasks we’ll be comfortable letting machines take over?

That’s a deep question. For now, I think the key idea is "show your work."

As things become more autonomous, people need to trust the system, and that’s hard when they don’t understand how it arrived at a decision. Even if the AI gives the correct answer, people want to know how it got there.

We learned this the hard way at Forethought.

At first, we’d just give the answer, but customers wanted more control. They wanted to know the data sources, understand how the decision was made. Giving people control, even if the AI is doing most of the work, will be a big UX principle moving forward.

Another big point is, instead of building a whole new app, bring the intelligence to where the user is already working. At Forethought, we didn’t try to rebuild Zendesk’s ticketing system – we brought intelligence into it, subtly, while they were working. This will become more important over time.

Another point is to rely on human feedback for system improvement. Allow users to interact with AI, within their workflow, through natural language, instead of relying on pre-programmed decision trees. This creates positive feedback loops, so the AI gets better over time.

Many are not doing this yet, but I expect it will become more common.

There are so many possibilities – interfaces shifting from visual dashboards to text-based inquiry, coding automation enabling non-technical users to customize their own UX.

It feels like these aspects could really make or break a product experience, even if the raw agentic capabilities are there.

Exactly. And that’s what I meant by "startup-complete." You still need to build a great user experience, figure out distribution, and build a sustainable business. Having the best LLM won’t do it alone – that will commoditize.

It’s so hard to build a successful AI company. Even though tools have gotten easier to use – maybe because the tools are easier to use – creating a sustainable business requires so much more than just a fancy demo.

Totally. I suspect this will play out like past tech cycles.

In the early days of the Internet, open protocols like HTTP, SMTP, and TCP/IP enabled a wave of digital businesses to be built. These open standards were the foundational building blocks of the web.

Some companies succeeded, like Amazon, but there was also a lot of over-investment and hype. A lot of companies failed because they couldn't figure out product.

We’re in a similar moment now – there’s a rush of capital because no one wants to miss out on the AI company that dominates a particular sector.

But, as you mentioned, complexities around UX, distribution, and product haven’t gotten any easier. It’ll take time for the right form factors to emerge – patience, focus, and real product taste will separate the winners from the losers.

I’m not sure there’s always a first mover advantage right now.

Absolutely. For any startup, even if you build the best product, there’s still a high probability of failure.

With AI products, it’s even harder to succeed.

You’re dealing with new workflows and big questions about how humans interact with machines. The core infrastructure is shifting so fast. It's a tougher problem. The quality of the team and the ability to build real, scalable products are still key. Despite the noise, the fundamentals haven't changed.

07 | Rethinking the entrepreneur-investor relationship

As you think about the entrepreneur-investor relationship, what do you think needs to change from the last tech cycle? Do you think that there's a way that investors and entrepreneurs can interact better or differently?

I have a lot of thoughts on this, not necessarily related to AI.

A few things come to mind. My best investors are the ones who get in the weeds.

One investor on my cap table, Vanessa Larco at NEA, is a world-class product thinker. She’d sit down with me and my PM and nail our product strategy. Another investor with go-to-market experience helped us with a full sales training session. With you as well, I’d see the tangible value-add from a customer intro, candidates, or helping close capital. Those kinds of investors, who really care and get involved, add the most value.

Most VCs just give you money and opine in board meetings. If a VC can send you one customer, one candidate, or have one conversation around capital, they're in the top 80th percentile. That’s the sad reality.

The hype cycles we see now are great for short-term excitement, but in the long run, building a company comes down to the fundamentals. It’s about those tough moments, like losing your first customer or struggling to raise your next round, when you need a backer who truly understands the vision and sticks by you.

We need more VCs who are genuinely involved and care about the journey, not just chasing the next big thing.

I agree. Venture has become so transactional. People are driven by fear – of missing out, of something not working and looking dumb – so they spread themselves thin trying to hit the one thing they can point to. This dilutes the focus it takes to build something important.

You see it with portfolios that are 50+ companies – how can you dig in and be thoughtful for each of those companies, or make any of those positions meaningful for your fund?

I do see a real changing of the guard in VC, of new investors starting new shops, trying to solve this problem, which is amazing.

I agree.

Thank you for having me. I appreciate you letting me hop on and ramble about AI. It's always fun, and always great to catch up with you.

You too, as always.

01 | How machines learned to read

At Timespan Ventures, we think about technology on a timeline, through a historical lens.

This helps (i) filter out incremental products, those recycling old primitives; (ii) anticipate new software paradigms; and (iii) visualize how those breakthroughs need to be productized to unlock new categories of value.

One shift we are investing behind is the ability for AI to process unstructured, multimodal data.^[1]

Early machine learning systems like recurrent neural networks (RNNs) processed data sequentially, analyzing each component in a fixed order. This limited their ability to retain information and understand complex relationships across large data sets.

To overcome this, data had to be pre-formatted and fed to computers in a specific order.

However, in the 2010s, two major breakthroughs in parallel processing^[2] enabled computers to move beyond these constraints:

1. Unlocking scale: GPUs, originally designed for graphic rendering in gaming, were adapted to process large datasets using thousands of parallel cores.^[3] This new chip design allowed developers to dramatically scale the amount of data and compute used in model training, which resulted in larger and more sophisticated neural networks. The chart below shows the exponential growth in computation used to train AI over time. Before GPUs, the total resources dedicated to training top-performing models grew steadily at 1.5x per year; with modern GPUs, this growth accelerated to 5x every year.

2. Algorithmic breakthroughs: In 2017, Google researchers introduced a “self-attention” mechanism, the underpinning of the transformer model.^[4] This method enabled AI to analyze relationships in data simultaneously (rather than sequentially), capturing context and long-range dependencies. It also eliminated the need to feed data in a clear, structured order, as models could dynamically assign importance to each element based on its relevance to others, regardless of their sequence. (Thanks to ongoing algorithmic modifications, AI models are currently advancing at more than twice the pace of Moore’s Law!)

Together, these advancements have transformed how machines process data, eliminating the need for rigid pre-formatting or upfront modification.^[5]

In other words, computers can now handle raw, unstructured information – words, images, video – at a higher level of abstraction.

This is a familiar pattern in software. For example, transpilers abstracted manual code translation between languages,^[6] and containers abstracted environment configuration, enabling applications to run seamlessly across different platforms.^[7]

Now, this shift is happening with data.

This represents a significant leap forward. It’s why generative AI felt so impressive – and human – when it first hit the consumer market.

And understanding this evolution also sheds light on AI’s shortcomings – where these models still underperform, why some question the $200B annual spend on model development – and the role startups can play to harness the raw power of these models for applications in the real economy.

02 | Application layer ~ Reasoning layer

As model capabilities advance, what role can application-layer architecture play? Can startup applications build a competitive edge against incumbents that integrate directly with these models and already have advantages in data and distribution?

These are timely questions.

Today’s models excel at general knowledge. Trained on massive, internet-scale datasets, they demonstrate impressive recall and inductive reasoning. Ask an LLM about any topic – quantum physics, 17th-century Tulip Mania, or Act IV of Hamlet – and it responds thoroughly, in seconds.

However, these foundational models are still challenging to work with.

Unaided, they struggle with planning, deductive reasoning, and abstraction. For instance, they falter when prompted with superfluous information, multi-step problems, or obscured subjects – tasks that require “thinking” beyond pattern-based predictions.

This inability to reason is especially problematic when applying AI to more complex fields like supply chain management, medicine, and law, domains where context and judgment are essential.

And research indicates that simply scaling models with more data and compute is unlikely to close this gap.

While the latest mega models appear to handle complex tasks better, they still rely on pattern recognition rather than true, principled reasoning. For example, OpenAI’s o1 model – a GPT-4 variant optimized for step-by-step problem solving – still struggles to respond well to complex or unsolvable inputs, demonstrating a reliance on prediction patterns and approximate retrieval rather than true understanding. Even future models, such as OpenAI's upcoming Orion, are not expected to show substantial gains in this capability, especially when factoring in their massive development costs.

But this “reasoning gap” is one that startups can exploit, particularly those building domain-specific applications.

Until recently, many AI applications were thin “wrappers” around models, offering limited differentiation. Today, however, post-training techniques – often referred to as cognitive architecture – can create a deeper intelligence layer within applications by integrating code, prompts, and model calls to transform user input into more precise actions and responses.

In fact, these enhancements can deliver gains equivalent to a 5–30x increase in training compute – at a fraction of the cost.

Equivalent Training Compute Required to Match Post-Training Enhancement Gains

This chart shows the improvement from several post-training enhancement techniques, measured by Compute-Equivalent Gain (GEC) – the increase in pre-training compute needed to match the enhancement's performance boost. Source: https://arxiv.org/pdf/2312.07413

These techniques can also drive differentiation and establish a near-term moat.

Since post-training enhancements are most effective when tailored to specific industries, model-layer players in the race to build general capabilities are unlikely to compete directly. Non-AI-native incumbents would need to cannibalize their existing product infrastructure to keep up.

If designed well, products using these techniques can build a unique foundation, providing an edge over other startup competitors applying AI in similar markets but lacking the same technical depth and sophistication.

03 | A framework for intelligent applications

Below is a framework we’ve developed to decompose and the modern application layer. I’ve found it useful to reference when evaluating how new, AI-native applications can apply these foundational models to specific industries, and build an early, technical edge.

Collectively, these components enable AI-native applications to overcome the reasoning and planning limitations of large, general models – and deliver deeper personalization, insight, and efficiency.

Collaborative, adaptive UX drives stickiness and repeat use. Advanced training methods, proprietary training data, and domain-specific knowledge graphs produce more nuanced outputs from unstructured data than what standalone models can achieve. Modular design and scalable pipelines enhance cost-efficiency and scalability.

Below are some of the aspects to focus on, though some may be more relevant than others, depending on the company, product vision, and market.

These technical elements alone aren’t enough to establish long-term defensibility. However, they can unlock a material performance edge that – when paired with a thoughtful product roadmap, distribution, and GTM strategy – can catalyze a growth flywheel, data accumulation, and distribution advantages that ladder up to a more durable moat over time.

Now is a special moment in the evolution of AI.

We’re seeing the limits of investing in model scaling and entering a moment when durable, specialized AI-native applications can emerge. With a clearer understanding of the potential – and limits – of foundational models, we can now better pinpoint where application-layer software can bridge gaps and deliver machine intelligence to real-world use cases.

At Timespan, our ambition is to be a thoughtful, committed partner to the protagonists of this story – the founders in the earliest stages of building a modern stack, solving industry problems with unstructured data in creative ways, and moving boldly and expediently to wow customers and navigate to product-market fit.

Endnotes:

[1] Unstructured data refers to information that doesn’t have a predefined format or organization, making it harder to analyze and interpret compared to structured data, which is organized into a format like rows and columns that computers can more easily read. Unstructured data includes things like text documents, emails, social media posts, images, audio, video files, and sensor data, which vary widely in format and content.

[2] Parallel processing splits a task into independent units that run simultaneously on multiple processing cores, allowing faster task completion. For example, in image analysis, each core might analyze a different part of an image at the same time, then combine the results for a full analysis. In contrast, sequential processing handles each part of the image one after another, using a single core to process each section in order. This sequential approach is slower, as it waits for each step to finish before moving to the next.

[3] A core is a basic processing unit within a computer's CPU or GPU, capable of executing instructions or performing calculations. Each core can handle its own task independently. In CPUs, cores are typically powerful but limited in number, making them well-suited for sequential tasks. GPUs, however, have thousands of smaller, more specialized cores that excel in parallel processing, allowing them to handle large volumes of data concurrently, which is ideal for tasks like graphics rendering or AI computations. NVIDIA’s early growth as a gaming chip company – before becoming a leader in AI – is a great reminder that technology does not track to pre-existing sectors or categories!

[4] With self-attention, each input to the model (like a word) is tokenized and represented by three components: a query (what it’s looking for in other words), a key (what it offers to others), and a value (its actual content). The model uses these queries and keys to calculate attention scores that quantify the relationships between tokens. By focusing on these connections, the model can understand context across the whole input, capturing all of these relationships in parallel. This mechanism not only boosts the predictive power of the model, but also its reasoning capability. By capturing long-range relationships and focusing on the most relevant data points, self-attention allows the model to draw from the full context, enabling it to find complex patterns and produce structured, context-aware outputs and reason through tasks (like answering questions or generating summaries) with greater accuracy and logical consistency. This mechanism is called “self-attention” because the model is only attending to parts of the input itself, rather than external data, allowing each word to "attend" to relevant words around it.

[5] This chart estimates the contributions of scaling and algorithmic innovation in terms of the raw compute that would be naively needed to achieve a state-of-the-art level of performance. The contribution of algorithmic progress is roughly half as much as that of compute scaling. Source: https://epochai.org/blog/algorithmic-progress-in-language-models.

[6] A transpiler, also known as a source-to-source compiler, is a tool that converts code written in one programming language into equivalent code in another language, typically at a similar abstraction level. Unlike a traditional compiler, which often translates high-level language code to lower-level machine code or bytecode, a transpiler converts code from one high-level language to another. This process enables developers to write code in one language but leverage the features and compatibility of another.

[7] A container is a self-contained unit of software that includes everything an application needs to run – its code, libraries, and system tools – so it works the same way in different environments. Unlike full virtual machines, containers share the host operating system, which makes them lightweight and efficient. This isolation means that each container can run independently on the same system, allowing developers to easily deploy and scale applications consistently across servers.

The way we build technology is undergoing a profound shift. New development standards and advancements in coding automation are making software development significantly faster and more accessible.

Code, once the most proprietary and costly component of the software stack, is rapidly becoming a commodity.

I’ve been reflecting on where this will most affect our industry, and I believe open source software will be at the center of this transformation.

I predict that our conception of open source – how it is used, who uses it, how it gets integrated into products – might look fundamentally different than in any prior era of technology.

02 | The pros and cons of open source

Open source software (OSS) is software where the source code is freely available for anyone to inspect, use, and modify for their own use case. It offers several benefits:

• Integrating OSS into in-house applications allows for deeper customization and modularity, compared to buying all-in-one, proprietary software, because the underlying code can be directly copied and edited to meet specific business needs.

• A large community of contributors leads to rapid improvements, organic adoption, robust tooling, and (oftentimes) enhanced security, as large networks of developers identify and patch vulnerabilities.

• OSS is often more cost-effective, allowing firms to circumvent all-in-one licensing fees and vendor lock-in. 97% of firms report net cost savings from using OSS, and without it, companies would need to spend 3.5x more on software.

However, OSS has historically been a tough sell for investors.

Generating revenue and building a competitive edge are challenging when the core product (the codebase) is free and accessible. Only a few open source companies – like MongoDB and Databricks – have surpassed $1B in revenue, with business models relying on peripheral services like support, hosting, or premium security.

Additionally, OSS implementation requires technical expertise, which limits broader adoption. Closed source alternatives – with their plug-and-play functionality, user-friendly APIs, and dedicated support – appeal to buyers seeking ease of use.

As a result, open source companies receive less than 5% of global software spend^[1] and under 5% of U.S. VC investment.

03 | A spike in open source

In the past several years, open source projects have gained ground, especially vis-a-vis closed-source alternatives.

For example, open source data management systems are now as preferred as proprietary ones, a sharp contrast from a decade ago when proprietary solutions were nearly twice as popular.^[2]

Two-thirds of companies increased their use of OSS last year, particularly in (a) machine learning, where frameworks like TensorFlow and PyTorch dominate, and (b) data processing, where companies like Netflix and Uber find Apache Hadoop and Spark now suitable for enterprise-scale workflows.

Moreover, open source's highly-engaged communities and large user bases are often driving faster, more efficient revenue growth than closed-source software, which usually relies on traditional sales and marketing.^[3]

What’s driving this spike?

This rise in open source adoption and commercialization is closely tied to the standardization of web development.

I’ve written before how frameworks like React / Next make front-end development easier. In addition, standardized tools like Docker and Kubernetes, RESTful APIs, and micro-services^[4] have made integrating and customizing open source software significantly faster and more efficient.

As coding automation continues to advance, we may be entering a new era, one where open source is orders of magnitude more powerful and accessible.

04 | Will coding automation create a new paradigm for open source?

AI-driven coding automation is poised to revolutionize software development.

Programming assistants like GitHub Copilot are automating code generation, review, and deployment. (Already, Copilot estimates 55% time savings on task completion for developers.)

Like past technology cycles, where digital distribution and data storage costs fell to near-zero, the structural barriers that have always limited open source adoption – the costs of creating, customizing, debugging, and deploying code – are rapidly declining.

As this trend accelerates, software’s value proposition may shift in favor of open source. If managing OSS is more cost-effective, more customizable, and now simpler than closed-source solutions, it may well become the dominant model for software development. This may be especially true as software budgets get strained, buyers get more discerning around ROI, and sales cycles extend.

Here are key areas where AI tooling could reshape open source:

• Simplified integration: Coding assistants – already used by half of developers on a daily basis – will simplify OSS integration, allowing smaller teams to deploy and customize code much more quickly and with fewer errors.

• Wider access: Natural language processing will allow non-technical users to manipulate open source code using plain language. This opens OSS to a much wider audience, rapidly expanding the market for software development.

• Automated maintenance: AI will streamline the maintenance and security of OSS in live environments by automating updates, proactively resolving bugs, and eliminating the need for manual oversight. This will make OSS even more reliable and secure, addressing concerns that have historically slowed its adoption in enterprise settings.

• New business models: AI-enabled customization, security, and performance monitoring could create new, recurring revenue streams for OSS companies – and a more scalable cost structure for providing those services. For example, open source provider Elastic began charging for AI-powered features like performance monitoring and security in its Elastic Cloud business, boosting that segment’s revenue by 29% year-over-year and growing its share of total revenue to 43% in 2024, up from 35% in 2022.^[5]

• Faster R&D: Open source relies on global networks of developers to maintain code. However, collaboration at a large scale often faces bottlenecks, such as problems with code merging, conflict resolution, and quality control. AI tools are providing automated solutions for these issues, enabling open source to innovate faster than closed source in terms of quality and deployment speed.

AI is reducing the cost of code generation to near-zero, breaking down the long-standing barriers to OSS integration and monetization.

In this new paradigm, the fundamental value in software could shift – from code itself, to the unique ways it is shaped and customized directly by the end user.

As a result, open source may soon have an enduring competitive edge over proprietary software.

Endnotes:

[1] In 2022, OSS spend was estimated at $25B (source) and the overall software market was estimated at $583.5B (source).

[2] Source: https://db-engines.com/en/ranking_osvsc. The DB-Engines Ranking measures popularity by combining factors like web mentions, search trends, technical discussions, job postings, professional profiles, and social media activity. These metrics are standardized and averaged to create a relative popularity score for each database system.

[3] Source: https://www.bvp.com/atlas/roadmap-open-source.

[4] A microservice is a software architecture where an application is built from small, independent services, each handling a specific function. Unlike monolithic systems, microservices can be developed, deployed, and scaled separately, offering greater flexibility, modularity, and easier maintenance.

[5] Elastic N.V. (2024). Q4 2024 shareholder letter. Source. Pages 21, 59.

There’s an ongoing debate in Silicon Valley around open versus closed AI models.

Yesterday, the National Telecommunications and Information Administration (NTIA), an agency within the Department of Commerce, released a report weighing the benefits and risks of open models. This work was mandated by President Biden's October 2023 Executive Order on “Safe, Secure, and Trustworthy AI.”

TL;DR: it’s too early to propose any restrictions on open models.

This is a small, somewhat unexpected victory for open-source advocates.

(Although “too early” is the operative phrase that best summarizes NTIA’s conclusions. This was more of a “let’s punt and continue to evaluate” than anything else.)

Beyond the final recommendation, the report does offer some early insight into an important question – how as a society should we think about open access to this powerful new technology?

02 | Definitions and methodology

The report defines “open models” as AI systems with model weights^[1] that are available to the public.

Model weights are numerical values that determine a model's output based on a given input. They act as the AI’s “blueprint,” allowing the underlying model to be used, replicated, integrated directly into an application, and adjusted for various use cases. Examples of open models include LLaMA (by Meta) and Mistral.

In contrast, “closed” models, like the most recent ones provided by OpenAI, keep these weights private. Closed models only allow users to submit inputs and receive outputs via web interfaces or APIs.

Open models allow for easier customization and access. They enable local data processing, which enhances privacy since data does not have to be sent to the model developer. Open models are generally cheaper to run than closed models for similar use cases.

However, because their weights are openly available, they pose challenges in monitoring and preventing misuse by malicious actors. This includes the potential development of weapons (bio, nuclear, cyber), illegal content, and dis/misinformation.

This report specifically examined:

(a) large, dual-use foundational models (excluding smaller models below 10 billion parameters), and

(b) the marginal impact of open models, i.e., their risks and benefits beyond those of closed models and other pre-existing technologies.

03 | Key takeaways

The report concludes that the benefits of open models—developer contributions, customization, data privacy, democratized access, and competition that drives down costs—currently outweigh the marginal risks of misuse.

But I found the fine print most interesting:

• Today, closed models typically have a performance advantage. However, open models are only a few months behind, and the time to performance parity is shrinking. Footnote 32 on page 53 of the report has some great insight from industry operators on this point.^[2]

• The risks of open models, such as malicious actors fine-tuning or removing safety features for harmful purposes, are offset by the benefits of developer collaboration to identify vulnerabilities and implement safety measures. In instances where models are used inappropriately, the transparency around weights and source code should create better conditions for auditing, accountability, and response time.

• For risks related to societal wellbeing (i.e., open models being used to generate illegal sexual material, dis/misinformation, or discriminatory outputs), the negative impact may come more from existing technology, rather than direct, public access to model weights. For instance, open models might make it easier to create “deep fake” content. But focusing regulation and resources on controlling the spread of these “deep fakes” through existing distribution channels like social networks may yield a better ROI. Instead of focusing solely on what started the fire, focus on the conditions that allowed it to spread.

• Open models may not substantially exacerbate misuse, as closed models are also prone to manipulation (albeit to a lesser extent). For example, the non-consensual, AI-generated intimate images of Taylor Swift that spread across the internet in early 2024 were made using a closed model. Similarly, OpenAI recently reported that malicious nation-state-affiliated actors were using ChatGPT, a closed model, for their cyber operations.

• Regulating open models is unlikely to change the trend towards an oligopoly of a few dominant foundational models. High barriers to compute access, capital, and talent availability will have a greater influence on these dynamics.

• Having a few open models among the preferred set of large providers should foster healthy competition further up the AI supply chain, particularly at the tooling and application layers. Open models are easier to customize, which should lead to a more robust ecosystem of specialized applications and reduce the systemic risk of over-reliance on a single system (we all experienced the risks of over-reliance during the recent CrowdStrike failure).

At this juncture, it’s far too early to declare whether open versus closed will “win,” or which is ultimately “better.” And perhaps that is the wrong debate to have in the first place. Both have risks and benefits. Great companies will be built on either – or, more likely, both.

What is important is that policymakers continue to monitor the risks and benefits, and respond appropriately to protect people and allow for healthy market dynamics as this technology evolves.

As for my own investment thesis:

1. I don’t have a fixed point of view whether a startup should build on a closed- vs open model. I care a lot more about whether there’s a clear narrative about why an individual model (or stitching of multiple models) is the right fit for a particular product based on pricing, utility, and developer functionality.

2. If closed models are unlikely to win long-term based solely on a performance edge, I expect they will invest more in commercial integrations, developer tooling, and network activity on top of their core models. We’re seeing it already with OpenAI’s launch of SearchGPT. Going after broad use cases (e.g., AI-powered personal assistants or search) is a very risk endeavor for startups. Closed models will throw virtually unlimited resources at these obviously large markets as they grow and try to differentiate beyond sheer performance.

Philosophically, I believe open models are an important part of the ecosystem. They foster healthy competition, developer optionality, and flexibility. They also offer cost efficiencies, which are important in this early stage of technology development.

If the marginal risk to society is not material, let the market dictate how and where open and closed models get used.

I’m glad that’s where the NTIA landed – at least for now.

Endnotes:

[1] A quick primer on model weights from this report (page 8): “An AI model processes an input—such as a user prompt — into a corresponding output, and the contents of that output are determined by a series of numerical parameters that make up the model, known as the model’s weights. The values of these weights, and therefore the behavior of the model, are determined by training the model with numerous examples. The weights represent numerical values that the model has learned during training to achieve an objective specified by the developers. Parameters encode what a model has learned during the training phase, but they are not the only important component of an AI model. For example, foundation models are trained on great quantities of data; for large language models (LLMs) in particular, training data can be further decomposed into trillions of sub-units, called tokens. Other factors also play a significant role in model performance, such as the model’s architecture, training procedures, the types of data (or modalities) processed by the model, and the complexity of the tasks the model is trained to perform.”

[2] A few notable quotes:

Center for AI Policy: “We find that the timeframe between closed and open models right now is around 1.5 years. We can arrive at this conclusion by analyzing benchmark performance between current leading open weight AI models and the best closed source AI models.”

Unlearn.ai: “At the moment, it takes about 6 months to 1 year for similarly performing open models to be successfully deployed after the deployment of OpenAI’s closed models. The time gap between proprietary image recognition models and high-quality open-source alternatives has narrowed relatively quickly due to robust community engagement and significant public interest. In contrast, more niche or complex applications, such as those requiring extensive domain- specific knowledge or data, might see longer timeframes before competitive open models emerge.”

Databricks: “Databricks believes that major open source model developers are not far behind the closed model developers in creating equally high performance models, and that the gap between the respective development cycles may be closing.”

Meta: “It is not possible to generally estimate this timeframe given the variables involved, including the model deployment developers’ business models and whether, in the case of Llama 2, they download the model weights from Meta directly or accessed it through third-party services like Azure or AWS.”

Consumer marketplaces are digital platforms that facilitate transactions between individual customers and various sellers, such as peers, freelancers, and businesses. These companies have been among the most consequential in venture capital. Examples include Amazon, Uber, Airbnb, and Etsy.

It’s a model almost perfectly designed for the connective tissue of the internet – linking diverse users across the globe into a singular hub of commercial activity.

Successful consumer marketplaces do four things remarkably well:

1. Define a novel, recurring experience. Amazon created the first destination for purchasing everyday goods (starting with books) through the web browser.

2. Drive better unit economics and scalable growth through new technology. Uber used GPS, mobile distribution, and real-time data processing to achieve economies of scale, on-demand delivery, and a dramatically better cost structure.

3. Harness network effects to create high switching costs. GoodRx’s extensive pharmacy network, discounts, and integrated telehealth services made it difficult for consumers to find comparable savings and convenience elsewhere.

4. Run a creative go-to-market strategy to crack (pun intended!) the chicken-egg problem (where users on one side of the platform only find it useful if the other side is already active). Airbnb did this by scraping Craigslist to automate outreach to its early cohort of hosts, then thoughtfully curating its initial listings to attract renters.

Timing is key to evaluating new consumer marketplaces (although often overlooked). That's because, historically, these models grow in tandem with technological shifts that unlock new types of commercial activity.

02 | Underlying patterns in consumer marketplaces

When examining the evolution of consumer marketplaces, several patterns emerge.

// As automation improves, digital marketplaces are both (a) specializing and (b) handling more complex transactions. Early platforms like eBay managed relatively simple transactions for second-hand, commodity goods. Now, with better data processing and advanced search capabilities, platforms are building products that can match heterogeneous supply (in Fiverr’s case, freelancers with diverse skills) to more complex projects. This trend will accelerate as advancements in AI and improvements in data processing drive even deeper automation.

// Strong network effects lead to industry concentration. In the last several years, 2-3 companies have consistently accounted for 40-60% of total annual GMV among the top 100 private consumer marketplaces.^[1] Public companies reflect a similar trend – Amazon, for example, commands nearly 40% of e-commerce market share.

For entrepreneurs, this dynamic highlights (i) the importance of timing, to capitalize on new technology shifts and secure a first-mover advantage, and (ii) the need for a clear product thesis that accounts for precisely how this moment in technology can service unmet needs for buyers and sellers.

// Data ownership and customization are increasingly important for suppliers. SaaS platforms like Shopify and social networks like Instagram are unbundling the traditional marketplace model. Instead of having a central intermediary trafficking transaction flows, sellers are now building custom storefronts and distributing them directly to various devices and social networks in order to retain more control over their data and customer experience. To compete, new marketplaces must also address these needs. This can be achieved by using decentralized infrastructure and/or better self-custodial tools.

// Historically, the most transformative marketplaces build new types of network endpoints. These endpoints serve as the essential building blocks that give rise to entirely new product categories.

A network endpoint acts as a gateway that ingests and processes data into a marketplace network. Examples include distribution channels like web browsers, IoT devices, mobile phones, and APIs that pull and integrate data from external sources. These new types of endpoints introduce unique data assets into the product experience, which then unlock entirely new categories of commerce.

For example, Uber tapped into a new type of endpoint (mobile distribution) to feed a new type of data asset (real-time location data) into its product, which was essential for creating a new category (on-demand rides). Similarly, GoodRx built its own proprietary API to feed a new type of data asset (real-time prescription drug pricing mapped against insurance plan formularies^[2]) into its product. This created an entirely new market around prescription savings and price comparison.

I expect these trends to continue in this next wave of technology development.

03 | New trends in consumer marketplaces

Recently, I have been spending time with companies that are in the early innings of building new consumer marketplaces.

A few years ago, this space felt stale – too many "Uber for [inset niche, existing product here]."

But today feels different. Founders are in experimentation mode, testing use cases and exploring the potential for new technology to open up entirely new commercial categories.

One trend I'm digging into is portable identity management. Startups are developing systems for longitudinal digital identities, which integrate seamlessly across different marketplaces. Imagine Craigslist 2.0, where your verified information, preferences, and transaction history travel with you into different niche marketplace verticals. This makes interactions smoother and more personalized, and means fewer fraud issues and enhanced trust between buyers and sellers.

Another trend is around harnessing the power of artificial intelligence to create new economies around very complex workflows. Most existing marketplaces focus on one-to-one matching. But AI can unlock more complex, multi-party coordination. Picture, for example, a personal finance management marketplace that unlocks access for a whole new customer segment that is unwilling to pay traditional advisor fees. An AI agent could organize advisors, tax consultants, investment products, insurance agents, and estate planners. The AI handles administrative tasks and sequencing, ensuring each step is assigned to the right professional at the right time. This frees up time for professionals to focus on their unique skills, take on significantly more clients (and compensation) for their time, and creates greater accountability and transparency for the end buyer.

One last trend is creator augmentation. In the last several years, brands have increasingly looked to influencers to market their products. In 2016, $1.7B was spent on influencer marketing. That figure reached $21.1B in 2023 (a 43% CAGR).^[3] As this market continues to grow and large foundational models improve, it will allow these influencers to capture more rent from these arrangements and scale their likeness, tone, and personalized recommendations across the internet. Imagine a creator-led marketplace with:

• WYSIWYG tooling,^[4] so creators can easily build custom, dynamic storefronts that are unique to their brand and voice

• a personalized dashboard, powered by models fine-tuned with creator data. This would enable creators to communicate at scale across multiple channels and give them insight into what is motivating their fan base

• bespoke product recommendations that align not just with the creator’s brand, but also with the specific follower and their specific relationship to that creator

• full creator control over their tooling and data, to build trust, increase the likelihood of adoption, and provide an authentic user experience.

If Sam Altman envisions a world where a one-person team can build a unicorn company, perhaps a more immediate opportunity is for individual creators to build and manage their own mini-marketplaces, all on a singular back-end network.

Conceptually, none of these trends feel entirely new. Many have been in the entrepreneurial imagination for some time. But with recent technology advances, we’re finally seeing products materialize and deliver tangible functionality.

If you are building along any of these themes, or have a different take on what the next, landmark consumer marketplace will look like, I’d love to connect.

Endnotes:

[1] Sources: 2022, 2021, 2020 a16z Marketplace 100 reports. Instacart represented 64.2% of private marketplace GMV in 2022, 71.5% in 2021, and Airbnb, DoorDash, Instacart, and Postmates collectively represented 76% of private marketplace GMV in 2020. (Shout out to Bennett Carroccio, co-founder of Canal and an entrepreneur I have partnered with, who first ran this marketplace analysis in 2020.)

[2] A formulary is a list of prescription medications approved for use and covered by a particular health insurance plan or provided by a healthcare provider.

[3] Source.

[4] WYSIWYG stands for "what you see is what you get." It refers to a software interface that allows users to see what the end result will look like while the document or content is being created. This is commonly used in the context of text editors, website builders, and content management systems where the user can format text, insert images, and make other changes in a visual editor that directly reflects how the content will appear when published.