Co to jest stos AI native? Poradnik dla firm

Stos AI native to zestaw warstw, z których buduje się aplikację z modelem AI w środku procesu, a nie obok niego: interfejs, protokół między agentem a ekranem, backend agenta oraz modele i narzędzia. Taka aplikacja pokazuje odpowiedź na bieżąco, wywołuje narzędzia, zatrzymuje się po zatwierdzenie człowieka i trzyma stan agenta widoczny obok danych. Gotowy czat, np. Open WebUI, wystarcza do rozmowy z modelami i dokumentami. Własny interfejs ma sens, gdy agent ma zmieniać dane w Waszych systemach, a człowiek musi widzieć, co zatwierdza.

Poradnik jest dla lidera IT, architekta i zarządu firmy od 50 osób, która z pilotażu czatu przechodzi do aplikacji z agentem. Czym jest sam agent, opisuje poradnik „Co to jest agent AI”, a jak agent łączy się z narzędziami — poradnik o MCP i protokołach agentów. Na końcu jest mapa wszystkich wpisów o stosie AI native na blogu. Stan wszystkich informacji: 6.10.2026.

Aplikacja AI native, czyli AI w środku procesu

Większość firm zaczyna od okna czatu: pracownik pyta, model odpowiada, a reszta pracy dzieje się jak dawniej. To asystent obok procesu. Aplikacja AI native jest projektowana od początku wokół tego, że część kroków wykonuje model. Różnicę widać w czterech cechach.

Cecha	Co widzi użytkownik	Czego wymaga od stosu
Strumieniowanie	odpowiedź i kolejne kroki pojawiają się na bieżąco, nie po minucie ciszy	transportu zdarzeń (np. SSE, WebSocket) i interfejsu, który składa je w całość
Narzędzia	agent czyta i zapisuje dane w CRM, ERP, bazie zgłoszeń	backendu agenta z listą narzędzi, uprawnieniami i dziennikiem
Człowiek w pętli	przed skutkiem pojawia się karta „zatwierdź / popraw / odrzuć”	przerwania w przebiegu agenta i wznowienia po decyzji
Stan agenta w interfejsie	widać, nad czym agent pracuje, co już zmienił i co tylko proponuje	wspólnego stanu agenta i ekranu, synchronizowanego w obie strony

Agent bez strumieniowania przypomina kolegę, który mówi „już kończę” i znika na kwadrans. Użytkownik, który przez długą chwilę nie wie, co robi agent, zamyka kartę albo — gorzej — klika „zatwierdź” bez czytania.

Ta sama logika obowiązuje w gotowych platformach vendorów. Microsoft opisuje aplikacje AI native na Azure, a wpis Aplikacje AI native w Microsoft Azure pokazuje, które usługi za tym stoją. Ten poradnik dotyczy otwartego stosu, który firma składa i utrzymuje sama albo z partnerem.

Cztery warstwy stosu AI native

Najprościej czytać stos od ekranu w dół. Każda warstwa ma inne pytanie do rozstrzygnięcia i inną osobę, która za nie odpowiada.

1. Interfejs. To, co widzi człowiek: wątek rozmowy, karty zatwierdzeń, tabela z danymi, formularz z propozycją agenta. Zwykle React albo inny framework webowy plus biblioteka komponentów (shadcn/ui, Radix UI, Base UI) i design system. Pytanie: czy użytkownik odróżnia propozycję od wykonanego działania?
2. Protokół agent–interfejs. Kontrakt, którym agent przesyła na ekran tekst, wywołania narzędzi, stan i prośby o decyzję. Otwartym standardem jest tu AG-UI. Pytanie: czy można wymienić backend agenta bez przepisywania ekranu?
3. Backend agenta. Framework, który prowadzi przebieg: LangGraph, Microsoft Agent Framework, Mastra, własny kod na Vercel AI SDK. Tu żyją reguły, pamięć, limity i dziennik. Pytanie: gdzie zapisuje się, co agent zrobił i kto to zatwierdził?
4. Modele i narzędzia. Model językowy (w chmurze vendora albo własny) oraz narzędzia i dane firmy, podłączone np. przez MCP. Pytanie: do czego agent ma dostęp i z czyimi uprawnieniami?

