Amazon Web Services har sat sin oprindelige administrerede agenttjeneste for Amazon Bedrock i vedligeholdelsestilstand til ny indførelse. Tjenesten, der tidligere var kendt som Amazon Bedrock Agents, er nu dokumenteret som Amazon Bedrock Agents Classic, og AWS siger, at den ikke længere er åben for nye kunder fra den 30. juli 2026.

Det betyder ikke, at eksisterende implementeringer holder op med at fungere. AWS siger, at nuværende kunder kan fortsætte med at bruge Bedrock Agents Classic, og det står separat, at Amazon Bedrock-modeller, Knowledge Bases og Guardrails ikke er påvirket af ændringen. Men retningen for nye agentarbejdsbelastninger er klar: AWS anbefaler Amazon Bedrock AgentCore som den sammenlignelige vej for nye eller migrerede agentapplikationer.

For teams, der bygger på Bedrock, er dette mere end en tjenestenavnsændring. Det skifter standardarkitekturen for AWS-hostede agenter fra den ældre Bedrock Agents-grænseflade til en nyere runtime og værktøjsstak centreret om AgentCore. For platforme, der leverer en AI API-gateway, LLM-routinglag eller virksomhedsagentinfrastruktur, skaber afskæringen et kompatibilitets- og migreringsspørgsmål, der ligger sammen med almindeligt modelvalg.

Hvad blev ændret den 30. juli

AWS-dokumentationen identificerer nu Amazon Bedrock Agents som Amazon Bedrock Agents Classic. Den samme vejledning i vedligeholdelsestilstand siger, at Bedrock Agents Classic er lukket for nye kunder fra den 30. juli 2026, mens eksisterende kunder kan fortsætte med at bruge det.

Den praktiske betydning afhænger af kundens AWS-konto og nuværende brug. Eksisterende produktionssystemer bygget på Classic bør ikke forudsætte en øjeblikkelig nedlukning alene baseret på den offentlige vedligeholdelsesmeddelelse. Nye teams, nye konti og organisationer, der standardiserer fremtidig agentinfrastruktur, bør imidlertid behandle Classic som en ældre sti i stedet for som standard Bedrock-agenttjenesten.

AWS peger nye og migrerende kunder til Bedrock AgentCore. Virksomheden beskriver AgentCore som støtte for styret orkestrering og et bredere sæt af produktionsagent-kapaciteter, herunder værktøjseksponering gennem Model Context Protocol, hukommelse, identitet, observerbarhed og sporing. Disse funktioner tyder på, at AWS bevæger sig fra en smallere administrator-agent-builder til en mere generel agent-runtime for langlivede, værktøjsbrugende applikationer.

En grænse er også vigtig: Ændringen handler om Bedrocks administrerede agent-orkestreringslag, ikke hele Bedrock-platformen. AWS siger, at grundfjeldsmodeller, vidensbaser og autoværn ikke påvirkes. Et team kan stadig bruge Bedrock-modelinferens eller hentning og sikkerhedskomponenter, selvom det skal besøge agentorkestreringstjenesten omkring dem igen.

Hvorfor er dette vigtigt for agentbyggere

Agentinfrastruktur er blevet sværere at behandle som en tynd indpakning omkring et modelopkald. En produktionsagent har ofte brug for værktøjstilladelser, hukommelsesregler, identitetskortlægning, logning, evaluering og omkostningstilskrivning. Når det administrerede orkestreringslag ændres, skal udviklere muligvis gennemgå, hvordan prompter, værktøjsskemaer, genfinding, autoværn og overvågning er koblet sammen.

Det gælder især for virksomheder, der har adopteret Bedrock Agents Classic som et administreret alternativ til at bygge deres egen orkestrering. Hvis disse virksomheder nu opretter yderligere miljøer, ombord på nye forretningsenheder eller genopbygger i nye AWS-konti, kan de støde på en anden tilgængelighed og anbefalet arkitektur end den, der bruges af deres eksisterende implementeringer.

Afskæringen påvirker også leverandører og interne platformsteams, der abstraherer Bedrock bag en samlet grænseflade. En multi-sky eller multi-model platform kan ikke behandle dette blot som "rute til en AWS-model." Det kan være nødvendigt at vide, om en kunde påberåber sig almindelig modelslutning, en Knowledge Base-arbejdsgang, en Guardrails-politik, en Classic-agent eller en AgentCore-hostet arbejdsbelastning. Det er forskellige operationelle overflader med forskellige migrationsrisici.

