On August 26, the cloud provider definitively stopped being a place where you simply rent GPUs. AWS is simultaneously securing millions of future accelerators, separating evaluation from the agent framework, carrying knowledge across account boundaries, and proposing that autonomy be increased through external policies.
These are four layers of the same system: physical resources, observable trajectories, access to data, and the authority to act. Alongside this, GitHub is moving model selection and plugin updates into enterprise policy, while cloud vendors themselves are beginning to supply agents with maintained knowledge of their own services.
The main competition is no longer for the best chat interface, but for the control plane in which an organization can operate many different agents.
Infrastructure
AWS and NVIDIA promise another two million GPUs — but for now, it is only a promise
AWS and NVIDIA announced a plan to deploy two million additional GPUs across AWS's global infrastructure in 2027–2028. One hundred thousand of them are intended for secure US federal workloads. The agreement also covers Vera CPUs, NVLink Fusion and NVHBM, integration with Nitro and EFA, Nemotron in Bedrock and SageMaker, and acceleration for the cuDF and cuVS libraries.
Two million is not capacity that was installed on August 26. The partners did not provide a regional schedule, a price, a confirmed purchase volume, or dates when customers could access it. This is a forward-looking commitment by two companies with a direct interest in the scale of the headline.
But the direction of the agreement matters more than the exact number. AWS and NVIDIA are tying together not one shipment of accelerators, but the hardware roadmap, networking, virtualization, models, and software libraries. A unit of cloud AI capacity is becoming a coordinated system planned in advance rather than a collection of interchangeable servers.
Source: joint AWS and NVIDIA announcement.
CodeArts Agent moved from preview to commercial availability without evidence of quality
Huawei Cloud scheduled the commercial availability of CodeArts Agent for the end of August 26, GMT+8. Existing users keep the same price and terms.
The service notice says almost nothing about the product's capabilities and contains no measurements, so it cannot tell us how well the agent writes code or what it is comparable to. The event is narrower, but more honest: Huawei considers the service stable enough for ordinary sale and is no longer treating it as a preview.
Such transitions are worth recording without the marketing superstructure. GA changes expectations around support and billing, but it does not turn the product into a technical leader.
Source: Huawei Cloud service notice.
Evaluation and data
Agent evaluation is breaking free of a specific harness
AgentCore Evaluations accepts OpenTelemetry traces with generative AI semantics and claims support for agents built with LangGraph, LlamaIndex, the OpenAI Agents SDK, Google ADK, the Claude Agent SDK, and Strands. The contract is built around the observable trajectory rather than the internal design of the framework.
AWS does not demonstrate on a common sample that its built-in judges assess all of these harnesses equally well. Framework-agnostic therefore means a shared connection format here, not proven equivalence of results.
The boundary is still drawn in the right place. An organization will inevitably change models and runtimes faster than it changes its own quality criteria. If an evaluation lives inside one framework, a migration erases the comparison history. A trace-based layer keeps the agent's actual action as the unit of control even when the executor underneath it is replaced.
Source: AgentCore section.
An enterprise agent gains knowledge without creating a second copy of the data
AWS presented a reference architecture in which AgentCore in one account accesses a knowledge base and Redshift Serverless in another. It offers both a code-based version using Strands and a declarative harness; the data boundary remains in the source account.
This is a tutorial, not a new service or an independent security audit. It does not prove that any given configuration is automatically secure.
The practical point lies elsewhere. The fast path to an enterprise agent often starts by copying documents into a separate vector store beside the runtime. That creates a new uncontrolled version of the corpus, a separate retention policy, and another place where data can leak. Cross-account retrieval brings the agent to governed data without moving the data to the agent.
Source: AgentCore technical resources.
Autonomy and policy
An agent's authority should grow with proven reliability, not model capability
AWS described graduated autonomy: permissions rise or fall as evidence of reliability accumulates. AgentCore Gateway applies Cedar policies outside the agent process, with deny-by-default and forbid-wins semantics. Changes to the prompt, configuration, and tools pass through a delivery gate; a single prohibited tool call fails the adversarial suite.
This is AWS's own reference architecture, not a measured production outcome. But it articulates an important principle: model capability and system authority are separate axes. A smarter agent does not automatically receive more permissions.
Autonomy then becomes reversible. The system does not have to choose between manual approval for every step and unconditional access to everything. It can grant a narrow level of authority, observe it, expand it after proof, and immediately return to a lower level when the model, prompt, or toolset changes.
Source: graduated autonomy from AWS.
Developer tools
AWS gives coding agents maintained knowledge of its cloud
Agent Toolkit for AWS is intended for Kiro, Claude Code, Codex, Cursor, and other coding agents. The vendor describes it as a specialized layer of current knowledge about its services and CLI.
There are no metrics showing fewer errors or a comparison with ordinary documentation. But the product itself addresses a systemic problem: a training cutoff and ad hoc web searches are a poor fit for a cloud whose APIs, valid parameters, and recommendations change constantly.
Cloud providers used to supply SDKs to people. Now they are beginning to supply maintained operational knowledge to the executor that writes commands. This is useful only with clear provenance and versioning: an “official skill” must show which service version its advice applies to, or the vendor's authority merely makes an outdated command more convincing.
Source: AWS Developer Tools Blog.
GitHub centralizes both the model and extension updates
GitHub began enforcing a global model availability policy for Copilot Business and Enterprise, and added an enterprise-managed autoUpdate setting for plugin marketplaces.
The changelog confirms the features and the date, but not adoption or security outcomes. Together, the two changes establish a single administrative boundary. An organization determines not only which models may receive its code, but also whether the capabilities an agent obtains through a marketplace are updated automatically.
These decisions are more closely related than they look. Changing the model changes the agent's behavior; changing a plugin changes the actions available to it. Both events should pass through policy, and their versions should be preserved in the trace. Otherwise, an investigation will see the same Copilot even though both the actual executor and its tools have changed.
Source: GitHub Copilot changelog.
The issue's main technological shift
On August 26, the cloud became the operating environment for agent authority.
It promises physical compute, accepts traces independently of the framework, carries queries across account boundaries to the data, applies Cedar policy to tool calls, and gives agents current knowledge of its own APIs. GitHub is building a similar administrative layer at the level of IDEs and extensions.
Such a control plane can survive a model replacement. That is its central value: the organization manages not intelligence as a brand, but observable actions, data, and authority that remain its own.
What to discuss with the technical team
- Will our evaluations and historical comparisons survive a change of agent framework?
- Are we copying corporate data to the agent where we could instead provide governed cross-account access to the original source?
- What evidence must an agent produce before it receives the next level of autonomy, and what revokes that level automatically?
- Are the model policy, prompt, skills, and plugins versioned together with the trace for a specific task?
- How do we verify the freshness of the official knowledge that a vendor gives a coding agent?