AWS laver en kompatibilitetsændring, der er vigtig for teams, der bygger agentinfrastruktur oven på Amazon Bedrock AgentCore. Ifølge AWS-dokumentation er AWS Agent Registry i øjeblikket i offentlig forhåndsvisning under bedrock-agentcore-navneområdet, men fra 6. august 2026 flyttes tjenesten til agent-registry-navneområdet.
Dette er ikke en ny grundmodellancering, og det er ikke en prismeddelelse. Det er et VVS-skifte. Men for udviklere, der driver agenter, værktøjskataloger, modelkontekstprotokollignende integrationer eller interne registre, er VVS-ændringer ofte dem, der først bryder produktionsscripts.
AWS siger, at brugere skal opdatere slutpunkter, IAM-politikker, SDK-klienter, CLI-scripts og registreringsdatabasedata som en del af flytningen. Det gør dette til en rigtig migrationsbegivenhed snarere end et kosmetisk omdøbning. Ethvert system, der kalder det gamle navneområde direkte, giver tilladelser til det eller automatiserer registreringsoperationer via kommandolinje- eller SDK-arbejdsgange, kan have brug for ændringer, før det kan arbejde rent med den nye tjenesteidentitet.
Hvad er ændret i AWS Agent Registry
AWS Agent Registry er dokumenteret som en offentlig forhåndsvisningstjeneste forbundet med Amazon Bedrock AgentCore. Registret er beregnet til at hjælpe teams med at administrere og opdage agenter, herunder agentkort og relaterede metadata, der bruges i agentøkosystemer. Indtil nu har previewet levet under bedrock-agentcore navneområdet.
Ændringen den 6. august adskiller registreringsdatabasen i agent-registry-navneområdet. Rent praktisk betyder det, at integrationer bør stoppe, hvis man antager, at registreringsdatabasen kun er en underdel af det bredere Bedrock AgentCore-navneområde. AWS-dokumentation fremhæver flere områder, der kræver opmærksomhed: serviceendepunkter, identitets- og adgangsstyringspolitikker, SDK-klienter, CLI-scripts og registreringsdata.
Disse kategorier dækker de fleste steder, hvor agentinfrastrukturen bliver klæbrig. Slutpunkter kan være indlejret i servicekonfigurationen. IAM-tilladelser kan administreres af sikkerhedsteams i stedet for applikationsudviklere. SDK-klienter kan være fastgjort i interne biblioteker. CLI-scripts kan køre i CI-pipelines eller operations-runbooks. Registerdata skal muligvis migreres eller genregistreres afhængigt af, hvordan et team bruger forhåndsvisningstjenesten.
Hvorfor dette betyder noget for agent- og MCP-værktøjer
Timingen er bemærkelsesværdig, fordi agentinfrastrukturen bliver mere formel. Nylige ændringer på tværs af markedet har skubbet udviklere væk fra engangsdemoer og mod styrede systemer: registre, værktøjsservere, brugsrapportering, adgangskontrol og revisionsspor. I den sammenhæng er en ændring af registreringsdatabasens navneområde et signal om, at AWS behandler agentopdagelse og -administration som en særskilt infrastrukturoverflade.
For teams, der eksperimenterer med agenter, kan dette være en lille vedligeholdelsesopgave. For virksomheder, der bygger interne platforme omkring agentkataloger, er arbejdet bredere. Opkald til registreringsdatabasen kan sidde bag udviklerportaler, sikkerhedsgennemgangssystemer, orkestreringslag, godkendelsesarbejdsgange eller automatiserede implementeringer. Hvis disse systemer blev bygget under forhåndsvisningsperioden, kan de indeholde antagelser, som nu skal revurderes.
Ændringen er også relevant for implementering af Model Context Protocol og andre agentinteroperabilitetsmønstre. Agentregistre kan blive stedet, hvor platforme opdager, hvad en agent er, hvilke værktøjer den kan bruge, hvilke endepunkter den afslører, og hvilke tillidsgrænser der gælder. Hvis en gateway, orkestrator eller partnerplatform eksponerer AWS-støttede agenter for kunder, skal den vide, om den ser på det gamle navneområde, det nye navneområde eller begge dele i en overgangsperiode.
Hvem er berørt
De mest direkte berørte brugere er udviklere og platformsteams, der allerede bruger AWS Agent Registry under offentlig forhåndsvisning. De bør auditere enhver kode eller infrastruktur, der refererer til bedrock-agentcore for registreringsoperationer. Det omfatter applikationskode, infrastruktur-som-kode-skabeloner, IAM-politikker, CI-job, CLI-scripts, SDK-indpakninger, lokalt udviklerværktøj og dokumentation, der bruges af supportteams.
Sikkerheds- og skystyringsteam er også berørt. IAM-ændringer kan tage længere tid end programrettelser, fordi de ofte kræver gennemgang, tjek med mindste privilegier og godkendelsesarbejdsgange. En navnerumsflytning kan kræve nye tilladelser, opdaterede servicereferencer og opdaterede politikskabeloner. Hvis organisationer har interne kontroller, der blokerer ukendte tjenestenavneområder som standard, skal det nye agent-registry-navneområde muligvis tilføjes, før udviklere kan fortsætte.
API-gateway- og automationsleverandører har et andet problem: kundeforvirring. AWS har for nylig også flyttet Bedrock Agents ind i en "klassisk" vej til tilgængelighed for nye kunder, og styrede nyt arbejde mod AgentCore. Agent Registry-navneområdemigreringen er adskilt fra den tidligere Bedrock Agents Classic-afskæring, men begge hændelser påvirker den samme brede kategori af agentinfrastruktur. Dokumentation, onboarding-flows og supportsvar bør gøre denne skelnen klar.
Praktiske migreringstrin
Team bør starte med en opgørelse. Søg i repositories, implementeringsmanifester, politikfiler og CI-scripts for registreringsdatabasen-relaterede opkald under det gamle Bedrock AgentCore-navneområde. Identificer derefter, hvilke referencer der er køretidskritiske, og hvilke der kun er dokumentation eller eksempler.
Dernæst skal du opdatere IAM-politikker og teste dem på en ikke-produktionskonto. Ændringer i navneområdet afslører ofte alt for brede tilladelser eller skjulte afhængigheder. En kontrolleret test kan vise, om de nye servicereferencer er tilstrækkelige, før produktionsagenter eller registre er afhængige af dem.
SDK- og CLI-brug bør kontrolleres separat. Nogle teams kalder cloud-tjenester gennem officielle SDK-klienter; andre skal ud til CLI-kommandoer inde i bygge pipelines. Begge veje kan fejle forskelligt. SDK-klienter kan have brug for versionsopdateringer eller nye servicekonstruktører. CLI-scripts kan have brug for nye kommandonavne, slutpunktsflag eller godkendelsesantagelser.
Registreringsdata fortjener sin egen migreringsplan. AWS-dokumentation siger, at registerdata skal opdateres, men den operationelle virkning vil afhænge af, hvordan hvert team har modelleret agenter, identifikatorer og metadata. Teams bør verificere, om agentposter, agentkort, versioner eller referencer forbliver stabile efter migrering, og om downstream-systemer cacher disse identifikatorer.
For virksomheder, der bruger en multimodel-API eller AI API-gateway, er den større lektie, at agentinfrastruktur nu har brug for den samme ændringsstyringsdisciplin som modelrouting. En gateway såsom Model Gate er muligvis ikke direkte involveret i AWS Agent Registry-migrering, men det operationelle mønster er velkendt: API-overflader på udbydersiden ændrer sig, og teams har brug for centraliseret konfiguration, brugssynlighed, nøglekontroller og tydeligt ejerskab for at undgå spredte brud.
Hvad er fortsat usikkert
De tilgængelige oplysninger kommer fra AWS-dokumentation snarere end en separat lanceringsblog eller en bredere meddelelse. Det gør ikke ændringen mindre handlebar, men den begrænser den offentlige kontekst omkring AWS's køreplan for registreringsdatabasen. Dokumentationen bekræfter navnerummigreringen og kategorierne af påkrævede opdateringer; det giver ikke i det hentede materiale en detaljeret markedspositioneringsforklaring eller uafhængig bekræftelse fra en anden AWS-kilde.
Fordi AWS Agent Registry er i offentlig forhåndsvisning, bør teams også antage, at flere grænsefladeændringer er mulige. Preview-tjenester er nyttige til tidlig adoption, men de kræver stærkere abstraktionsgrænser end modne API'er. Hvis registreringsdatabasen er spredt ud over mange applikationer, er dette et godt tidspunkt at konsolidere dem bag interne biblioteker eller platformstjenester, så den næste ændring er lettere at absorbere.