ExpertsFM

20VC: Horizontal vs Vertical Agents: Who Wins | Model Routing: Commodity or Increasing in Value | The Future of the Inference Market | Why Founders Should Take Discounts for Tier 1 Firms with Harrison

The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch · October 18, 2026

5 Selected Lessons:

heuristic · 2 priority · 2 framework · 1
Where value accrues in vertical AI agents
priority based on: reasoning Harrison Chase

Source

The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20VC: Horizontal vs Vertical Agents: Who Wins | Model Routing: Commodity or Increasing in Value | The Future of the Inference Market | Why Founders Should Take Discounts for Tier 1 Firms with Harrison (October 18, 2026) · at 11:42 ▸

When this applies

when deciding where to invest scarce effort in a layered technology stack serving a specific domain

The takeaway

In any domain where quality is hard to define generically, the people who can encode what 'good' means capture outsized value because that judgment is the scarce, non-commoditizable input.

Why it works

Domain experts who can precisely define what 'good' looks like (write evals/verifiers) hold knowledge that generic model or harness providers cannot replicate, so value concentrates where that judgment is captured and operationalized.

One level up

When a capability becomes broadly available (intelligence, compute, tooling), value shifts to whoever can direct and judge it for a specific context.

Where it stops holding

This stops working when a domain's quality bar is simple/objective enough that anyone can write the verifier, or when models become good enough at a task that domain-specific harness tuning adds no measurable lift.

Detail

hierarchy:
  • 1. Domain experts who can write verifiers/evals capturing what 'good' means in a vertical
  • 2. Those who then tune the harness/context using that domain knowledge
  • 3. Generic harness or model providers, who capture less value because they lack domain specificity
rationale: If you're building a vertical agent, start at the harness/context-engineering layer (highest ROI) before touching the model/post-training layer.

In their words

If value is derived through verification, I think the people who win are the domain experts, the people who are able to kind of like quantify what that value means, which is very hard.
Three prerequisites for successful AI infrastructure teams
priority based on: observed outcome Harrison Chase

Source

The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20VC: Horizontal vs Vertical Agents: Who Wins | Model Routing: Commodity or Increasing in Value | The Future of the Inference Market | Why Founders Should Take Discounts for Tier 1 Firms with Harrison (October 18, 2026) · at 48:27 ▸

When this applies

when assessing any early-stage technical team in a fast-moving market for investability

The takeaway

Rank founding-team quality by: (1) elite technical depth, (2) execution speed, (3) brand/early-mover visibility — in markets changing too fast for careful planning to substitute for speed.

Why it works

Deep technical credibility attracts trust and talent, execution speed matters because market conditions shift before slower teams can adapt, and brand built from viral early traction compounds into a durable advantage that outlasts the initial feature set.

One level up

In a fast-moving, crowded market, bet on team attributes (talent, speed, brand) over specific current product features, since the product will keep changing.

Where it stops holding

This stops working in slower-moving, more stable markets where careful planning and moat-building matter more than raw speed and virality.

Detail

