AWS està fent un canvi de compatibilitat important per als equips que creen una infraestructura d'agents a la part superior d'Amazon Bedrock AgentCore. Segons la documentació d'AWS, AWS Agent Registry es troba actualment en previsualització pública a l'espai de noms bedrock-agentcore, però a partir del 6 d'agost de 2026, el servei es trasllada a l'espai de noms agent-registry.

Aquest no és un llançament de model de fundació nou i no és un anunci de preus. És un canvi de fontaneria. Però per als desenvolupadors que operan els agents, els catàlegs d'eines, les integracions a l'estil del protocol de context model o els registres interns, els canvis de fontaneria solen ser els que trenquen primer els scripts de producció.

AWS diu que els usuaris han d'actualitzar els punts finals, les polítiques IAM, els clients SDK, els scripts CLI i les dades del registre com a part del moviment. Això fa que sigui un veritable esdeveniment de migració en lloc d'un canvi de nom estètic. Qualsevol sistema que cridi directament a l'espai de noms antic, li concedeixi permisos o que automatitzi les operacions del registre mitjançant la línia d'ordres o els fluxos de treball de l'SDK pot necessitar canvis abans de poder funcionar correctament amb la nova identitat del servei.

Què ha canviat a AWS Agent Registry

AWS Agent Registry està documentat com un servei de previsualització pública associat amb Amazon Bedrock AgentCore. El registre està pensat per ajudar els equips a gestionar i descobrir agents, incloses les targetes d'agent i les metadades relacionades que s'utilitzen als ecosistemes d'agents. Fins ara, la previsualització ha viscut sota l'espai de noms bedrock-agentcore.

El canvi del 6 d'agost separa el registre en l'espai de noms agent-registry. En termes pràctics, això significa que les integracions haurien de deixar de suposar que el registre és només una subpart de l'espai de noms més ampli de Bedrock AgentCore. La documentació d'AWS indica diverses àrees que requereixen atenció: punts finals del servei, polítiques de gestió d'identitats i accés, clients SDK, scripts CLI i dades del registre.

Aquestes categories cobreixen la majoria dels llocs on la infraestructura d'agents es torna enganxosa. Els punts finals es poden incrustar a la configuració del servei. Els permisos IAM els poden gestionar els equips de seguretat en lloc dels desenvolupadors d'aplicacions. Els clients SDK es poden fixar a les biblioteques internes. Els scripts CLI poden estar executant-se en canalitzacions CI o runbooks d'operacions. És possible que les dades del registre necessitin migrar o tornar a registrar-se en funció de com utilitzi un equip el servei de previsualització.

Per què això és important per a les eines d'agent i MCP

El moment és notable perquè la infraestructura d'agents s'està tornant més formal. Els canvis recents a tot el mercat han fet que els desenvolupadors s'allunyen de les demostracions puntuals i cap a sistemes governats: registres, servidors d'eines, informes d'ús, controls d'accés i pistes d'auditoria. En aquest context, un canvi de l'espai de noms del registre és un senyal que AWS està tractant el descobriment i la gestió d'agents com una superfície d'infraestructura diferent.

Per als equips que experimenten amb agents, aquesta pot ser una petita tasca de manteniment. Per a les empreses que creen plataformes internes al voltant dels catàlegs d'agents, el treball és més ampli. Les trucades de registre poden estar darrere de portals de desenvolupadors, sistemes de revisió de seguretat, capes d'orquestració, fluxos de treball d'aprovació o desplegaments automatitzats. Si aquests sistemes es van crear durant el període de previsualització, poden contenir supòsits que ara s'han de revisar.

El canvi també és rellevant per als desplegaments del protocol de context del model i altres patrons d'interoperabilitat d'agents. Els registres d'agents poden convertir-se en el lloc on les plataformes descobreixen què és un agent, quines eines pot utilitzar, quins punts finals exposa i quins límits de confiança s'apliquen. Si una passarel·la, un orquestrador o una plataforma de socis exposa agents recolzats per AWS als clients, ha de saber si està mirant l'espai de noms antic, el nou espai de noms o tots dos durant un període de transició.

Qui està afectat

Els usuaris més directament afectats són els desenvolupadors i els equips de plataforma que ja utilitzen AWS Agent Registry durant la previsualització pública. Haurien d'auditar qualsevol codi o infraestructura que faci referència a bedrock-agentcore per a les operacions del registre. Això inclou codi d'aplicació, plantilles d'infraestructura com a codi, polítiques IAM, treballs de CI, scripts CLI, embolcalls d'SDK, eines de desenvolupadors locals i documentació utilitzada pels equips d'assistència.

