AI-assisted analysis. See our editorial policy.
Human editorial review not recorded
The line that explains this entire session comes from the customer rather than the vendor, in the last ten minutes: they are getting ready for a world where metadata is how their agent-based systems will find the data they need, and access it through the controls being built (53:41).
That sentence relocates a function. Data governance has spent two decades as a compliance activity — a catalogue maintained because auditors ask for one, describing data that people find through other means. If agents locate data through the catalogue, the catalogue stops describing the access path and becomes it.
Why that changes the stakes
The difference is between a map and a road.
An incomplete catalogue is a documentation problem when humans navigate by asking colleagues, remembering where things live, and reading table names. Those workarounds are invisible in any governance metric and they are why catalogues survive being wrong.
An agent has none of them. It cannot ask the person who built the pipeline, and it does not know that a table's real meaning diverged from its description three years ago. What the metadata says is what exists.
Which means a governance programme that was adequate for compliance may be badly inadequate as an access layer, and nobody finds out until an agent confidently queries the wrong thing.
The enforcement point they make in passing
The most honest moment addresses the perennial failure: rules get written, business teams do not follow them, and everyone knows this story — the argument for the platform being that the rules can be enforced rather than published (11:43).
That is the correct diagnosis. Governance frameworks fail at the enforcement step, not the definition step, and the reason is straightforward: following a rule that lives in a document is voluntary, and the person who ignores it saves time while someone else absorbs the consequence.
Making the rule a property of the system removes the choice. It is also the point where governance programmes generate the most resistance, and the session does not discuss what happens when enforcement blocks a team that has a deadline.
The automation that is genuinely useful
Two capabilities in the demonstration are worth the attention.
Descriptions generated from technical metadata (24:18) attack the specific reason catalogues rot: writing a description is work for the person who least benefits from it. A generated first draft that a human corrects is a far better economic proposition than a blank field.
Suggested glossary terms — including flags for personal data — presented greyed out until explicitly accepted (25:37) is the better design of the two. The suggestion does nothing until someone confirms it, which keeps a person accountable for the classification while removing the burden of finding candidates. That is the right division of labour for a task where a false negative has regulatory consequences.
The access workflow follows the same pattern: approval granted with a filter attached and a stated reason recorded (34:24). Recording why is the part that matters, because access reviews are impossible when the record shows what was granted and not what it was for.
The scale that justifies the effort
The customer numbers give the argument weight: more than 20 million customers and close to 750 million financial transactions monthly, at an institution approaching its third century (47:19, 45:28).
At that volume the case for automation is not efficiency. No human process describes and classifies data arriving at that rate, which means the choice is between generated metadata that is imperfect and no metadata at all.
Their framing of the goal — simplification reducing the cost of change so they can keep pace with customer needs (52:22) — is the honest business case. It is not a compliance argument dressed up. It is a claim that the descriptive layer has become the constraint on how fast the institution can build anything, which is a considerably stronger reason to invest in it than an audit finding.
Key numbers
Talk chapters
Key takeaways
- 01
The customer frames the goal as readiness for a world where metadata is how agents find data and access it under governed controls. 53:41
- 02
The argument for the platform is enforcement rather than publication, since governance frameworks fail at the enforcement step. 11:43
- 03
Descriptions generated from technical metadata attack the reason catalogues rot — writing them is work for whoever benefits least. 24:18
- 04
Classification suggestions including personal-data flags stay inactive until explicitly accepted, keeping a person accountable for the call. 25:37
- 05
Access approvals record a filter and a stated reason, which is what makes later access reviews possible at all. 34:24
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.
