AWS Agent Registry namespace change creates a migration checkpoint for agent infrastructure

AWS is making a compatibility change that matters for teams building agent infrastructure on top of Amazon Bedrock AgentCore. According to AWS documentation, AWS Agent Registry is currently in public preview under the bedrock-agentcore namespace, but from August 6, 2026, the service moves to the agent-registry namespace.

This is not a new foundation model launch and it is not a pricing announcement. It is a plumbing change. But for developers operating agents, tool catalogs, Model Context Protocol-style integrations or internal registries, plumbing changes are often the ones that break production scripts first.

AWS says users must update endpoints, IAM policies, SDK clients, CLI scripts and registry data as part of the move. That makes this a real migration event rather than a cosmetic rename. Any system that calls the old namespace directly, grants permissions against it, or automates registry operations through command-line or SDK workflows may need changes before it can work cleanly with the new service identity.

What changed in AWS Agent Registry

AWS Agent Registry is documented as a public-preview service associated with Amazon Bedrock AgentCore. The registry is intended to help teams manage and discover agents, including agent cards and related metadata used in agent ecosystems. Until now, the preview has lived under the bedrock-agentcore namespace.

The August 6 change separates the registry into the agent-registry namespace. In practical terms, that means integrations should stop assuming the registry is only a sub-part of the broader Bedrock AgentCore namespace. AWS documentation calls out several areas that require attention: service endpoints, identity and access management policies, SDK clients, CLI scripts and registry data.

Those categories cover most of the places where agent infrastructure becomes sticky. Endpoints may be embedded in service configuration. IAM permissions may be managed by security teams rather than application developers. SDK clients may be pinned in internal libraries. CLI scripts may be running in CI pipelines or operations runbooks. Registry data may need migration or re-registration depending on how a team uses the preview service.

Why this matters for agent and MCP tooling

The timing is notable because agent infrastructure is becoming more formal. Recent changes across the market have pushed developers away from one-off demos and toward governed systems: registries, tool servers, usage reporting, access controls and audit trails. In that context, a registry namespace change is a signal that AWS is treating agent discovery and management as a distinct infrastructure surface.

For teams experimenting with agents, this may be a small maintenance task. For companies building internal platforms around agent catalogs, the work is broader. Registry calls may sit behind developer portals, security review systems, orchestration layers, approval workflows or automated deployments. If those systems were built during the preview period, they may contain assumptions that now need to be revisited.

The change is also relevant to Model Context Protocol deployments and other agent interoperability patterns. Agent registries can become the place where platforms discover what an agent is, what tools it can use, what endpoints it exposes and what trust boundaries apply. If a gateway, orchestrator or partner platform exposes AWS-backed agents to customers, it needs to know whether it is looking at the old namespace, the new namespace, or both during a transition period.

Who is affected

The most directly affected users are developers and platform teams already using AWS Agent Registry during public preview. They should audit any code or infrastructure that references bedrock-agentcore for registry operations. That includes application code, infrastructure-as-code templates, IAM policies, CI jobs, CLI scripts, SDK wrappers, local developer tooling and documentation used by support teams.

Security and cloud governance teams are also affected. IAM changes can take longer than application patches because they often require review, least-privilege checks and approval workflows. A namespace move may require new permissions, updated service references and refreshed policy templates. If organizations have internal controls that block unknown service namespaces by default, the new agent-registry namespace may need to be added before developers can proceed.

API gateway and automation vendors have a different problem: customer confusion. AWS recently also moved Bedrock Agents into a “Classic” path for new-customer availability, steering new work toward AgentCore. The Agent Registry namespace migration is separate from that earlier Bedrock Agents Classic cutoff, but both events affect the same broad category of agent infrastructure. Documentation, onboarding flows and support responses should make that distinction clear.

Practical migration steps

Teams should start with an inventory. Search repositories, deployment manifests, policy files and CI scripts for registry-related calls under the old Bedrock AgentCore namespace. Then identify which references are runtime-critical and which are only documentation or examples.

Next, update IAM policies and test them in a non-production account. Namespace changes often reveal overly broad permissions or hidden dependencies. A controlled test can show whether the new service references are sufficient before production agents or registries depend on them.

SDK and CLI usage should be checked separately. Some teams call cloud services through official SDK clients; others shell out to CLI commands inside build pipelines. Both paths can fail differently. SDK clients may need version updates or new service constructors. CLI scripts may need new command names, endpoint flags or authentication assumptions.

Registry data deserves its own migration plan. AWS documentation says registry data must be updated, but the operational impact will depend on how each team has modeled agents, identifiers and metadata. Teams should verify whether agent records, agent cards, versions or references remain stable after migration, and whether downstream systems cache those identifiers.

For businesses using a multi-model API or AI API gateway, the larger lesson is that agent infrastructure now needs the same change-management discipline as model routing. A gateway such as Model Gate may not be directly involved in AWS Agent Registry migration, but the operational pattern is familiar: provider-side API surfaces change, and teams need centralized configuration, usage visibility, key controls and clear ownership to avoid scattered breakage.

What remains uncertain

The available information comes from AWS documentation rather than a separate launch blog or broader announcement. That does not make the change less actionable, but it does limit the public context around AWS’s roadmap for the registry. The documentation confirms the namespace migration and the categories of required updates; it does not, in the retrieved material, provide a detailed market-positioning explanation or independent confirmation from another AWS source.

Because AWS Agent Registry is in public preview, teams should also assume that more interface changes are possible. Preview services are useful for early adoption, but they require stronger abstraction boundaries than mature APIs. If registry operations are scattered across many applications, this is a good moment to consolidate them behind internal libraries or platform services so the next change is easier to absorb.