Jak przypadkiem zaczęliśmy budować firmę osobowo-agentową

Nie planowaliśmy tego. Nie było spotkania, na którym ktoś powiedział: od dziś budujemy organizację agentową. Nie rozpisywaliśmy trzyletniej transformacji AI i nie rysowaliśmy docelowej architektury firmy. Po prostu w różnych miejscach zaczęli powstawać wyspecjalizowani agenci.

Jeden zna konkretny projekt. Inny specjalizuje się w określonej technologii. Po stronie growth działa agent analizujący Google Ads, obok niego agent SEO i kolejny zajmujący się e-commerce. Każdy z nich powstał z innego powodu. Budowali je różni ludzie. Nie według jednego centralnego planu, tylko tam, gdzie ktoś znał problem wystarczająco dobrze, żeby wiedzieć, czego od takiego systemu potrzebuje. I chyba właśnie dlatego przez jakiś czas nie widziałem, co właściwie się dzieje. W którymś momencie dotarło do mnie, że nasza firma zaczyna mieć więcej specjalistów niż pracowników. Nie w sensie księgowym. Agent nie jest pracownikiem i nie zamierzam udawać, że nim jest.

Chodzi o role.

Przez wiele lat liczba specjalizacji, które firma mogła realnie rozwijać, była bezpośrednio związana z liczbą ludzi. Jeżeli chcieliśmy być mocniejsi w konkretnej technologii - potrzebowaliśmy człowieka, który dobrze ją zna. Jeżeli chcieliśmy rozwijać SEO - potrzebowaliśmy specjalisty SEO. Dokładniejsza analiza reklam oznaczała kolejne godziny spędzone na zaglądaniu do kilku systemów, porównywaniu danych i pamiętaniu, dlaczego dwa tygodnie wcześniej podjęliśmy określoną decyzję. Nadal potrzebujemy ludzi z różnymi kompetencjami. To się nie zmieniło. Zmienia się coś innego.

Dobry specjalista może dziś budować wokół siebie dodatkową warstwę specjalizacji. Programista może mieć agenta znającego jeden konkretny projekt i drugiego wyspecjalizowanego w technologii, z którą pracuje. Osoba odpowiedzialna za wzrost może pracować z agentem Ads, agentem SEO i agentem e-commerce. Projektant może mieć obok siebie system, który obserwuje działające strony, zbiera dane, śledzi zmiany w UX i przypomina o decyzjach, które zapadły kilka miesięcy wcześniej.

Człowiek nie staje się przez to mniej potrzebny. Po prostu nie musi już wszystkiego robić sam.

Przez długi czas po prostu korzystaliśmy z AI

Sam długo pracowałem dokładnie tak jak większość ludzi. Miałem problem, więc otwierałem model. Opisywałem sytuację, wklejałem dane, dostawałem odpowiedź. Czasami świetną. Czasami przeciętną. Czasami bardzo przekonującą i całkowicie błędną. Po wszystkim zamykałem rozmowę i wracałem do pracy.

AI było dobrym narzędziem, ale prawdziwy kontekst nadal zostawał po mojej stronie. To ja pamiętałem, co wydarzyło się tydzień wcześniej. Wiedziałem, dlaczego coś zmieniliśmy. Pamiętałem, że podobny pomysł już testowaliśmy i jaki był efekt. Przy kolejnej rozmowie znowu trzeba było tłumaczyć, czym zajmuje się firma, jak działa projekt, co jest ważne i czego nie wolno ruszać. Tak można pracować szybciej ale nie buduje się jednak w ten sposób pamięci organizacji.

Pierwsza większa zmiana nastąpiła wtedy, kiedy przestaliśmy każdą rozmowę zaczynać od zera. Zamiast ogólnego AI zaczęły pojawiać się wyspecjalizowane role.

• Nie agent do programowania, tylko agent znający konkretny projekt.

• Nie AI do marketingu, tylko system odpowiedzialny za Google Ads.

• Nie chatbot SEO, tylko agent mający własne źródła danych, pamięć i jasno określony obszar pracy.

Wtedy AI przestało być wyłącznie narzędziem, które człowiek uruchamia, kiedy czegoś potrzebuje. Zaczęło dostawać stałe miejsce w sposobie działania firmy.

