Amazon Web Services

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.

AWS infrastructure security team / AWS re:Invent

The story that should outlive this session is about a question that worked perfectly and cost 1.3 million tokens. The answer was good, it passed the team's question-and-answer checks and acceptance testing, and the tool calls were sensible — yet a single query consumed enough to have destroyed throughput at production scale. That is a category of defect traditional software mostly does not have, because the cost is incurred inside a reasoning process with no fixed shape. The team extended their agent framework for per-turn reasoning visibility and then bounded how much data the agent could pull, a sequence that matters because the guardrail could not have been written before the behaviour was observed. Their architecture separates agent logic from data logic so each side scales independently, and their closing advice is to find the simplest pattern that delivers the benefit and analyse with real data afterwards.

Henry Wang / AWS re:Invent

Buried near the end is the most useful sentence in the session: three agentic products are in production, one is about to launch, and one was taken back to the drawing board — and that last one produced some of the most valuable data the team got. The technical argument builds toward verification, starting from a limitation rather than a capability: traditional testing only goes so far because these models are probabilistic, which quietly invalidates most of an enterprise QA apparatus. Their answer is to measure properties rather than check outputs, tracking relevance, completeness and tone while noting other organisations will need different measures. The distinction between hard and soft guardrails clarifies the design question of how much safety requirement can be pushed into a deterministic layer, and their red-teaming runs as a schedule rather than a gate.

Ravi / AWS re:Invent

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 media and sports team / 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.

Kinshuk Pahare / AWS re:Invent

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.

Jay Raval / AWS re:Invent

Cudby opens by asking what baseline exists before any AI tooling is deployed, and answers it himself: for most organisations, none. That absence is what makes impact reporting unreadable, and the session's argument is about sequencing rather than instrumentation. Adoption and engagement are leading indicators; financial return is a lagging one, and reading the lagging figure without the leading ones produces a number nobody can act on — a poor result might mean the tools do not work, or that nobody uses them, or that they are pointed at the wrong tasks. The finding drawn from this year's industry research sets the expectation for anyone planning a rollout: structured enablement determines outcomes, and switching the tools on and hoping does not work. Placed beside Amazon's own measurement work at the same conference, the notable thing is how careful the category has become about what it claims.

Joe Cudby / AWS re:Invent

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.

Raja / 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.

Sohaib Katariwala / AWS re:Invent

The example that makes this session concrete comes from medicine: a nurse who sees a physician about to administer the wrong medication and, in an environment where speaking up carries risk, does not. Nothing about the nurse's competence was the failure — the information existed in the room and did not move. Security work makes this worse, because the cost of a missed signal is delayed and the person who spots it is often junior to the person who would be contradicted. The anxiety zone described — real pressure to deliver with no safety to contribute — is a fair description of an organisation during an incident, which is exactly when information most needs to travel. The four-stage model localises the failure so a leader can tell which intervention is needed, and the reframing of reversible decisions separates mistakes that deserve a penalty from those that do not.

Jessie Skibbe / 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.

Shikha Verma / 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.

Steve Blackwell / 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.

Iris Sheu / AWS re:Invent

The warning that makes this session worth watching is aimed at everyone who thinks this is a procurement problem: traditional development approaches are no longer sufficient, and adding AI tools to an existing process will not help either. The Ericsson account locates the constraint precisely — thousands of engineers across the globe make small-team Agile practice very hard because handovers become unavoidable, and the AI-native claim is that agents can carry context across a handover in a way documents never could. Their four-level maturity model encodes a sequence: context infrastructure before organisational change, and organisational change before the tooling pays off. Skipping the middle step produces individually faster engineers inside unchanged coordination structures. Their governance and culture arguments are unusually direct, and notable mainly for appearing inside a session about a command-line coding agent.

Ali Maaz / AWS re:Invent

Beer names the constraint that makes key management genuinely hard, and it is not the mathematics: the key at the top of a hierarchy must be in plain text at all times for the system to stay available. Everything below can be encrypted by something above; the root cannot, or there is nothing to start from. The threat model that has moved from theoretical to planning-relevant is harvest now, decrypt later — capture encrypted traffic today, decrypt it when capability arrives — which means the exposure is to everything transmitted now rather than to a future secret, and inverts the usual reasoning about when to migrate. The strategic argument is about delegation, and it is a vendor's argument that happens to be right: cryptographic agility is not something most organisations can retrofit, because the assumptions live in code written by people who have left. One remark connects the session to the rest of the conference, on certificate infrastructure built for a countable number of endpoints.

Ken Beer / AWS re:Invent

Beach invents a language no model has seen in order to establish something most context-management advice lacks: a controlled baseline. From there he walks the obvious fix — paste the documentation into a rules file — into its own failure, which is that it works while quietly taxing every unrelated request. The corrections that follow are the transferable part. Compress the reference to what the model actually uses. Make the rules prescriptive rather than descriptive, telling the agent when the material applies and how to validate its own output. Then shrink the file to a pointer and fetch documentation at the moment of need, so context cost is paid only when relevant and the reference cannot go stale. His closing habit is the one most likely to outlive the tooling: when an agent visibly struggles, ask it what guidance would have prevented it.

