Stos AI, który faktycznie chodzi mi w produkcji
Każde narzędzie AI, które u mnie chodzi w produkcji: co zarobiło sobie miejsce, co wyleciało i jak to wszystko trzyma się razem.
GTM Architect & Growth Operator · Insights · 22 maja 2026
TL;DR · Najważniejsze wnioski
- Cztery warstwy: rozumowanie, wykonanie, research, CRM/dane. Każda ma jedno zadanie i konkretny powód, żeby tam być.
- Lista wyciętych mówi więcej niż lista zachowanych. Zapier, Notion AI i kilka enrichmentów nie przeżyły zderzenia z prawdziwą produkcją.
- Test: narzędzie daje lepszy output, czy tylko przerzuca robotę gdzie indziej? Pierwsze zostaje. Drugie pali ci czas.
Jest taka wersja tego artykułu, której nie napiszę: ta z 47 narzędziami, tabelą porównawczą i oceną na dziesiątki. Czytałeś. Nie pomogło.
Tu jest inna: każde AI, które dziś chodzi u mnie w produkcji, konkretne zadanie, które robi, i powód, dla którego zarobiło sobie slot. Powiem ci też, co wyleciało: to część zwykle bardziej użyteczna niż lista keep.
Jedna rama na start: rozróżniam narzędzia, które dają lepszy output, od tych, które tylko przerzucają pracę gdzie indziej. Pierwsze zostają. Drugie palą ci czas i dają poczucie produktywności, nic przy tym nie naprawiając.
Stos warstwa po warstwie
Claude Sonnet/Opus do złożonej diagnostyki: analiza ICP, review architektury GTM, synteza pozycjonowania. Gdy zadanie wymaga trzymania sprzecznych ograniczeń i dojścia do obroninego wniosku.
Claude Code prowadzi agent stack: research pipelines, pętle enrichmentu, drafty contentu, klasyfikacja CRM. Warstwa, która łączy inteligencję z work product.
Exa MCP do real-time web research. Automatyzacja przeglądarki na stronach blokujących crawlery. Perplexity do syntetycznego background research.
HubSpot MCP do operacji CRM. GA4 i Amplitude jako źródła danych, na podstawie których rozumuje warstwa wnioskowania.
Warstwa 1: Rozumowanie
Claude Sonnet / Opus do złożonej pracy diagnostycznej: analiza ICP, review architektury GTM, synteza pozycjonowania. Wszędzie, gdzie zadanie wymaga trzymania wielu sprzecznych ograniczeń naraz i dojścia do obroninego wniosku, nie tylko dopasowania patternu.
Nie sięgam po Claude’a do wszystkiego. Rutynowy drafting, proste poprawki, zwykłe zapytania researchowe: to nie potrzebuje pełnej warstwy rozumowania. Odpalanie Opus na rewrite subject line’a to jak użycie klucza dynamometrycznego do powieszenia obrazka.
Test operacyjny: Czy dojdę do tej samej odpowiedzi bez niego? Jeśli tak, nie używam. Jeśli zadanie naprawdę wymaga rozumowania: ważenia kompromisów, syntezy sprzecznych sygnałów, zbudowania spójnego argumentu z rozproszonych inputów: wtedy sięgam po tę warstwę.
Warstwa 2: Egzekucja
Claude Code prowadzi agent stack. Research pipelines, pętle enrichmentu, drafty contentu z danych audytowych, klasyfikacja CRM: wszystko leci tutaj. To narzędzie o największej dźwigni w stosie: nie dlatego, że jest najmądrzejsze, ale dlatego, że łączy inteligencję z realnym work product.
Kluczowa konfiguracja: CLAUDE.md per klient, narzędzia MCP do dostępu do danych, Skills do konkretnych podzadań. Opisałem stos outboundowy szczegółowo i jak chodzi u klientów. W skrócie: Claude Code z dobrym kontekstem operatora produkuje robotę, która kiedyś wymagała zespołu.
Cursor do kodu, który musi żyć w repo. Kiedy buduję MCP server, rozszerzam Cloudflare Worker albo shipuję feature do jednego z moich produktów, Cursor obsługuje edycję. Claude Code myśli i prowadzi agentów; Cursor daje integrację IDE i diff review.
Nie dublują się. Claude Code to operator; Cursor to edytor. Różne zadania, różne konteksty.
Warstwa 3: Research
Exa MCP do real-time web research w trakcie agent runów. Exa jest zbudowana pod LLM: semantic search, czyste odpowiedzi, bez dramy z blockowaniem crawlerów. Po kilku miesiącach zastąpiła Brave Search, bo jakość wyników na zapytaniach o firmy jest konsekwentnie lepsza.
Automatyzacja przeglądarki MCP (Playwright) do stron, które blokują tradycyjne scrapowanie: firmowe strony na LinkedIn, cenniki SaaS, sygnały z Glassdoor. To nie jest narzędzie do masowego crawlowania: służy do kilku stron o dużej wartości na projekt, gdzie statyczny search nie wystarczy.
Perplexity do szybkiego background research na branżach, rynkach lub tematach technicznych, gdzie potrzebuję zsyntezowanego punktu startu, nie surowych wyników. Traktuję go jak generator research briefu, nie źródło. Cokolwiek ważnego stamtąd wyciągnę, weryfikuję.
Warstwa 4: CRM i dane
HubSpot MCP do operacji CRM: czytanie rekordów kontaktów i firm, klasyfikacja pod ICP, flagowanie problemów z jakością danych, generowanie payloadów aktualizacyjnych. Większość pracy CRM była wcześniej ręczna i niespójna. Z MCP w loopie logika klasyfikacji jest spójna i audytowalna.
GA4 / Amplitude do analityki: nie przez narzędzia AI, ale jako źródło danych, na podstawie których Claude rozumuje. Pobieram eksporty raportów albo korzystam bezpośrednio z GA4 Data API, a potem karmię warstwę wnioskowania ustrukturyzowanymi danymi. “Oto ostatnie 90 dni pozyskiwania po kanałach i konwersji po kohortach: jaka jest diagnoza?” To zadanie, z którym warstwa rozumowania radzi sobie dobrze, gdy dane są czyste.
Co zostało wycięte
- Zapier : wizualny workflow builder, kruchy przy złożoności
- Notion AI : ciasne okno kontekstowe, generyczny output
- Apollo/Clearbit enrichment : model kredytowy, płytki reasoning
- GPT-4 / Gemini : brak konkretnego zadania w tym stosie
- Serwery MCP : inspekcja, wersjonowanie, nie padają przy zmianach auth
- Claude z pełnym kontekstem wiedzy : myśli w poprzek struktury
- Agent research stack : lepsza jakość outputu w moim use case
- Claude (jedna spójna warstwa rozumowania z jasnymi zadaniami)
To jest ta część, która zazwyczaj nie pojawia się w AI stack roundupach.
Zapier: zastąpiony przez serwery MCP. Zapier świetnie nadaje się do łączenia aplikacji bez pisania kodu, ale każdy złożony proces, który próbowałem w nim zbudować, stawał się problemem przy utrzymaniu. Serwery MCP wymagają więcej pracy na początku i pisania kodu, ale można je sprawdzić, wersjonować i nie psują się, gdy aplikacja aktualizuje swój proces uwierzytelniania.
Notion AI: nigdy nie zasłużył na swoje miejsce. Wyniki były zbyt ogólnikowe. Okno kontekstowe ograniczało się do bieżącej strony, więc nie potrafiło uwzględnić mojej rzeczywistej struktury wiedzy. Piszę w Notion, ale myślę z pomocą Claude’a.
Enrichment Apollo/Clearbit: zastąpiony przez agent research stack w moim use case. W skali z zespołem sprzedaży kredyty enrichmentowe nadal mają sens. Dla jakości researchu i głębokości personalizacji, jakiej potrzebuję w pracy z klientami, agent stack daje lepszy output taniej.
GPT-4 / Gemini: nie w aktywnym użyciu. Nie dlatego, że są złe, ale stos jest już spójny i dodawanie modeli bez konkretnego zadania dla każdego tworzy decision overhead bez poprawy jakości outputu. Pytanie nie brzmi “czy ten model jest dobry?”, tylko “czy robi coś, czego mój obecny stos nie robi?”.
Zasada działania
Stos nie jest po prostu listą narzędzi. To zbiór decyzji dotyczących tego, gdzie w procesie pracy znajduje się inteligencja oraz za co odpowiada każda warstwa.
Warstwa rozumowania: dokonuje oceny, diagnozuje problem, ustala logikę. Warstwa wykonawcza: realizuje zadania, generuje wyniki, utrzymuje kontekst. Warstwa badawcza: dostarcza dane z rzeczywistego świata do pozostałych warstw. Warstwa danych: przechowuje zapisy tego, co się wydarzyło i jakie ma to znaczenie.
Każde narzędzie zasługuje na swoje miejsce, ponieważ wykonuje dane zadanie lepiej niż inne rozwiązania. Gdy narzędzie przestaje spełniać tę rolę: gdy jego wydajność spada, koszty utrzymania rosną lub pojawia się lepsza alternatywa: zostaje wycofane.
Lista ulegnie zmianie. Niektóre z wymienionych tu pozycji znikną za pół roku. Nie ma w tym nic złego. Zasada działania pozostaje ta sama.
Jeśli budujesz stos AI pod GTM i chcesz drugiej opinii, co zostawić i co wyciąć: umów rozmowę.
