AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
The hardest problem in this session has nothing to do with machine learning. It is that you cannot reliably tell who owns a machine.
The comparison drawn is with the automotive industry, where every vehicle has an identification number and registration goes through a state authority. Heavy equipment has no equivalent — someone can simply assert that they own a tractor, and establishing otherwise is genuinely difficult (17:48).
Everything the connected-product strategy promises depends on solving that first.
Why ownership is the load-bearing problem
Consider what the platform is supposed to do. Detect a developing fault from telemetry, generate a service ticket, and have someone contact the customer to arrange a visit (9:03).
Every step after detection requires knowing who the customer is. Which organisation operates the machine, who holds the service agreement, which dealer covers them, who receives the call. Get that wrong and the predictive maintenance capability produces a correct prediction delivered to the wrong person.
This is why an identity problem outranks an analytics one. The model can be excellent and the value still fails to land, because the last step in the chain is a phone call to a specific human being.
The estate that makes it difficult
The scale explains why this was not solved earlier: millions of machines operating on nearly every continent, of which 1.5 million are connected and streaming data (12:46).
And the structural complication — around 160 dealers, each an independent business running its own systems, which made incorporating their service records genuinely complex (15:31).
That is the real shape of the problem. The service history of a machine, which is what makes prediction possible, is distributed across 160 independent companies with no obligation to record it the same way. The telemetry belongs to the manufacturer. The context that makes telemetry meaningful belongs to someone else.
The state they were in
The description of the prior situation is refreshingly direct: multiple analytics platforms and warehouses accumulated over years, and dealers who were confused because different systems gave different answers to the same question (14:08).
The last part is the diagnosis. The problem was not that the tools were bad. It was that the same question returned different answers depending on where it was asked, which destroys trust in all of them simultaneously — including the ones that were right.
Their response was to define a single authoritative answer to the basic questions: what is an asset, what is a customer, what is a dealer (15:59). That sounds like a modelling exercise and is really a political one, because each existing system encodes a definition that some group depends on, and choosing one means telling the others their answer was wrong.
The engineering that followed — analytics pipelines and a training environment that runs at scale, addressing what they describe as the previous failure of vendors to scale to their needs (16:27) — is the easier half.
The pattern the framing describes
The connected-product progression laid out at the start is a good map: connect the product, apply analytics, use the data to understand how customers actually use it, then make the product software-defined so capabilities can be delivered after the sale (2:16, 3:40).
The step that changes a business is the third one. Telemetry originally justified as maintenance turns out to describe usage patterns, and usage patterns describe customers — which is a different asset than the one the sensors were installed to produce.
The concrete example given elsewhere is the maintenance engineer arriving with the right parts already in the van (5:54). That is the version of predictive maintenance that pays for itself, and it requires the prediction to be accurate enough to commit inventory to a truck before anyone has inspected the machine.
Which loops back to the beginning. That level of confidence needs service history from 160 dealers, correct machine identity, and a reliable link to the customer — three problems that are all about records rather than models, and all harder than the analytics sitting on top of them.
Key numbers
Talk chapters
Key takeaways
- 01
Unlike vehicles with an identification number and state registration, heavy equipment ownership can simply be asserted, which makes onboarding genuinely hard. 17:48
- 02
Around 160 independent dealers hold the service records that make telemetry meaningful, with no shared way of recording them. 15:31
- 03
The prior failure was that different accumulated systems answered the same question differently, destroying trust in all of them at once. 14:08
- 04
The response was defining single authoritative answers to what an asset, a customer and a dealer are — a political exercise as much as a modelling one. 15:59
- 05
The version of predictive maintenance that pays for itself has the engineer arriving with the right parts already in the van. 5:54
Entities mentioned
Related talks
The practical counterpart to the argument made elsewhere this season that specification is what contains model entropy. Raval and Harris name the failure they are addressing precisely — a prompt-and-pray loop in which working code arrives with no record of what the model assumed, which requirements were fuzzy, what design was chosen or why, leaving nothing to review and nothing to iterate against when a defect surfaces months later. Their answer is three committed markdown artefacts: requirements written in a structured requirements syntax with acceptance criteria attached to each user story, a design document carrying technical decisions together with the reasoning behind them, and a task list whose entries cite the requirement numbers they satisfy. The traceability is the point — a reviewer questioning a decision in a pull request can follow it back through the task to the design to the requirement, all in the same repository. Notably they keep the human between each phase rather than after it, with the agent surfacing ambiguity as questions before proceeding.
Drawn from a year of engagements with more than a hundred companies, this is the most direct challenge in the season's programme to the assumption that faster code generation produces faster delivery. Mishra and Raja open with external evidence rather than their own: an industry study putting realised velocity gains in the ten to fifteen per cent range, and a controlled experiment in which developers using AI estimated themselves roughly a fifth more productive while measurement showed them a fifth slower. Their diagnosis is that both prevailing working styles fail for opposite reasons. Handing an ambiguous problem to an agent and awaiting a finished result produces a volume of code the developer must nonetheless sign for and cannot confidently review, so it stalls before production. The senior engineer's alternative — decomposing the work personally and inserting AI into narrow slots — keeps the intellectual load exactly where it was, and leaves the surrounding process untouched, so hours saved in editing are consumed by the meetings that process still requires.
Brooker builds the definition from the bottom up rather than asserting it, using a deliberately absurd arithmetic task to separate three categories: what a model computes reliably as a fixed function of its input, what merely needs to arrive in the system prompt, and what genuinely requires reaching into the world. Only the third category justifies a tool, and the distinction matters because most production disappointment comes from tools built for the first two. His working definition follows — a system given a goal that loops between inference and tool calls until it reaches one — with the observation that modern agents increasingly embed code in their definitions, not for expressiveness but because replacing inference steps with deterministic code improves reliability while lowering both latency and cost. The remainder covers what production actually demands around that loop: somewhere to run, memory that persists preferences, a gateway to internal and external tools, evaluation, and formal methods applied to policy.
The most concrete attempt this conference season to answer a question the agentic coding sessions mostly leave open: if commit counts and hours saved are the wrong measures, what replaces them? Otto's account is unusually specific about why the obvious alternative fails — summing the small time savings a platform team delivers produces figures exceeding a hundred per cent of a developer's time, and a minute returned is not code in production. Their replacement borrows from Amazon's retail supply chain, where cost to serve measures what it takes to place a package on a doorstep, and applies the same shape to software: total cost divided by units of delivery, with the unit chosen to fit the team. The supporting research is the more quotable finding — across tens of thousands of developers over five years, individual velocity reverts to the team's mean, making team velocity the strongest predictor of both individual output and perceived productivity, which is the empirical case against measuring individuals at all.
The framing statistic is organisational rather than technical: around eighty per cent of organisations expected to have platform engineering teams going into 2026, up from about forty-five per cent a couple of years earlier. The interesting part is the doubling. The problem described is teams solving the same problems separately, producing inconsistency and redundancy — dangerous not because of duplicated effort but because each independent solution has its own security properties, and the organisation's real posture is the weakest rather than the average. The most valuable content is that two financial services organisations went in diametrically opposite directions on workload identity and both are described as working, which implies the choice is determined by context rather than by a general answer. The honest note follows immediately: even with standardised patterns the result remains fragmented.
The moment in this demonstration that deserves attention is a failure: the agent's first query returned the wrong results, so it consulted a mapping tool to learn what fields exist and rewrote the query with the correct names. That recovery is the capability, because production logging is never fully documented — field names drift and the schema in anyone's head is out of date. An agent that requires accurate documentation requires the thing nobody has. The scenario is well chosen, since with traffic at ten times normal and every service alerting, the difficulty is not detection but correlated noise. Where the session goes past observability is the business impact estimate, which multiplies observed errors by historical averages and produces a number for leadership whose assumptions are not visible — an unverifiable figure delivered alongside verifiable ones.