O czym jest ten film
- Czym jest „graph engineering” (inżynieria grafu) i czym różni się od prompt engineeringu i context engineeringu.
- Dlaczego wrzucanie całego zadania w jeden czat z AI jest ryzykowne — jeden model w jednym przebiegu decyduje, bada, ocenia i chwali sam siebie.
- Jak wygląda „wersja grafowa”: planer dzieli pytanie, badacze pracują równolegle, sceptyk atakuje słabe wnioski, scalacz tworzy rekomendację, człowiek zatwierdza.
- Podstawowy słownik: graf to zadania połączone strzałkami, a „stan” to wiedza przepływająca przez system.
- Dwa znaczenia słowa „graf” w AI: graf wiedzy (relacje między informacjami) i graf agentowy (przepływ pracy). Odcinek dotyczy tego drugiego.
- Kiedy warto używać grafu, a kiedy to przerost formy — reguła: wiele kroków, część równolegle, wynik wymaga sprawdzenia.
- Rozbudowany przykład: walidacja pomysłu na produkt księgowy dla sprzedawców Shopify — od planera po bramkę człowieka.
- Trzy poziomy zaawansowania: ręczny przebieg, Claude Code z plikami .md, dopiero potem narzędzia jak LangGraph, AutoGen, n8n, make.com.
- Praktyczne zastosowania: obsługa klienta, produkcja treści, programowanie (przegląd kodu, testy, pull requesty).
- Główna pułapka: więcej agentów nie znaczy lepiej. Celem jest najmniejszy graf, który podnosi jakość — plus „pamięć”, którą praca po sobie zostawia.
Redakcyjne tłumaczenie
Kolejny modny termin — czy tym razem coś warty?
Przyszedłem tu, żeby porozmawiać o pojęciu, które od jakiegoś czasu robi furorę na Twitterze: graph engineering, czyli inżynieria grafu. Na pewno je widzieliście — ja też. I szczerze mówiąc, kiedy zobaczyłem je po raz pierwszy, pomyślałem: „Dobra, to realna rzecz, czy znów wymyśliliśmy hasło, żeby każdy poczuł, że zostaje w tyle?”. Bo AI ma tę zabawną właściwość, że co kilka tygodni wybucha nowy termin: prompt engineering, context engineering, agent engineering, vibe coding, loop engineering, a teraz inżynieria grafu.
Część tych haseł to czysty hype. Część jest naprawdę przydatna. Inżynieria grafu należy do tych przydatnych, bo daje dużo lepszy sposób myślenia o tym, jak praca z AI faktycznie zostaje wykonana. W tym odcinku wyjaśnię ją prostym językiem. Chcę, żebyś pod koniec potrafił wziąć jeden przepływ pracy, który już prowadzisz z AI — badanie klientów, sortowanie zgłoszeń, produkcję treści albo walidację pomysłu na startup — i zamienić go w prostą mapę kroków, kontroli, przekazań, pętli i akceptacji człowieka.
Trzy poziomy: prompt, kontekst i graf
Najprościej ująć to tak. Prompt engineering to sposób, w jaki lepiej pytasz AI. Context engineering to sposób, w jaki dostarczasz AI lepszych informacji. A inżynieria grafu to sposób, w jaki projektujesz pracę wokół AI — tak, żeby całość przestała żyć w jednym wielkim, chaotycznym czacie.
Podam przykład. Wyobraź sobie, że badasz nowy pomysł. Większość ludzi otwiera czat i pyta: „Czy powinienem zbudować ten produkt?”. Model da pewną siebie odpowiedź. Zabrzmi całkiem mądrze. Może poda wielkość rynku, kilku konkurentów, może plan wejścia na rynek — i masz wrażenie, że zrobiłeś research.
Ale jeśli zwolnisz, zauważysz coś niewygodnego. Jeden model w jednym przebiegu zdecydował, co jest ważne, zbadał rynek, zinterpretował dowody, napisał rekomendację i sam ocenił swoją pewność. To dużo zaufania włożonego w jeden blok tekstu. W skrajnym przypadku możesz oprzeć na tej jednej odpowiedzi lata swojego życia — i pracować nad czymś zupełnie nie tym.
Jak wygląda wersja grafowa
Wersja grafowa wygląda zupełnie inaczej. Najpierw planer rozbija pytanie na osie. Jeden badacz przygląda się klientowi, drugi konkurencji, kolejny dystrybucji, następny cenom, jeszcze inny ryzykom. Potem sceptyk próbuje zabić słabe wnioski. Następnie scalacz zamienia to, co przetrwało, w jednostronicową rekomendację. A na końcu ty zatwierdzasz decyzję, zanim zaczniesz działać.
Efektem wciąż może być pisemny raport, ale praca za nim jest zaprojektowana o wiele lepiej. I to jest w istocie inżynieria grafu: bierzesz chaotyczne zadanie AI i zamieniasz je w przepływ, którym da się realnie zarządzać.
Podstawowy słownik bez wykładu z informatyki
Zdefiniujmy pojęcia, nie robiąc z tego wykładu akademickiego. Swoją drogą, jednym z pierwszych przedmiotów na studiach była u mnie teoria grafów, więc to dla mnie sentymentalny powrót. (Informacja dodatkowa: teoria grafów to dział matematyki o obiektach — „wierzchołkach” — połączonych „krawędziami”; stąd cała metafora tego odcinka).
Kiedy ludzie mówią „graf”, mają na myśli po prostu zadania połączone strzałkami. Każde zadanie to krok w przepływie. Strzałki pokazują, co dzieje się dalej. A wspólne notatki przepływające przez system to „stan” — czyli po prostu: co system wie do tej pory. Brzmi technicznie przez jakieś pięć sekund, po czym uświadamiasz sobie, że tak właśnie w rzeczywistości wykonuje się pracę.
Pomyśl o obsłudze klienta. Gdy klient pisze, praca rzadko sprowadza się do „odpowiedz na zgłoszenie”. Najpierw trzeba zrozumieć, jakiego rodzaju to problem. Potem sprawdzić historię konta klienta. Może przeszukać dokumentację w poszukiwaniu właściwej zasady. Potem napisać odpowiedź. Wreszcie zdecydować, czy sprawa jest na tyle ryzykowna, że przed wysyłką powinien ją przejrzeć człowiek. Gdy narysujesz te kroki i połączysz w kolejności, w której faktycznie od siebie zależą — to jest graf.
Weźmy treści. Gdy robię odcinek na YouTube, praca to nie samo „napisz skrypt”. Dobry odcinek zaczyna się od researchu, tezy, przykładów, haka, może skryptu, potem pomysły na tytuły, kierunki na miniaturę, tablica w Excalidraw, a na końcu przejście, w którym pytam: „Czy to brzmi jak człowiek, czy jak ktoś uwięziony w onboardingu jakiegoś SaaS-a?”. Część tych kroków musi następować po sobie — tezę chcesz mieć przed skryptem, skrypt przed tablicą. Ale inne mogą dziać się równolegle: jeden badacz szuka przykładów, drugi kontrargumentów, jeden bada kąt odbiorcy, drugi praktyczne workflow. Potem te wyniki scalają się z powrotem w skrypt.
Dlaczego prosta linia czatu zawodzi
I tu graf zaczyna się opłacać. Większość ludzi używa AI w linii prostej, bo czat sprawia, że wszystko wydaje się sekwencyjne. Pytasz o research, potem o podsumowanie, potem o szkic, potem o poprawki, potem o tytuły. Dla prostych rzeczy to działa. Ale gdy praca ma wiele elementów, linia prosta staje się wolna, rozmyta i trudna do zaufania.
Graf pozwala zaprojektować pracę jak mały zespół. Jedna część planuje, kilka pracuje równolegle, inna sprawdza, jeszcze inna scala, a człowiek zatwierdza ostatni krok. Gdy to zaskoczy, robi się dużo mniej tajemnicze.
Dwa znaczenia słowa „graf”
Tu rodzi się sporo zamieszania, bo są dwie różne rzeczy nazywane grafem w AI.
Pierwsza to graf wiedzy. Pomaga AI rozumować o relacjach między rzeczami. Na przykład: ten klient pracuje w tej firmie, ta firma używa tego produktu, ten produkt łączy się z tym narzędziem, to zgłoszenie dotyczy tej funkcji, a ta funkcja należy do tego zespołu. Grafy wiedzy pomagają, bo zwykły RAG często pobiera fragmenty tekstu podobne do pytania, ale gubi się, gdy odpowiedź wymaga połączenia różnych osób, firm, tematów, twierdzeń i zdarzeń. (Informacja dodatkowa: RAG, retrieval-augmented generation, to technika, w której model najpierw wyszukuje pasujące fragmenty dokumentów, a potem na ich podstawie generuje odpowiedź). Istnieją narzędzia w rodzaju Microsoft GraphRAG, bo czasem AI musi zrozumieć relacje wewnątrz wiedzy, a nie tylko pobrać najbliższy akapit.
Druga wersja to graf agentowy. Dotyczy tego, jak przemieszcza się praca: planer przekazuje zadania badaczom, badacze pracują równolegle, sceptyk sprawdza wnioski, syntezator scala części, a człowiek zatwierdza końcową odpowiedź. Ten odcinek jest głównie o grafach agentowych, bo to wersja, którą jako founder, twórca, operator czy mały zespół możesz zacząć stosować już dziś.
Najłatwiej zapamiętać różnicę tak: grafy wiedzy pomagają AI rozumieć, jak łączą się informacje, a grafy agentowe — jak powinna przemieszczać się praca. Docelowo najlepsze systemy używają obu.
Kiedy używać grafu, a kiedy nie
Jak to utaktycznić? Używaj grafu, gdy praca ma wiele kroków, wiele źródeł, może wiele ścieżek, kontrole, ryzyko lub akceptacje. Jeśli prosisz AI o dziesięć nazw dla projektu albo o streszczenie krótkiego maila — grafu nie potrzebujesz. Ale jeśli robisz głęboki research, plan wejścia na rynek, sortowanie zgłoszeń, przegląd kodu, przygotowanie do rozmów sprzedażowych, syntezę opinii klientów albo cykliczną produkcję treści — wtedy myślenie grafowe zaczyna się liczyć.
Reguła jest prosta: użyj grafu, gdy praca ma wiele kroków, część z nich może dziać się równocześnie, a końcowy wynik wymaga sprawdzenia, zanim zacznie mieć znaczenie. Kształt przypomina romb: zaczyna się od jednego pytania, rozdziela na równoległe ścieżki, sprawdza pracę i scala wszystko z powrotem w jedną odpowiedź.
Przykład: produkt księgowy dla sprzedawców Shopify
Załóżmy, że pytanie brzmi: „Czy powinienem uruchomić produkt księgowy oparty na AI dla sprzedawców Shopify?”. Wersja chaotyczna to jedno wielkie pytanie i jedna wielka odpowiedź.
Wersja grafowa zaczyna się od planera. Planer mówi mniej więcej: „Żeby dobrze odpowiedzieć, musimy zrozumieć ból klienta, krajobraz konkurencji, punkt wejścia na rynek, presję cenową i ryzyka”. A potem praca się rozdziela.
Jeden badacz studiuje sprzedawców Shopify i ich ból związany z księgowością. Używają QuickBooks? Arkuszy? Zatrudniają księgowych? Denerwują się w okresie podatkowym? Szukają automatyzacji, czy tylko kogoś, kto raz w miesiącu posprząta bałagan?
Drugi badacz studiuje konkurentów. Czy istnieją już narzędzia księgowe dla Shopify? Czy firmy księgowe budują to ręcznie? Czy produkty w App Store w ogóle to rozwiązują? Czy freelancerzy na Upwork albo Fiverr robią pracę, którą oprogramowanie mogłoby częściowo zastąpić?
Trzeci badacz studiuje dystrybucję. Gdzie faktycznie przebywają sprzedawcy Shopify? Jakie newslettery czytają? Które agencje mają już ich zaufanie? Jakie kategorie aplikacji Shopify przeszukują? Jakie frazy zdradzają intencję zakupową? Te trzy zadania mogą dziać się równocześnie, bo od siebie nie zależą.
Potem wchodzi sceptyk. Pyta: które twierdzenia są rzeczywiście poparte dowodami? Które dane są nieaktualne? Którego konkurenta pomijamy? Gdzie mylimy ból z gotowością do zapłaty? Gdzie AI brzmiało pewnie, niczego nie udowadniając? Ten krok znaczy więcej, niż się wydaje. Wiele researchu AI zawodzi, bo ten sam model, który pisze odpowiedź, sam ją ocenia. To jak prosić kogoś, żeby napisał sobie ocenę okresową, a potem dziwić się, że opisuje siebie jako wizjonera. W dobrym grafie sprawdzanie jest osobnym zadaniem.
Potem następuje scalenie. Krok scalający bierze dowody, które przetrwały, i zamienia je w rekomendację. Realizować? Wstrzymać? Zabić? Jaki jest punkt wejścia? Kto jest pierwszym klientem? Co przetestować w tym tygodniu? Jaki dowód realnie zmieniłby nasze zdanie?
Na końcu jest bramka człowieka. Tam decydujesz, co dalej. Może nagrasz analizę landing page’a sprzedawcy Shopify. Może przeprowadzisz wywiady z dziesięcioma właścicielami agencji. Może zbudujesz mały kalkulator szacujący koszt uporządkowania księgowości. A może uznasz, że rynek jest zbyt zatłoczony, i pójdziesz dalej. I o to chodzi: inżynieria grafu nie podejmuje za ciebie decyzji. Daje lepszy sposób wytworzenia dowodów, na których tę decyzję opierasz.
Zacznij dużo prościej, niż widzisz na Twitterze
Tu ludzie zbyt szybko przekombinowują. Na Twitterze widzisz, jak od pierwszego dnia używają LangGraph, AutoGen albo własnych frameworków agentowych. Swój pierwszy graf możesz spokojnie uruchomić ręcznie, za kulisami. Nie wiem, czemu mało kto tak robi.
Ważna jest struktura. Nadaj każdemu zadaniu własny „pas ruchu”. Jeden pas robi research klienta, drugi konkurencji, trzeci dystrybucji. Potem pas kontrolera atakuje dowody, a pas scalający zamienia to, co przetrwało, w rekomendację. To już jest inżynieria grafu — poziom pierwszy. Tak, jest wolniejsza niż w pełni zautomatyzowany system, ale dużo łatwiejsza do zrozumienia. A jeśli wersja ręczna nie daje wyraźnie lepszej pracy, to jej automatyzacja po prostu wyprodukuje mierną pracę szybciej.
Pierwszy trening to narysowanie grafu, zanim go zautomatyzujesz. Ja zrobiłbym to na pustej tablicy Excalidraw albo TLDraw. Na górze zapisałbym końcowy rezultat. Potem narysował zadania: planer, badacz klienta, badacz konkurencji, badacz dystrybucji, sceptyk, scalenie, akceptacja człowieka. Potem strzałki: planer zasila trzech badaczy, badacze zasilają sceptyka, sceptyk zasila scalenie, scalenie zasila decyzję człowieka. I to wystarczy.
Poziom średni i zaawansowany
Gdy zadziała trzykrotnie ręcznie, dopiero wtedy sięgam po narzędzia. Wersja średniozaawansowana to Claude Code albo repozytorium, gdzie każdy krok zapisuje pliki. Planer pisze plan.md, badacz customer.md, competitors.md i distribution.md, sceptyk review.md, a krok scalający recommendation.md. Fajne jest to, że zostaje ślad — widzisz, co się wydarzyło, porównujesz wersje i możesz ponownie użyć struktury za tydzień czy kilka tygodni później.
Wersja zaawansowana to LangGraph, AutoGen Graph Flow, n8n, make.com albo własne skrypty do orkiestracji grafu. LangGraph jest przydatny, gdy chcesz punkty kontrolne stanu, trwałość, akceptacje z człowiekiem w pętli i bardziej niezawodną kontrolę przebiegu. AutoGen Graph Flow sprawdza się, gdy chcesz ukierunkowany przepływ z krokami sekwencyjnymi, równoległymi, warunkowymi rozgałęzieniami i pętlami. Narzędzia jak n8n czy make.com przydają się, gdy graf dotyka codziennych systemów: Slacka, poczty, Airtable czy CRM. (Informacja dodatkowa: n8n i make.com to platformy do automatyzacji bez kodu, łączące różne aplikacje w przepływy).
Ale narzędzie nie jest istotą — powinno przyjść po workflow. Jeśli zautomatyzujesz przepływ, którego nie rozumiesz, dostaniesz bałagan. Jeśli najpierw go zrozumiesz, automatyzacja staje się oczywista.
Zastosowania w firmie
Obsługa klienta. Prosty graf zaczyna od klasyfikacji problemu: rozliczenia, mylący produkt, błąd, ryzyko rezygnacji, czy coś innego. Potem sprawdza kontekst konta: nowy klient, wartościowy, pisał już wcześniej, sfrustrowany? Potem przeszukuje dokumentację i wewnętrzne zasady — może całą firmową wiki czy tablicę w Notion. Potem tworzy szkic odpowiedzi. Kontroler sprawdza go pod kątem trafności, tonu i ryzyka. A człowiek zatwierdza wszystko, co dotyczy zwrotów, zmian na koncie, rozzłoszczonych klientów, ryzyka prawnego czy obietnic, których firma może później żałować. Prawdziwy przepływ to nie „odpowiedz na zgłoszenie”, lecz: zrozum, zbadaj, napisz, sprawdź, zatwierdź.
Tworzenie treści. Graf treści zaczyna od researchu, potem tezy, przykładów, haka, szkicu skryptu. Kontroler pyta, czy przykłady są konkretne, czy tempo działa, czy hak zasługuje na uwagę wobec działających formatów i czy tekst brzmi jak dana osoba. Potem graf rozgałęzia się na tytuły, koncepcje miniatur, opisy, B-roll. To bliskie temu, jak pracowałby prawdziwy lider treści, którego byś zatrudnił.
Programowanie. Graf kodowania zaczyna od planu, potem jeden agent edytuje kod, drugi przegląda różnice, kolejny uruchamia testy, następny sprawdza interfejs w przeglądarce, jeszcze inny szuka przypadków brzegowych, a człowiek zatwierdza końcowy pull request. Tam właśnie zmierzają narzędzia do kodowania z AI. Sam model piszący kod to tylko jeden element — dźwignia jest w planowaniu, testowaniu, przeglądaniu i decydowaniu, co bezpiecznie wdrożyć.
To ważny punkt: inżynieria grafu sprawia, że jakość mniej zależy od tego, czy ktoś zapamięta idealny prompt. Uspójnia przeglądy, czyści delegowanie, czyni akceptację wyraźną, daje miejsce na dokładanie narzędzi, pamięci, kontroli i uprawnień w czasie — i zamienia pracę z AI z czatu w rodzaj systemu operacyjnego.
Jedna pułapka: więcej agentów nie znaczy lepiej
Chcę przestrzec przed jednym błędem: więcej agentów nie oznacza automatycznie lepszego wyniku. Czasem więcej agentów to więcej szumu — pięciu pracowników AI pewnie powtarzających ten sam błędny pomysł. Czasem system spędza więcej czasu na koordynacji niż na myśleniu. Celem nie jest największy możliwy graf. Widziałem, jak ludzie na X stają się wirusowi z ogromnymi grafami, ale to nie o to chodzi. Celem jest najmniejszy graf, który podnosi jakość pracy.
Dobry graf usuwa fałszywe czekanie, oddziela pracowników od kontrolerów, wstawia akceptację człowieka tam, gdzie błędy są kosztowne, zatrzymuje się, gdy odpowiedź jest wystarczająco dobra, i zostawia użyteczny stan: notatki, dowody, szkice, źródła i decyzję — żeby dało się z tego skorzystać później.
Kontekst jako fosa: praca, która tworzy pamięć
Ten ostatni punkt jest niedoceniany, bo prawdziwa kumulująca się wartość inżynierii grafu polega nie na tym, że jedno zadanie wychodzi lepiej. Chodzi o to, że twoja praca zaczyna produkować pamięć. Każdy graf badania klienta tworzy lepsze notatki o klientach. Każdy graf treści tworzy lepsze przykłady i wglądy o odbiorcach. Każdy graf wsparcia tworzy lepszy feedback produktowy. Tu kontekst staje się fosą: graf produkuje pracę, ale też produkuje pamięć, która sprawia, że następny graf jest mądrzejszy. Staje się twoim aktywem.
Jak zacząć
Wybierz jeden przepływ, który już co tydzień prowadzisz z AI — może badanie pomysłów, przygotowanie odcinków podcastu, przegląd landing page’y, analiza opinii klientów. Zapisz końcowy wynik w jednym zdaniu, na przykład: „Chcę jednostronicową rekomendację, czy ten pomysł na startup warto testować”.
Potem wypisz zadania, które wykonałby świetny człowiek: doprecyzowałby pytanie, zbadał klientów, konkurentów, dystrybucję, ryzyka, sprawdził dowody, sformułował rekomendację. Narysuj strzałki tam, gdzie praca faktycznie zależy od poprzedniego kroku — badanie klientów i konkurencji może dziać się równocześnie, ale sceptyk potrzebuje najpierw researchu, a rekomendacja potrzebuje przejścia sceptyka.
Dodaj jedną bramkę człowieka przed kosztowną decyzją. Jeśli wynikiem jest prywatna notatka, bramka może być lekka. Jeśli to mail do klienta, publiczny post, wdrożenie kodu, zwrot pieniędzy albo cokolwiek dotykającego danych produkcyjnych — bramka musi być surowsza. Potem przejdź to raz ręcznie. Nie musisz budować gigantycznego projektu automatyzacji — po prostu stwórz zadania i strzałki.
Kiedy zrobisz to raz, zaczniesz inaczej widzieć pracę z AI. Przestaniesz myśleć „jaki jest najdoskonalszy prompt do tego zadania”, a zaczniesz myśleć „jaki jest najdoskonalszy workflow” — i projektować ścieżkę, która daje odpowiedź. Dlatego uważam inżynierię grafu za koncept warty uwagi. To kolejny logiczny krok po promptowaniu. Najwięcej z AI wyciągną ludzie, którzy potrafią rozbić pracę na właściwe kawałki, dać każdemu odpowiedni kontekst, sprawdzić wynik i utrzymać człowieka we właściwym miejscu.
Podsumowując: wybierz jeden przepływ, narysuj zadania i strzałki, usuń fałszywe czekanie, uruchom niezależne zadania równolegle, dodaj sceptyka, scal to, co przetrwało, sam zatwierdź ostatni krok. Masz swój pierwszy graf. A gdy jeden graf działa, nie promptujesz już AI — zarządzasz jego pracą. To kolejny poziom: bycie menedżerem agentów.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Graf to trzeci poziom po prompcie i kontekście
Na czym polega: Prompt engineering poprawia pytanie, context engineering poprawia dostarczane informacje, a inżynieria grafu projektuje samą pracę wokół AI, żeby nie żyła w jednym czacie.
Jak stosować: Zanim zaczniesz „optymalizować prompt”, zapytaj, czy problem nie jest w istocie problemem workflow — czy zadanie nie ma wielu kroków, które warto rozdzielić.
Na co uważać: Nie każde zadanie potrzebuje grafu. Do prostych, jednokrokowych zadań to przerost formy.
2.Jeden czat = jeden model robi wszystko naraz
Na czym polega: W zwykłym czacie ten sam model decyduje, co ważne, bada, interpretuje, pisze rekomendację i sam ocenia swoją pewność — to za dużo zaufania w jeden blok tekstu.
Jak stosować: Przy decyzjach o dużej stawce (na których oprzesz miesiące pracy) świadomie rozdziel te role zamiast wierzyć jednej pewnej siebie odpowiedzi.
Na co uważać: Pewny ton modelu nie jest dowodem trafności. Im ładniej brzmi odpowiedź, tym większa pokusa, by pominąć weryfikację.
3.Sprawdzanie musi być osobnym zadaniem
Na czym polega: Wiele researchu AI zawodzi, bo model, który pisze odpowiedź, sam ją ocenia — jak pracownik piszący sobie ocenę okresową. W grafie sceptyk to oddzielna rola, która atakuje słabe wnioski.
Jak stosować: Dodaj krok, w którym osobny agent (albo osobny przebieg) pyta: które twierdzenia są poparte, które dane nieaktualne, gdzie mylimy ból z gotowością do zapłaty.
Na co uważać: Sceptyk musi dostać research, zanim go oceni — to zależność sekwencyjna, nie da się jej zrównoleglić z badaniem.
4.Odróżniaj graf wiedzy od grafu agentowego
Na czym polega: Graf wiedzy pomaga AI rozumieć relacje między informacjami; graf agentowy porządkuje przepływ pracy. To dwie różne rzeczy nazywane tym samym słowem.
Jak stosować: Na start skup się na grafie agentowym — to on jest natychmiast użyteczny dla foundera, twórcy czy operatora. Graf wiedzy (np. GraphRAG) rozważ, gdy odpowiedzi wymagają łączenia rozproszonych faktów.
Na co uważać: Nie myl ich w dyskusjach — rozmówca może mieć na myśli zupełnie inny problem. Docelowo najlepsze systemy łączą oba.
5.Reguła włączenia grafu: wiele kroków, równoległość, kontrola
Na czym polega: Graf ma sens, gdy praca ma wiele kroków, część może dziać się równocześnie, a wynik wymaga sprawdzenia, zanim zacznie mieć znaczenie.
Jak stosować: Zastosuj do deep researchu, planów GTM, sortowania zgłoszeń, przeglądu kodu, syntezy opinii, cyklicznych treści. Do 10 nazw czy streszczenia maila — odpuść.
Na co uważać: Kryterium „wymaga sprawdzenia” jest kluczowe — jeśli wynik nie niesie ryzyka, dodatkowa struktura tylko spowalnia.
6.Najpierw uruchom graf ręcznie, dopiero potem automatyzuj
Na czym polega: Pierwszy graf możesz przejść ręcznie, dając każdemu zadaniu osobny „pas”. To już jest inżynieria grafu — poziom pierwszy, wolniejszy, ale zrozumiały.
Jak stosować: Narysuj graf na Excalidraw/TLDraw: rezultat na górze, zadania jako węzły, strzałki jako zależności. Przejdź go ręcznie trzy razy, zanim sięgniesz po narzędzia.
Na co uważać: Jeśli wersja ręczna nie daje wyraźnie lepszej pracy, automatyzacja tylko wyprodukuje mierny wynik szybciej. Nie automatyzuj czegoś, czego nie rozumiesz.
7.Trzy poziomy dojrzałości: ręcznie → pliki .md → orkiestrator
Na czym polega: Poziom podstawowy to ręczne pasy, średni to Claude Code, gdzie każdy krok zapisuje plik (plan.md, customer.md, review.md, recommendation.md), zaawansowany to LangGraph, AutoGen, n8n czy make.com.
Jak stosować: Wersja z plikami .md daje ślad audytowy — możesz porównywać wersje i ponownie użyć struktury za tydzień. LangGraph wybierz, gdy potrzebujesz punktów kontrolnych stanu i człowieka w pętli; n8n/make, gdy graf dotyka Slacka, poczty czy CRM.
Na co uważać: Narzędzie to nie istota — dobierz je po zrozumieniu workflow, nie odwrotnie.
8.Bramka człowieka dopasowana do stawki
Na czym polega: Przed kosztowną lub nieodwracalną decyzją wstaw akceptację człowieka; jej surowość zależy od ryzyka.
Jak stosować: Przy prywatnej notatce bramka może być lekka. Przy mailu do klienta, publicznym poście, wdrożeniu kodu, zwrocie pieniędzy czy danych produkcyjnych — zdecydowanie surowsza i obowiązkowa.
Na co uważać: Graf nie podejmuje decyzji za ciebie — dostarcza dowodów. Nie oddawaj bramki automatowi tam, gdzie błąd jest drogi.
9.Najmniejszy skuteczny graf, nie największy
Na czym polega: Więcej agentów to często więcej szumu — pięciu pracowników AI pewnie powtarzających ten sam błąd albo system, który więcej czasu koordynuje niż myśli. Celem jest najmniejszy graf podnoszący jakość.
Jak stosować: Usuwaj fałszywe czekanie, oddzielaj pracowników od kontrolerów, zatrzymuj graf, gdy odpowiedź jest wystarczająco dobra.
Na co uważać: Wirusowe, rozbudowane grafy z X to nie wzorzec do naśladowania. Rozrost to koszt, nie zaleta.
10.Graf produkuje pamięć — kontekst jako fosa
Na czym polega: Prawdziwa kumulująca się wartość to nie lepsze pojedyncze zadanie, lecz to, że praca zostawia po sobie pamięć: lepsze notatki o klientach, przykłady, feedback produktowy, które robią następny graf mądrzejszym.
Jak stosować: Świadomie zapisuj stan każdego przebiegu (notatki, dowody, źródła, decyzję) w trwałym miejscu, żeby zasilał kolejne uruchomienia.
Na co uważać: Wartość kumuluje się tylko, jeśli faktycznie zachowujesz i ponownie wykorzystujesz stan — ulotny wynik czatu tej pamięci nie buduje.