Pod tymi warstwami działa jeszcze zaplecze wytwarzania: TypeScript i Zod pilnują kontraktów danych, Vitest i Playwright testują ścieżkę użytkownik–agent, a pnpm, Nx czy Turborepo porządkują repozytorium. To ono decyduje, czy aplikację da się bezpiecznie zmieniać co tydzień. Szerzej o tej części piszę w poradniku o AI SDLC, a o całej infrastrukturze otwartego stosu — w poradniku „Co to jest AI OS”.

AG-UI: kontrakt między agentem a ekranem

AG-UI to według dokumentacji otwarty, lekki protokół oparty na zdarzeniach, który standaryzuje połączenie agentów z aplikacjami użytkownika. Działa nad HTTP i WebSocket. Projekt powstał ze współpracy CopilotKit z LangChain i CrewAI, a dokumentacja wymienia integracje m.in. z LangGraph, CrewAI, Microsoft Agent Framework, Google ADK, AWS Strands Agents, Mastra, Pydantic AI i Claude Agent SDK.

Protokół opisuje kategorie zdarzeń: cykl życia przebiegu (start, kroki, koniec, błąd), wiadomości tekstowe w częściach, wywołania narzędzi z argumentami i wynikiem, migawki i zmiany stanu, a także aktywność, subagentów i rozumowanie. Dla firmy najważniejsze jest przerwanie: przebieg kończy się wynikiem „interrupt”, interfejs pokazuje decyzję do podjęcia, a agent rusza dalej dopiero po odpowiedzi człowieka.

Stan na 6.10.2026: repozytorium ag-ui-protocol/ag-ui ma licencję MIT, pakiety @ag-ui/core i @ag-ui/client są w wersji 1.0.2 (5.10.2026), a nowe wydania pojawiają się niemal codziennie. W Microsoft Agent Framework integracja AG-UI ma status preview.

Wniosek dla architektury: AG-UI nie zastępuje MCP ani A2A. MCP łączy agenta z narzędziami, A2A z innym agentem, AG-UI z człowiekiem. Żaden z nich nie decyduje, co agentowi wolno — to wciąż sprawdza serwer.

Biblioteki interfejsu: z czego składa się ekran

Nad protokołem są biblioteki, które oszczędzają zespołowi pisania tych samych elementów: wątku rozmowy, strumieniowania, kart narzędzi i zatwierdzeń. Trzy najczęściej spotykane w otwartym stosie (stan na 6.10.2026):

Projekt	Rola	Licencja	Wersja (data)
CopilotKit	agent osadzony w aplikacji: generatywne UI, wspólny stan, człowiek w pętli; React, Angular, Vue, React Native; zbudowany na AG-UI	MIT	1.77.0 (2.10.2026)
assistant-ui	komponenty czatu dla Reacta: wątek, strumieniowanie, wywołania narzędzi jako komponenty, karty zatwierdzeń, dostępność	MIT	@assistant-ui/react 0.15.25 (6.10.2026)
Vercel AI SDK	zestaw TypeScript: jedno API do wielu vendorów modeli, narzędzia, agenci (Core) oraz hooki czatu (UI) dla Reacta, Next.js, Vue i Svelte	Apache 2.0	ai 7.0.128 (5.10.2026)

Każdy z nich rozwiązuje inną część. CopilotKit pasuje, gdy agent ma działać w istniejącym ekranie procesu, np. obok formularza zamówienia. assistant-ui daje dopracowany wątek rozmowy, który zespół składa z prymitywów. AI SDK łączy backend z modelami i dostarcza hooki, na których można zbudować własny interfejs. Wersje poniżej 1.0 (assistant-ui) i tempo wydań (CopilotKit wydał kilka wersji w tydzień) oznaczają, że aktualizacje trzeba zaplanować, a nie robić „przy okazji”.

Niżej leży zwykły frontend: React (19.3.0 z 9.09.2026), Next.js (16.3.8 z 30.09.2026), komponenty Radix UI, Base UI i shadcn/ui, Tailwind CSS, TanStack Table do tabel z danymi agenta. Wpisy w mapie poniżej opisują każdy z nich w tym samym układzie: rola, alternatywy, ograniczenia i próba w projekcie. Design system (Material, Fluent, Carbon) warto wybrać przed pierwszym ekranem, bo stany błędu i niepewności AI muszą wyglądać spójnie w całej aplikacji.

Gotowy czat czy własny interfejs?

