Amazon Web Services постави оригиналната си управлявана агентска услуга за Amazon Bedrock в режим на поддръжка за ново приемане. Услугата, известна преди като Amazon Bedrock Agents, сега е документирана като Amazon Bedrock Agents Classic и AWS казва, че вече не е отворена за нови клиенти от 30 юли 2026 г.

Това не означава, че съществуващите внедрявания спират да работят. AWS казва, че настоящите клиенти могат да продължат да използват Bedrock Agents Classic и отделно посочва, че моделите на Amazon Bedrock, базите знания и Guardrails не са засегнати от промяната. Но посоката за нови натоварвания на агенти е ясна: AWS препоръчва Amazon Bedrock AgentCore като сравним път за нови или мигрирани агентски приложения.

За екипи, изграждащи върху Bedrock, това е повече от промяна на името на услугата. Той премества архитектурата по подразбиране за хоствани от AWS агенти от по-стария интерфейс на Bedrock Agents към по-нов стек за изпълнение и инструменти, центриран върху AgentCore. За платформи, които предоставят AI API шлюз, слой за маршрутизиране на LLM или инфраструктура на корпоративни агенти, прекъсването създава въпрос за съвместимост и миграция, който стои заедно с обикновения избор на модел.

Какво се промени на 30 юли

Документацията на AWS вече идентифицира Amazon Bedrock Agents като Amazon Bedrock Agents Classic. Същите указания за режим на поддръжка казват, че Bedrock Agents Classic е затворен за нови клиенти от 30 юли 2026 г., докато съществуващите клиенти могат да продължат да го използват.

Практическото значение зависи от AWS акаунта на клиента и текущото използване. Съществуващите производствени системи, изградени на Classic, не трябва да предполагат незабавно спиране въз основа само на публично известие за поддръжка. Въпреки това, новите екипи, новите акаунти и организациите, стандартизиращи бъдещата агентска инфраструктура, трябва да третират Classic като наследен път, а не като агентска услуга на Bedrock по подразбиране.

AWS насочва нови и мигриращи клиенти към Bedrock AgentCore. Компанията описва AgentCore като поддържаща управлявана оркестрация и по-широк набор от възможности на производствени агенти, включително излагане на инструменти чрез протокола за контекст на модела, памет, идентичност, наблюдаемост и проследяване. Тези функции предполагат, че AWS преминава от по-тесен създател на управлявани агенти към по-общо време за изпълнение на агенти за дълготрайни приложения, използващи инструменти.

Една граница също е важна: промяната се отнася до слоя за оркестрация на управляван агент на Bedrock, а не до цялата платформа на Bedrock. AWS казва, че моделите Bedrock, базите знания и парапетите не са засегнати. Екипът все още може да използва компоненти за извеждане или извличане на модели на Bedrock и за безопасност, дори ако трябва да преразгледа услугата за оркестриране на агенти около тях.

Защо това има значение за създателите на агенти

Инфраструктурата на агентите стана по-трудна за разглеждане като тънка обвивка около извикване на модел. Производственият агент често се нуждае от разрешения за инструменти, правила за памет, картографиране на идентичност, регистриране, оценка и приписване на разходите. Когато управляваният слой за оркестрация се промени, разработчиците може да се наложи да прегледат как подканите, схемите на инструментите, извличането, предпазните парапети и наблюдението са свързани заедно.

Това е особено вярно за предприятия, които са приели Bedrock Agents Classic като управлявана алтернатива за изграждане на собствена оркестрация. Ако тези компании сега създадат допълнителни среди, включат нови бизнес единици или възстановят нови акаунти в AWS, те може да се сблъскат с различна наличност и препоръчителна архитектура от тази, използвана от съществуващите им внедрявания.

Прекъсването също засяга доставчици и екипи на вътрешни платформи, които абстрахират Bedrock зад унифициран интерфейс. Мултиоблачна или мултимоделна платформа не може да третира това просто като „маршрут към AWS модел“. Може да се наложи да знае дали клиентът извиква обикновен извод за модел, работен поток от база знания, политика на Guardrails, класически агент или работно натоварване, хоствано от AgentCore. Това са различни оперативни повърхности с различни рискове за миграция.

