Wykrywanie w czasie działania w AWS Agent Registry przenosi konfigurację narzędzi poza proces budowania

AWS przedstawił szczegóły wykrywania w czasie działania w AWS Agent Registry 20 października, pokazując alternatywę dla zakodowania na stałe każdej możliwości w agencie. Podejście przenosi wybór narzędzi do działającej aplikacji, gdzie orkiestrator — agent koordynujący żądanie — przeszukuje katalog przed wyborem połączeń. Ta zmiana kwestionuje architekturę, którą wiele zespołów może wygodnie utrzymywać, dopóki ich katalog narzędzi nie zacznie rozrastać się między działami.

Kluczowa rywalizacja toczy się między konfiguracją na etapie budowania a wyborem w czasie działania. Konfiguracja na etapie budowania daje deweloperom wyraźny wykaz dostępnych możliwości. Wybór w czasie działania pozwala temu wykazowi zmieniać się niezależnie, ale sprawia, że wyniki wyszukiwania stają się częścią zachowania aplikacji. Pytanie brzmi, czy zespoły potrafią zachować przewidywalne wykonywanie, jednocześnie pozwalając możliwościom ewoluować poza cyklem wydawniczym orkiestratora.

Anthropic również promował ładowanie narzędzi na żądanie, dzięki czemu przykład AWS ma rozpoznawalny punkt odniesienia w branży. AWS przenosi dyskusję do obszaru zarządzania katalogami przedsiębiorstwa, gdzie obok kontekstu modelu znaczenie mają zatwierdzanie, własność, szczegóły połączeń i zasady dostępu. Dla deweloperów i nabywców korporacyjnych istotna zmiana ma charakter organizacyjny: dostępność narzędzia może zależeć od zarządzania katalogiem, a nie od kolejnego wdrożenia aplikacji.

Wykrywanie w czasie działania AWS Agent Registry zmienia moment wyboru połączeń

Przewodnik po wykrywaniu w czasie działania przedstawia pętlę Discover, Instantiate, Execute. Jego przykład łączy serwer do zarządzania zamówieniami z agentami ds. cen i obsługi klienta. Są to scenariusze demonstracyjne, a nie dowody z niezależnie ocenionego wdrożenia korporacyjnego.

Przykład wykorzystuje MCP, Model Context Protocol, który standaryzuje sposób udostępniania przez aplikacje narzędzi i kontekstu systemom AI. Wykorzystuje również A2A, protokół agent-agent do komunikacji między agentami. Połączenie obu w tej samej pętli wykrywania sprawia, że przykład jest istotny wykraczając poza katalog pojedynczych funkcji.

Zmiana architektoniczna polega na tym, że orkiestrator wybiera połączenia po otrzymaniu żądania, zamiast uwzględniać każde połączenie w swoim procesie budowania.

To rozróżnienie zasługuje na większą uwagę, niż sugeruje samo słowo „wykrywanie”. Katalog konsultowany przez deweloperów pomaga ludziom wybierać integracje podczas implementacji. Katalog konsultowany podczas wykonywania pomaga określić, z których integracji aplikacja może skorzystać w przypadku konkretnego żądania.

Zmienia to znaczenie dodawania możliwości. Przy jawnym łączeniu deweloperzy zwykle decydują, gdzie dana integracja należy, przed wydaniem orkiestratora. Przy wyborze w czasie działania zgodna możliwość może zostać uwzględniona za pośrednictwem katalogu. Aplikacja nadal potrzebuje zasad interpretowania i wykorzystywania tego, co wykryje.

To rozróżnienie zmienia również zakres kontroli recenzentów. Przegląd kodu źródłowego orkiestratora nie musi już ujawniać jego pełnego przyszłego zestawu możliwości. Rzetelny przegląd musi uwzględniać także katalog, uprawnienia do publikacji, praktyki zatwierdzania i oczekiwania dotyczące zgodności.

Rozważmy hipotetycznego asystenta przedsiębiorstwa, który już obsługuje pytania dotyczące zamówień. Zespół wsparcia wprowadza specjalistę do spraw roszczeń gwarancyjnych. Korzyścią architektoniczną byłoby umożliwienie wykrywania tego specjalisty bez dodawania kolejnej nazwanej integracji do aplikacji koordynującej.

Ta korzyść zależy od zgodności. Nowo opublikowana usługa z nieznaną metodą połączenia nadal wymaga pracy integracyjnej. Wykrywanie w czasie działania przesuwa część decyzji na później; nie sprawia, że każda możliwa usługa staje się natychmiast użyteczna.

