AWS lukker Bedrock Agents Classic for nye kunder, og skyver nye agentbygg mot AgentCore

Amazon Web Services har satt sin opprinnelige administrerte agenttjeneste for Amazon Bedrock i vedlikeholdsmodus for ny bruk. Tjenesten tidligere kjent som Amazon Bedrock Agents er nå dokumentert som Amazon Bedrock Agents Classic, og AWS sier at den ikke lenger er åpen for nye kunder fra og med 30. juli 2026.

Det betyr ikke at eksisterende distribusjoner slutter å fungere. AWS sier at nåværende kunder kan fortsette å bruke Bedrock Agents Classic, og det står separat at Amazon Bedrock-modeller, kunnskapsbaser og Guardrails ikke påvirkes av endringen. Men retningen for nye agentarbeidsmengder er klar: AWS anbefaler Amazon Bedrock AgentCore som den sammenlignbare banen for nye eller migrerte agentapplikasjoner.

For team som bygger på Bedrock, er dette mer enn en endring av tjenestenavn. Den skifter standardarkitekturen for AWS-vertsbaserte agenter fra det eldre Bedrock Agents-grensesnittet til en nyere kjøretids- og verktøystabel sentrert på AgentCore. For plattformer som gir en AI API-gateway, LLM-rutingslag eller infrastruktur for bedriftsagenter, skaper cutoff et kompatibilitets- og migrasjonsspørsmål som ligger ved siden av ordinært modellvalg.

Hva endret 30. juli

AWS-dokumentasjonen identifiserer nå Amazon Bedrock Agents som Amazon Bedrock Agents Classic. Den samme veiledningen i vedlikeholdsmodus sier at Bedrock Agents Classic er stengt for nye kunder fra 30. juli 2026, mens eksisterende kunder kan fortsette å bruke den.

Den praktiske betydningen avhenger av kundens AWS-konto og nåværende bruk. Eksisterende produksjonssystemer bygget på Classic bør ikke forutsette en umiddelbar stans basert på det offentlige vedlikeholdsvarselet alene. Nye team, nye kontoer og organisasjoner som standardiserer fremtidig agentinfrastruktur bør imidlertid behandle Classic som en eldre bane i stedet for standard Bedrock-agenttjeneste.

AWS peker nye og migrerende kunder til Bedrock AgentCore. Selskapet beskriver AgentCore som støtte for administrert orkestrering og et bredere sett med produksjonsagentfunksjoner, inkludert verktøyeksponering gjennom Model Context Protocol, minne, identitet, observerbarhet og sporing. Disse funksjonene antyder at AWS beveger seg fra en smalere administrator-agentbygger til en mer generell agentkjøring for langvarige, verktøybrukende applikasjoner.

En grense er også viktig: Endringen handler om Bedrocks administrerte agentorkestreringslag, ikke hele Bedrock-plattformen. AWS sier at berggrunnsmodeller, kunnskapsbaser og rekkverk ikke påvirkes. Et team kan fortsatt bruke Bedrock-modellslutning eller gjenfinning og sikkerhetskomponenter selv om det må besøke agentorkestreringstjenesten rundt dem på nytt.

Hvorfor dette er viktig for agentbyggere

Agentinfrastruktur har blitt vanskeligere å behandle som en tynn innpakning rundt en modellanrop. En produksjonsagent trenger ofte verktøytillatelser, minneregler, identitetskartlegging, logging, evaluering og kostnadsattribusjon. Når det administrerte orkestreringslaget endres, kan det hende at utviklere må gjennomgå hvordan meldinger, verktøyskjemaer, henting, rekkverk og overvåking kobles sammen.

Dette gjelder spesielt for bedrifter som tok i bruk Bedrock Agents Classic som et administrert alternativ til å bygge sin egen orkestrering. Hvis disse selskapene nå oppretter flere miljøer, ombord på nye forretningsenheter eller bygger om i nye AWS-kontoer, kan de støte på en annen tilgjengelighet og anbefalt arkitektur enn den som brukes av deres eksisterende distribusjoner.

Utbruddet påvirker også leverandører og interne plattformteam som abstraherer Bedrock bak et enhetlig grensesnitt. En multisky- eller multimodellplattform kan ikke behandle dette bare som "rute til en AWS-modell." Den kan trenge å vite om en kunde påberoper seg vanlig modellslutning, en Knowledge Base-arbeidsflyt, en Guardrails-policy, en Classic-agent eller en AgentCore-vertsarbeidsbelastning. Dette er forskjellige operasjonelle overflater med ulik migrasjonsrisiko.