Model jest chyba najmniej interesującą częścią agenta

Łatwo dziś zrobić coś, co wygląda jak agent. Model, dobry prompt, kilka narzędzi, prosty interfejs. Im dłużej je budujemy, tym mniej interesuje mnie jednak sam model. Jeden system może działać na Claude, inny na GPT czy DeepSeek. Za rok część z nich zapewne będzie korzystała z czegoś zupełnie innego. Model zawsze można wymienić. Znacznie trudniej zbudować to, co go otacza - rolę, kontekst, wiedzę, pamięć, narzędzia, zasady działania, ograniczenia i historię wcześniejszych decyzji. W naszych frameworkach działa już gotowa knowledge layer. Zbiera i porządkuje informacje projektowe, a dane trafiają do wspólnej bazy. Dzięki temu projekt może mieć własną warstwę wiedzy. Agent może z niej korzystać, a później do tego samego kontekstu można podłączyć kolejnego specjalistę z zupełnie inną rolą. Jeden zna projekt, drugi lepiej zna technologię, kolejny może kiedyś odpowiadać za jakość, bezpieczeństwo albo dokumentację. Nie trzeba za każdym razem zaczynać od pustego okna i opowiadać całego świata od nowa.

To jest dla mnie znacznie ważniejsze niż nazwa modelu, który akurat siedzi pod spodem.

Firma zaczyna mieć drugą warstwę

Dziś widzę naszą organizację mniej więcej tak:

                         GRUPA INSIGHT

                             LUDZIE
                               │
            ┌──────────────────┼──────────────────┐
            │                  │                  │
            ▼                  ▼                  ▼

       DEVELOPMENT           GROWTH           DESIGN / UX

       człowiek              człowiek           człowiek
          +                     +                  +
   agenci projektowi       Ads Agent          UX Agent
   agenci technologii      SEO Agent          kolejny etap
                           E-commerce Agent

            │                  │                  │
            └──────────────────┼──────────────────┘
                               ▼

                    DRUGA WARSTWA ORGANIZACJI

                    wiedza • pamięć • narzędzia
                    decyzje • historia • wyniki

Nie wszystkie te systemy są połączone jedną centralną pamięcią. I nie powinny być. Agent znający kod konkretnego projektu nie potrzebuje dostępu do danych reklamowych. System Ads nie musi znać architektury aplikacji. Ale wzorzec zaczyna się powtarzać.

• Człowiek ma własnych cyfrowych specjalistów.

• Projekt ma własną wiedzę.

• Cały obszar firmy może mieć system, który obserwuje go w czasie.

I dopiero teraz zaczynamy dochodzić do naprawdę ciekawego problemu - jak wszystkie te role zorganizować.

Najlepiej zobaczyłem to przy budowie agenta Ads

Na początku zadanie wydawało się proste. System miał analizować kampanie i wyciągać wnioski. Sama analiza szybko okazała się jednak najmniej interesującą częścią. Agent musiał wiedzieć, dla jakiej firmy pracuje. Znać wcześniejsze rekomendacje. Pamiętać, co zostało zaakceptowane, co odrzucone i co już wdrożono. Musiał korzystać z różnych źródeł danych i zauważać, kiedy te źródła mówią coś zupełnie innego. Jeżeli Google Ads pokazuje jedną sytuację, a GA4 zupełnie inną - nie może po prostu wybrać liczby, która najlepiej pasuje do jego historii. Najpierw musi zauważyć problem i zrozumieć jego znaczenie. Czasami dojść do wniosku, że na podstawie dostępnych danych nie powinien podejmować określonej decyzji. Z prostego pomysłu na system analizujący reklamy powstała więc znacznie większa architektura.

W dużym uproszczeniu wygląda ona tak:

                         POJEDYNCZY AGENT

                        CONTEXT BOOTSTRAP
                               ↓
                         AGENT PLANNER
                               ↓
                           TOOL LAYER
                               ↓
                        CONFIDENCE ENGINE
                               ↓
                       CAPABILITY POLICY
                               ↓
                        REASONING LOOP
                               ↓
                          ACTION ENGINE
                               ↓
                   DETERMINISTIC GUARDRAILS
                               ↓
                       HUMAN IN THE LOOP
                               ↓
                            OUTCOME
                               ↓
                             MEMORY
                               ↺