Ważną granicą jest zatem obsługiwany przez aplikację kontrakt połączenia. Deweloperzy mogą dopuścić nowe możliwości w ramach tego kontraktu, zachowując kontrolę nad protokołami, metodami dostępu i polityką wykonywania. To węższa i bardziej użyteczna obietnica niż uniwersalna integracja typu plug-and-play.

Dla czytelników oceniających wykrywanie w czasie działania AWS Agent Registry pierwsze pytanie powinno dotyczyć tego, które zmiany architektura faktycznie rozdziela. Dodanie zgodnej możliwości różni się od zmiany zasad, na których możliwości działają.

Zespoły platformowe dziedziczą problem publikowania katalogu

AWS opisuje swój zarządzany katalog możliwości jako usługę wykrywania z przepływami publikacji i zatwierdzania. Dokumentacja rozróżnia wydawców, kuratorów i konsumentów. Te role uwidaczniają ważną konsekwencję organizacyjną: wykrywanie możliwości wymaga ciągłej odpowiedzialności.

Wybór w czasie działania przenosi pracę koordynacyjną z pojedynczych wydań integracji do publikowania, przeglądu i utrzymania katalogu.

Inżynierowie platformowi odczuwają najbardziej bezpośrednią presję. Przy konfiguracji na etapie budowania repozytorium aplikacji zapewnia oczywisty punkt koordynacji. Przy zmieniającym się katalogu potrzebują innego sposobu określania, które możliwości do siebie należą i które zmiany wymagają szerszego przeglądu.

Właściciele możliwości stają przed innym obowiązkiem. Działający endpoint nie wystarcza, jeśli konsumenci nie potrafią zrozumieć, kiedy go wybrać. Właściciel powinien opisać zamierzone zadanie, istotne wyłączenia, oczekiwane dane wejściowe i ograniczenia operacyjne wystarczająco jasno, aby inny zespół mógł ocenić połączenie.

Przypomina to utrzymywanie współdzielonego interfejsu między zespołami. Opis niesie znaczenie, natomiast kontrakt połączenia określa, co oprogramowanie faktycznie może zrobić. Słabość w którymkolwiek z tych obszarów może wywołać zamieszanie, którego agent koordynujący nie zdoła niezawodnie rozstrzygnąć.

Zatwierdzanie również wymaga konkretnego celu. Organizacja może przed dopuszczeniem możliwości oceniać poziom bezpieczeństwa, własność, zobowiązania wsparcia lub zgodność. Te kontrole odpowiadają na różne pytania, więc etykieta zatwierdzenia nie powinna stać się skrótem dla każdego możliwego zapewnienia.

Zatwierdzona usługa może nadal nie nadawać się do konkretnego żądania użytkownika. Produkcyjne narzędzie raportowe może być związane z tematem, lecz niedostępne dla pracownika składającego żądanie. Możliwość wsparcia może wyjaśniać politykę, nie mając uprawnienia do zmiany zamówienia.

Dla nabywców korporacyjnych sugeruje to bardziej szczegółową dyskusję zakupową. Należy pytać, kto utrzymuje rekordy katalogu, kto zatwierdza zmiany i kto reaguje, gdy opublikowana możliwość staje się niedostępna. Zarządzana usługa wykrywania nie może samodzielnie przypisać tych wewnętrznych obowiązków.

To samo rozróżnienie dotyczy wiedzy organizacyjnej. Zespoły potrzebują wspólnego miejsca na decyzje, wyjątki i procedury operacyjne obok rekordów czytelnych dla maszyn. Przeszukiwalna baza wiedzy odpowiada na tę potrzebę dokumentacyjną, podczas gdy rejestr służy wykrywaniu w czasie działania.

Presja nie polega po prostu na centralizowaniu wszystkiego. Zbyt szeroki katalog może stać się trudny do zarządzania, a wąsko odizolowane katalogi mogą zachować problemy koordynacyjne, które wykrywanie powinno ograniczać. Zespoły powinny wyznaczać granice wokół rzeczywistych wzorców własności i konsumpcji.

Użyteczną miarą postępu byłoby ograniczenie zależności między wydaniami. Jeśli każda nowa możliwość nadal wymaga edycji orkiestratora, skoordynowanych zatwierdzeń i ręcznych aktualizacji konsumentów, organizacja zyskała katalog bez osiągnięcia znacznej niezależności architektonicznej.

