AI Data Architecture

The rare enterprise session that describes the wiring rather than the outcome. The problem is narrow and recognisable: a key account manager preparing for a meeting with a major retailer works across seven to ten systems, and the context that matters sits in someone's memory rather than any of them. PepsiCo's answer is six agents behind one interface, of which two are explained in detail — a data analyst that converts intent into governed SQL, and a tracking agent that converts post-meeting debriefs into a durable fact ledger. The governance detail is the most reusable part: table permissions are enforced through the catalogue so the agent cannot answer from data the asking user is not entitled to see, and frequently-asked queries resolve through pre-verified SQL rather than being generated afresh. Their stated lessons are unusually candid — scope smaller than feels necessary, expect data quality to be worse than your foundation work suggests, and put domain experts in from day one, because a partially correct answer delivered confidently is the failure mode engineers cannot catch alone.

Microsoft Build

Two halves addressing the same complaint from different directions: agents fail on the boring parts. Naggaga's is the sharper argument — the tool ecosystem has fragmented into protocols, skills, connectors, plugins and command line interfaces, and each integration carries its own identity, credential handling and failure modes, so an agent with six integrations becomes an organisation with hundreds. Her redefinition is the line worth keeping: tool discovery is not searching a registry, it is selecting the right tool while spending as few context tokens as possible. Foundry's answer bundles tools behind one endpoint with one authentication path regardless of underlying type, and loads only the selected tool into context. Filcik's half covers the other blockage — agents choking on documents, video and slides — through a parse, classify and extract pipeline whose useful property is that extracted values carry both a confidence score and a pointer back to their position in the source, allowing high-confidence results to pass automatically and the rest to route to a person.

Microsoft Build

The organising observation comes from watching coding agents: they are remarkably good at local file access, navigating a repository and forming an understanding, because everything is local and cheap to read. The limit is what happens when knowledge lives in systems an agent cannot walk at volumes it cannot read. What follows is a bottleneck of rate rather than accuracy — a person issues a query, reads, refines and repeats a handful of times, while an agent may issue ten searches or several rounds of twenty because asking costs nothing and it is exploring rather than looking something up. Latency budgets calibrated to someone waiting for a page become dominant when multiplied twentyfold inside one task. The infrastructure argument generalises: agentic load is unpredictable in a way application load is not, so paying per use sidesteps a capacity decision nobody has the information to make.

Microsoft Build

The framing is the most accurate description of a common failure offered at this conference: agents can reason but cannot really read. Real enterprise content is scanned PDFs, long threads, documents with complex tables, images and audio — and an agent handed one of those writes custom code, uploads images, misreads tables and skips figures. What makes this failure persistent is that it degrades quality and cost at the same time, so it never presents as a tuning problem with a dial to turn. The alternative is a parse, classify and extract pipeline that produces structured output before anything reaches the model, with a claimed 85 per cent reduction in tokens. The reframing matters more than the number: reasoning capacity spent recovering structure is capacity not spent on the task, and the recovery fails silently — a misread table produces a confident answer built on wrong numbers.

Microsoft Build

The most interesting number is not about the database: around 8 per cent of the lines of code modified in this release were changed by AI, offered as a measure rather than a productivity claim, by a team with no obvious reason to volunteer it. It is also more credible than most adoption statistics — small enough to believe and specific enough to check against a repository. The analytical content sits in the historical comparison: vector and embedding capability existed with modest uptake until an unrelated consumer product made the concept legible, after which adoption rose almost vertically. For anyone building infrastructure that is uncomfortable, because it means a feature's uptake may be gated on comprehension rather than capability. The architectural argument — let applications work against data where it lives rather than moving it through pipelines — is newly plausible because agentic access fits neither traditional profile.

Microsoft Build

The most revealing phrase here is a design goal rather than a feature: teaching not just how to use the packages but how to use them effectively, building applications that have good taste, because a merely functional dashboard is not what anyone wants. That is an admission about where the constraint has moved. Nobody in the demonstration worries about whether the agent can produce a working dashboard; the worry is whether it will produce a good one. For thirty years the limiting factor was construction, and the demonstration makes the point without meaning to by skipping past the building to the finished result. What remains is judgement about what should be built, which the tooling does not provide and which cannot be verified by a test. The narrative is honest about the consequence: requests arrive faster because the cost of asking fell along with the cost of building.

Microsoft Build

The most honest moment here is an aside about how the presenters have tracked their own projects: plans in documents, plans in spreadsheets, plans in bug comments, and once a plan written on a receipt. That describes the actual category being addressed — not software nobody has built, but the small internal tool every team improvises badly because building it properly was never worth the effort. The demo turns on a single question: the generated app is strictly single player, so what happens when you want to share it with the team? That boundary is where improvised tools historically died, because it is where accounts, shared storage and access rules begin. Here it is crossed in one step, with the access rules generated and deployed automatically — which is convenient, and is also the moment the application acquires obligations nobody reviewed.

Google I/O