Model jest tylko fragmentem tego układu. Cała reszta decyduje o tym, czy mamy do czynienia z chatbotem, czy z systemem, któremu można powierzyć konkretną odpowiedzialność. Agent najpierw musi wiedzieć, gdzie pracuje. Człowiek nie rozpoczyna każdego dnia od poznawania firmy od nowa. Pamięta klientów, zna historię projektu, wie, dlaczego tydzień wcześniej podjęto taką a nie inną decyzję. Agent bez kontekstu tego nie ma.

Dlatego przed właściwą pracą ładuje wiedzę o miejscu, w którym się znajduje. W przypadku systemu Ads są to informacje o koncie, kontekst biznesowy, wcześniejsze raporty i historia rekomendacji. Agent projektowy potrzebuje czegoś zupełnie innego - architektury, dokumentacji, historii decyzji, zasad konkretnego systemu. To nie jest najbardziej efektowna część całej układanki. Znacznie łatwiej pokazać na demo model, który błyskawicznie odpowiada na pytanie. Tyle że bez tej warstwy każdy agent pozostaje kolejnym konsultantem, któremu codziennie rano trzeba opowiedzieć firmę od początku.

Później dochodzą narzędzia i planowanie. Klasyczny skrypt dostaje instrukcję - pobierz te dane, policz te wskaźniki, wygeneruj raport. Agent dostaje problem. Jeżeli coś wygląda źle na poziomie kampanii, może zejść głębiej. Sprawdzić słowa kluczowe, potem search terms, porównać Ads z Analytics, zajrzeć do Search Console, sprawdzić, czy podobny problem pojawił się wcześniej. Nie chodzi o pobranie wszystkiego. Chodzi o zebranie dowodów potrzebnych w konkretnej sytuacji. Dopiero wtedy można mówić o reasoning.

Dobry agent musi też umieć powiedzieć: nie wiem

To jedna z rzeczy, których najbardziej brakowało mi w pierwszych systemach AI. Model potrafi bardzo dobrze odpowiadać. Znacznie gorzej radzi sobie z zatrzymaniem się we właściwym momencie. Na niepełnych danych agent nadal może zauważyć ewidentne marnowanie budżetu albo oczywisty problem. Nie powinien jednak udawać, że potrafi wiarygodnie prognozować sprzedaż. Dlatego w naszych systemach pojawiły się warstwy confidence i capability policy. Agent nie ocenia wyłącznie, jak pewny jest odpowiedzi. Musi też wiedzieć, z czego wynika niepewność i co przy takim poziomie danych w ogóle wolno mu zrobić. To subtelna, ale ważna różnica. Nie wystarczy powiedzieć modelowi, żeby był ostrożny. Jeżeli coś naprawdę jest niedozwolone - powinien zatrzymać to kod, a nie prompt. Stąd deterministyczne guardraile i człowiek, który nadal zatwierdza albo odrzuca działanie. Autonomia sama w sobie nie jest dla mnie celem - celem jest lepsze działanie firmy.

Rekomendacja potrzebuje własnej historii

Klasyczny raport żyje krótko. Przychodzi mail, czytamy go, może coś zmieniamy. Tydzień później pojawia się kolejny. Po miesiącu mało kto dokładnie pamięta, dlaczego wcześniej zmniejszyliśmy budżet, jakie wtedy były dane i czy efekt okazał się zgodny z oczekiwaniem. Agent nie powinien pracować w ten sposób. Rekomendacja ma własny cykl życia. Może zostać zgłoszona, zaakceptowana, odrzucona albo odłożona. Później może wrócić do ponownej oceny. Czasami zostanie wycofana. Dlatego w naszym systemie pojawiły się statusy takie jak REASSESS i WITHDRAWN.

