The final day of August brought the month to a natural conclusion: after an explosion in agent capabilities, the industry began taking inventory. AWS opened an organizational registry for agents, tools, and skills. GitHub turned a month of VS Code changes into a map of new runtime surfaces, while reminding users that a selected model could disappear from the platform the very next day.
Catalog, lifecycle, external review, and structured workflow descriptions sound dull beside “autonomous agent.” But they are the parts that let a system survive a change of model, team, or another beautiful demo.
Agent control plane
AWS opened a registry for agents, tools, and skills
AWS Agent Registry became generally available in five regions. The governed catalog stores agents, tools, skills, and custom resources; supports keyword and semantic search; allows publication through an MCP server and cross-account access; and automatically discovers AgentCore Gateways and agents across an organization.
The official sources confirm availability but provide no figures for search precision, latency, adoption, or actual savings from reuse. Five regions describes the service on August 31, not a permanent property.
Two neighboring releases show why the registry exists. Amazon Quick can find registered agents and MCP servers, while a reference pattern connects an MCP server in AgentCore Runtime to several chat agents and workflows without a separate connector for each one. Catalog, runtime, and client are beginning to operate as a single layer.
This is not universal portability. Authentication, network boundaries, and tool schemas do not disappear. The registry solves discovery and governance, but it must not hide incompatibility in the capability it finds.
Sources: Agent Registry GA, Quick integration, MCP reference pattern.
Developer tooling
In one month, VS Code became a dispatcher for multiple agents
GitHub's roundup covers VS Code 1.132–1.135: parallel agent sessions, /btw,
Agent Host, plugins, and related changes to Copilot workflows. The page is a
monthly roundup, so August 31 dates the summary itself, not every feature it
lists.
There is no shared metric for quality or adoption. But the systems direction is clear. The editor no longer serves one assistant in a side panel: it manages multiple sessions, a background host, and installable packages of behavior.
The central UX question changes with that kind of IDE. It is no longer enough to make prompting convenient. A developer must know which agent owns the branch, what is running in the background, where a skill came from, and which result is waiting for review. Session management becomes part of correctness.
Source: August roundup for Copilot in VS Code.
GitHub warned that selected Copilot models would disappear the next day
GitHub published a notice that support for a number of Copilot models would end on September 1. On August 31, only the warning itself is replay-safe: the deprecation had not yet taken effect. The exact list and instructions belong to the changelog and should not be reconstructed from memory.
It is a small release with a large operational implication. A saved prompt, router policy, or organizational default can break without a single repository change, simply because the platform ended the lifecycle of an upstream model.
A model abstraction must include lifecycle. Teams need a dependency inventory, a replacement before the deadline, a regression evaluation, and a clearly understood fallback. Otherwise, “automatically choose the best model” works only until the provider removes it from the menu.
Source: GitHub notice.
Safety governance
Anthropic promised to move alignment-security review outside the company
Anthropic revisited incidents it had publicly described on July 30 and August 4, and announced process changes that include plans for an external review by METR.
The timeline matters: the incidents themselves did not happen on August 31. The day's news is the organizational response. And for now it remains a promise — there is no completed independent analysis or measurable result from the new controls.
Even so, external review changes the structure of trust. An internal postmortem is conducted by the team whose process failed. An independent party may find different assumptions and demand evidence the company did not consider necessary. The value will not come from METR's name, but from the published boundaries of access, methodology, and Anthropic's response to the findings.
Source: Anthropic update.
Infrastructure
One hundred megawatts in NEOM marks the start of construction, not a finished AI cluster
HUMAIN and DataVolt announced the first phase of an AI data center campus in NEOM. Construction has begun on a 100 MW phase within a 360 MW project.
The source does not specify the number or manufacturer of accelerators, PUE, the date of full availability, or guaranteed customer demand. Electrical capacity therefore cannot be translated into AI throughput, and the start of construction cannot be described as available compute.
The signal is still notable: Saudi Arabia is bringing energy, capital, and data center construction together in an attempt to create a regional AI infrastructure layer. But everything difficult in the project lies between “we have a site and an agreement” and “a customer can run a workload.”
Source: HUMAIN and DataVolt in NEOM.
Evaluation
WorkflowBench evaluates the structure of an executable process, not the prose of an answer
WorkflowBench proposes generating a DAG with business rules from natural- language requirements. Its dataset contains 635 synthetic rules; the benchmark separately evaluates structure, exact conditions, JSON validity, and LLM-judge validity.
The authors report roughly 89% judge validity, 90% exact-condition accuracy, 99–100% valid JSON, and about half as many prompt tokens as the baseline. All figures are self-reported and depend on the synthetic generator, evaluator, and selected models. A real workflow adds permissions, partial failures, and human approvals that do not appear in the headline.
But the object of evaluation is the right one. A workflow can sound convincing in prose and still be wrong as a graph: it can misplace a branch, a condition, or the order of side effects. Verifying structure and rules is closer to production than grading the quality of its explanation.
Source: WorkflowBench.
The issue's main technological shift
On August 31, a capability became an inventory item.
The registry says which agents and tools exist. The IDE shows where their sessions live. Model lifecycle reminds us that the worker is temporary. External review examines the platform owner's process. A workflow benchmark separates executable structure from persuasive prose.
The month began with “what else can the model do?” and ends with a more mature question: “can we find, verify, replace, and safely remove whatever lets it do that?” That is the control plane capable of surviving the next model cycle.
What to discuss with the technical team
- Do we have a complete registry of agents, tools, skills, owners, and cross-account permissions?
- Does the IDE show which worktree, background process, and result belong to a particular agent session?
- Which workflows will break when the primary model is deprecated, and when was the fallback last tested?
- What makes an external safety review independent: access to data, its methodology, or the right to publish a finding the company disputes?
- Do we validate a generated workflow as a graph of conditions and side effects, or only as text?