hierarchy:
  • 1. Talent — exceptionally strong technical teams (e.g., Fireworks' founders wrote PyTorch)
  • 2. Speed — ability to iterate and execute quickly as the market changes rapidly
  • 3. Brand — early viral traction that becomes a durable advantage, even amid heavy competition
rationale: When there's a breakout company with a strong technical roster that has proven it can execute quickly, 'you just don't look at the price and you just invest.'

In their words

one, I think like the talent that they have is tremendously strong
Trace-to-improvement loop across context, harness, and model
framework based on: lived experience Harrison Chase

Source

The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20VC: Horizontal vs Vertical Agents: Who Wins | Model Routing: Commodity or Increasing in Value | The Future of the Inference Market | Why Founders Should Take Discounts for Tier 1 Firms with Harrison (October 18, 2026) · at 21:43 ▸ · at 24:31 ▸

When this applies

when building any system that should improve itself using feedback generated from operating in production

The takeaway

A single stream of operational exhaust can feed multiple distinct improvement mechanisms; design a separate 'outer loop' process for each target (data store, logic layer, core engine) rather than assuming one feedback pipeline suffices for all.

Why it works

Different kinds of improvement require different pipelines to consume the same raw exhaust (traces): updating a text memory file needs a summarizing agent, updating harness code needs a code-editing agent, and updating model weights needs post-training — each channel converts observation into a different kind of durable change.

One level up

Continual improvement systems need an explicit outer loop (observe → extract learning → apply → verify) layered on top of the core execution loop, and the application step differs by what layer is being improved.

Where it stops holding

This stops working when the system lacks reliable evals to verify that a proposed change actually improved things, or when the 'meta-reflection' step (distilling traces into learnings) is beyond current model capability for the task.

Detail

procedure:
  • 1. Capture traces (exhaust) of agent runs
  • 2. Run a dedicated process to extract learnings depending on target: an agent to summarize into memory, an agent to edit harness code, or post-training to update model weights
  • 3. Apply the update
  • 4. Verify improvement using evals before trusting the change
rationale: Continual learning changes the surrounding system (an outer loop), not the core agent loop itself, which stays an LLM calling tools.

In their words

It will look like take traces, get learnings, fix something, measure it to make sure it improved, and then repeat.
Erase the product as models improve
heuristic based on: lived experience Harrison Chase

Source

The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20VC: Horizontal vs Vertical Agents: Who Wins | Model Routing: Commodity or Increasing in Value | The Future of the Inference Market | Why Founders Should Take Discounts for Tier 1 Firms with Harrison (October 18, 2026) · at 6:24 ▸

When this applies

when building any product layer on top of a rapidly improving underlying technology or platform

The takeaway

Continuously identify which parts of your product are temporary workarounds for a platform's current limitations versus durable value that the platform will never provide, and be willing to delete the former quickly.

Why it works

As the underlying capability absorbs functionality natively (e.g. tool calling moving into the model API), the scaffolding you built to work around its old limitations becomes dead weight and must be deleted, not maintained.

One level up

Build durable value only where the layer below you structurally cannot reach (proprietary data, external APIs, system integration), not where you're patching a temporary gap.

Where it stops holding

This stops working when you can't tell which parts are hacks versus durable value, or when you're too slow to react and competitors delete/replace the hack-based feature first.

Detail

rule: Treat workaround features built for current model limitations as temporary; delete them as soon as the platform absorbs the capability natively.
threshold: When a major lab ships a native version of a hack you built (e.g. native tool calling vs DSL+parsing), switch immediately rather than maintain the legacy path.
rationale: The system around the model (data, APIs, orchestration) will always be needed; the hacks for chain-of-thought, planning, tool-calling that can be absorbed into the model itself will not.

In their words

The main way our business changes as the model gets better is we basically have to erase big parts of our product.
'Everything just works' — inference demand is systematically underestimated
heuristic based on: data cited Harrison Chase (citing Eric Vishria, Benchmark)

Source

The Twenty Minute VC (20VC): Venture Capital | Startup Funding | The Pitch — 20VC: Horizontal vs Vertical Agents: Who Wins | Model Routing: Commodity or Increasing in Value | The Future of the Inference Market | Why Founders Should Take Discounts for Tier 1 Firms with Harrison (October 18, 2026) · at 0:00 ▸ · at 46:13 ▸ · at 56:23 ▸

When this applies

when forecasting demand for a resource at the early stage of an exponentially growing new technology category

The takeaway

In a genuinely massive and still-growing market, multiple competitors across a layer can all succeed simultaneously because demand growth outpaces the market's ability to be saturated.

Why it works

In an early, rapidly expanding market, total demand expansion outpaces any single competitive dynamic, so nearly any capable provider can succeed because the market itself, not competitive positioning, is the binding constraint.

One level up

Don't apply zero-sum competitive analysis to markets that are still in the exponential demand-growth phase — distinguish 'who wins the market' questions from 'is there enough market for many to win' questions.

Where it stops holding

This stops working once the market matures and growth slows, at which point competitive differentiation (not just capability) starts to determine winners, or if demand growth suddenly plateaus.

Detail

rule: When in doubt about a market's absolute size in an exploding category, assume demand is larger than your gut estimate.
threshold: Harrison says he 'really underestimated' both inference demand and coding-agent demand over the ~3-4 year life of LangChain.
rationale: The market for inference is so large that 'any inference will work' — fireworks, AWS, Crusoe will all find demand.

In their words

This market is so big. There's just so much demand for it. And I don't know if it's going to get less anytime soon.