Amazon Web Services har satt sin ursprungliga hanterade agenttjänst för Amazon Bedrock i underhållsläge för ny användning. Tjänsten tidigare känd som Amazon Bedrock Agents är nu dokumenterad som Amazon Bedrock Agents Classic, och AWS säger att den inte längre är öppen för nya kunder från och med den 30 juli 2026.

Det betyder inte att befintliga implementeringar slutar fungera. AWS säger att nuvarande kunder kan fortsätta använda Bedrock Agents Classic, och det står separat att Amazon Bedrock-modeller, kunskapsbaser och Guardrails inte påverkas av förändringen. Men riktningen för nya agentarbetsbelastningar är tydlig: AWS rekommenderar Amazon Bedrock AgentCore som den jämförbara vägen för nya eller migrerade agentapplikationer.

För team som bygger på Bedrock är detta mer än en tjänstnamnsändring. Den flyttar standardarkitekturen för AWS-värdade agenter från det äldre gränssnittet för Bedrock Agents till en nyare runtime och verktygsstack centrerad på AgentCore. För plattformar som tillhandahåller en AI API-gateway, LLM-routinglager eller infrastruktur för företagsagenter, skapar cutoff en kompatibilitets- och migreringsfråga som ligger vid sidan av det vanliga modellvalet.

Vad som ändrades den 30 juli

AWS-dokumentationen identifierar nu Amazon Bedrock Agents som Amazon Bedrock Agents Classic. Samma vägledning för underhållsläge säger att Bedrock Agents Classic är stängt för nya kunder från den 30 juli 2026, medan befintliga kunder kan fortsätta använda det.

Den praktiska innebörden beror på kundens AWS-konto och nuvarande användning. Befintliga produktionssystem byggda på Classic bör inte förutsätta en omedelbar avstängning enbart baserat på det offentliga underhållsmeddelandet. Nya team, nya konton och organisationer som standardiserar framtida agentinfrastruktur bör dock behandla Classic som en äldre väg snarare än standardtjänsten för Bedrock-agenter.

AWS pekar nya och migrerande kunder till Bedrock AgentCore. Företaget beskriver AgentCore som stöd för hanterad orkestrering och en bredare uppsättning produktionsagentfunktioner, inklusive verktygsexponering genom Model Context Protocol, minne, identitet, observerbarhet och spårning. Dessa funktioner tyder på att AWS flyttar från en smalare hanterade agentbyggare till en mer allmän agentkörning för långlivade, verktygsanvändande applikationer.

En gräns är också viktig: förändringen handlar om Bedrocks hanterade agentorkestreringslager, inte hela Bedrock-plattformen. AWS säger att berggrundsmodeller, kunskapsbaser och skyddsräcken inte påverkas. Ett team kan fortfarande använda Bedrock-modellinferens eller hämtning och säkerhetskomponenter även om det behöver besöka agentorkestreringstjänsten runt dem igen.

Varför detta är viktigt för agentbyggare

Agentinfrastruktur har blivit svårare att behandla som ett tunt omslag runt ett modellanrop. En produktionsagent behöver ofta verktygsbehörigheter, minnesregler, identitetskartläggning, loggning, utvärdering och kostnadstillskrivning. När det hanterade orkestreringsskiktet ändras kan utvecklare behöva se över hur uppmaningar, verktygsscheman, hämtning, skyddsräcken och övervakning kopplas samman.

Det gäller särskilt för företag som anammat Bedrock Agents Classic som ett hanterat alternativ till att bygga sin egen orkestrering. Om dessa företag nu skapar ytterligare miljöer, ombord på nya affärsenheter eller bygger om i nya AWS-konton, kan de stöta på annan tillgänglighet och rekommenderad arkitektur än den som används av deras befintliga implementeringar.

Avbrytningen påverkar även leverantörer och interna plattformsteam som abstraherar Bedrock bakom ett enhetligt gränssnitt. En plattform med flera moln eller flera modeller kan inte bara behandla detta som "väg till en AWS-modell." Den kan behöva veta om en kund åberopar vanlig modellslutledning, ett kunskapsbasarbetsflöde, en Guardrails-policy, en klassisk agent eller en AgentCore-värd arbetsbelastning. Det är olika operativa ytor med olika migreringsrisker.