Najbardziej interesuje mnie moment, w którym agent wraca do własnego wcześniejszego wniosku i stwierdza, że dwa tygodnie temu miał on sens, ale nowe dane zmieniły sytuację. Albo przeciwnie - nadal go podtrzymuje. Firma nie działa w pojedynczym promptcie. Działa poprzez decyzje, ich konsekwencje i kolejne decyzje podejmowane później. Jeżeli agent ma być częścią organizacji, musi mieć własną historię.

Potem obok Ads pojawiło się SEO

I wtedy zrobiło się naprawdę ciekawie. Kiedy działał tylko agent Ads, można było traktować go jako osobną specjalizację. Teraz obok niego działa agent SEO. Jest również agent e-commerce. Każdy patrzy na inny fragment tego samego biznesu.

• AI Ads widzi kampanie, koszty, zapytania i konwersje.
• AI SEO obserwuje widoczność, strukturę serwisu, treści, problemy techniczne i sygnały z Search Console.
• AI E-commerce patrzy na ofertę, produkty, kategorie, zachowanie użytkowników i sprzedaż.

I bardzo szybko okazuje się, że tych światów nie da się naprawdę rozdzielić.

Temat, który słabo wygląda w reklamach, może być strategicznie ważny dla SEO. Dane z kampanii mogą pokazać, które komunikaty naprawdę przyciągają ludzi. SEO może zauważyć zmianę popytu. E-commerce może pokazać, że ruch oceniany przez jeden system jako słaby w rzeczywistości wpływa na sprzedaż gdzie indziej. Nie potrzebujemy więc jednego superagenta, który będzie udawał eksperta od wszystkiego, potrzebujemy różnych specjalistów.

Ale w pewnym momencie sami specjaliści przestają wystarczać, bo ktoś musi zobaczyć całość. Jeżeli AI Ads rekomenduje ograniczenie budżetu, AI SEO widzi strategiczny temat, a AI E-commerce zauważa, że użytkownicy z tego obszaru mają dłuższą ścieżkę do zakupu, nie wystarczy wygenerować trzech osobnych raportów. Potrzebna jest warstwa, która rozumie, że właśnie pojawił się konflikt. U nas tę rolę zaczyna pełnić Orchestrator. Nie ma być kolejnym specjalistą od Ads, SEO czy e-commerce. Jego zadaniem nie jest wygrywanie z pozostałymi agentami. Ma pilnować całego procesu. Wie, który agent powinien zająć się danym problemem i może przekazać mu kontekst zebrany przez innego specjalistę. Widząc sprzeczne rekomendacje, nie wybiera automatycznie jednej z nich. Zbiera dowody, sprawdza, czego brakuje i decyduje, czy potrzebna jest kolejna analiza, eksperyment albo decyzja człowieka.

Dopiero tutaj zaczyna powstawać coś, co naprawdę przypomina organizację. Specjaliści patrzą na biznes ze swojej strony. Orchestrator pilnuje, żeby nie pracowali tak, jakby pozostali nie istnieli. Pod nimi znajduje się wspólna warstwa dowodów i pamięci. Nie oznacza to, że każdy agent widzi wszystko. Różne role nadal mają różne dostępy i różne zakresy odpowiedzialności. Chodzi o coś innego.

Kiedy dwa systemy dochodzą do innych wniosków, organizacja powinna wiedzieć, dlaczego się różnią. Orchestrator ma pomóc zamienić tę różnicę zdań w proces decyzyjny, a nie w trzy kolejne raporty do przeczytania.

W development dzieje się coś podobnego

Agenci programistyczni mają inne cele, ale wzorzec jest ten sam. Mamy systemy przygotowane do pracy z konkretnymi projektami. Mają własną warstwę wiedzy i nie zaczynają od pustego kontekstu. Informacje zbierane przez framework trafiają do bazy danych i stają się bazą dla kolejnych specjalizacji.

Jeden agent może dobrze znać projekt. Inny konkretną technologię. Z czasem obok nich mogą pojawić się kolejne role - jakość, bezpieczeństwo, dokumentacja. Nie chcemy produkować agentów tylko dlatego, że można je zbudować.

Agent ma sens wtedy, gdy istnieje trwały problem. Powtarzalna praca. Duża ilość kontekstu. Wiele źródeł danych. Konieczność pamiętania wcześniejszych decyzji. Albo obszar, którego człowiek po prostu nie jest w stanie stale pilnować.

