AWS gör en kompatibilitetsändring som är viktig för team som bygger agentinfrastruktur ovanpå Amazon Bedrock AgentCore. Enligt AWS-dokumentation är AWS Agent Registry för närvarande i offentlig förhandsvisning under namnutrymmet bedrock-agentcore, men från och med den 6 augusti 2026 flyttas tjänsten till agent-registry-namnområdet.

Detta är inte en lansering av en ny grundmodell och det är inte ett prismeddelande. Det är ett VVS-byte. Men för utvecklare som driver agenter, verktygskataloger, modellkontextprotokollliknande integrationer eller interna register, är VVS-byten ofta de som förstör produktionsskripten.

AWS säger att användare måste uppdatera slutpunkter, IAM-policyer, SDK-klienter, CLI-skript och registerdata som en del av flytten. Det gör detta till en riktig migrationshändelse snarare än ett kosmetiskt namnbyte. Alla system som anropar det gamla namnområdet direkt, ger behörigheter mot det eller automatiserar registeroperationer via kommandorads- eller SDK-arbetsflöden kan behöva ändras innan det kan fungera rent med den nya tjänstidentiteten.

Vad ändrades i AWS Agent Registry

AWS Agent Registry är dokumenterat som en offentlig förhandsvisningstjänst associerad med Amazon Bedrock AgentCore. Registret är avsett att hjälpa team att hantera och upptäcka agenter, inklusive agentkort och relaterad metadata som används i agentekosystem. Fram till nu har förhandsvisningen levt under namnutrymmet bedrock-agentcore.

Ändringen den 6 augusti separerar registret i namnområdet agent-registry. Rent praktiskt betyder det att integrationer bör sluta förutsätta att registret bara är en del av det bredare namnutrymmet Bedrock AgentCore. AWS-dokumentationen nämner flera områden som kräver uppmärksamhet: tjänstens slutpunkter, policyer för identitets- och åtkomsthantering, SDK-klienter, CLI-skript och registerdata.

Dessa kategorier täcker de flesta platser där agentinfrastrukturen blir klibbig. Slutpunkter kan vara inbäddade i tjänstekonfigurationen. IAM-behörigheter kan hanteras av säkerhetsteam snarare än applikationsutvecklare. SDK-klienter kan vara fästa i interna bibliotek. CLI-skript kan köras i CI-pipelines eller operations-runbooks. Registerdata kan behöva migreras eller omregistreras beroende på hur ett team använder förhandsgranskningstjänsten.

Varför detta är viktigt för agent- och MCP-verktyg

Timingen är anmärkningsvärd eftersom agentinfrastrukturen blir mer formell. De senaste förändringarna på marknaden har drivit utvecklare bort från enstaka demos och mot styrda system: register, verktygsservrar, användningsrapportering, åtkomstkontroller och revisionsspår. I det sammanhanget är en ändring av registernamnutrymmet en signal om att AWS behandlar agentupptäckt och -hantering som en distinkt infrastrukturyta.

För team som experimenterar med agenter kan detta vara en liten underhållsuppgift. För företag som bygger interna plattformar kring agentkataloger är arbetet bredare. Registeranrop kan sitta bakom utvecklarportaler, säkerhetsgranskningssystem, orkestreringslager, godkännandearbetsflöden eller automatiserade distributioner. Om dessa system byggdes under förhandsgranskningsperioden kan de innehålla antaganden som nu måste ses över.

Ändringen är också relevant för Model Context Protocol-distributioner och andra interoperabilitetsmönster för agenter. Agentregister kan bli platsen där plattformar upptäcker vad en agent är, vilka verktyg den kan använda, vilka slutpunkter den avslöjar och vilka förtroendegränser som gäller. Om en gateway, orkestrator eller partnerplattform exponerar AWS-stödda agenter för kunder måste den veta om den tittar på det gamla namnområdet, det nya namnområdet eller båda under en övergångsperiod.

Vem berörs

De mest direkt berörda användarna är utvecklare och plattformsteam som redan använder AWS Agent Registry under offentlig förhandsvisning. De bör granska all kod eller infrastruktur som refererar till bedrock-agentcore för registeroperationer. Det inkluderar applikationskod, mallar för infrastruktur som kod, IAM-policyer, CI-jobb, CLI-skript, SDK-omslag, lokala utvecklarverktyg och dokumentation som används av supportteam.