För Model Gate-användare och liknande gateway-kunder är lärdomen att LLM API-routing inte längre bara handlar om pris, latens och modellkvalitet. Agentplacering spelar också roll. En gateway kan hjälpa till att centralisera API-nyckelhantering, användningsanalys, teamkontroller och utgiftssynlighet, men den måste fortfarande respektera kapaciteten och livscykelstatusen för de underliggande leverantörstjänsterna.

Vem påverkas

Den mest direkt berörda gruppen är AWS-kunder som planerar nya hanterade agenter som bygger på Bedrock. Om de inte tidigare har använt Bedrock Agents Classic bör de förvänta sig att AgentCore är den rekommenderade vägen. Team som redan kör Classic-agenter kan fortsätta använda dem, enligt AWS, men bör planera för tjänstens underhållsställning när de fattar långsiktiga färdplansbeslut.

Molnarkitekter påverkas eftersom referensarkitekturer kan behöva uppdateras.Dokumentation, Terraform-moduler, interna gyllene vägar och säkerhetsgranskningar som antog Bedrock Agents Classic som standardlager för hanterade agenter bör kontrolleras mot AgentCores API:er, identitetsmodell, observerbarhetsfunktioner och operativa krav.

Säkerhets- och ledningsteam är också i omfattning. AgentCores betoning på identitet, verktygsexponering, observerbarhet och spårning återspeglar de problem som företag nu försöker lösa: vilken användare eller tjänst som agerar, vilka verktyg en agent kan anropa, vilken data den kan hämta, hur ett beslut kan granskas och hur skenande verktygsslingor eller dyra modellanrop upptäcks.

Programvaruleverantörer kan behöva ett stöd som bygger på Bedalrock. Befintliga kunder kan fortfarande vara på Classic, medan nya kunder kan behöva AgentCore. Det kan innebära ytterligare testning, funktionsflaggor, kundspecifik distributionslogik och tydligare dokumentation om vilken Bedrock-agentsökväg som stöds.

Praktiska konsekvenser och öppna frågor

Det första praktiska steget är inventering. Teamen bör identifiera om de använder Bedrock Agents Classic, plain Bedrock modell API:er, kunskapsbaser, Guardrails eller anpassad orkestrering utanför Bedrock. Meddelandet om underhållsläge påverkar dessa kategorier på olika sätt.

Det andra steget är att kartlägga migreringsberoenden snarare än att anta ett direkt lyft-och-skift. Agentarbetsbelastningar kan bero på verktygsdefinitioner, hämtningskonfiguration, promptmallar, IAM-behörigheter, granskningsloggar och programspecifik felhantering. Att flytta till AgentCore kan vara en möjlighet att förbättra observerbarhet och identitetskontroller, men det kan fortfarande kräva integrationsarbete.

Det tredje steget är kostnads- och styrningsgranskning. Nya agentkörtider gör det ofta lättare att ansluta fler verktyg och köra mer autonoma arbetsflöden. Det ökar värdet av användningsanalys, attribution på begäran och budgetkontroller. I en gatewaymiljö bör teamen bestämma vilka samtal som flyter genom ett centralt policylager och vilka som finns kvar inom AWS-hanterad orkestrering.

Vissa detaljer förblir kontospecifika. Oberoende kommentarer har föreslagit att kvalificering kan bero på tidigare kontoanvändning och att vissa nyligen släppta modeller efter avstängning kanske inte blir tillgängliga via Classic. Dessa punkter bör verifieras mot kundens eget AWS-konto och AWS nuvarande underhållslägesdokumentation innan de behandlas som policy.

Den större signalen är tydlig nog: AWS lämnar inte Bedrock-agenter, men det flyttar nytt agentarbete bort från det ursprungliga Bedrock Agents-gränssnittet. För utvecklare och plattformsteam är det säkra antagandet att framtida AWS-agentinvesteringar kommer att koncentreras kring AgentCore, medan Bedrock Agents Classic blir ett kompatibilitetsproblem för befintliga implementeringar.