Open WebUI to gotowa, samodzielnie hostowana aplikacja czatu. Według dokumentacji działa offline, łączy się z Ollama i API zgodnymi z OpenAI, ma RAG, role z grupami, SSO, LDAP i SCIM oraz obsługę narzędzi i serwerów MCP. Dla wielu firm to najkrótsza droga do wspólnego, kontrolowanego czatu z modelami i dokumentami.

Jest jedno zastrzeżenie, które firmy od 50 osób powinny przeczytać przed wdrożeniem. Licencja Open WebUI (wersja 0.11.4, stan na 6.10.2026) zabrania zmiany lub usunięcia brandingu „Open WebUI”, chyba że wdrożenie ma nie więcej niż 50 użytkowników końcowych w kroczącym okresie 30 dni, jest pisemna zgoda autora albo licencja enterprise. Jeśli planujecie firmowego asystenta z własnym logo, warunki licencji oceni prawnik.

Własny interfejs kosztuje więcej pracy, ale jest konieczny, gdy agent działa w procesie, a nie w rozmowie. Proponuję cztery pytania (uproszczenie autora):

1. Czy agent ma zmieniać dane w systemach firmy? Jeśli tylko odpowiada i streszcza — gotowy czat zwykle wystarczy.
2. Czy człowiek zatwierdza działanie, widząc dane przed i po? Jeśli tak — potrzebny jest ekran procesu z kartą zatwierdzenia, nie okno czatu.
3. Czy wynik ma trafić do istniejącej aplikacji (CRM, panel zamówień)? Jeśli tak — osadźcie agenta w tej aplikacji (np. CopilotKit, assistant-ui).
4. Czy branding, licencja i liczba użytkowników pasują do gotowego produktu? Jeśli nie — własny interfejs na bibliotekach z licencją MIT lub Apache 2.0.

Rozsądna ścieżka bywa dwuetapowa: gotowy czat dla całej firmy do pracy z wiedzą i osobna aplikacja z agentem dla jednego procesu, w którym liczy się zapis w systemie.

Ryzyka: bezpieczeństwo, koszt i niepewność

Bezpieczeństwo. Interfejs jest ostatnim miejscem, w którym człowiek może zatrzymać błąd, ale nie miejscem, w którym działa kontrola dostępu. OWASP Top 10 for LLM Applications 2025 wskazuje trzy ryzyka szczególnie ważne dla tej warstwy: wstrzyknięcie poleceń (LLM01) — także przez treść dokumentu czy strony, którą agent czyta; niewłaściwą obsługę wyniku modelu (LLM05) — np. wyświetlenie wygenerowanego HTML bez oczyszczenia; oraz nadmierną sprawczość (LLM06) — agenta z szerszymi uprawnieniami, niż wymaga zadanie. Ukrycie przycisku w interfejsie nie odbiera agentowi uprawnienia. Sprawdzenie musi być po stronie serwera.

Koszt. Biblioteki są open source, ale aplikacja nie. Płacicie za pracę zespołu, utrzymanie przy częstych wydaniach, hosting i zużycie modeli. OWASP opisuje osobno nieograniczone zużycie zasobów (LLM10): agent w pętli albo użytkownik wklejający całe repozytorium potrafią szybko zużyć budżet. Limity na rozmowę, użytkownika i dzień ustawcie przed pierwszym pilotażem.

UX niepewności. Model mówi tym samym pewnym tonem, gdy ma rację i gdy jej nie ma. Wytyczne Microsoft Research z CHI 2019 (18 zasad interakcji człowieka z AI) zalecają m.in. jasno pokazać, co system potrafi i jak dobrze, oraz umożliwić szybką korektę. W aplikacji z agentem oznacza to: propozycja wygląda inaczej niż wykonana zmiana, źródła są widoczne, a „odrzuć” jest tak samo łatwe jak „zatwierdź”.

Dojrzałość projektów. Część stosu zmienia się co tydzień, a niektóre elementy są jeszcze przed wersją 1.0 albo w fazie kandydata do wydania (Cordis 4.0.0-rc.10 z 8.09.2026). Przypnijcie wersje, prowadźcie rejestr zależności i miejcie test, który po aktualizacji sprawdzi całą ścieżkę: od pytania użytkownika do zatwierdzonego zapisu.

Jak zacząć: jeden proces, jeden ekran, jedna próba

