AWS voert een compatibiliteitswijziging door die belangrijk is voor teams die een agentinfrastructuur bouwen bovenop Amazon Bedrock AgentCore. Volgens AWS-documentatie is AWS Agent Registry momenteel in openbare preview onder de naamruimte bedrock-agentcore, maar vanaf 6 augustus 2026 wordt de service verplaatst naar de naamruimte agent-registry.

Dit is geen lancering van een nieuw basismodel en geen prijsaankondiging. Het betreft een wijziging van het sanitair. Maar voor ontwikkelaars die agents, toolcatalogi, Model Context Protocol-achtige integraties of interne registers bedienen, zijn loodgieterswerkveranderingen vaak degenen die als eerste de productiescripts kapot maken.

AWS zegt dat gebruikers eindpunten, IAM-beleid, SDK-clients, CLI-scripts en registergegevens moeten updaten als onderdeel van de verhuizing. Dat maakt dit tot een echte migratiegebeurtenis in plaats van een cosmetische naamsverandering. Elk systeem dat de oude naamruimte rechtstreeks aanroept, er machtigingen voor verleent of registerbewerkingen automatiseert via opdrachtregel- of SDK-workflows, heeft mogelijk wijzigingen nodig voordat het netjes kan werken met de nieuwe service-identiteit.

Wat is er veranderd in het AWS Agent Registry

AWS Agent Registry is gedocumenteerd als een openbare preview-service die is gekoppeld aan Amazon Bedrock AgentCore. Het register is bedoeld om teams te helpen bij het beheren en ontdekken van agenten, inclusief agentkaarten en gerelateerde metagegevens die worden gebruikt in agentecosystemen. Tot nu toe stond de preview onder de naamruimte bedrock-agentcore.

De wijziging van 6 augustus verdeelt het register in de naamruimte agent-registry. In praktische termen betekent dit dat integraties niet langer mogen aannemen dat het register slechts een subonderdeel is van de bredere Bedrock AgentCore-naamruimte. In de AWS-documentatie worden verschillende gebieden genoemd die aandacht vereisen: service-eindpunten, beleid voor identiteits- en toegangsbeheer, SDK-clients, CLI-scripts en registergegevens.

Deze categorieën omvatten de meeste plaatsen waar de infrastructuur van agenten plakkerig wordt. Eindpunten kunnen zijn ingebed in de serviceconfiguratie. IAM-machtigingen kunnen worden beheerd door beveiligingsteams in plaats van door applicatieontwikkelaars. SDK-clients kunnen worden vastgezet in interne bibliotheken. CLI-scripts worden mogelijk uitgevoerd in CI-pijplijnen of bewerkingsrunbooks. Registergegevens moeten mogelijk worden gemigreerd of opnieuw worden geregistreerd, afhankelijk van hoe een team de preview-service gebruikt.

Waarom dit belangrijk is voor agent- en MCP-tools

De timing is opmerkelijk omdat de agentinfrastructuur steeds formeler wordt. Recente veranderingen op de markt hebben ontwikkelaars weggeduwd van eenmalige demo's naar beheerde systemen: registers, toolservers, gebruiksrapportage, toegangscontroles en audittrails. In die context is een wijziging in de registernaamruimte een signaal dat AWS de detectie en het beheer van agenten behandelt als een afzonderlijk infrastructuuroppervlak.

Voor teams die experimenteren met agenten kan dit een kleine onderhoudstaak zijn. Voor bedrijven die interne platforms rond agentcatalogi bouwen, is het werk breder. Registeraanroepen kunnen zich achter ontwikkelaarsportals, beveiligingsbeoordelingssystemen, orkestratielagen, goedkeuringsworkflows of geautomatiseerde implementaties bevinden. Als deze systemen tijdens de preview-periode zijn gebouwd, kunnen ze aannames bevatten die nu opnieuw moeten worden bekeken.

De wijziging is ook relevant voor de implementatie van Model Context Protocol en andere interoperabiliteitspatronen voor agenten. Agentregisters kunnen de plek worden waar platforms ontdekken wat een agent is, welke tools hij kan gebruiken, welke eindpunten hij blootlegt en welke vertrouwensgrenzen van toepassing zijn. Als een gateway, orkestrator of partnerplatform door AWS ondersteunde agenten aan klanten blootstelt, moet het tijdens een overgangsperiode weten of het naar de oude naamruimte, de nieuwe naamruimte of beide kijkt.

Wie wordt getroffen

De meest direct getroffen gebruikers zijn ontwikkelaars en platformteams die al AWS Agent Registry gebruiken tijdens de openbare preview. Ze moeten elke code of infrastructuur controleren die verwijst naar bedrock-agentcore voor registerbewerkingen. Dat omvat applicatiecode, infrastructuur-als-code-sjablonen, IAM-beleid, CI-taken, CLI-scripts, SDK-wrappers, lokale ontwikkelaarstools en documentatie die wordt gebruikt door ondersteuningsteams.

