Agentic AI

The observation that organises this session is not about capability but about attention. Engineers increasingly file a ticket rather than opening an editor, and the code comes back — which changes what the surrounding tools are for. If the agent works while you do something else, the conversation between you is no longer a workspace; it is the mechanism by which the agent surfaces a question it cannot resolve alone. Interfaces built for continuous conversation optimise for flow, and interfaces built for interruption should optimise for the opposite. A runtime constraint follows immediately: an agent that starts a long-running job cannot block until it finishes, which turns out to be a workflow-engine problem rather than a model one. The panel's closing formulation — that deciding what to build is the hard skill and always was — reads as reassurance and functions as a warning, since that judgement is downstream of exactly the work now being delegated.

Google I/O

The clearest statement at I/O of how an agent API differs from a chat API, and the reasoning behind each departure is stated rather than assumed. Three changes matter. Conversation state moves to the server: a call returns an identifier, and passing it back continues the thread, retiring the client-side history array. The data model abandons alternating user and model turns for discrete steps, on the argument that a trace containing reasoning, tool calls, environment responses and compaction was never really a conversation and modelling it as one distorted it. And agents receive their own persistent remote environment rather than acting on the caller's machine — addressable by identifier, and shareable, so a research agent's output files become an application builder's input without passing through the context window. Schmid is explicit that scaffolded environment files are deliberately not model input, which is what keeps large artefacts out of the context budget. Schaeff's first half covers the real-time voice path, where the notable property is speech-to-speech across ninety languages with transcription of both directions.

Google I/O

Four of Google's model, product and search leads on what changes once agents run for hours rather than seconds, and the most quotable argument comes from Dean: the constraint is moving out of the model and into the tools around it. By Amdahl's law, an agent spending half its time in tools built for human-speed interaction cannot gain more than a doubling however fast the model becomes — which reframes a great deal of current infrastructure work as latency debt. Their internal response is concrete: rewriting Python tooling into Go, framed as a fully specified translation task rather than an open prompt, produced order-of-magnitude speedups overnight. Reid supplies the counterweight from Search, where acceptable latency turns out to scale with how much work is being taken off the user rather than being a fixed budget. Woodward's detail is the quietest and perhaps the most telling: teams that have stopped writing product documents for humans and now write context files for models to act on directly.

Google I/O

The most revealing moment in this segment is not the hardware but a question the assistant asks before acting: would you like to confirm. On any other device that is unremarkable; on glasses it states the entire design problem. Every consumer transaction interface built in two decades has relied on a visual review step where errors get caught, and a device worn on the face has no review screen in any meaningful sense. What replaces it is the assistant restating what it is about to do, which must contain everything a user would have checked and be short enough to listen to — two requirements that pull against each other. Adding a tip after confirmation shows this is a conversation with amendments rather than a single transaction, which makes the boundary between negotiating and committing a design decision rather than an emergent property.

Google I/O

Jensen Huang used NVIDIA's 2026 GTC keynote to argue that AI has crossed an inference inflection: models that once only generated text now reason and act, and each step multiplies the compute a single task consumes. He put NVIDIA's forward demand visibility above one trillion dollars through 2027, then spent much of the keynote explaining why that is a factory-economics claim rather than a chip claim — a gigawatt of AI factory costs roughly forty billion dollars before any compute is installed, so throughput per watt is what determines revenue. The technical centrepiece was the Vera Rubin platform; the strategic surprise was NVIDIA absorbing the Groq team to cover the low-latency decode that NVLink alone cannot reach. He closed on two extensions of the agentic thesis: OpenClaw as an emerging operating system for agents, hardened for enterprises as NemoClaw, and physical AI, where four new robotaxi partners add roughly eighteen million vehicles a year.

NVIDIA GTC

The claim worth arguing about here is that the native currency for AI agents will be crypto, because agents will not carry cards and blockchain is the interface most native to them. It comes from someone with an obvious interest in it being true, which is a reason to examine it rather than dismiss it. The strong part is structural: card networks assume a cardholder who can be contacted and can attest to a transaction, and an autonomous process breaks each of those assumptions. What does not follow is the conclusion, because nothing prevents existing networks issuing delegated credentials with limits and revocation. The panel's most direct voice calls these areas highly speculative with hard use cases, and both positions can hold, since stablecoins and speculative assets are separable in a way the panel treats as one thing. The quieter claim about tokenised government instruments is the more consequential one.

World Economic Forum Annual Meeting

A show of hands opens the session: nearly everyone has piloted, far fewer have scaled, and everyone who scaled hit problems they did not anticipate. What makes the panel useful is where the four answers do not point. None of the executives — running a healthcare manufacturer, a payments network, an energy producer and a consultancy — blames model capability, cost or data infrastructure. All four describe an organisational constraint. McInerney's account is the sharpest and is an account of failure: eighteen months of executive advocacy and democratised model access produced nothing, until three hundred senior leaders were put in a room for two days and made to build agents themselves. Jakobs supplies the mechanism worth copying, measuring returned clinician time against the three to seven minutes a patient currently receives rather than against cost. Nasser rejects the premise that acquiring compute produces value, and locates returns in operations rather than in the back-office functions most organisations automate first.

World Economic Forum Annual Meeting

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.

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.

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.

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.

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 most useful sentence here concerns where reliability is achievable: for workflows calling well-structured interfaces and producing checkable code, the path is faster. The implication is that there is a slower path, and it is the one most enterprise pilots are on. The division separates work whose output can be checked mechanically from work where correctness is a judgement, and only the first admits an engineering approach to improvement. The best illustration is browser automation that examines what the customer would observe rather than the underlying markup, walking checkout and booking flows and identifying revenue leakage — a framing that defines success in the business's own terms and is verifiable in the good sense. The demonstration's fifteen to twenty tool calls are the honest measure of what agentic means: not one clever response but a chain of decisions each depending on the last.

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

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.

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.

AWS re:Invent

The most honest moment in this session comes near the end: most of the security processes the team has automated still route their output to security engineers rather than the business, because the results are not good enough. That sits half an hour after a story about two engineers building a working prototype in two days that runs a training exercise in seven minutes for ninety-one cents. The gap between the two is the subject. What distinguishes them is not model capability but whether the task has a verification loop a machine can close, which reframes the automation question entirely. Three loops appear — citation, self-checking, and a compiler pass that guarantees syntactic validity — and only the last removes a person. The rejection of single-number evaluation scores in favour of precision and recall follows directly, because in security the two error types have wildly different costs.

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.

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.

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.

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