For Model Gate-brukere og lignende gateway-kunder er lærdommen at LLM API-ruting ikke lenger bare handler om pris, ventetid og modellkvalitet. Agentplassering er også viktig. En gateway kan bidra til å sentralisere API-nøkkeladministrasjon, bruksanalyse, teamkontroller og kostnadssynlighet, men den må fortsatt respektere evnene og livssyklusstatusen til de underliggende leverandørtjenestene.

Hvem er berørt

Den mest direkte berørte gruppen er AWS-kunder som planlegger nye administrerte agenter som bygger på Bedrock. Hvis de ikke tidligere har brukt Bedrock Agents Classic, bør de forvente at AgentCore er den anbefalte banen. Team som allerede kjører Classic-agenter kan fortsette å bruke dem, ifølge AWS, men bør planlegge for tjenestens vedlikeholdsposisjon når de tar langsiktige veikartbeslutninger.

Skyarkitekter er berørt fordi referansearkitekturer kan trenge oppdatering.Dokumentasjon, Terraform-moduler, interne gyldne baner og sikkerhetsgjennomganger som antok at Bedrock Agents Classic var det standard administrerte agentlaget, bør sjekkes mot AgentCores APIer, identitetsmodell, observerbarhetsfunksjoner og operasjonelle krav.

Sikkerhets- og styringsteam er også i omfang. AgentCores vektlegging av identitet, verktøyeksponering, observerbarhet og sporing gjenspeiler problemene bedrifter nå prøver å løse: hvilken bruker eller tjeneste som handler, hvilke verktøy en agent kan ringe, hvilke data den kan hente, hvordan en beslutning kan revideres, og hvordan løpende verktøyløkker eller dyre modellanrop blir oppdaget.

Programvareleverandører kan trenge en dual-rock-støtte som bygger på Bedalrock. Eksisterende kunder kan fortsatt være på Classic, mens nye kunder kan trenge AgentCore. Det kan bety ytterligere testing, funksjonsflagg, kundespesifikk distribusjonslogikk og klarere dokumentasjon om hvilken Bedrock-agentbane som støttes.

Praktiske konsekvenser og åpne spørsmål

Det første praktiske trinnet er inventar. Lagene bør identifisere om de bruker Bedrock Agents Classic, plain Bedrock modell APIer, Knowledge Bases, Guardrails eller tilpasset orkestrering utenfor Bedrock. Varselet om vedlikeholdsmodus påvirker disse kategoriene annerledes.

Det andre trinnet er å kartlegge migrasjonsavhengigheter i stedet for å anta en direkte løft-og-skift. Agentarbeidsbelastninger kan avhenge av verktøydefinisjoner, hentingskonfigurasjon, ledetekstmaler, IAM-tillatelser, revisjonslogger og programspesifikk feilhåndtering. Å flytte til AgentCore kan være en mulighet for å forbedre observerbarhet og identitetskontroller, men det kan fortsatt kreve integreringsarbeid.

Det tredje trinnet er kostnads- og styringsgjennomgang. Nye kjøretider for agenter gjør det ofte enklere å koble til flere verktøy og kjøre mer autonome arbeidsflyter. Det øker verdien av bruksanalyse, attribusjon på forespørselsnivå og budsjettkontroller. I et gatewaymiljø bør team bestemme hvilke samtaler som flyter gjennom et sentralt policylag og hvilke som forblir i AWS-administrert orkestrering.

Noen detaljer forblir kontospesifikke. Uavhengige kommentarer har antydet at kvalifisering kan avhenge av tidligere kontobruk og at noen nylig utgitte modeller etter avslutning kanskje ikke blir tilgjengelige gjennom Classic. Disse punktene bør verifiseres mot kundens egen AWS-konto og AWS sin gjeldende vedlikeholdsmodusdokumentasjon før de behandles som policy.

Det større signalet er klart nok: AWS forlater ikke Bedrock-agenter, men det flytter nytt agentarbeid bort fra det originale Bedrock Agents-grensesnittet. For utviklere og plattformteam er den sikre antagelsen at fremtidige AWS-agentinvesteringer vil konsentrere seg rundt AgentCore, mens Bedrock Agents Classic blir et kompatibilitetsproblem for eksisterende distribusjoner.