Z drugiej strony niezależne publikowanie nie powinno oznaczać niewidocznej zmiany zachowania. Konsumenci potrzebują sposobu, by zrozumieć, które możliwości znalazły się w zasięgu ich aplikacji. Niezależność operacyjna działa najlepiej, gdy własność i komunikacja zmian pozostają jawne.

Pętla oddziela wyszukiwanie, łączenie i działanie

Mechanizm wykrywania w czasie działania AWS Agent Registry staje się jaśniejszy, gdy każdy etap traktuje się jako odrębną decyzję. Znalezienie odpowiedniej możliwości, ustanowienie połączenia i decyzja o podjęciu działania są zadaniami powiązanymi. Wymagają różnych dowodów i różnych mechanizmów kontroli.

AWS dokumentuje hybrydowe wyszukiwanie rejestru, które łączy dopasowanie semantyczne, oparte na znaczeniu, z dopasowaniem słów kluczowych. Na trafność wpływają nazwy, opisy i deskryptory protokołów. Deskryptor to ustrukturyzowane metadane opisujące możliwość i szczegóły jej połączenia.

Dokumentacja wyszukiwania stwierdza również, że wykrywalne wyniki są ograniczone do zatwierdzonych rekordów. Indeksowanie wyszukiwania jest ostatecznie spójne, co oznacza, że zatwierdzona zmiana nie staje się od razu widoczna wszędzie. Te właściwości sprawiają, że wykrywanie jest zarówno mechanizmem zarządzania, jak i zmieniającą się zależnością środowiska wykonawczego.

Wyszukiwanie zawęża zbiór kandydatów; aplikacja nadal musi ustanowić prawidłowe połączenie i wybrać odpowiednie działanie.

W przykładzie AWS wykrywanie zwraca metadane połączenia bez poświadczeń wywołania, czyli materiału uwierzytelniającego niezbędnego do wywołania możliwości. Aplikacja pozyskuje poświadczenia osobno. Następnie składa tymczasowego wewnętrznego agenta z wykrytych możliwości i zwalnia jego klientów po obsłużeniu żądania.

To rozdzielenie ma znaczenie, ponieważ trafność nie ustanawia uprawnienia. Usługa może doskonale pasować do żądania, pozostając niedostępna dla aplikacji. Odwrotnie, aplikacja może mieć ważne poświadczenia do usługi, która nie powinna obsługiwać bieżącego zadania.

Etap instancjacji, w którym aplikacja konstruuje odpowiedniego klienta, należy zatem rozumieć jako granicę integracji. Oprogramowanie musi zinterpretować deskryptor, rozpoznać typ połączenia i zastosować ustaloną ścieżkę uwierzytelniania. Wyniki wyszukiwania nie mogą zastąpić tych kontroli.

Etap wykonywania wprowadza kolejną granicę. Wybranie możliwości wsparcia nie rozstrzyga, czy aplikacja powinna pobrać informacje, zaproponować zmianę czy tę zmianę wykonać. Organizacje powinny definiować te rozróżnienia w polityce wykonywania, zamiast oczekiwać, że trafność wyszukiwania je wyrazi.

Hipotetyczne żądanie zwrotu pieniędzy ilustruje tę różnicę. Wykrywanie może wskazać specjalistę ds. polityki oraz usługę informacji o zamówieniach. Aplikacja nadal musiałaby ustalić tożsamość klienta, pobrać właściwą transakcję i odróżnić poradę dotyczącą kwalifikowalności od upoważnienia do realizacji zwrotu.

Ta architektura jest atrakcyjna, ponieważ może zawęzić zakres tego, co model widzi dla danego żądania. Tworzy jednak także zależność wcześniejszego etapu: właściwa możliwość musi trafić do zbioru kandydatów, zanim model będzie mógł ją wybrać. Zdolny model nie może wybrać integracji, której nigdy nie otrzyma.

Sugeruje to osobną ocenę etapów. Brakujący kandydat to problem wykrywania. Odrzucone połączenie to problem uwierzytelniania lub zgodności. Nieodpowiednie działanie po pomyślnym połączeniu to problem wykonywania. Łączenie ich w jedną kategorię awarii utrudnia ukierunkowanie ulepszeń.

Pętla wyjaśnia także, gdzie buforowanie, czyli ponowne wykorzystanie wcześniejszych wyników, staje się wyborem polityki. Ponowne wykorzystanie wyników wykrywania może ograniczyć powtarzalną pracę, ale zespoły powinny zdecydować, jak świeżość danych i wycofanie możliwości wpływają na ten wybór. Odpowiednia równowaga zależy od konsekwencji działania aplikacji.