1. Wybierzcie proces, w którym agent ma coś zmienić, np. przygotowanie korekty zamówienia do zatwierdzenia. Zapiszcie, co agent może zrobić sam, a co zatwierdza człowiek.
2. Zdecydujcie: gotowy czat czy własny ekran — według czterech pytań z karty powyżej.
3. Narysujcie ekran zatwierdzenia przed kodem: dane przed i po, źródła, przyciski zatwierdź, popraw, odrzuć.
4. Zbudujcie cienką ścieżkę przez wszystkie warstwy: interfejs, AG-UI albo strumień AI SDK, backend agenta z jednym narzędziem i dziennikiem.
5. Przetestujcie awarie: zerwanie połączenia w połowie wywołania narzędzia, odmowę użytkownika, przekroczenie limitu kosztu. Interfejs nie może pokazać propozycji jako wykonanej zmiany.
6. Zapiszcie decyzję architektoniczną: wybrane biblioteki i wersje, licencje, właściciel utrzymania, warunek wymiany.

Taką aplikację najlepiej buduje inżynier, który rozumie zarówno proces klienta, jak i warstwy stosu. Tego uczy kurs Forward Deployed AI Engineer w Akademii — od rozmowy z właścicielem procesu po odbiór działającej aplikacji. Niezależnie od vendora i partnera.

Mapa wpisów o stosie AI native

Wszystkie wpisy na blogu o warstwach aplikacji AI native, pogrupowane od agenta do zaplecza wytwarzania.

A. Agent na ekranie: protokół i gotowe interfejsy

• AG-UI: otwarty kontrakt między agentem a ekranem — zdarzenia między agentem a interfejsem.
• CopilotKit: interfejs człowiek–agent w aplikacji — agent osadzony w ekranie procesu.
• Open WebUI: własny interfejs do modeli AI — gotowy, samodzielnie hostowany czat.
• Cordis: kompozycja usług dla agentów AI — składanie usług i pluginów z kontrolą zakresu.
• Aplikacje AI native w Microsoft Azure — ten sam wzorzec na platformie vendora.

B. Interfejs: React i komponenty

• React w aplikacjach AI: stan rozmowy i działania
• React Router: czytelna nawigacja w produkcie AI
• React Hook Form: formularz pod kontrolą człowieka
• shadcn/ui w aplikacji AI: kod pod kontrolą zespołu
• Radix UI: dostępne prymitywy dla interfejsu AI
• Base UI: własny wygląd i dostępne interakcje AI
• Tailwind CSS w systemie AI: szybki, spójny interfejs
• Lucide React: czytelne ikony w aplikacji AI
• TanStack Table: kontrola danych w tabeli agenta
• dnd-kit: przenoszenie zadań agenta pod kontrolą

C. Design systemy dla aplikacji AI

• Design system dla aplikacji AI: jak wybrać — Material, Carbon i Fluent na tych samych zadaniach.
• Material Design w aplikacji AI: kryteria wyboru
• Fluent Design w aplikacji AI: czytelność i kontrola

D. Runtime, backend i dane aplikacji

• Node.js w suwerennym systemie AI: rola runtime
• Next.js dla aplikacji AI: kiedy pełny framework pomaga
• Awilix: wymiana zależności w backendzie agenta
• Drizzle ORM: jawne dane aplikacji agentowej
• PostHog: pomiar użycia AI z kontrolą danych

E. Kontrakty, testy i jakość kodu

• TypeScript: kontrakty dla suwerennej aplikacji AI
• Zod: walidacja danych na granicy agenta AI
• Vitest: szybkie testy jednostek i kontraktów AI
• Playwright: test całej ścieżki użytkownik–agent
• ESLint jako bramka zmian od agenta kodującego
• Prettier: mniej szumu w zmianach pisanych przez AI

F. Budowanie i monorepo

• Vite: krótka pętla pracy nad interfejsem AI
• pnpm: powtarzalne zależności dla agentów kodujących
• Corepack: wersja menedżera pakietów pod kontrolą
• Nx w AI SDLC: graf projektów i zakres zmian
• Turborepo: szybki feedback w monorepo AI

Poradniki powiązane

• Co to jest agent AI? — czym agent różni się od bota i asystenta.
• Co to jest MCP? — protokoły agentów: MCP, A2A, AG-UI.
• Co to jest AI OS? — infrastruktura otwartego, suwerennego stosu.
• Co to jest AI SDLC? — wytwarzanie oprogramowania z agentami.