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 actually exist, then rewrote the query using the correct names (45:53).
That recovery is the capability. Everything else in the session is infrastructure supporting it.
Why the recovery matters more than the answer
An agent that writes a correct query on the first attempt has demonstrated that it was given good enough context. An agent that writes a wrong query, notices, and finds out what it needs has demonstrated something more valuable: it can operate in an environment nobody described to it in advance.
That distinction decides whether these systems work in real infrastructure. Production logging is never fully documented. Field names drift, services are added by teams that did not read the conventions, and the schema in anyone's head is out of date. An agent that requires accurate documentation is an agent that requires the thing nobody has.
Discovering the schema at run time is how it copes. The cost is latency and tokens — one wasted query plus a lookup plus a rewrite — and that is a straightforwardly good trade against the alternative of maintaining perfect documentation.
The scenario is well chosen
The situation used is traffic at ten times normal levels with checkout failures beginning, and an engineering team receiving alerts while overwhelmed by data from many services all alerting at once (44:06).
That is the right test case because the difficulty is not detecting the problem. Everything is alerting. The difficulty is that the signal is buried in a volume of correlated noise, where every downstream service reports failures caused by one upstream cause.
Which is a task where an agent has a genuine structural advantage over a person. Reading a hundred alert streams and correlating timing is exactly the kind of work humans do slowly and badly under pressure, and where being fast matters more than being subtle.
Where it goes past observability
The step that changes the nature of the tool is the business impact estimate. The agent has access to sales tables as well as logs (50:11), and queries the sales history for normal order volume and average order value in order to estimate what the failures cost (50:38).
That is a genuinely useful output and it is a different kind of claim than anything else in the session.
A log analysis is checkable. The query ran, the events are there, someone can verify the count. An impact estimate multiplies observed error counts by historical averages and produces a number that will be forwarded to leadership (49:35) — and the assumptions inside it are not visible in the output.
Would those failed orders have converted? Were they retried successfully? Is the historical average representative of this traffic spike, which is by definition abnormal? Each is a modelling decision the agent made implicitly, and the result arrives with the same confident presentation as the log query.
The risk is not that the estimate is wrong. It is that an unverifiable number produced alongside verifiable ones inherits their credibility.
The onboarding claim
The supporting argument is that teams can begin analysing logs from various services in minutes rather than days (25:46).
That is the correct thing to have optimised. Observability tooling fails at adoption far more often than at capability, and the reason is almost always that connecting a new service is tedious enough to defer. A team that can point at a log stream and get value immediately will connect all of them; a team facing a day of configuration per service will connect the two that are already broken.
The governance note that the underlying project now sits within a neutral foundation (8:11) matters for a related reason. Observability data is the most locked-in category of infrastructure data there is — it is high-volume, low-value individually, and expensive to migrate — which makes the governance of the format a legitimate part of the purchasing decision rather than a detail.
关键数据
- 10x
- traffic level in the scenario, with checkout failures beginning and every service alerting 44:06
演讲章节
关键要点
- 01
The first query returned wrong results, so the agent consulted a field mapping and rewrote it — the recovery is the capability being shown. 45:53
- 02
The scenario is ten times normal traffic with every microservice alerting, where the difficulty is correlated noise rather than detection. 44:06
- 03
The agent is given access to sales tables alongside logs, and estimates impact from normal order volume and average order value. 50:38
- 04
That estimate is an unverifiable number produced alongside verifiable ones, and inherits their credibility on the way to leadership. 49:35
- 05
Onboarding a new log source is targeted at minutes rather than days, which is where observability tooling usually fails. 25:46
提及的实体
相关演讲
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 line that explains this session comes from the customer in the last ten minutes: they are preparing for a world where metadata is how agent-based systems find the data they need and access it through the controls being built. That relocates a function — governance has spent two decades as compliance activity describing data that people locate by other means, and if agents navigate by the catalogue then the catalogue stops describing the access path and becomes it. An incomplete catalogue is a documentation problem when humans can ask a colleague; an agent has no such workaround. The most honest moment addresses the perennial failure that rules get written and ignored, with enforcement rather than publication as the argument. Generated descriptions and greyed-out classification suggestions divide the labour correctly, keeping a person accountable while removing the burden of finding candidates.