Enterprise AI Adoption

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.

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 number in this session's title is a triage improvement. The story underneath is that the queue being triaged should never have grown that large, and what fixed the root cause was not AI. The diagnosis is candid: it was easier to obtain an exception than to fix the problem, partly because application teams did not know how to fix certain vulnerabilities — not bad developers, simply not security engineers. That produces a self-reinforcing failure where a better scanner makes things worse, because more findings enter a pipeline limited by developer capability. Average false-positive review time falling from thirty days to thirteen is real and is a faster way to process the symptom. The durable change is a tiered security champions programme whose second tier exists to verify the first, anticipating the incentive that delegation creates.

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