Kolejnym użytkownikiem Twojego oprogramowania będzie agent AI. Czy Twoja architektura jest na to gotowa?

Wyobraź sobie, że agent AI zajmuje się sporem klienta dotyczącym rozliczenia. Czyta reklamację, sprawdza historię konta i stwierdza, że należy przyznać klientowi zwrot środków. Wszystko w ciągu kilku sekund.

Imponujące. A teraz poproś go, żeby faktycznie przyznał zwrot.

Umowa z klientem znajduje się w innym systemie. Zasady zatwierdzania są ukryte w kodzie aplikacji. Narzędzie do rozliczeń wymaga, by ktoś klikał kolejne ekrany.

Agent rozumie, co trzeba zrobić, ale architektura nie pozwala mu dokończyć zadania.

Tego problemu spodziewam się w coraz większej liczbie przedsiębiorstw, gdy agentowa AI trafia do środowisk produkcyjnych. Dziwne jest jednak to, że przeszkoda uniemożliwiająca dokończenie zadania ma niewiele wspólnego z inteligencją agenta.

Przez lata modernizowaliśmy oprogramowanie dla przedsiębiorstw z myślą o ludziach, którzy z niego korzystają. Teraz musimy dostosować je do agentów, którzy będą coraz częściej nim zarządzać.

Interfejs użytkownika nigdy nie był całym produktem

Zastanówmy się, jak działa dziś oprogramowanie dla przedsiębiorstw. Ludzie otwierają aplikacje, przeglądają pulpity, podejmują decyzje i przenoszą pracę z jednego systemu do drugiego. Interfejs użytkownika to sposób, w jaki wchodzą w interakcję z firmą.

Agent niekoniecznie potrzebuje tych ekranów. Może pobierać informacje i inicjować działania za pośrednictwem interfejsów API, serwerów Model Context Protocol (MCP) i innych interfejsów programistycznych. To część przejścia na architekturę bez interfejsu użytkownika.

Architektura bez interfejsu użytkownika nie oznacza jednak, że aplikacja znika. Jej dane, reguły biznesowe, uprawnienia i wymogi zgodności nadal mają znaczenie. Powiedziałbym nawet, że mają jeszcze większe.

Przez lata dostawcy oprogramowania budowali przewagę konkurencyjną w oparciu o dopracowane interfejsy użytkownika, przyzwyczajenia użytkowników i koszty ponownego szkolenia pracowników. Ta przewaga słabnie, gdy agenci wykonują coraz więcej zadań bez otwierania interfejsu aplikacji. Na wartości zyskuje za to bazowy system ewidencji: wiarygodne dane, sprawdzona logika domenowa, nadzór operacyjny i transakcje, które można poddać audytowi.

Ma to również konsekwencje biznesowe: do 2030 roku nawet 234 mld USD wydatków na aplikacje dla przedsiębiorstw może być zagrożone zakłóceniami związanymi z agentową AI. To wydatki narażone na zakłócenia, a nie środki, które na pewno znikną. Gdy agenci przejmują zadania wykonywane dotąd przez ludzi za pośrednictwem pulpitów, rozliczanie za użytkownika może być coraz częściej zastępowane modelami opartymi na wykorzystaniu, wykonanych działaniach lub osiągniętych wynikach.

Dla dostawców oprogramowania to wyzwanie związane z modelem biznesowym. Dla przedsiębiorstw polegających na ich aplikacjach — wyzwanie architektoniczne.

Zmodernizowaliśmy poszczególne elementy, ale nie przepływ pracy

Większość przedsiębiorstw od lat prowadzi modernizację. Jeden zespół aktualizuje starsze aplikacje. Inny przenosi rozproszone dane na nowoczesną platformę. Trzeci tworzy integracje albo po prostu odświeża interfejs użytkownika.

Każdy projekt z osobna może zakończyć się sukcesem. Problemy zaczynają się, gdy agent musi wykonać przepływ pracy obejmujący wszystkie te elementy.

Możesz przekazać agentowi dokładne informacje o kliencie, ale jeśli aplikacja, która ma na ich podstawie działać, ukrywa kluczowe reguły w starszym kodzie, co stanie się dalej? Możesz też udostępnić przejrzyste API, podczas gdy dane, które za nim stoją, pozostaną niespójne. Agent może podjąć działanie, ale czy możesz zaufać jego decyzji?

W obu przypadkach zmodernizowaliśmy część technologii, ale nie samą pracę.

Agentowej AI nie obchodzi, który projekt modernizacyjny zakończył się sukcesem. Liczy się to, czy działa cały przepływ pracy.