Wyszukiwanie narzędzi Anthropic pokazuje szerszą zmianę architektoniczną

AWS zajmuje się problemem wykraczającym poza zarządzanie katalogiem chmurowym. Anthropic opisuje wyszukiwanie narzędzi na żądanie, które polega na odraczaniu definicji narzędzi do momentu, gdy stają się istotne. Wspólna idea polega na unikaniu umieszczania pełnej biblioteki możliwości w kontekście modelu, czyli informacji dostępnych podczas generowania.

Opublikowane przez Anthropic podejście oznacza wybrane definicje do odroczonego ładowania. Claude może następnie wyszukiwać odpowiednie narzędzia i otrzymywać ich definicje w razie potrzeby. To przydatny kontekst do zrozumienia kierunku AWS, bez traktowania tych podejść jako wymiennych produktów.

Wspólną zasadą projektową jest selektywna ekspozycja, podczas gdy odpowiedzialność za integrację pozostaje specyficzna dla każdego systemu.

To porównanie pomaga oddzielić podstawowy wybór architektoniczny od pozycjonowania dostawców. Zespół może uznać, że ładowanie każdego narzędzia z góry jest marnotrawstwem, a jednocześnie nadal preferować jawne połączenia dla najważniejszych procesów. Selektywna ekspozycja nie wymaga, by każda decyzja aplikacji była dynamiczna.

Porównanie zapobiega też przesadnemu twierdzeniu o nowości. Odkrywanie w czasie działania jest częścią szerszego wysiłku na rzecz zarządzania rosnącymi bibliotekami możliwości. Przykład AWS wnosi konkretny wzorzec przedsiębiorstwowy, zamiast sugerować, że branża dopiero teraz odkryła ten problem.

Dla zespołu platformowego istotne pytanie brzmi: gdzie powinna należeć decyzja dotycząca katalogu. Niektóre aplikacje potrzebują centralnie zarządzanego katalogu obejmującego możliwości utrzymywane oddzielnie. Inne przede wszystkim muszą zapobiec przytłoczeniu dostępnego kontekstu modelu przez istniejącą bibliotekę narzędzi.

Te wymagania częściowo się pokrywają, ale nie są tożsame. Mniejszy prompt nie zapewnia automatycznie procesu zatwierdzania. Zarządzany katalog nie określa automatycznie najlepszej strategii wyboru dla konkretnego modelu lub zadania.

Najmocniejszy argument za jawnym łączeniem również zasługuje na uczciwe rozważenie. Gdy proces ma stabilną sekwencję i ograniczony zestaw możliwości, deweloperzy mogą bezpośrednio sprawdzić zamierzone połączenia. Pobieranie w czasie działania musiałoby zapewnić wyraźną korzyść, by uzasadnić kolejny punkt decyzyjny.

Hipotetyczny zaplanowany proces uzgadniania dobrze ilustruje taki przypadek. Jeśli aplikacja zawsze pobiera rekordy, porównuje je i zapisuje zatwierdzony raport, wyszukiwanie tych samych możliwości za każdym razem może wnosić niewielką wartość. Sama sekwencja już wyraża wymaganie biznesowe.

Asystent ogólnego przeznaczenia stoi przed inną sytuacją. Jego zapytania mogą obejmować niepowiązane zadania, a dostępne możliwości mogą należeć do niezależnie zmieniających się zespołów. Wybór w czasie działania staje się bardziej przekonujący, gdy utrzymywanie kompletnego, jawnego spisu generuje powtarzającą się pracę koordynacyjną.

Sugeruje to praktyczną zasadę oceny: porównuj architektury względem tych samych zadań i scenariuszy zmian. Uwzględnij rutynowe wykonanie, dodawanie możliwości, awarie i odzyskiwanie sprawności. Przekonująca demonstracja powinna pokazać, gdzie dynamiczny wybór pomaga, zamiast zakładać, że elastyczność jest z natury wartościowa.

Nabywcy powinni też unikać oceniania architektury wyłącznie na podstawie wielkości katalogu. Istotniejsze pytanie brzmi, czy użyteczne możliwości pozostają wykrywalne i są poprawnie stosowane wraz ze zmianami katalogu. Imponujący spis ma ograniczoną wartość, gdy zwykłe zapytania nadal wymagają ręcznego kierowania.

Jakość odkrywania wymaga własnych dowodów produkcyjnych