For Model Gate-brugere og lignende gateway-kunder er lektionen, at LLM API-routing ikke længere kun handler om pris, latenstid og modelkvalitet. Agentplacering har også betydning. En gateway kan hjælpe med at centralisere API-nøglestyring, brugsanalyse, teamkontroller og forbrugssynlighed, men den skal stadig respektere mulighederne og livscyklusstatus for de underliggende udbydertjenester.

Hvem er berørt

Den mest direkte berørte gruppe er AWS-kunder, der planlægger nye managed-agent-baserede systemer på Bedrock. Hvis de ikke tidligere har brugt Bedrock Agents Classic, skal de forvente, at AgentCore er den anbefalede vej. Team, der allerede kører Classic-agenter, kan fortsætte med at bruge dem, ifølge AWS, men bør planlægge for tjenestens vedligeholdelsesposition, når de træffer langsigtede beslutninger om køreplaner.

Cloud-arkitekter er berørt, fordi referencearkitekturer muligvis skal opdateres.Dokumentation, Terraform-moduler, interne gyldne stier og sikkerhedsgennemgange, der antog Bedrock Agents Classic som det standardadministrerede agentlag, bør kontrolleres i forhold til AgentCores API'er, identitetsmodel, observerbarhedsfunktioner og driftskrav.

Sikkerheds- og styringsteams er også omfattet. AgentCores vægt på identitet, værktøjseksponering, observerbarhed og sporing afspejler de problemer, som virksomheder nu forsøger at løse: hvilken bruger eller tjeneste, der handler, hvilke værktøjer en agent kan kalde, hvilke data den kan hente, hvordan en beslutning kan revideres, og hvordan løbske værktøjsløkker eller dyre modelkald detekteres.

Software-leverandører kan have brug for en du-understøttelse af Bedalrock. Eksisterende kunder kan stadig være på Classic, mens nye kunder muligvis har brug for AgentCore. Det kan betyde yderligere test, funktionsflag, kundespecifik implementeringslogik og klarere dokumentation om, hvilken Bedrock-agentsti der understøttes.

Praktiske konsekvenser og åbne spørgsmål

Det første praktiske trin er opgørelse. Holdene bør identificere, om de bruger Bedrock Agents Classic, almindelige Bedrock-model API'er, vidensbaser, guardrails eller tilpasset orkestrering uden for Bedrock. Meddelelsen om vedligeholdelsestilstand påvirker disse kategorier forskelligt.

Det andet trin er at kortlægge migreringsafhængigheder i stedet for at antage et direkte løft og skift. Agentarbejdsbelastninger kan afhænge af værktøjsdefinitioner, genfindingskonfiguration, promptskabeloner, IAM-tilladelser, revisionslogfiler og applikationsspecifik fejlhåndtering. At flytte til AgentCore kan være en mulighed for at forbedre observerbarhed og identitetskontrol, men det kan stadig kræve integrationsarbejde.

Det tredje trin er gennemgang af omkostninger og styring. Nye agentkørselstider gør det ofte lettere at forbinde flere værktøjer og køre mere autonome arbejdsgange. Det øger værdien af ​​brugsanalyse, tilskrivning på anmodningsniveau og budgetkontrol. I et gateway-miljø bør teams beslutte, hvilke opkald der flyder gennem et centralt politiklag, og hvilke der forbliver i AWS-administreret orkestrering.

Nogle detaljer forbliver kontospecifikke. Uafhængige kommentarer har antydet, at berettigelse kan afhænge af tidligere kontobrug, og at nogle nyligt udgivne modeller efter afskæring muligvis ikke bliver tilgængelige gennem Classic. Disse punkter bør verificeres i forhold til kundens egen AWS-konto og AWS's nuværende vedligeholdelses-mode-dokumentation, før de behandles som politik.

Det større signal er klart nok: AWS forlader ikke Bedrock-agenter, men det flytter nyt agentarbejde væk fra den originale Bedrock Agents-grænseflade. For udviklere og platformsteams er den sikre antagelse, at fremtidige AWS-agentinvesteringer vil koncentrere sig omkring AgentCore, mens Bedrock Agents Classic bliver et kompatibilitetsproblem for eksisterende implementeringer.