ExpertsFMGoogle DeepMind's Logan Kilpatrick: Why the Model Eats the Harness
Training Data · June 11, 2026
5 Selected Lessons:
framework · 2 heuristic · 1 priority · 1 reasoning_pattern · 1
Focus as the startup's superpower against model-company breadth
Source
Training Data — Google DeepMind's Logan Kilpatrick: Why the Model Eats the Harness (June 11, 2026) · at 41:36 ▸
When this applies
when a small, focused competitor faces a much larger, better-resourced generalist competitor in a fast-moving technology market
The takeaway
Structural breadth (many products, many obligations) is a real constraint on big companies' ability to go deep in any one vertical — depth in domain expertise beats a bigger company's general capability in that narrow zone.
Why it works
Large companies with many products and user obligations cannot concentrate on any single vertical's specific customer/ecosystem knowledge; a focused startup can out-execute them there precisely because it has nothing else to do.
One level up
When facing a powerful generalist, don't compete on generality — compete on depth in a vertical the generalist is structurally unable to prioritize.
Where it stops holding
This stops working when the 'capability overhang' is severe enough that the general model fully subsumes the vertical use case without needing domain-specific expertise at all.
Detail
hierarchy:
- 1. Domain expertise / customer/ecosystem knowledge in a vertical
- 2. Focus (ability to concentrate entirely on one problem)
- 3. General model capability (which big labs have in abundance but can't aim narrowly)
rationale: Big companies 'have an obligation to do a bunch of things' and therefore structurally cannot focus the way a startup can, which is why startup opportunity has expanded rather than shrunk despite more capable models.
In their words
Like it's just, you can really like run laps around even the best model labs because like focus is the like superpower of startups. Like if you can focus, you can do anything.
Agent harness as cross-product through-line
Source
Training Data — Google DeepMind's Logan Kilpatrick: Why the Model Eats the Harness (June 11, 2026) · at 1:46 ▸
When this applies
when a company with many disparate product lines wants a single technical layer that can be rebased across all of them to create consistency and leverage
The takeaway
Find or build the lowest common infrastructure layer that can become the connective tissue across a sprawling portfolio, then let specialized products diverge only ~20% from that shared base.
Why it works
A shared underlying execution layer (model + harness) lets every product inherit new capabilities simultaneously instead of each team rebuilding agentic behavior independently.
One level up
Centralize the expensive, hard-to-replicate core; decentralize only the cheap, use-case-specific surface.
Where it stops holding
This stops working when products' use cases diverge so much that the shared harness requires more customization than it saves, eroding the leverage of a common base.
Detail
procedure:
- Identify a capability (coding agent harness) that works well for its narrow use case
- Generalize it into a base harness shared across products (~80% identical)
- Specialize the remaining ~20% per product (e.g., vibe-coding vs. always-on consumer agent)
- Roll the same harness into as many products as possible to create a unifying through-line
benchmarks: {"shared_base_fraction":"~80%"}
rationale: A single evolving harness lets a company with 'sub hundred' products gain agentic capability everywhere at once rather than reinventing it per product.
In their words
I think you have that base harness that like probably has like 80% of the same stuff. And then you specialize for coding or for whatever the use case is.
The model eats the harness
Source
Training Data — Google DeepMind's Logan Kilpatrick: Why the Model Eats the Harness (June 11, 2026) · at 38:32 ▸
When this applies
when deciding whether to build durable value in the infrastructure/tooling layer wrapped around a rapidly improving core technology
The takeaway
Any layer built to compensate for a fast-improving core technology's current limitations is a temporary moat; the core technology will eventually internalize that layer's function, so don't mistake today's scaffolding advantage for a durable one.
Why it works
External scaffolding (tool-calling, search, code execution, containerized harnesses) initially sits a few steps ahead of what's baked into model weights; as training absorbs these capabilities natively, the scaffolding's differentiating value gets 'eaten' and becomes undifferentiated infrastructure.
One level up
In fast-moving technology stacks, assume today's workaround layer becomes tomorrow's commodity feature — build your durable advantage elsewhere.
Where it stops holding
This stops working when the scaffolding serves genuinely diverse external integrations (e.g., multiple search providers) that users want regardless of model-native capability, so some external layers persist even after the model 'could' do it natively.
Detail
procedure:
- Recognize that 'the model' today is actually model weights + surrounding scaffolding (tool calling, containers, harness)
- Expect scaffolding capabilities to be progressively absorbed into the model itself via training
- Anticipate that the locus of competitive alpha will shift away from the harness once absorption happens
- Build a 'harness bench' type evaluation to track how well models generalize across different harnesses, as a leading indicator of this absorption
benchmarks: {"prediction_horizon":"roughly 12 months for harness-building alpha to diminish"}
rationale: The scaffolding is a stopgap for capability the model doesn't yet have natively; once the model has it, the stopgap's value collapses.
In their words
The scaffolding is like oftentimes a couple of steps ahead of what is like baked directly into the model. And then what ends up happening is like the model eats that scaffolding and it becomes part of the native model system
Culture inherits from founder archetype
Source
Training Data — Google DeepMind's Logan Kilpatrick: Why the Model Eats the Harness (June 11, 2026) · at 43:53 ▸
When this applies
when trying to predict or explain an organization's culture and priorities from its founder's background/identity
The takeaway
To understand why an organization behaves the way it does, look at the founder's defining identity/background as a strong predictive signal, not just its stated mission.
Why it works
Founders imprint their personal orientation (scientist, businessman, esoteric thinker) onto early company norms, which then persist structurally even as the company scales.
Where it stops holding
This stops working when leadership has turned over significantly or when the company has scaled far beyond the founder's direct influence, diluting the original imprint.
Detail
approach: Map an org's observable culture back to the founder's personal identity/background as an explanatory lens
signals:
- Demis's Nobel-scientist background correlating with DeepMind's 'solve disease' scientific mission framing
- Sam's business orientation correlating with OpenAI's commercial culture
rationale: It's 'so easy to get lost in this competitive race' of benchmark numbers and lose sight of the founding scientific mission — the culture lens helps keep that mission salient.
In their words
Demis is a Nobel Prize scientist and like the sort of OG of a lot of this stuff. And sort of you feel that in the deep mind culture.
Dogfood your own model as daily driver while still using competitors' tools
Source
Training Data — Google DeepMind's Logan Kilpatrick: Why the Model Eats the Harness (June 11, 2026) · at 18:12 ▸
When this applies
when deciding how strictly to mandate internal use of your own product versus staying exposed to competitors' products
The takeaway
Require default internal usage of your own product for the feedback loop, but explicitly permit competitor tool usage to avoid insular blind spots.
Why it works
Mandating your own product as default usage creates a feedback flywheel (scale of engineers, A/B tests, live experiments) that directly improves the product; simultaneously permitting competitor use keeps you from losing situational awareness of the ecosystem.
Where it stops holding
This stops working when internal engineers are not representative of external customers, making the feedback loop misleading rather than useful.
Detail
rule: Use all competitor models/products for ecosystem awareness, but mandate your own product as the daily driver for the majority of engineers
threshold: hundred thousand plus engineers as the scale that makes the feedback flywheel a competitive advantage
rationale: Scale of engineering resources running live experiments on your own product should be a structural advantage if you actually use it.
In their words
Google more broadly, has like a hundred thousand plus incredible engineers who are using the models and giving feedback.