Najważniejsza niepewność dotyczy zachowania poza demonstracją. Prezentacja AWS ilustruje pętlę, ale nie ustala, jak będzie działał konkretny katalog przedsiębiorstwa. Twierdzenia dotyczące produkcji powinny opierać się na reprezentatywnej ocenie, a nie na diagramach architektury.

API odkrywania zwraca pasujące metadane uporządkowane według trafności i obsługuje filtrowanie strukturalne. Dzięki temu zestaw kandydatów jest obserwowalnym wynikiem działania aplikacji. Zespoły mogą sprawdzić, co zwróciło odkrywanie, zanim zaczną analizować, co model zrobił później.

Ocena produkcyjna powinna mierzyć, czy odkrywanie dostarcza niezbędne możliwości, w tym dla zapytań, w których nie należy używać żadnej możliwości.

Zacznij od rozróżnienia wyników wiarygodnych i wystarczających. Specjalista ds. rozliczeń może brzmieć adekwatnie w pytaniu o zamówienie, lecz nie posiadać informacji o wysyłce potrzebnych do udzielenia odpowiedzi. Osoby oceniające powinny wskazać możliwości wymagane do ukończenia zadania, zamiast akceptować dowolny wynik z powiązanym opisem.

Niejednoznaczne zapytania zasługują na szczególną uwagę. Użytkownik proszący o „naprawienie mojego zamówienia” może mieć na myśli zmianę adresu, korektę opłaty albo zgłoszenie uszkodzonych towarów. Bezpieczna aplikacja powinna rozpoznać, kiedy konieczne jest doprecyzowanie, zamiast uznawać silne dopasowanie wyszukiwania za rozstrzygnięty zamiar.

Przypadki negatywne są równie ważne. Niektóre zapytania nie powinny tworzyć żadnego połączenia, ponieważ w katalogu brakuje właściwej możliwości. Inne powinny zostać zatrzymane, ponieważ użytkownik nie ma uprawnień albo żądane działanie wykracza poza zakres aplikacji.

Rozrost katalogu powinien stać się jawnym warunkiem testowym. Zespoły mogą powtarzać tę samą ocenę po dodaniu nakładających się możliwości, zmianie opisów lub wycofaniu usług. Ujawniłoby to, czy zwykłe zmiany konserwacyjne inaczej kierują zapytania, nawet gdy kod źródłowy orkiestratora pozostaje niezmieniony.

Jakość opisów również powinna być oceniana bez zachęcania do języka promocyjnego. Wydawcy mają motywację, aby ich możliwości były wykrywalne. Recenzenci powinni przedkładać dokładny zakres i wyłączenia ponad opisy twierdzące, że usługa obsługuje każde sąsiednie zadanie.

Rozdzielenie odkrywania i uwierzytelniania tworzy użyteczne przypadki awarii do przetestowania. Odpowiednia możliwość może mieć wygasłe poświadczenia, niedostępny punkt końcowy lub niezgodną odpowiedź. Aplikacja powinna wyjaśnić ograniczenie, nie zastępując po cichu działania mniej odpowiednim.

Odzyskiwanie sprawności zasługuje na równie dokładną analizę. Ponowienie wyszukiwania informacji różni się od ponowienia żądania, które zmienia rekordy biznesowe. Zespoły powinny ustalić, czy operację można bezpiecznie powtórzyć, zanim zezwolą automatycznemu odzyskiwaniu na jej ponowne wykonanie.

Dowody operacyjne powinny łączyć zapytanie z wybraną możliwością i końcowym wynikiem. W przeciwnym razie płynna odpowiedź może ukryć nieudane wyszukiwanie, niezamierzony mechanizm zastępczy lub działanie, które nigdy nie zostało ukończone. Recenzenci potrzebują dowodów dotyczących wykonania, a także jakości odpowiedzi.

Pojawia się też pytanie o odpowiedzialność, gdy ocena kończy się niepowodzeniem. Odpowiedzialną stroną może być wydawca możliwości, kurator katalogu lub zespół aplikacyjny. Wczesne określenie tych obowiązków ułatwiłoby obsługę wyboru w czasie działania między działami.

W przypadku odkrywania w czasie działania AWS Agent Registry obietnicą, którą można obronić, jest elastyczność architektoniczna w określonych granicach. Lepsza dokładność, niższe koszty operacyjne i łatwiejsze utrzymanie pozostają wynikami, które każda implementacja powinna potwierdzić.

Obserwuj migrację, wzrost katalogu i niezależne publikowanie