Beveiligings- en cloudbeheerteams worden ook getroffen. IAM-wijzigingen kunnen langer duren dan applicatiepatches, omdat ze vaak beoordeling, controles met minimale bevoegdheden en goedkeuringsworkflows vereisen. Voor een naamruimteverplaatsing zijn mogelijk nieuwe machtigingen, bijgewerkte servicereferenties en vernieuwde beleidssjablonen nodig. Als organisaties interne controles hebben die onbekende servicenaamruimten standaard blokkeren, moet de nieuwe agent-registry naamruimte mogelijk worden toegevoegd voordat ontwikkelaars verder kunnen gaan.

API-gateway- en automatiseringsleveranciers hebben een ander probleem: verwarring bij klanten. AWS heeft Bedrock Agents onlangs ook naar een ‘klassiek’ pad verplaatst voor de beschikbaarheid van nieuwe klanten, waardoor nieuw werk richting AgentCore wordt gestuurd. De migratie van de Agent Registry-naamruimte staat los van de eerdere afsluiting van Bedrock Agents Classic, maar beide gebeurtenissen hebben invloed op dezelfde brede categorie agentinfrastructuur. Documentatie, onboarding-stromen en ondersteuningsreacties moeten dat onderscheid duidelijk maken.

Praktische migratiestappen

Teams moeten beginnen met een inventarisatie. Zoek in opslagplaatsen, implementatiemanifesten, beleidsbestanden en CI-scripts voor registergerelateerde oproepen onder de oude Bedrock AgentCore-naamruimte. Bepaal vervolgens welke referenties runtime-kritisch zijn en welke slechts documentatie of voorbeelden zijn.

Werk vervolgens het IAM-beleid bij en test het in een niet-productieaccount. Wijzigingen in de naamruimte brengen vaak te brede machtigingen of verborgen afhankelijkheden aan het licht. Een gecontroleerde test kan uitwijzen of de nieuwe servicereferenties voldoende zijn voordat productieagenten of registers ervan afhankelijk zijn.

Het SDK- en CLI-gebruik moet afzonderlijk worden gecontroleerd. Sommige teams bellen cloudservices aan via officiële SDK-clients; anderen gebruiken CLI-opdrachten binnen build-pijplijnen. Beide paden kunnen anders mislukken. SDK-clients hebben mogelijk versie-updates of nieuwe serviceconstructors nodig. CLI-scripts hebben mogelijk nieuwe opdrachtnamen, eindpuntvlaggen of authenticatie-aannames nodig.

Registergegevens verdienen een eigen migratieplan. AWS-documentatie zegt dat registergegevens moeten worden bijgewerkt, maar de operationele impact zal afhangen van hoe elk team agenten, identificatiegegevens en metadata heeft gemodelleerd. Teams moeten verifiëren of agentrecords, agentkaarten, versies of referenties stabiel blijven na de migratie, en of downstream-systemen deze ID's in de cache opslaan.

Voor bedrijven die een multi-model API of AI API-gateway gebruiken, is de grotere les dat de agentinfrastructuur nu dezelfde discipline op het gebied van verandermanagement nodig heeft als modelroutering. Een gateway zoals Model Gate is misschien niet direct betrokken bij de migratie van AWS Agent Registry, maar het operationele patroon is bekend: API-oppervlakken aan de providerzijde veranderen en teams hebben gecentraliseerde configuratie, gebruikszichtbaarheid, belangrijke controles en duidelijk eigendom nodig om verspreide breuk te voorkomen.

Wat blijft onzeker

De beschikbare informatie is afkomstig uit AWS-documentatie en niet uit een afzonderlijke lanceringsblog of bredere aankondiging. Dat maakt de verandering niet minder uitvoerbaar, maar beperkt wel de publieke context rond de routekaart van AWS voor het register. De documentatie bevestigt de naamruimtemigratie en de categorieën vereiste updates; het geeft in het opgehaalde materiaal geen gedetailleerde uitleg over de marktpositionering of onafhankelijke bevestiging van een andere AWS-bron.

Omdat AWS Agent Registry zich in een openbare preview bevindt, moeten teams er ook van uitgaan dat er meer interfacewijzigingen mogelijk zijn. Preview-services zijn handig voor vroege acceptatie, maar vereisen sterkere abstractiegrenzen dan volwassen API's. Als registerbewerkingen over veel applicaties verspreid zijn, is dit een goed moment om ze achter interne bibliotheken of platformservices te consolideren, zodat de volgende verandering gemakkelijker op te vangen is.