Context Engineering

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

Most of this session is a platform tour. The part that will still matter is a taxonomy of three agent identities and the fact that capability is gated by which one you choose rather than by which model you use. An assistive agent extends the person operating it and inherits their access; an autonomous one runs in the background with permissions granted directly on cloud resources, and loses the tools that were previously reached through a person's identity; the third has its own account, alias and ability to act on its own behalf. That progression is an administrative commitment rather than a capability upgrade, which is why the last tier requires approval through an administrative console. The harness abstraction supplies tools and context compaction without extra work, and the demo's own network failures illustrate the operational character of these systems better than the architecture slides do.

Microsoft Build

The argument for running models locally used to be privacy. Here it is more specific and better reasoned: with a smaller model you can work at the full context length and largely stop worrying about compaction, because agentic workloads run locally hit hardware limits quickly. Compaction is the failure mode that quietly degrades long agent runs, when an agent forgets a constraint from forty steps ago or keeps a summary that lost the detail that mattered. Framing local inference as a way to avoid it is a real trade with a stated boundary — not that local models are better, but that capacity to hold the whole problem can beat raw capability on any single step. The threshold claim that local models are now viable for real work is the kind that changes behaviour, and thirty seconds from nothing installed to working makes the experiment nearly free.

Microsoft Build

The transferable content here is not the demonstrations but a set of rules for writing instructions an agent will follow. Supporting files are provided alongside a main instruction file, with explicit statements about when and how each applies, so that material loads at the start but is used only for specific tasks — and so the agent can skip a step entirely when it is unnecessary. One subtask was extracted into its own file specifically so it could be skipped when the user has already named the target, which is instruction design as software design. The practical warning is that customisations should be extracted and renamed, because a bulk update of the shared instructions can silently overwrite them. Two unremarked demo moments establish the real working rhythm: start the long-running task first and fill the time with something else.

Google I/O

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

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

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

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