Säkerhets- och molnstyrningsteam påverkas också. IAM-ändringar kan ta längre tid än programkorrigeringar eftersom de ofta kräver granskning, minsta privilegiekontroller och godkännandearbetsflöden. En flytt av namnområde kan kräva nya behörigheter, uppdaterade tjänstreferenser och uppdaterade policymallar. Om organisationer har interna kontroller som blockerar okända tjänstnamnrymder som standard, kan det nya agent-registry-namnutrymmet behöva läggas till innan utvecklare kan fortsätta.

API-gateway- och automationsleverantörer har ett annat problem: kundförvirring. AWS flyttade nyligen också Bedrock Agents till en "klassisk" väg för tillgänglighet för nya kunder, vilket styrde nytt arbete mot AgentCore. Agent Registry-namnutrymmesmigreringen är separat från den tidigare Bedrock Agents Classic-gränsen, men båda händelserna påverkar samma breda kategori av agentinfrastruktur. Dokumentation, introduktionsflöden och supportsvar bör göra denna skillnad tydlig.

Praktiska migreringssteg

Lag bör börja med en inventering. Sök i arkiv, distributionsmanifest, policyfiler och CI-skript efter registerrelaterade anrop under det gamla namnområdet Bedrock AgentCore. Identifiera sedan vilka referenser som är körtidskritiska och vilka som bara är dokumentation eller exempel.

Uppdatera sedan IAM-policyer och testa dem i ett icke-produktionskonto. Namnutrymmesändringar avslöjar ofta alltför breda behörigheter eller dolda beroenden. Ett kontrollerat test kan visa om de nya tjänstreferenserna är tillräckliga innan produktionsagenter eller register är beroende av dem.

SDK- och CLI-användning bör kontrolleras separat. Vissa team anropar molntjänster via officiella SDK-klienter; andra ska ut till CLI-kommandon inuti bygga pipelines. Båda vägarna kan misslyckas på olika sätt. SDK-klienter kan behöva versionsuppdateringar eller nya tjänstekonstruktörer. CLI-skript kan behöva nya kommandonamn, slutpunktsflaggor eller autentiseringsantaganden.

Registerdata förtjänar en egen migreringsplan. AWS-dokumentationen säger att registerdata måste uppdateras, men den operativa effekten kommer att bero på hur varje team har modellerat agenter, identifierare och metadata. Teamen bör verifiera om agentposter, agentkort, versioner eller referenser förblir stabila efter migrering och om nedströmssystem cachelagrar dessa identifierare.

För företag som använder en multimodell-API eller AI API-gateway är den större lärdomen att agentinfrastrukturen nu behöver samma förändringshanteringsdisciplin som modellrouting. En gateway som Model Gate kanske inte är direkt involverad i AWS Agent Registry-migrering, men det operativa mönstret är bekant: API-ytor på leverantörssidan förändras och team behöver centraliserad konfiguration, användningssynlighet, nyckelkontroller och tydligt ägande för att undvika spridda brott.

Vad är fortfarande osäkert

Den tillgängliga informationen kommer från AWS-dokumentation snarare än en separat lanseringsblogg eller ett bredare tillkännagivande. Det gör inte förändringen mindre genomförbar, men det begränsar det offentliga sammanhanget kring AWS:s färdplan för registret. Dokumentationen bekräftar namnutrymmesmigreringen och kategorierna av nödvändiga uppdateringar; det ger inte, i det hämtade materialet, en detaljerad marknadspositioneringsförklaring eller oberoende bekräftelse från en annan AWS-källa.

Eftersom AWS Agent Registry är i offentlig förhandsvisning bör teamen också anta att fler gränssnittsändringar är möjliga. Förhandsgranskningstjänster är användbara för tidig användning, men de kräver starkare abstraktionsgränser än mogna API:er. Om registeroperationer är utspridda över många applikationer är detta ett bra tillfälle att konsolidera dem bakom interna bibliotek eller plattformstjänster så att nästa förändring är lättare att ta till sig.