Tak wygląda to w praktyce. Klient potrzebował przyspieszyć przygotowywanie wycen skomplikowanych napraw silników, przy których umowy określają, które części można naprawić, wymienić lub poddać regeneracji. Każda wycena wymagała kilku dni, a czasem nawet tygodni ręcznego przeszukiwania umów i instrukcji obsługi technicznej. Klient zmodernizował już platformę danych, ale wyceny nie powstawały szybciej, ponieważ wąskim gardłem nigdy nie były dane. Problemem były poszukiwania informacji. Przebudowaliśmy ten przepływ pracy w oparciu o zestaw agentów badawczych, skróciliśmy czas poszukiwania informacji o 80%, a wyceny zaczęły powstawać w zupełnie innym tempie.

Dlatego modernizacji aplikacji i danych nie można planować jako dwóch niezależnych strumieni prac. Architektura musi wspierać osiągnięcie pełnego celu biznesowego.

Samo API nie przygotuje systemu na agentów

Kusi, by uznać, że rozwiązanie jest proste: udostępnić punkty końcowe, połączyć agenta i gotowe.

Szkoda, że to nie takie proste.

Pobieranie informacji to jedno. Przyznanie zwrotu środków, aktualizacja dokumentacji finansowej czy zamówienie części zamiennej to zupełnie inna sprawa. Mówimy tu o wykonywaniu działań, a nie tylko o dostępie.

Właśnie w tym kontekście używam określenia interfejs kontroli agentów: chodzi o ograniczony, podlegający nadzorowi interfejs, za pośrednictwem którego agenci odczytują dane z systemów ewidencji i zapisują w nich informacje.

Interfejsy API i serwery MCP mogą udostępniać agentom narzędzia i dane. MCP nie egzekwuje jednak automatycznie reguł biznesowych ani nie określa, kto jest uprawniony do działania. Te mechanizmy trzeba nadal zaprojektować i wdrożyć w systemach bazowych oraz przepływach pracy.

Czy agent może pobierać wiarygodne dane? Czy reguły biznesowe są jasno określone i stosowane w sposób spójny? Czy może rekomendować działanie, ale wykonywać tylko te działania, do których jest uprawniony? Gdy coś pójdzie nie tak, czy możemy prześledzić działanie, obsłużyć wyjątek i, jeśli to możliwe, cofnąć jego skutki?

Nie są to problemy, które lepszy model rozwiąże sam z siebie. To kwestie dotyczące przepływu pracy, projektowania aplikacji, architektury danych, integracji i nadzoru. Trzeba na nie odpowiedzieć łącznie.

Zacznij od pracy, nie od technologii

Od czego więc zacząć?

Nie zaczynałbym od przekształcania każdej aplikacji w aplikację bez interfejsu użytkownika ani od udostępniania wszystkich dostępnych interfejsów API. Zacząłbym od jednego istotnego procesu biznesowego.

Prześledź go od początku do końca. W których systemach przechowywane są rekordy? Gdzie znajduje się logika biznesowa? Którym danym agent może ufać? Które decyzje wymagają zatwierdzenia przez człowieka? Co się stanie, jeśli system przestanie działać w połowie procesu? Jak utrzymywany jest nadzór?

Odkryjesz luki, które mają znaczenie. To twoja mapa drogowa modernizacji: skoordynowany portfel prac obejmujący aplikacje, dane, integracje i mechanizmy kontrolne, podporządkowany celowi biznesowemu, a nie oderwanym od siebie projektom technologicznym.

Mierz postępy odpowiednio do celu. Nie liczbą udostępnionych interfejsów API ani ilością przeniesionych danych, lecz tym, czy proces kończy się niezawodnie, jak rozwiązywane są sytuacje wyjątkowe i czy poprawiają się wyniki biznesowe.

Celem nie jest autonomia we wszystkich obszarach, lecz niezawodne i godne zaufania działanie, z ludzką oceną tam, gdzie jest potrzebna.

Prawdziwa zmiana wykracza poza architekturę bez interfejsu

Nie chodzi o to, że cieszy mnie perspektywa rezygnacji z pulpitów nawigacyjnych. Cieszy mnie to, co się stanie, gdy ludzie nie będą już musieli ręcznie przenosić pracy między niepołączonymi systemami, żeby wykonać swoje zadania.

Nie osiągniemy tego jednak, umieszczając agenta na architekturze, której nigdy nie zaprojektowano z myślą o jego obsłudze.

Oprogramowanie dla przedsiębiorstw nowej generacji będzie definiowane nie tylko przez to, co pozwala ludziom zobaczyć. Zdefiniuje je także to, co pozwala agentom robić — niezawodnie i odpowiedzialnie.