Bezpośredni punkt obserwacji jest konkretny. Przewodnik migracji rejestru AWS podaje, że dedykowana przestrzeń nazw agent-registry została uruchomiona 6 sierpnia 2026 r. Przestrzeń nazw to identyfikator usługi używany w interfejsach i konfiguracji. Obsługa podglądowej przestrzeni nazw rejestru bedrock-agentcore kończy się 30 października.

Przewodnik opisuje zmiany dotyczące punktów końcowych usługi, uprawnień, klientów, identyfikatorów zasobów i powiązanej konfiguracji. Podaje, że pozostałe oferty AgentCore pozostają niezmienione przez tę zmianę przestrzeni nazw rejestru. Dla obecnych użytkowników wersji podglądowej migracja jest zatem krótkoterminowym zagadnieniem operacyjnym.

Kolejne dowody powinny pokazać ukończoną migrację, stabilne odkrywanie przy wzroście katalogu oraz dodawanie możliwości bez niepotrzebnych zmian w orkiestratorze.

Po pierwsze, warto obserwować, czy użytkownicy wersji podglądowej kończą migrację i weryfikują ścieżki odkrywania. Po udanej aktualizacji konfiguracji powinny pojawić się dowody, że docelowa aplikacja nadal potrafi znajdować i wywoływać zatwierdzone możliwości. Wzmocniłoby to zaufanie do ciągłości operacyjnej.

Niepowodzenia migracji same w sobie nie podważałyby wyboru w czasie działania. Ujawniłyby jednak wymagania utrzymaniowe związane z poleganiem na zmieniającym się zarządzanym interfejsie. Zespoły powinny rozróżniać problem migracji usługi od słabości własnego projektu wyszukiwania lub wykonania.

Po drugie, warto obserwować oceny, które rozszerzają katalog przy stałym zbiorze zapytań. Użytecznym sygnałem byłoby dalsze odkrywanie niezbędnych możliwości mimo większego nakładania się funkcji i niejednoznaczności. Raportowanie wyłącznie udanych przykładów pozostawiłoby nierozstrzygnięte centralne pytanie o skalowanie.

Dowody pogarszającego się wyboru osłabiłyby argument za szerokim wdrożeniem bez dodatkowych mechanizmów kontroli. Sugerowałyby, że standardy opisów, granice katalogu, filtrowanie lub praktyki oceny wymagają rewizji. Rozszerzanie katalogu należy traktować jako zmianę zachowania wartą testowania.

Po trzecie, warto obserwować, czy niezależne zespoły mogą publikować zgodne możliwości bez rutynowych zmian w orkiestratorze. To korzyść organizacyjna wynikająca z przeniesienia połączeń poza procesy budowania. Najmocniejsze dowody obejmowałyby wdrożenie, konfigurację uwierzytelniania, własność i wycofanie, a nie tylko publikację.

Jeśli dodawanie możliwości wielokrotnie wymaga specjalnej obsługi w aplikacji koordynującej, architektura zaoferuje mniej niezależności, niż sugeruje jej diagram. Jeśli zespoły mogą dodawać możliwości przy zachowaniu przewidywalnego zachowania, odkrywanie w czasie działania zapewni mierzalną zmianę w koordynacji wydań.

Te sygnały są ważniejsze niż ogólne prognozy dotyczące autonomicznych agentów. Łączą projekt z obserwowalnymi wynikami inżynieryjnymi: ciągłością podczas migracji, niezawodnym wyborem w okresie wzrostu oraz ograniczoną koordynacją przy zmianach możliwości.

Do wstępnej oceny wybierz ograniczony proces, w którym odpowiedzialność za możliwości już obejmuje wiele zespołów. Ustal obecne zależności wydaniowe i zachowanie w przypadku awarii przed wprowadzeniem odkrywania w czasie działania AWS Agent Registry. Zachowaj jawnie zdefiniowane reprezentatywne zapytania, oczekiwane możliwości i niedopuszczalne działania. Porównaj zwykłe zapytania z niejednoznacznymi pytaniami, brakującymi usługami i odmową dostępu. Następnie wprowadź zgodną możliwość i sprawdź, co faktycznie zmienia się w publikowaniu, zatwierdzaniu, uwierzytelnianiu, odkrywaniu i wykonaniu. Zachowaj ustalenia wraz z decyzjami technicznymi, aby przyszli opiekunowie systemu rozumieli jego granice. Przed rozszerzeniem katalogu zapytaj, czy aplikacja stała się łatwiejsza do rozbudowy, pozostając jednocześnie zrozumiała dla osób odpowiedzialnych za jej zachowanie.