The most consequential sentence here concerns what happens after the demo: sometimes you want a quickly assembled application as a proof of concept, and other times you want it to stick around with real users and persistent data. The security additions are best read as answers to the failure modes that creates — keeping prompts off the client, restricting model access to the application, rate limits preventing a few users consuming everyone's quota, ignoring prompts arriving from the client. Each assumption being corrected is one a rapidly built application makes by default, harmless in a demonstration and consequential the first day it is public. The claim that strong security rules were written by the agent deserves the most scrutiny, because an overly permissive access rule produces no visible symptom — it works fine while allowing access it should not.

Google I/O

The most useful line is a rule about sequencing rather than a technology choice: do not let perfect stand in the way, get it working, optimise cost and resourcing later. What makes it non-trivial is what it is applied to, since the organisation is always-on and whatever was built had to hold during the handful of nights a year when the audience is largest. The tension they name is moving fast without paying for it in trade-offs that persist, and their resolution is procedural rather than architectural — agreements settled ahead of time so execution never stops to negotiate, which is the real bottleneck in large-organisation migrations. Two numbers are given, of which transcription accuracy improving by sixty per cent matters most, because transcription feeds search, clipping and highlight generation and its accuracy decides whether an entire class of content operations can be automated at all.

AWS re:Invent

The change is easy to miss and large in practice: rather than configuring an extraction pipeline with triggers and scheduling, you declare a materialised view and the system maintains it. That collapses work most data teams treat as unavoidable, since a pipeline is a transformation plus the orchestration around it, and most of that orchestration exists to keep a derived dataset current. The performance argument comes with both a number and a mechanism, which is rarer than it should be — around twenty per cent reduced cost, driven by local disk, where exhaustion fails jobs and constraint slows them with stragglers holding up everything else. That contradicts where teams look first, since disk exhaustion presents as symptoms shared with many other problems. The most honest passage concerns engine upgrades, which got harder precisely because the data lake features teams want depend on the newest releases.

AWS re:Invent

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.

AWS re:Invent

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.

AWS re:Invent

The hardest problem in this session has nothing to do with machine learning: you cannot reliably tell who owns a machine. Unlike vehicles, which carry an identification number and go through state registration, heavy equipment has no equivalent — someone can simply assert ownership. Everything the connected-product strategy promises depends on solving that, because every step after fault detection requires knowing who to contact. The estate explains why it was not solved earlier: millions of machines with 1.5 million connected, and around 160 dealers who are independent businesses with their own systems, holding the service history that makes telemetry meaningful. The prior state is described directly — multiple accumulated platforms, and dealers confused because the same question returned different answers, which destroys trust in all of them including the correct ones.

AWS re:Invent

The statistic this session opens on is that over 74 per cent of companies surveyed are not set up to succeed at their data and AI initiatives, and the diagnosis is more interesting than the number: the obstacle is tool sets stitched together manually, which makes work slower and more expensive rather than more agile. That makes the product answer integration rather than capability. The most credible sequence in the demonstration is one where the analysis fails — a hypothesis about customer satisfaction and long-term value that does not hold, abandoned in favour of a broader search. Demonstrations almost never show this, and it clarifies what the assistance is for: not finding the answer, but making the cost of testing an idea low enough that abandoning one stops being expensive. The load-bearing assumption underneath is a well-maintained data catalogue.

AWS re:Invent

The framing question is better than the answer most teams give: can the problematic statement be identified and fixed, and separately, is this the right instance type. The order matters, because a database at full utilisation from poorly written statements presents identically to one that is genuinely undersized, and resizing is a one-line change while query analysis is work. The number that settles the argument is a query moving from thirty seconds to forty-six milliseconds — a factor no amount of hardware closes, which is why sizing is the wrong first move. Their treatment of caching depends entirely on sequence: applied before the query is understood it hides a problem that returns when access patterns shift, and applied afterwards it removes work that genuinely did not need repeating. The operational figure that makes the whole discipline affordable is a failover of up to thirty seconds, which turns instance sizing into a reversible decision.

AWS re:Invent

The show of hands at the start tells you what this session is about: roughly half the room had generated cost reports in the standard format, and considerably fewer had analysed them. That gap is the whole problem, because producing the export is configuration while turning it into something anyone acts on is the work. The single most valuable element described is unglamorous — an invoice identifier column that lets reported figures match the invoice actually paid, which is the difference between a report and an accountable number. Every cost reporting effort dies at the reconciliation step, usually because aggregation cannot be tied back to a specific charge. The remainder is data preparation rather than analysis, and the detail about needing pattern matching to extract tag values reveals where the real difficulty sits.

AWS re:Invent

The forecast this session opens with is over 1.3 billion AI agents in production by 2028, offered with the suggestion that it may be conservative. Treated as a claim about connection counts rather than a market prediction it becomes useful: the thing on the other end of a database connection is increasingly something that decided moments ago it needed storage. Provisioning latency, a background annoyance for twenty years, becomes a hard dependency in an automated build, and maintenance that presupposes a human operator who scheduled a window no longer fits. The customer migration that grounds the abstraction — eight engineers moving four and a half petabytes in under 120 days — is credible mainly because it ran between closely related products, which is the honest caveat. The optimiser improvement buried at the end matters more than it looks, because an agent writing its own queries has hand-tuned none of them.

AWS re:Invent