Następny naturalny obszar to UX

Nie chodzi o agenta, który sam projektuje strony. To byłoby najmniej interesujące zastosowanie. Znacznie ciekawszy jest specjalista pracujący obok projektanta. Może znać projekt i pamiętać wcześniejsze decyzje. Analizować działającą stronę, zbierać sygnały, wskazywać niespójności, śledzić rozwiązania pojawiające się w dobrych produktach. Może zauważyć obszar wart sprawdzenia. Przypomnieć, że podobny pomysł został kiedyś odrzucony. Wyciągnąć z danych coś, czego projektant nie miał czasu regularnie obserwować.

Projektant nadal projektuje. To on rozumie markę i widzi całość. Ale nie musi być jedyną osobą, która pamięta wszystko, obserwuje wszystko i pilnuje wszystkiego. I właśnie tutaj widzę najważniejszą zmianę.

Firma osobowo-agentowa nie polega na tym, że agenty robią wszystko. Polega na tym, że ludzie przestają być sami w swoich specjalizacjach.

Liczba ludzi przestaje opisywać wszystkie kompetencje firmy

Grupa Insight od lat ma szeroki zakres usług. Software. E-commerce. SEO. Ads. UX. Design. AI. Dla zewnętrznego obserwatora naturalne jest pytanie, jak firma tej wielkości może naprawdę rozwijać tyle specjalizacji. Do niedawna odpowiedź była prosta. Dziś zakres specjalizacji firmy przestaje jednak wynikać wyłącznie z liczby osób w zespole. Coraz większe znaczenie mają systemy i cyfrowi specjaliści budowani wokół ich pracy.

Dobry programista nie staje się mniej potrzebny dlatego, że ma agenta znającego projekt. Przestaje po prostu tracić czas na ciągłe odtwarzanie kontekstu.

Specjalista SEO nie znika dlatego, że działa agent SEO. Może poświęcić mniej czasu na zbieranie danych i więcej na rzeczy, które naprawdę wymagają jego głowy.

Projektant nie przestaje być potrzebny dlatego, że obok niego pojawi się agent UX. Dostaje więcej czasu na najważniejszą część swojej pracy - dobrą decyzję.

AI nie musi zmniejszać zespołu. Może zwiększać liczbę specjalizacji dostępnych dla tego samego zespołu.

Firma składająca się z kilkunastu osób może zacząć działać tak, jakby obok nich pracowała dodatkowa warstwa bardzo wąsko wyspecjalizowanych ekspertów. Nie ludzi udających maszyny. Nie maszyn udających ludzi. Po prostu nowych ról.

Być może to właśnie jest firma osobowo-agentowa

Nie wiem jeszcze, czy ta nazwa zostanie z nami na dłużej. Na dziś dobrze opisuje to, co widzę. Firmę złożoną z ludzi i drugiej warstwy wyspecjalizowanych systemów. Programiści mają własnych cyfrowych specjalistów. Projekty własną wiedzę. Marketing ma agentów obserwujących różne obszary. E-commerce ma własny system. Z czasem podobna warstwa pojawi się przy UX i prawdopodobnie w kolejnych częściach organizacji. Każdy agent ma inną rolę, inny kontekst, inne narzędzia i inne uprawnienia.

To, na jakim modelu działa dziś konkretny agent, jest najmniej ważne. Modele będą się zmieniać. Role, wiedza, pamięć i proces zostaną. A ludzie, którzy wiedzą, po co te systemy w ogóle istnieją, nadal będą najważniejszą częścią organizacji. Przez ostatnie lata dużo mówiło się o tym, ilu ludzi zastąpi AI.
Coraz mniej interesuje mnie to pytanie.

Znacznie ciekawsze jest dla mnie to, co stanie się z firmą, w której każdy dobry specjalista może zbudować wokół siebie własny zespół cyfrowych specjalistów.

My chyba właśnie zaczynamy to sprawdzać. Nie poprzez prezentacje i nie poprzez teorię. Po prostu któregoś dnia zorientowaliśmy się, że nasza firma zaczyna mieć więcej specjalistów niż pracowników.