За потребителите на Model Gate и подобни клиенти на шлюз урокът е, че LLM API маршрутизирането вече не се отнася само до цена, латентност и качество на модела. Поставянето на агент също има значение. Един шлюз може да помогне за централизиране на управлението на API ключове, анализа на използването, контролите на екипа и видимостта на разходите, но все пак трябва да зачита възможностите и състоянието на жизнения цикъл на основните услуги на доставчика.

Кой е засегнат

Най-пряко засегнатата група са клиентите на AWS, които планират нови компилации на управляван агент на Bedrock. Ако не са използвали преди това Bedrock Agents Classic, те трябва да очакват AgentCore да бъде препоръчителният път. Екипите, които вече работят с класически агенти, могат да продължат да ги използват, според AWS, но трябва да планират позицията на поддръжка на услугата, когато вземат решения за дългосрочна пътна карта.

Облачните архитекти са засегнати, тъй като референтните архитектури може да се нуждаят от актуализиране.Документацията, модулите Terraform, вътрешните златни пътища и прегледите на сигурността, които приемат Bedrock Agents Classic като стандартен управляван агентски слой, трябва да бъдат проверени спрямо API на AgentCore, модела на идентичност, функциите за наблюдение и оперативните изисквания.

Екипите за сигурност и управление също са в обхвата. Акцентът на AgentCore върху идентичността, експозицията на инструмента, видимостта и проследяването отразява проблемите, които предприятията сега се опитват да разрешат: кой потребител или услуга действа, кои инструменти може да извика агент, какви данни може да извлече, как може да бъде одитирано решение и как се откриват неуспешни цикли на инструменти или скъпи извиквания на модели.

Доставчиците на софтуер, надграждащи върху Bedrock, може да се нуждаят от период на двойна поддръжка. Съществуващите клиенти може все още да използват Classic, докато новите клиенти може да имат нужда от AgentCore. Това може да означава допълнително тестване, флагове за функции, специфична за клиента логика на внедряване и по-ясна документация за това кой път на агента на Bedrock се поддържа.

Практически последствия и отворени въпроси

Първата практическа стъпка е инвентаризацията. Екипите трябва да определят дали използват Bedrock Agents Classic, API на обикновен Bedrock модел, Бази знания, Guardrails или персонализирана оркестрация извън Bedrock. Известието за режим на поддръжка засяга тези категории по различен начин.

Втората стъпка е да картографирате зависимостите за миграция, вместо да приемате директно повдигане и преместване. Работните натоварвания на агентите може да зависят от дефинициите на инструмента, конфигурацията за извличане, шаблоните за подкана, IAM разрешенията, журналите за проверка и обработката на грешки, специфични за приложението. Преминаването към AgentCore може да е възможност за подобряване на контролите за наблюдение и самоличност, но все още може да изисква работа по интегрирането.

Третата стъпка е преглед на разходите и управлението. Новите времена за изпълнение на агенти често улесняват свързването на повече инструменти и изпълнението на по-автономни работни потоци. Това увеличава стойността на анализа на използването, приписването на ниво заявка и контрола на бюджета. В среда на шлюз екипите трябва да решат кои обаждания преминават през централен слой на правилата и кои остават в управляваната от AWS оркестрация.

Някои подробности остават специфични за акаунта. Независим коментар предполага, че допустимостта може да зависи от предишното използване на акаунта и че някои новоиздадени модели след прекъсване може да не станат достъпни чрез Classic. Тези точки трябва да бъдат проверени спрямо собствения акаунт на клиента в AWS и текущата документация на AWS за режим на поддръжка, преди да бъдат третирани като правила.

По-големият сигнал е достатъчно ясен: AWS не напуска агентите на Bedrock, но премества работата на новия агент от оригиналния интерфейс на агентите на Bedrock. За разработчиците и платформените екипи безопасното предположение е, че бъдещите инвестиции на AWS агенти ще се съсредоточат около AgentCore, докато Bedrock Agents Classic се превръща в проблем за съвместимостта за съществуващи внедрявания.