Brian Beach / AWS re:Invent

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.

Eva Knight / AWS re:Invent

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.

Marc Brooker / AWS re:Invent

The forecast the session leans on deserves examination before acceptance: over a third of enterprise software including agentic AI by 2028, up from around one per cent. Read carefully that is not a prediction that a third of software will be agentic, but that products will contain some agentic capability — a much lower bar most vendors clear by adding a feature. The useful framing follows immediately in the build-versus-buy question, which is more interesting for agents than for conventional software because the usual reasoning does not transfer: value sits in the connection between generic reasoning and specific context, and a purchased agent brings capability with no context. Their explanation of why agents differ commercially is compact and correct — something that pursues an outcome can be sold against a job rather than a capability. The mechanics get less attention than the forecast and matter more.

Idan Mislitz / 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 database specialist team / AWS re:Invent

The session opens by dismantling the reassuring version of its own subject: you put a box around the workload, secure it, call it confidential computing, and the problem is solved — which is why the presentation exists. The gap comes down to one question: how do you know the code you are talking to is the code that is running, rather than taking someone's word for it. A protected environment addresses operator access but not the customer's actual objection, which is that they cannot confirm any of it. Attestation converts the claim into a signed measurement, and the step that turns evidence into a control is a key policy permitting operations only when the environment matches. Trust becomes arithmetic rather than process, with no reviewer to convince and no exception to grant, which is what allows a model owner and a data owner to collaborate without trusting each other.

Alex Graf / 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.

Justin Marks / AWS re:Invent

The most useful admission here is that intuition is what fails: the team stepped back because performance work was not going as fast as they wanted and found their instincts were leading them astray. The mechanism is that bottlenecks hide others — you remove the visible one and uncover a worse problem that was masked behind it, which is why a correct fix so often moves no numbers. Their answer is to survey broadly before drilling in, explicitly checking whether the processor back end is worse, finding it is not, and setting it aside. The diagnostic figure is instructions per cycle averaging below one against hardware capable of eight to twelve, which reframes the problem from slow code to an idle processor. Every fix that follows is about memory layout rather than logic, and returns nearly twenty per cent more throughput from configuration alone.

Toby Buckley / AWS re:Invent

The design decision at the centre of this session is one most teams get wrong: rather than assembling a large context and handing it to the agent, extract what actually matters from the conversation. That is the difference between a longer window and a memory — one holds more, the other decides what is worth holding. The instinct to add room fails invisibly, because an agent with an enormous context does not attend to all of it equally. The most instructive moment is an admission that the identifier for whose memory this is happens to be hardcoded, and should instead derive from who is logged in. Trivial in a notebook and the entire security model in production, since memory is per-actor by construction and the wrong binding produces an agent that recalls someone else's details — a breach that presents as good service.

Akasha Seag / AWS re:Invent

The number that matters here is not a benchmark but a shape: scaling up to 2.2 million virtual cores and back down to zero across four hours. Peak capacity has never been the hard part of scientific computing, because institutions have built large clusters for decades — the difficulty was that the cluster was sized for the peak and idle the rest of the year. Returning to zero removes that calculation, which suits genomics precisely, since analysis is bursty by nature. The acceleration claim is a change in the kind of activity rather than a productivity gain: eight hours means return tomorrow, thirty-five minutes means adjust and run again. The hardware explanation is unusually clear that cores per chip rather than total core count drives the improvement, and two operational findings — provisioning cost and a storage benchmark that showed no difference — are more portable than the hardware itself.

Marissa Powers / AWS re:Invent

Twenty-nine minutes after asking whether anyone really wants to hand production keys to an agent, the demonstration disables tool confirmation entirely. That is not hypocrisy — approving every call would be unwatchable — but the gap between the stated concern and the working configuration is the one every team will meet. The scope makes it concrete: the example prompt blocks network addresses and creates snapshots, which are write operations on production initiated by a chain of reasoning that started as a sentence in English. The design response is decomposition, and the split between an investigating agent and an acting one is where a permission boundary can sit. The construction itself is genuinely simple, and the generated report of 859 critical findings is both the session's most useful artefact and the place the trust question returns in a form nobody can check by hand.

Sean Abdi / AWS re:Invent

Everything in this session is downstream of one diagram: an accelerator has finite memory bandwidth and finite compute throughput, and where a workload sits between them is decided by how many operations it performs per byte read. Landing memory-bound means expensive compute units idle while data arrives, and every technique demonstrated exists to move a kernel across that line. The natural objection is that a compiler should handle this, and the implicit answer is that it cannot, because the decision depends on tensor shapes whose relative importance a general compiler cannot infer. The kernel structure repeats identically for every operation — allocate on-chip, copy down, compute, copy back — which is an explicit data-movement schedule with arithmetic attached, and which ties the code to one memory hierarchy. Two practices are worth stealing regardless of hardware: measuring on a few layers rather than a whole model, and verifying numerical equivalence rather than assuming it.

Scott Perry / 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.

G2 Krishnamoorthy / AWS re:Invent