O czym jest ten film
- Mark Kashef pokazuje autorską platformę agentów AI klasy przedsiębiorstwa, zbudowaną na AWS Bedrock — efekt ponad miesiąca pracy i blisko dziesięciu milionów tokenów.
- Punkt wyjścia: frameworki typu OpenClaw czy Hermes świetnie sprawdzają się u osób prywatnych i mikrufirm, ale organizacje z rygorystycznymi wymogami bezpieczeństwa dotąd musiały stać na uboczu.
- Na otwarcie agent głosowy „Jarvis” streszcza stan całej operacji: prace zespołu, wydatki, zgodność z normami i bezpieczeństwo.
- Autor prowadzi widza przez wszystkie moduły: przegląd wydatków, agenci, sesje (m.in. z Telegramu i Slacka), czat, playground z różnymi modelami, koszty, audyt, zgodność, integracje, bazę wiedzy i branding.
- Kluczowa koncepcja całego materiału to „mapowanie”: każdą funkcję osobistego buildu (pliki, baza, sekrety, operator) zastępuje natywna usługa chmury — S3, DynamoDB, Secrets Manager, IAM.
- Architektura spina wszystkie kanały wejściowe przez load balancer i orkiestrator, a każda wiadomość przechodzi przez limity zapytań, wyłączniki awaryjne, limity kosztów i skany antywyciekowe.
- Strategia modelowa: drogi model planuje i decyduje, tańsze modele open-source i natywne usługi AWS (Titan, Nova) wykonują prostszą robotę — także generowanie obrazów i audio.
- Bezpieczeństwo opiera się na sześciu filarach: wyłączniki awaryjne, nieusuwalny dziennik audytu, twarde limity wydatków, bariery ochronne (guardrails), zasada najmniejszych uprawnień i stałe skanowanie wycieków poświadczeń.
- RAG i pamięć agentów działają w całości wewnątrz środowiska: dokumenty wektorowane natywnie, wspomnienia selekcjonowane tanim modelem i priorytetyzowane według aktualności, wagi i ważności.
- Wniosek końcowy: w budowie klasy enterprise wygrywa planowanie — tygodnie projektowania przed pierwszą linijką kodu — a dzięki CLI i agentom kodującym prototyp może przygotować nawet osoba nietechniczna.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zamiast przenosić build, zmapuj każdą funkcję na chmurowy odpowiednik
Na czym polega: osobisty agent (typu Hermes czy OpenClaw) składa się z modeli dostępnych przez API, plików lokalnych, jednego operatora, prostej bazy i sekretów w pliku na dysku. W wersji dla firmy każdą z tych funkcji przejmuje natywna usługa chmury: Bedrock (modele), S3 (pliki), IAM (uprawnienia zamiast „jednego operatora”), DynamoDB (dane), Secrets Manager (poświadczenia).
Jak stosować: zrób dwukolumnową tabelę — w lewej każda funkcja twojego osobistego buildu, w prawej odpowiednik u wybranego dostawcy chmury. Ta sama mapa przenosi się między AWS, Azure i Google Cloud.
Na co uważać: odpowiedniki nie są darmowe i nie są identyczne — każda usługa ma własny cennik, limity i krzywą nauki. „Sekrety w pliku” i Secrets Manager to operacyjne światy, które trzeba naprawdę opanować.
2.Drogi model jako dyrygent, tanie modele jako siła robocza
Na czym polega: w chmurze płaci się za API bez subwencyjonującej subskrypcji, więc czołowy model (u autora: Claude) opłaca się tam, gdzie planuje i podejmuje decyzje. Masową, prostą robotę — klasyfikowanie, tagowanie, przeglądanie rozmów — warto zrzucać na tańsze modele open-source (np. Qwen) albo natywne modele AWS (Titan).
Jak stosować: przypisz każdemu zadaniu w potoku przetwarzania właściwy model: planowanie — model czołowy, selekcja wspomnień — tani „koń roboczy” (u autora Haiku), trywialne etykietowanie — najtańszy model natywny.
Na co uważać: koszty odpytywania modeli w chmurze rosną szybko, a jakość tańszych modeli bywa niższa niż w ich subskrypcyjnych odpowiednikach — porównaj te same zadania na kilku modelach, zanim przypiszesz role na stałe.
3.Każda odpowiedź przechodzi kontrolę antywyciekową, zanim opuści system
Na czym polega: po wygenerowaniu odpowiedzi system skanuje ją pod kątem danych osobowych, kluczy dostępowych, tokenów (Slack, Salesforce, GitHub), nagłówków kluczy API i danych kart — wszystkiego, co mogłoby zostać użyte przeciwko tobie lub firmie.
Jak stosować: prowadź jawną „listę przykazań” — wzorców, których nie wolno wypuścić na zewnątrz — i skanuj obie strony komunikacji: to, co wchodzi do modelu, i to, co z niego wychodzi. Odrzucone odpowiedzi zapisuj do dziennika audytu.
Na co uważać: skan wycieków to nie produkt typu „ustaw i zapomnij”: pojawiają się nowe formaty sekretów, a fałszywe alarmy wymagają konserwacji. Jeden przeoczony wzorzec to potencjalny wyciek.
4.Wyłączniki awaryjne, przycisk paniki i twarde limity kosztów
Na czym polega: każda usługa w stacku ma wyłącznik awaryjny (kill switch), jest jeden przycisk zatrzymujący cały system, a po przekroczeniu dziennego limitu wydatków platforma sama blokuje rozmowy z agentami do następnego dnia.
Jak stosować: projektuj limity dzienne, a nie tylko miesięczne; przypisz odpowiedzialność za wyłączniki konkretnym osobom i przetestuj przycisk paniki, zanim będzie potrzebny po raz pierwszy.
Na co uważać: samo utrzymanie infrastruktury w chmurze to stały rachunek miesięczny, niezależnie od zużycia. Taki stack nie zastępuje taniego osobistego buildu na Hostingerze czy Railway — to narzędzie na przypadki korporacyjne i klienckie.
5.Zasada najmniejszych uprawnień od pierwszego użytkownika
Na czym polega: nowy członek zespołu dostaje minimum dostępów (np. sam podgląd), a wszystko powyżej przyznaje się świadomie, pojedynczo. Reguły spisuje się w politykach IAM — żmudnych do pisania, dlatego warto korzystać z asystenta AI do ich draftowania.
Jak stosować: zdefiniuj role z góry (administrator, operator, analityk z podglądem) i nadawaj dodatkowe uprawnienia dopiero wtedy, gdy pojawia się konkretna potrzeba biznesowa.
Na co uważać: polityki są nudne i łatwo o błąd „na skróty” — wygenerowany przez AI projekt zawsze musi zweryfikować człowiek, bo jedno złe zastrzeżenie otwiera drzwi albo blokuje pracę.
6.Audyt, którego nie da się usunąć
Na czym polega: każde działanie na platformie — kto, co i kiedy — trafia do trwałego, nieusuwalnego dziennika, przechowywanego tak długo, jak wymagają przepisy (np. trzy–pięć lat). Każda akcja jest przy tym identyfikowalna i odwracalna.
Jak stosować: ustal okres retencji logów zgodnie z regulacjami branży i kraju; loguj także działania agentów, nie tylko ludzi; dane o akcjach trzymaj w bazie lub zaszyfrowanych zasobnikach.
Na co uważać: dziennik, którego nikt nie czyta, to martwy zapis — zaplanuj, kto i jak często analizuje logi (np. przez pulpit CloudWatch).
7.Baza wiedzy i pamięć — w całości wewnątrz środowiska
Na czym polega: dokumenty wektoruje natywny model (Titan Embed), wektory trafiają do S3, a tani model przegląda ostatnie tury rozmów i decyduje, co warto zapamiętać. Wspomnienia porządkuje się według aktualności, wagi i ważności.
Jak stosować: świadomie wybieraj między bazą dla jednego agenta a wspólną („zbiorowy umysł”, w którym wszyscy agenci widzą te same pliki); testuj odpowiedzi różnych modeli na tym samym dokumencie i śledź koszt każdego zapytania.
Na co uważać: natywne modele osadzające bywają słabsze od najlepszych zewnętrznych — to kompromis za brak ruchu danych poza środowisko. Przy wrażliwych dokumentach zwykle wart ceny.
8.Głosowy asystent tylko do odczytu i wyjaśniania
Na czym polega: „Jarvis” nawiguje po platformie i omawia dane głosowo, ale z założenia nie może niczego zmieniać ani usuwać — komenda głosowa nie może stać się operacją destrukcyjną.
Jak stosować: oddziel warstwę audio (u autora: Amazon Nova) od warstwy rozumowania (u autora: Claude); domyślnie blokuj operacje zapisu i odblokowuj je tylko dla konkretnych, przemyślanych przypadków.
Na co uważać: efektowna funkcja głosowa to pierwsze miejsce, którym zainteresuje się osoba atakująca system — przetestuj ją na poleceniach, które nie powinny zadziałać.
9.Buduj przez CLI i agenta kodującego, ale planuj tygodniami
Na czym polega: zamiast uczyć się konsoli AWS na pamięć, autor podłącza interfejs wiersza poleceń (AWS CLI) i pozwala agentowi kodującemu (Claude Code, Codex) tworzyć usługi w swoim imieniu — spędziwszy uprzednio dwa tygodnie na planowaniu przed pierwszą budową i po kilka tygodni przed każdą kolejną iteracją.
Jak stosować: pracuj w trybie planowania: opisz cel i „wymarzoną wizję”, pozwól modelowi zaproponować zestaw usług, ścieraj koncepcje wielokrotnie — aż dostaniesz solidną ściągę architektoniczną. Dopiero potem buduj.
Na co uważać: darmowy próg chmury kończy się szybko, a podpięta karta zostanie obciążona za realną infrastrukturę. Eksperymentuj tylko wtedy, gdy masz konkretny przypadek firmowy lub kliencki.
10.Zgodność z normami to droga, nie przełącznik
Na czym polega: platforma wylicza gotowość wobec SOC 2 i HIPAA (co spełnione częściowo, co niespełnione) i generuje „brief naprawczy” — gotowy prompt do modelu, który krok po kroku pomaga domykać luki.
Jak stosować: potraktuj skany zgodności jako listę kontrolną od pierwszego dnia budowy, a nie dodatek na koniec; regularnie odświeżaj treść norm, bo się zmieniają.
Na co uważać: „zgodność wygenerowana przez AI” nie zastępuje audytora ani prawnika — normy różnią się między krajami i branżami, więc zawsze dołącz drugą parę oczu: specjalistę od bezpieczeństwa znającego twoje realia.
Redakcyjne tłumaczenie
Na start: agent, który streszcza stan całej firmy
Zaczynamy od demonstracji. Wchodzę na własny pulpit, najeżdżam na agenta „Jarvis” i proszę o krótkie podsumowanie tego, co widać na ekranie.
Jarvis: „Witaj z powrotem, Marku. Zaraz zrelacjonuję, co działo się w twoim zespole. Badacze domknęli analizę cen konkurencji, wdrożeniowcy przygotowali wersję 1.2 do publikacji, a ja złożyłam całość w jedno. Masz swoją firmę w jednym rzucie oka: trzech agentów w pracy, wszystko w ramach twojego własnego konta AWS. Wyłączniki awaryjne zostały tak, jak je ustawiłeś, a zasada najmniejszych uprawnień trzyma się w całym systemie. Gotowość pod SOC 2 i HIPAA jest liczona na żywo, na podstawie rzeczywistej konfiguracji, więc zawsze wiesz, na czym stoisz. Każda odpowiedź przechodzi kontrolę przed wysłaniem — od twojej ostatniej wizyty nic wrażliwego nie wyciekło. Wydatki trzymają się zwykłego poziomu, a dzienny limit jest daleko. Skoro każde działanie od twojego odejścia jest zalogowane, podpisane i odwracalne, nic tu nie stanowi zagadki. Jesteś na bieżąco. Wszystko spokojne i pod kontrolą.”
To, co właśnie widzieliście, to nie OpenClaw, nie agent Hermes ani nic gotowego z półki. To jeden z kilku agentów pracujących na usłudze AWS Bedrock. Od miesięcy osoby prywatne i bardzo małe firmy korzystają z open-source’owych frameworków niemal prosto z pudełka. Ale jeśli prowadzicie dojrzalszą firmę, organizację non-profit albo podmiot związany sztywnymi wytycznymi, przez te wszystkie miesiące siedzieliście na ławce rezerwowych. Nie mogliście zbudować korporacyjnego centrum dowodzenia, nie mówiąc o bezpiecznym sięganiu do Salesforce’a czy Slacka z telefonu. Cel tego materiału: przeprowadzić was przez ponad miesiąc pracy i blisko dziesięć milionów tokenów, które pochłonęło zbudowanie platformy na AWS Bedrock. Dostaniecie dokładny schemat — pokażę, jak to zrobiłem — a ten sam sposób myślenia przeniesiecie do Azure, Google Cloud i innych chmur. Jeśli zostaniecie do końca, zobaczycie efekt i to, jak powstał, żeby odtworzyć go u siebie, u klienta albo po prostu zrozumieć, jak buduje się takie produkty na poziomie korporacyjnym.
(Informacja dodatkowa: OpenClaw i Hermes to open-source’owe projekty do prowadzenia osobistych agentów AI, zwykle uruchamiane na własnym sprzęcie lub tanim hostingu. AWS Bedrock to usługa Amazona udostępniająca modele językowe — w tym Claude — w chmurze klienta, bez wysyłania danych na zewnątrz.)
Spacer po platformie
Zanim zejdziemy do szczegółów, wypada pokazać całość. Zakładka „Przegląd” rozkłada wydatki — bo budowa na takich platformach potrafi kosztować, zwłaszcza samo odpytywanie modeli. Dalej: lista agentów i ostatnie sesje; w sesje można wchodzić choćby z Telegramu. Otwieram asystenta i — jak na nagraniu — proszę o diagram w ASCII pokazujący jego budowę. Mogę też przejść do Slacka i prowadzić dokładnie tę samą rozmowę: agent z Telegramu i agent ze Slacka mają wspólny mózg, wspólne wspomnienia i — co najważniejsze — wspólny, w pełni zabezpieczony stack w moim środowisku AWS. Dla porządku: AWS to Amazon Web Services i będę tę nazwę powtarzał.
Dodanie agenta to kilka kliknięć: nowy agent, identyfikator, jakiś szablon, rola i zakres odpowiedzialności, przypisany model — resztę konfiguruje się z tyłu. Gotowego agenta można otworzyć, podejrzeć i edytować jego systemowy prompt, z nim pogadać, przejrzeć sesje i wspomnienia oraz podpiąć aplikację Slack (błyskawicznie, jeśli macie manifest — a jeśli nie, Claude Code albo Codex napiszą go za was) albo kanał Telegram. Najtrudniejsze jest samo zrozumienie, jak taki stack poskładać.
„Czat” i „Playground” pełnią podobne role. W czacie po prostu sprawdza się, czy agenci trzymają poziom. W playgroundzie — co wiele osób pomija — można na AWS, Azure czy Google Cloud rozmawiać nie tylko z Claude, ale i z modelami open-source. Claude będzie dostępny zawsze, bo Anthropic i AWS łączy partnerstwo; stale dochodzą nowe modele: Qwen, Moonshot, Meta, Mistral, a także natywne modele Amazona. To właśnie ich używa Jarvis, bo chodzi o to, żeby wszystko zostało wewnątrz środowiska — żadnych zewnętrznych zapytań do choćby Geminiego, poza własnymi serwerami.
Zakładka Jarvisa pozwala rozmawiać z nim wprost, każe mu przechodzić między zakładkami (jak w demie) i odpowiadać na pytania o system. Można wysyłać żądania tekstem albo tworzyć rutyny — na przykład rutynę, która przeprowadza demo platformy z lektorem, albo taką: „wejdź w zakładkę agentów, potem użycia, potem kosztów, a gdy kliknę ten przycisk, omów dokładnie to, co tam widzisz”.
Kolejne zakładki są oczywiste: rejestr sesji z agentami i zużycie rozpisane na pieniądze. Jedno ważne zastrzeżenie: przy budowie w takiej chmurze samo utrzymanie infrastruktury to stały rachunek miesięczny, do którego dochodzi część zmienna. Ten stack nie zastępuje więc osobistego, solowego buildu typu Hermes na Hostingerze, Railway czy innym hostingu — to narzędzie dla przypadków firmowych.
Zakładka kosztów podsumowuje wydatki bieżące i prognozowane, wskazuje winowajców oraz kwoty do odzyskania — bo jeśli nie wie się, co się robi, czeka tam mnóstwo ukrytych opłat. Na dole można wygenerować raport AI wyjaśniający, skąd dokładnie biorą się koszty i które usługi za nie odpowiadają; potem dyskutuje się z modelem: „czy tej usługi naprawdę potrzebuję, przy tym, co chcę osiągnąć?”. Obok działa dziennik audytu ze wszystkim, co się wydarzyło, uzupełniony o wyłączniki: każdą usługę w systemie da się zgasić jednym ruchem, a przycisk paniki jednym kliknięciem zatrzymuje cały serwer wraz z całym otoczeniem. Są też różne sposoby filtrowania odpowiedzi, do których jeszcze wrócę.
Wreszcie moduł zgodności. Nie zbudowałem Fort Knox — przynajmniej w tym wykonaniu, które widzicie — ale tę strukturę i model myślenia można potraktować jako pierwsze kroki na drodze do zgodności z SOC 2 albo HIPAA (to drugie dotyczy branży medycznej). Pomaga w tym pełne rozpisanie: co spełniamy częściowo, czego nie spełniamy — oraz tzw. brief naprawczy: klikasz i dostajesz gotowy prompt do modelu, który krok po kroku pomaga powoli, lecz konsekwentnie domykać luki. Naturalnie potrzebna jest druga para oczu — ktoś od IT, kto zna się na bezpieczeństwie, bo diabeł tkwi w szczegółach.
(Informacja dodatkowa: SOC 2 to amerykański standard zabezpieczeń dla firm przetwarzających dane klientów; HIPAA — amerykańskie przepisy o ochronie danych medycznych. W Unii Europejskiej rolę zbliżonych ram pełnią m.in. ISO 27001 i RODO.)
Integracje: Slack i Salesforce przez własny serwer
Przy Hermesie i OpenClaw ze integracją jest kolorowo — jedno kliknięcie albo jeden prompt. Na wyższym standardzie bezpieczeństwa trzeba jednak przemyśleć, jak dokładnie rozmawiacie z tymi usługami. Amazon prowadzi własne markety serwerów MCP; teoretycznie można więc podpiąć agenta i poprosić: „przejrzyj moje ostatnie wiadomości w Slacku i powiedz, jak ma na imię osoba, która ostatnia do mnie napisała, i co dokładnie napisała”. Wysyłam — i po kilku sekundach wykonuje się wywołanie narzędzia, które bezpiecznie przechodzi przez nasz serwer AWS. Następnie odpytuję Salesforce’a: „pokaż mi dziesięć największych szans sprzedażowych, jakie mamy teraz”. Po chwili dostaję dziesięć hipotetycznych szans uporządkowanych według wartości, z nazwami firm i przewidywanymi datami zamknięcia. Reszty integracji dziś nie będę przerabiał — większość pokazywałem już na kanale przy osobistym buildzie Claude Code.
(Informacja dodatkowa: MCP (Model Context Protocol) to otwarty standard łączenia modeli językowych z narzędziami i danymi zewnętrznymi — takimi jak Slack czy Salesforce.)
Jest też zakładka „Wiedza”: przeciągasz pliki, rozmawiasz z danymi, a agenci mogą sięgać do nich, odpowiadając na pytania. Można nadawać agentom misje, prowadzić wspomnienia, zbudować z nich zbiorowy umysł — i w końcu urządzić czat grupowy, żeby jednym pytaniem objąć wszystkich agentów naraz. A ponieważ całość celuje w dojrzalszego odbiorcę, można zmienić branding: przestawiam pulpit na motyw mojej agencji Prompt Advisors, zmieniam kolory i tak dalej.
Wiem, że tego jest dużo — dalej rozłożę te pojęcia znacznie czytelniej. Do tego czeka na was darmowy pakiet materiałów. A jeśli podoba wam się, jak tłumaczę te bardziej pośrednie tematy, których na YouTube zwykle nie znajdziecie, zajrzyjcie w pierwszy link pod filmem: poza dodatkowym szkoleniem z tego zagadnienia dostaniecie tam cały żywy kurs Claude Code, z nowym modułem co tydzień.
Pięć zmiennych, którymi rządzi się system klasy enterprise
Mamy podgląd gotowego produktu, więc schodzimy pod maskę — do fundamentów systemu operacyjnego dla firmy. Wiele pojęć pokrywa się z osobistym systemem agentów, ale w wariancie enterprise decyduje pięć zmiennych: przejrzystość, prostota, skalowalność, bezpieczeństwo i koszt. Cały ciężki wysiłek wykonuje się z tyłu, żeby na froncie było nieprawdopodobnie prosto i wygodnie. I warto pamiętać: jeśli nie pracowaliście z klientem korporacyjnym, to większość tej hucznej zabawy wokół AI — tej, w której sami eksperymentujemy — dla takich organizacji po prostu nie istnieje. Wystarczy, że zespół IT zada jedno pytanie: „gdzie faktycznie trafiają nasze dane i jak długo je trzymacie?”, i wszystko staje. Wszystko wstrzymane. Trzeba improwizować rozwiązania, żeby dojść do tego samego efektu. Takie pytania zdmuchują zabawę, ale w prawdziwym świecie są fundamentalne. Jeśli więc działacie solo, bezpieczeństwo nie siedzi wam w głowie i nie potrzebujecie tej przejrzystości — zostańcie przy OpenClaw, Hermesie czy moim buildzie CloudClaw. Wszystko poniżej dotyczy reszty.
Od Hermes do chmury: mapa funkcja po funkcji
Żeby przejść między światami, wyobraźcie sobie po jednej stronie agenta Hermes — świetnie zrobiony projekt open-source, z uznaniem dla zespołu. Pozwala sięgać do plików lokalnych i trzymać sekrety w pliku na własnym komputerze — w firmie to niemożliwe. Mostem między tymi światami jest proste ćwiczenie: każdą usługę albo funkcję Hermes mapujecie na natywną usługę wybranej chmury. Wybralibyście Azure? Zasada ta sama — bierzecie usługi dostępne tam i podstawiacie jedną funkcję drugą.
Konkretnie: modele hostowane albo wywoływane przez API → Amazon Bedrock, czyli plac zabaw ze wszystkimi modelami w zabezpieczonej, prywatnej sieci, odpytywany pojedynczymi wywołaniami jak typowe API konsumenckie. Pliki lokalne → S3, chmurowy odpowiednik Dysku Google: wrzucacie pliki myszką (nawet takie, o których nie słyszeliście, jak Parquet), a dodatkowo można je wektorować na miejscu — czyli nie tylko przechowywać, ale od razu przygotować do rozmowy z agentami i zastosowań typu pytania do własnych dokumentów. Jeden operator — wy i wasze imperium komputerów Mac mini → role IAM: lista tego, co jako członek zespołu wolicie zobaczyć, pobrać, a czego nie. Bazy danych: zamiast SQLite, Supabase czy Postgresa dostajecie szeroki wybór — DynamoDB, KMS i inne — a o wyborze decyduje połączenie ceny, potrzeby i wygody użycia. Sekrety → Secrets Manager: szyfruje poświadczenia i trzyma je w chmurze; gdy agent chce wywołać usługę albo API, sam sięga po dane dostępowe, wykonuje żądanie i tyle. Wreszcie bariery ochronne i audyt: pilnują, żeby właściwe pliki leżały we właściwych miejscach i żeby nikt nie widział tego, czego widzieć nie powinien.
Konsola bez zostawania ekspertem od konsoli
Od przodu AWS wygląda tak: kafelki dziesiątek usług. Dla nowicjusza to przytłaczające — nie wiadomo, co klikać, co omijać, co znaczą nazwy typu CodeBuild czy CodeCommit i czy w ogóle ich używać. Kluczowa przewaga jest jednak inna: naszym celem nie jest biegłość w konsoli, lecz wyciągnięcie z niej poświadczeń, żeby rozmawiać z chmurą za pośrednictwem wybranego modelu — Claude Code, Codex czy czego tam chcecie. Zamiast klikania po ikonach podłączacie interfejs wiersza poleceń AWS (CLI). Poprosi o serię poświadczeń, a potem zacznie budować w waszym imieniu; od czasu do czasu zwróci się o kliknięcie „akceptuję” przy politykach i aktualizacjach, ale ciężką robotę bierze na siebie — i rozmawia się z nim normalnym językiem. Zastrzeżenie: załóżcie darmowe konto i trzymajcie się darmowego progu; gdy zbudujecie prawdziwą infrastrukturę, a karta jest podpięta, chmura ją obciąży. Eksperymentujcie więc tylko z myślą o zastosowaniu korporacyjnym albo klienckim.
Gdy CLI działa, ster można oddać Claude Code i za jego pomocą stawiać usługi. Warto sporo pokręcić się w trybie planowania: „to jest dokładnie nasz cel, oto wymarzona wizja — jakie usługi będą potrzebne i gdzie dostaniemy najwięcej za te pieniądze?”. Idealnie nie będzie, ale wyjdzie bardzo dobra ściąga architektoniczna — taka, jakiej samemu brakowało pięć, sześć lat temu.
Cały obraz na jednym diagramie
Jeśli przed oczami robi się już mętnie, przyjrzyjcie się diagramowi zbierającemu całość w jednym kadrze — a potem wezmę każdą zakładkę na warsztat i pokażę, co siedzi pod spodem. Telegram, Slack, pulpity na komputerach — wszystko trafia do jednego węzła centralnego: load balancera, czyli rozdzielacza ruchu. Jego zadaniem (ma ich sporo, ale to najważniejsze) jest zarządzanie zapytaniami z różnych platform: gdy pięć czy dziesięć urządzeń naraz puka do agentów, balancer kolejkuje żądania, żeby nie dopuścić do lawiny równoległych połączeń, z których jedno zawisa albo pada. To brama, do której prowadzą wszystkie drogi. Za nią stoi orkiestrator Fargate, który decyduje, do której mikrousługi skierować żądanie — do DynamoDB (baza), S3 (nasz odpowiednik Dysku Google czy Dropboxa), KMS (poświadczenia), barier ochronnych czy Bedrocka (odpytywanie modeli). Trzeba zapisać wspomnienie? DynamoDB albo S3. Odpytać model? Claude przez Bedrock, a odpowiedź wraca na wszystkie wybrane platformy. Tyle w pigułce — teraz obieramy cebulę warstwa po warstwie.
(Informacja dodatkowa: Fargate to usługa AWS uruchamiająca kontenery bez zarządzania serwerami — autor używa jej jako „dyżurnego”, który kieruje ruch do właściwych mikrousług.)
Droga jednej wiadomości
Weźmy jedną turę: pojedynczą wiadomość wysłaną ze Slacka albo Telegramu. Co się z nią dzieje? Najpierw sprawdzamy limity zapytań. Potem ładujemy agenta, z którym rozmawiamy — w tym wypadku głównego agenta telegramowego. Następnie weryfikujemy dostęp do Bedrocka i czy wyłącznik awaryjny odblokowujący go jest włączony. Dalej — czy nie przekroczyliśmy limitu kosztów, zanim w ogóle wykonamy żądanie: mamy budżet, a AWS potrafi palić nie tokeny, lecz twarde pieniądze, i to błyskawicznie. Potem jeszcze kilka warstw, między innymi bariery ochronne, i dopiero wtedy odpalamy potrzebne narzędzia. Gdy odpowiedź wraca z Bedrocka, następuje skan: czy nie ma w niej danych osobowych, sekretów firmy — czegokolwiek z listy rzeczy, których nie wolno wypuścić do użytkownika. Jeśli przejdzie skan i audyt, dostajecie odpowiedź.
Z perspektywy infrastruktury wygląda to tak: wiadomość z Telegramu leci do rozdzielacza ruchu; ten weryfikuje właściwe konto, dostęp i sekrety; sprawdzamy, czy gadamy z właściwym agentem; wykonywana jest opisana przed chwilą tura — cała magia dzieje się w tym leju. Jeśli agenci muszą jeszcze porozmawiać między sobą, to następuje, a każda wiadomość wracająca do Telegramu przechodzi ponownie skan, żeby trzymać się waszej listy przykazań: co wolno, czego nie wolno mówić.
Kto dyryguje, a kto ciągnie: podział pracy między modelami
Piękno Bedrocka polega na tym, że nie jesteście skazani na modele Claude. Możecie ich używać — ale ponieważ płacicie za samo API, a nie subsydionowaną subskrypcję, zrobi się drogo. Sensowny podział jest więc taki: drogi model jako dyrygent — planista i decydent ustalający, co i jak ma się wydarzyć — a czarna robota spada na tańsze modele open-source, jak Qwen. Jest też Titan, natywny model AWS: nie jest najlepszy, ale do prostej pracy w stylu „zidentyfikuj to, otaguj tamto” starczy z powodzeniem. I jeszcze jedno: jeśli żaden z dostępnych modeli wam nie odpowiada, a znajdziecie coś na Hugging Face, teoretycznie możecie hostować to na własnym koncie AWS. Będzie kosztować godzinowo, ale to opcja znacznie bardziej „pod klucz” niż robienie wszystkiego samemu — na wypadek, gdyby nie można było sięgnąć po coś w rodzaju OpenRouter.
Z perspektywy danych: wspomnienia wszystkich agentów, pliki systemowe, foldery — wszystko leży w zasobnikach S3 zaszyfrowanych waszymi własnymi kluczami. Całość da się zgasić jednym kliknięciem; możecie kompletnie wyczyścić system do zera, bo nigdzie indziej nie ma kopii. Wszystkie odpytywania modeli w jednym miejscu, wszystkie pliki w jednym miejscu, wszystko w jednym ekosystemie — z założenia.
Sześć filarów bezpieczeństwa — i uczciwe „ale”
Mniej ekscytujące, ale konieczne. Bezpieczeństwo opiera się na sześciu głównych obszarach — i od razu zaznaczam: to nie katalog zamknięty, a to, co zbudowałem, nie jest bezpieczeństwem maksymalnym. Ekspert od cyberbezpieczeństwa miałby tu jeszcze co wyregulować, więc koniecznie porozmawiajcie ze specjalistą, jak to wszystko dopasować do was i waszych klientów.
Po kolei: po pierwsze, wyłączniki awaryjne — każdą usługę włącza się i wyłącza według potrzeb. Po drugie, audyt — platforma jest wielodostępna (multi-tenant, czyli jak SaaS: wielu użytkowników korzysta z niej na różne sposoby), a każde działanie zapisuje się w dzienniku, którego nie da się usuwać; retencję ustawiacie sami — trzy lata, pięć lat, zależnie od regulacji w waszym kraju — i można te wpisy trzymać w bazach albo w S3. Po trzecie, limity kosztów — po przekroczeniu progu wszystko się zamyka i nie pogadacie z agentami do następnego dnia, kiedy wchodzi świeża pula. Po czwarte, Bedrock Guardrails — bariery, których zadaniem jest wyłapać dane osobowe, zanim trafią do modelu albo z niego wyjdą. Po piąte, zasada najmniejszych uprawnień — każdy nowy użytkownik dostaje absolutne minimum dostępu do zasobów i dokumentów; jeśli czegoś potrzebuje, przyznajemy to dobrowolnie, a nie wszystkim od razu na dzień dobry. Po szóste, nieustanne skanowanie całego systemu pod kątem wycieku poświadczeń.
W wydzielonej sekcji „Stan bezpieczeństwa” widać na żywo, jak wasza organizma radzi sobie z codziennymi zagrożeniami — z poziomami wagi zależnymi od stawki — oraz co jest włączone, a co nie, wobec waszych standardów. Reguły dla użytkowników spisuje się w politykach; ich pisanie bywa upierdliwe, dlatego w platformie siedzi asystent AI do draftowania polityk. Jeśli nie wiecie, czym w ogóle jest polityka, śmiało przewijajcie dalej — pokazuję to głównie po to, żeby uświadomić, ile mało efektownych elementów ma budowa klasy enterprise. Od strony obserwowalności działa CloudWatch — wielki pulpit dowodzenia z metrykami i logami zdarzeń, w pełni konfigurowalny — oraz ścieżka audytowa jako rozwinięcie dziennika z interfejsu.
W sekcji zgodności jest wspomniana ocena gotowości: skan, którego logikę można zmieniać. Do samej treści norm — najnowszych wersji SOC 2 i HIPAA, jakie udało się ściągnąć za pomocą Claude — podchodźcie krytycznie: normy różnią się regionem, krajem i branżą. Jeśli chcecie, by AI pomogło w uczynieniu czegoś „zgodnym”, sprawdźcie to porządnie, upewnijcie się co do danych wejściowych i zadbajcie o człowieka w pętli, żeby wynik był wiarygodny.
Sam skan wycieków szuka konkretnych wzorców: kluczy dostępowych AWS, danych kart, numerów ubezpieczenia społecznego, tokenów Slacka i Salesforce’a, osobistych tokenów GitHub, nagłówków kluczy API — wszystkiego, co mogłoby zostać użyte przeciwko wam albo firmie.
Rozmowa z własnymi danymi — najpopularniejsze życzenie klientów od 2023 roku
„Chcemy rozmawiać z naszymi danymi” — najczęstsze życzenie każdej firmy, z jaką pracowaliśmy od 2023 roku. Jak to wygląda? Karmicie system dokumentem; jest połykany i osadzany. W Hermesie czy OpenClaw wybralibyście po prostu najtańsze API u jakiegoś dostawcy — np. embeddingi OpenAI albo modele Gemini, zwykły tor konsumencki. Tutaj optymalizujemy pod zasadę „wszystko w środku”: dokumenty wektoruje Amazon Titan Embed — przyzwoity model — a wektory lądują w naszym S3. Potem można już rozmawiać z plikiem. Do tego podpięty jest system pamięci: Haiku, tani koń roboczy, przegląda ostatnie tury rozmów i ocenia, czy jest coś na tyle istotnego, że warto zapamiętać — i zapisuje to w zbiorowym umyśle. Rusza pętla zwrotna: kolejne wymiany, zapisywanie wspomnień i ich porządkowanie według aktualności, wagi i ważności.
W praktyce wchodzę w zakładkę „Wiedza”, klikam i wybieram plik — np. pakiet promptów, który udostępniam darmowo, żeby pomóc wam ruszyć z takim buildem przy użyciu AWS CLI. System w czasie rzeczywistym wgrywa dokument, wyciąga treść, tnie na kawałki i osadza (można to konfigurować), a plik pojawia się na liście. Wystarczy wybrać model — np. Sonnet — i zapytać: „co jest w tym pliku?”. Żądanie leci do Sonnet, który zestrawia je z zawartością pakietu i wraca z pełnym rozpisaniem. Ważny szczegół: to nie musi być baza wiedzy dla jednego agenta — można ją udostępnić współdzielonym agentom, a wtedy wszyscy widzą wszystkie wgrane pliki. Wybór zależy od preferencji, wymogów bezpieczeństwa i pozostałych wymagań. Można też porównać, jak to samo pytanie obsłużą modele GPT-OSS czy DeepSeek. Żyjemy w czasach, w których można po prostu przejąć funkcje całych wyspecjalizowanych platform — i to z pełnym śledzeniem kosztu każdego pojedynczego zapytania.
Obraz i dźwięk bez wychodzenia z chmury
Multimedia. W Hermesie czy OpenClaw wystarczy dodać skill Geminiego, by korzystać z Nano Banana (obrazowego modelu Google), albo sięgnąć po obrazowy model OpenAI. Tutaj lepiej znaleźć model natywny dla Bedrocka — i tu znów zyskuje opisane wcześniej mapowanie. W moim wypadku modele Nova obsłużą nie tylko audio, ale i obrazy. Mówię: „stwórz obraz mango w przekroju, z rozpisaniem każdego elementu” — i wklejam prompt do Slacka, a równolegle do Telegrama. Po krótkiej chwili system przez Nova bezpiecznie generuje obraz i odsyła go z powrotem: widać, jak powstaje, a po pięciu–dziesięciu sekundach dostaję plik, który mogę otworzyć i obejrzeć. Czy to tak wyrafinowane jak modele Google? Nie. Ale w większości zastosowań da zbliżony efekt — bez bólu głowy z wysyłaniem żądania na zewnątrz, podczas którego może zdarzyć się cokolwiek.
Zespół, role i zaproszenia
Zarządzanie zespołem uprościłem maksymalnie: zakładka „Członkowie”, „Zaproś”, dodajecie osobę, zmieniacie jej rolę np. na „tylko podgląd” i zapisujecie. Zaproszenie wysyła mikrousługa AWS o nazwie SES. Jeśli znacie Resenda — narzędzie do łatwego stawiania potoków mailowych — to właśnie na SES jest zbudowane: zarabia na uproszczeniu dostępu do tej usługi. Adresat dostaje zaproszenie z dedykowanym linkiem, loguje się przez magiczny link — i możemy oglądać platformę jego oczami. Cała idea dostępu jest taka: jedno centrum dowodzenia firmy, grupa administratorów albo jeden admin; operatorzy korzystają z agentów; analityk albo osoba z podglądem widzi tylko liczby — możecie stawiać różne pulpity z wynikami z innych systemów. Da się też mieć rolę operatora, który używa agentów i sięga do danych, ale nie zagląda w mechanikę limitów kosztów. Słowem: role, obowiązki i dostęp przyznajecie wedle potrzeby.
Jarvis: pokazówka, która z założenia niczego nie zepsuje
Nawet najbardziej efektowna funkcja musi być dobrze zaprojektowana — także Jarvis. Fajnie, że przechodzi po zakładkach i omawia, co na nich widać, ale trzeba zagwarantować, że komenda głosowa nie zamieni się w coś destrukcyjnego: nie zniszczy danych, nie naruszy struktury backendu ani wymogu bezpieczeństwa. Dlatego Jarvisa projektuje się jako funkcję wyłącznie do odczytu i wyjaśniania. Za audio odpowiada model Nova z AWS, za rozumowanie — Claude (można podmienić na dowolny model open-source z platformy). Jeśli trzeba przeczytać dane — klikam agenta i mówię: „wyjaśnij mi, co się dzieje z kosztami”. Agent patrzy na stronę (to było zaskakująco trudne do zbudowania), zbiera dane z backendu, błyskawicznie rozumie, o co chodzi, i tłumaczy mi po ludzku, prowadząc rozmowę.
Jarvis: „Dobrze cię widzieć, Marku. W czym pomogę?”
Mark: „Możesz skoczyć na zakładkę kosztów?”
Jarvis: „Jasne, jestem na stronie kosztów.”
Mark: „Wyjaśnij mi w jednym zdaniu, skąd biorą się te prognozy.”
Jarvis: „Prognozy liczę z bieżącego dziennego tempa wydatków i struktury kosztów aktywnych planów.”
Mark: „A czemu tak wysoko? Czy to w ogóle dużo jak na taki build?”
Jarvis: „Twoje wydatki są wyraźnie poniżej średniej tygodniowej, a dzienny limit wciąż poza zasięgiem.”
Widzicie: jednym kliknięciem, w trakcie zwykłej rozmowy, agent buduje analizę na żywo, przeglądając kolejne zakładki. Dlatego tak ważne jest mocne dopracowanie samej wyjaśnialności — łącznie z pewnymi społeczniejszymi sygnałami w sposobie podawania informacji — ale funkcja pozostaje wyłącznie odczytem. To ma być smaczek rodem z science fiction, a w praktyce staje się namacalnym sposobem nawigacji i tłumaczenia tego, co dzieje się w systemie: rozbudowany przewodnik po platformie. Zapis będzie zablokowany, chyba że naprawdę go odblokujecie — i dokładnie wiecie, po co to robicie.
Przystępność ma też swoje miejsce w samym interfejsie: przygotowałem pełną wycieczkę po platformie — zakładka po zakładce, z wyjaśnieniem, co z czym się wiąże i jak działa. Ten poziom dostępności jest istotny, bo cała ta droga jest mocno iteracyjna: czeka was sporo pracy, przeglądów bezpieczeństwa i innowacji, żeby używać AI w sposób praktyczny, ale i świeży.
Zamiast zakończenia: planuj, dopóki nie masz pewności
Ten film mógłby trwać trzy–cztery godziny i wciąż nie wyczerpałbym tematu: każdej funkcji, planowania i inżynierii kontekstu, które to wszystko spajają. Chciałem przekazać sedno. Po pierwsze: świat OpenClaw i Hermes jest wspaniały i uroczy — na własny użytek. Ale przy pracy z klientami i przedsiębiorstwami na wyższym poziomie prowadzi się inne rozmowy i buduje inne systemy; bez przemyślenia i zaprojektowania takich rozwiązań te podmioty nie wezmą udziału w zabawie. Po drugie — strona jasna: choć moja wiedza pozwala mi działać na tym poziomie, nawet osoba nietechniczna — nie obiecuję, że w krótkim czasie — może spróbować naszkicować infrastrukturę, majsterkować i wystawić wersję 0 albo 1, którą dopracuje reszta zespołu. Gdy podłączycie te bardzo inteligentne modele do AWS CLI, dostajecie w ręce wszystkie mikrousługi — a Claude czy Codex zrozumieją, do czego służą i jak ich użyć. Ostatecznie wygrywa planowanie na pełną skalę: sam planowałem dwa tygodnie, zanim zacząłem cokolwiek budować, i przed każdą kolejną iteracją znów poświęcałem planowaniu kilka tygodni. System operacyjny klasy enterprise wygląda jak osobisty — tylko że między elementami biegnie więcej przewodów i mostów, a myśli się znacznie więcej o tym, co dzieje się z danymi, dokąd lecą żądania i jak odpowiedzialnie obcować z modelami.
Jak obiecałem, czeka pakiet darmowych materiałów: blueprint całego systemu, kopia slajdów i rozpiska serii promptów. Nie zbudują one tego za was — pochłonęło to mnóstwo czasu — ale wyznaczą kierunek i nastawienie, jak zabierać się za podobny projekt w firmie, u klienta czy u pracodawcy, i dadzą cegiełki na start. Materiały znajdziecie pod drugim linkiem. Jeśli natomiast chcecie mój dokładny build wraz z kolejnymi ulepszonymi wersjami — a docelowo także wariant dla Azure, bo wiele osób z sektora publicznego siedzi właśnie tam — zajrzyjcie pod pierwszy link: jako członek premium albo roczny dostaniecie system Claude Code OS, który doskonalimy już całym zespołem od czterech–pięciu miesięcy, wraz z dostępem do repozytorium i wszystkich przyszłych wersji. A jeśli uznaliście ten materiał za świeży i pomocny — zostawcie łapkę, ewentualnie komentarz. Do zobaczenia w następnym odcinku.