Els equips de seguretat i governança del núvol també es veuen afectats. Els canvis d'IAM poden trigar més que els pedaços de l'aplicació perquè sovint requereixen revisió, comprovacions de privilegis mínims i fluxos de treball d'aprovació. Un moviment d'espai de noms pot requerir nous permisos, referències de servei actualitzades i plantilles de polítiques actualitzades. Si les organitzacions tenen controls interns que bloquegen espais de noms de serveis desconeguts de manera predeterminada, és possible que s'hagi d'afegir el nou espai de noms agent-registry abans que els desenvolupadors puguin continuar.

Els proveïdors de passarel·les d'API i d'automatització tenen un problema diferent: la confusió del client. Recentment, AWS també va traslladar Bedrock Agents a un camí "clàssic" per a la disponibilitat de nous clients, dirigint el nou treball cap a AgentCore. La migració de l'espai de noms del registre d'agents és independent del tall anterior de Bedrock Agents Classic, però tots dos esdeveniments afecten la mateixa categoria àmplia d'infraestructura d'agents. La documentació, els fluxos d'incorporació i les respostes de suport haurien de deixar clara aquesta distinció.

Passos pràctics de migració

Els equips haurien de començar amb un inventari. Cerqueu repositoris, manifests de desplegament, fitxers de polítiques i scripts CI per a trucades relacionades amb el registre a l'antic espai de noms de Bedrock AgentCore. A continuació, identifiqueu quines referències són crítiques en temps d'execució i quines només són documentació o exemples.

A continuació, actualitzeu les polítiques d'IAM i proveu-les en un compte que no sigui de producció. Els canvis a l'espai de noms solen revelar permisos massa amplis o dependències ocultes. Una prova controlada pot mostrar si les noves referències de servei són suficients abans que els agents de producció o els registres en depenguin.

L'ús de l'SDK i la CLI s'ha de comprovar per separat. Alguns equips truquen a serveis al núvol mitjançant clients SDK oficials; d'altres desenvolupen ordres CLI dins de les canalitzacions de construcció. Tots dos camins poden fallar de manera diferent. Els clients SDK poden necessitar actualitzacions de versions o nous constructors de serveis. És possible que els scripts CLI necessitin noms d'ordres nous, senyals de punt final o supòsits d'autenticació.

Les dades del registre mereixen el seu propi pla de migració. La documentació d'AWS diu que les dades del registre s'han d'actualitzar, però l'impacte operatiu dependrà de com cada equip hagi modelat agents, identificadors i metadades. Els equips haurien de verificar si els registres de l'agent, les targetes d'agent, les versions o les referències es mantenen estables després de la migració i si els sistemes posteriors emmagatzemen aquests identificadors a la memòria cau.

Per a les empreses que utilitzen una API multimodel o una passarel·la d'API AI, la lliçó més gran és que la infraestructura d'agents necessita ara la mateixa disciplina de gestió de canvis que l'encaminament del model. És possible que una passarel·la com Model Gate no estigui directament implicada en la migració del registre d'agents d'AWS, però el patró operatiu és familiar: les superfícies de l'API del proveïdor canvien i els equips necessiten una configuració centralitzada, visibilitat d'ús, controls clau i propietat clara per evitar trencaments dispersos.

Què segueix sent incert

La informació disponible prové de la documentació d'AWS en lloc d'un bloc de llançament independent o un anunci més ampli. Això no fa que el canvi sigui menys viable, però limita el context públic al voltant del full de ruta d'AWS per al registre. La documentació confirma la migració de l'espai de noms i les categories d'actualitzacions necessàries; En el material recuperat, no proporciona una explicació detallada del posicionament en el mercat ni una confirmació independent d'una altra font d'AWS.

Com que el registre d'agents d'AWS es troba a la vista prèvia pública, els equips també haurien de suposar que són possibles més canvis a la interfície. Els serveis de previsualització són útils per a una adopció primerenca, però requereixen límits d'abstracció més forts que les API madures. Si les operacions de registre es troben disperses en moltes aplicacions, aquest és un bon moment per consolidar-les darrere de biblioteques internes o serveis de plataforma, de manera que el proper canvi sigui més fàcil d'absorbir.