Od zera do systemu AI w kwartał. Część 15: AI podłączone do narzędzi.

W części 14 zbudowaliśmy pierwszy proces, który działa sam. Trigger (wyzwalacz), akcja, efekt. Mały krok, wyraźna zmiana.

Ale nawet ten proces miał ograniczenie. AI działało tylko na danych, które ktoś mu podał na wejściu. Treść maila, plik w vault. Nic więcej.

Pojawia się naturalne pytanie. A co, jeśli chcę, żeby AI przed odpowiedzią sam sprawdził mój kalendarz? Zobaczył, ile mam zamówień dzisiaj? Przeczytał ostatnie maile od klienta, bez kopiowania ich ręcznie?

Do tego służą integracje. AI dostaje dostęp do Twoich narzędzi i zamiast prosić Cię o wszystko, sam wyciąga potrzebne dane. Odpowiedzi stają się konkretniejsze, bo model operuje na Twoich realiach, a nie abstrakcji.

W tym artykule pokażę cztery warstwy tej integracji. Od najprostszej (czyste API), przez gotowe węzły w workflow i MCP, aż do warstwy, o której mówi się najmniej: hooków w samym kliencie AI. Każda warstwa ma swoje miejsce. Nie wszystko trzeba robić najnowszym sposobem.

Zastrzeżenie: to co opisuję w tym cyklu bazuje na moim stacku technologicznym, czyli macOS i Claude jako główny model językowy. Zasady i podejście działają na każdym systemie operacyjnym i z każdym modelem AI, ale konkretne kroki i skróty klawiszowe opisuję pod Maca. Jeśli pracujesz na Windows lub Linux, większość rzeczy zrobisz tak samo, ale powyższe systemy mogą się różnić detalami, które musisz dostosować.

Ważne: opisuję tu model uproszczony, czyli idealny obraz tego, jak działa ten fragment systemu. W praktyce mój obecny system ma więcej warstw, wyjątków i automatyzacji. Na potrzeby tego cyklu pokazuję wersję, którą najłatwiej zrozumieć i odtworzyć u siebie.

Warstwa 1: API, czyli drzwi do systemów

API (Application Programming Interface) to sposób, w jaki systemy ze sobą rozmawiają. Każde większe narzędzie ma API. Gmail ma API. Kalendarz Google ma API. Shopify ma API. Instagram ma API (ograniczone, ale jest).

Dla Ciebie jako użytkownika API to “inny sposób korzystania z tego samego narzędzia”. Zamiast klikać w interfejsie, wysyłasz komendę tekstową i dostajesz odpowiedź.

Przykład. Chcesz dostać listę spotkań z najbliższego tygodnia. W interfejsie Google Calendar klikasz sidebar, przeglądasz listę, może kopiujesz tytuły. Przez API wysyłasz jedno zapytanie i dostajesz JSON z listą spotkań. AI czyta JSON jak zwykły tekst i może z nim pracować.

Prosty przykład z mojego systemu:

Sprawdź mój kalendarz Google na jutro. Jeśli mam spotkanie z klientem, przygotuj mi krótki brief: z kim, o której, jaki był kontekst ostatniej rozmowy (przeczytaj plik klienta w vault), jakie są pytania otwarte. Brief ma być krótszy niż pół strony.

Pod spodem dzieje się taka sekwencja:

AI wywołuje API kalendarza, pobiera listę jutrzejszych wydarzeń
Dla każdego klienta otwiera odpowiedni plik w vault
Wyciąga ostatnie ustalenia i pytania otwarte
Składa z tego brief

Sam bym robił to kilkanaście minut. System robi to w pięć sekund. Dlatego, że AI ma dostęp zarówno do kalendarza (przez API), jak i do wiedzy (przez pliki).

Trzy rzeczy, o które prosisz API

Każda integracja przez API obraca się wokół trzech operacji.

Czytanie. Pobierz listę z rzeczami. Pokaż mi dane z tego narzędzia. Sprawdź, co tam jest teraz. Większość integracji zaczyna się od czytania, bo to najprostsze i najbezpieczniejsze.

Szukanie. Znajdź rzeczy spełniające warunek. Pokaż mi wszystkie maile od konkretnego klienta z ostatniego miesiąca. Pokaż zamówienia o wartości powyżej tysiąca złotych.

Zapisywanie. Stwórz coś, zmień status, wyślij mail. To jest najbardziej inwazyjne, bo zmienia coś w systemie zewnętrznym. Tu trzeba być ostrożnym. Raz wysłany mail nie wraca.

Na początku integracji wystarczą Ci operacje czytania. AI widzi Twoje narzędzia, ale nic nie zmienia. Czujesz się bezpieczniej. Gdy zbudujesz zaufanie, dodajesz operacje zapisu.

Jak dajesz AI dostęp do API

Każde narzędzie wymaga autentykacji. API nie otwiera się dla każdego, kto zapyta. Musisz się przedstawić kluczem.

Typowy przepływ:

Krok 1: Logujesz się do panelu administratora narzędzia.

Krok 2: Szukasz sekcji “Developer”, “API”, “Integrations” albo podobnej.

Krok 3: Tworzysz klucz API. Może wyglądać jak długi ciąg znaków. Kopiujesz go.

Krok 4: Zapisujesz klucz w bezpiecznym miejscu. U mnie to plik w folderze POUFNE/ w vault, który nigdy nie trafia do żadnego backupu publicznego ani Gita.

Krok 5: W skrypcie lub workflow podajesz klucz jako parametr przy wywołaniu API.

Ważne: klucze nie są jak hasła wieczne. Jeśli przypadkiem wyślesz klucz w mailu lub pokażesz na wideo, trzeba go unieważnić i wygenerować nowy. Większość narzędzi pozwala to zrobić z panelu.

Drugie ważne. Niektóre klucze mają różne poziomy uprawnień. “Tylko czytanie” vs “pełny dostęp”. Zawsze wybieraj najmniejszy poziom, który wystarcza do Twojego zastosowania. Jeśli AI ma tylko czytać maile, nie dawaj mu klucza, który pozwala je też kasować.

Warstwa 2: gotowe integracje w Twoim procesie

Budowanie każdej integracji od zera, z ręcznym pisaniem zapytań do API, jest żmudne. Szczęśliwie większość popularnych narzędzi ma gotowe “węzły” w n8n, Make i innych platformach workflow.

Zamiast pisać kod, w n8n wybierasz z listy “Gmail”, logujesz się do swojego konta przez OAuth, i masz gotową operację “pobierz nowe maile”, “wyślij mail”, “dodaj etykietę”.

To jest warstwa, na której większość ludzi zostaje. I bardzo słusznie. Ośmiu z dziesięciu automatyzacji możesz zbudować z gotowych węzłów.

Kiedy to wystarcza:

Gdy narzędzie ma gotowy węzeł. Gmail, Calendar, Slack, Notion, Airtable, Google Sheets, Shopify, HubSpot i setki innych mają integracje w n8n. Po prostu używasz.

Gdy nie potrzebujesz niestandardowych operacji. Gotowy węzeł pokryje 90% operacji. Pozostałe 10% to zwykle rzeczy, które robisz rzadko.

Gdy nie masz doświadczenia z kodem. Węzeł klikasz, konfigurujesz, działa. Bez linijki kodu.

Kiedy musisz wyjść poza gotowe węzły:

A) Gdy narzędzie nie ma integracji. Niektóre polskie systemy (Comarch, niektóre CMS-y polskie) nie mają gotowych węzłów. Musisz użyć ogólnego węzła “HTTP Request” i ręcznie skonfigurować zapytanie.

B) Gdy potrzebujesz niestandardowej operacji. Masowe przetwarzanie setek rekordów, specyficzna kolejność operacji, logika która nie mieści się w jednym węźle.

W obu przypadkach AI może Ci pomóc. Wklejasz dokumentację API narzędzia i prosisz model:

Chcę w n8n wywołać API [nazwa narzędzia]. Konkretne zadanie: [opis]. Mam klucz API. Napisz mi konfigurację węzła HTTP Request: URL, metoda, nagłówki, body. Plus przykład odpowiedzi, której się spodziewać.

Dostajesz gotową konfigurację. Kopiujesz do n8n. Jeśli coś nie działa, wrzucasz błąd z powrotem do AI, model poprawia. Iteracja trwa kilka minut zamiast godzin.

Warstwa 3: MCP, czyli protokół zamiast osobnych integracji

W listopadzie 2024 Anthropic (twórca Claude) ogłosił standard o nazwie Model Context Protocol (MCP). W szybkim tempie zaczęły go obsługiwać inne modele.

Jedna rzecz z tej historii jest ważniejsza, niż wygląda. Pod koniec 2025 Anthropic przekazał MCP fundacji przy Linux Foundation, obok projektów Block i OpenAI. Standard przestał więc być cechą jednego dostawcy, a stał się czymś, czym zarządza się wspólnie. Dla kogoś, kto buduje system, to nie ciekawostka: integracja napisana pod MCP przeżyje zmianę modelu, którego używasz. Integracja napisana pod jednego dostawcy przeżyje ją tylko przypadkiem.

Idea jest prosta. Zamiast programować każdą integrację osobno, ustalasz uniwersalny protokół, w którym narzędzia “zgłaszają” modelowi, co potrafią. Model wie, z czego może skorzystać, i wybiera odpowiednie narzędzia w zależności od pytania.

Konkretny przykład. Mam serwer MCP do semantic search po moim vault. Model pyta (wewnętrznie, bez udziału mnie) “jakie narzędzia są dostępne?” Serwer odpowiada: “mam funkcję search z parametrami: zapytanie, tryb (słowa, wektory), limit”. Model teraz sam wie, że może to wywołać, gdy potrzebuje znaleźć coś w wiedzy.

Z mojej perspektywy wygląda to tak. Gdy pracuję z AI, mogę powiedzieć:

Przeszukaj moją bazę wiedzy pod kątem tego, co pisałem o uczciwości w sprzedaży. Zwróć pięć najbardziej istotnych notatek.

AI używa serwera MCP bez mojej ingerencji. Samodzielnie formułuje zapytanie, odbiera wyniki, analizuje i prezentuje mi odpowiedź.

Co zyskujesz w porównaniu do API:

Nie musisz znać składni API. Model sam wybiera narzędzia. Dla Ciebie jest to naturalna rozmowa.

Łatwo dodajesz nowe integracje. Instalujesz serwer MCP (są setki dostępnych: Gmail, Slack, GitHub, bazy danych, narzędzia dev), restartujesz klienta AI i narzędzie jest już dostępne.

Konfiguracja w jednym miejscu. Wszystkie serwery MCP konfigurujesz w jednym pliku (.mcp.json w moim przypadku). Łatwo kontrolować, co model widzi.

Koszt wejścia jest nieco wyższy niż przy gotowych węzłach w n8n, ale niższy niż przy ręcznym pisaniu integracji. Jeśli zaczynasz od zera, warto spojrzeć na MCP, zwłaszcza jeśli dużo pracujesz z AI interaktywnie (nie tylko w workflow’ach).

Warstwa 4: hooki w samym kliencie AI

Czwarta warstwa, o której rzadko się mówi, ale która zmienia codzienną pracę. Hooki to małe skrypty, które uruchamiają się automatycznie w odpowiedzi na zdarzenia w Twoim kliencie AI. Nie wywołujesz ich. Dzieją się same w tle.

Konkretne przykłady, które u mnie działają. Po każdej edycji pliku Markdown w vault uruchamia się walidator metadanych — sprawdza, czy frontmatter ma wymagane pola, czy daty są poprawne, czy tagi pasują do listy. Jeśli coś jest nie tak, dostaję ostrzeżenie zanim plik zostanie zapisany trwale. Po edycji kodu uruchamia się linter, który łapie typowe błędy. Przed każdym zapisem systemowym hook robi backup poprzedniej wersji do osobnego folderu — mogę wrócić do dowolnego punktu w czasie. Gdy plik pamięci urośnie powyżej progu, automatycznie odpala się kompresja. Na starcie sesji hook wczytuje kontekst ostatnich rozmów i decyzji, żebym nie zaczynał od pustej kartki.

Hooki to drobne rzeczy, których nie zauważasz, dopóki ich nie ma. Gdy ich brakuje, każdą drobną rzecz stanowiącą o jakości wyniku, musisz pamiętać sam. Z hookami system pilnuje siebie. Plus hooki są lokalne — nie wymagają chmury, nie generują kosztów, działają tak długo jak używasz klienta.

Konfiguracja: jeden plik tekstowy, w którym definiujesz “gdy wydarzy się X, uruchom skrypt Y”. Pierwszy hook zajmie Ci pół godziny do zrozumienia. Kolejne dziesięć — pięć minut każdy.

Które podejście kiedy

Cztery warstwy nie konkurują. Uzupełniają się.

API ręczne: gdy robisz coś raz, potrzebujesz pełnej kontroli, narzędzie nie ma gotowych integracji. Użyj ad hoc, skryptem.

Gotowe węzły w workflow: gdy automatyzujesz powtarzalne procesy (mail → zadanie, raport codzienny, social media). Użyj jako standardowe rozwiązanie.

MCP: gdy pracujesz z AI interaktywnie i chcesz, żeby model sam sięgał po dane. Szczególnie przydatne dla wyszukiwania w bazie wiedzy, dokumentacji, narzędzi dev.

Hooki: gdy chcesz, żeby jakiś proces obowiązywał bez Twojego udziału. Walidacja przed zapisem, backup przed zmianą, wczytanie kontekstu na starcie. To jedyna z czterech warstw, która działa, gdy o niej zapomnisz.

W mojej praktyce używam wszystkich czterech jednocześnie. W sesji z AI mam podpięte kilka serwerów MCP, które aktywują się automatycznie zależnie od pytania: local semantic search po vault, Context7 do aktualnej dokumentacji bibliotek (Astro, React, n8n, Tailwind i setki innych), współdzieloną pamięć między środowiskami pracy, serwer do wyszukiwania i walidacji nodów n8n bez wychodzenia z sesji, Playwright do automatyzacji przeglądarki gdy trzeba pobrać coś z dynamicznej strony, plus zestaw integracji z usługami (Slack, Gmail, Kalendarz, Drive, Vercel, Canva, Bitly), który dostawca AI udostępnia natywnie. Poranny briefing jest n8n workflow z gotowymi węzłami (Gmail, Calendar, Google Sheets). Niestandardowe analizy SEO to skrypty wywołujące API ręcznie. Hooki chodzą pod całością i nie zauważam ich, dopóki działają.

I jeszcze jedna zmiana względem pierwszej wersji tego systemu: modele nie pracują już tylko na tekście. Czytają też obrazy, zrzuty ekranu, dokumenty i transkrypcje audio. Integracja z narzędziami nie oznacza więc tylko “daj dostęp do API”, ale też “daj modelowi zobaczyć ten typ materiału, na którym naprawdę pracujesz”.

Bezpieczeństwo: najważniejsza zasada

Im więcej integracji, tym więcej miejsc, gdzie coś może pójść nie tak.

Trzy zasady, których trzymam się bezwzględnie.

Zasada 1: klucze tylko w POUFNE/. Nigdy w kodzie, w mailach, w commitach do Gita, w wiadomościach Slack. Jeden bezpieczny folder, jeden bezpieczny plik, reszta systemu czyta stamtąd.

Zasada 2: minimum uprawnień. Klucz do Analytics daj tylko z uprawnieniem “read”. Klucz do sklepu tylko do konkretnego magazynu. Nigdy klucz “all access”, jeśli nie musisz.

Zasada 3: regularna rotacja. Co jakiś czas generujesz nowe klucze, stare unieważniasz. Brzmi jak paranoja. Ale klucz, który wyciekł, może szkodzić cicho przez miesiące. Regularna rotacja ogranicza to okno.

Czwarta zasada, której ja osobiście używam: gdy nagrywam stream albo pracuję przy widocznym terminalu, wyłączam dostępy. Zmienna środowiskowa, która blokuje czytanie plików z POUFNE/. Lepiej przepytać dwa razy niż raz pokazać klucz.

Czego unikać

Dawania AI pełnego dostępu bez ograniczeń. Model działa zgodnie z tym, co rozumie. Jeśli ma pełen dostęp do sklepu i poprosisz “uporządkuj kategorie”, może zrobić coś, czego się nie spodziewałeś. Ograniczaj zakres.

Wklejania kluczy do rozmów z AI. Model sam też nie powinien widzieć Twoich surowych kluczy. Używaj zmiennych środowiskowych i przekazuj tylko potrzebne dane.

Budowania integracji dla integracji. Jeśli dodajesz trzecie czy czwarte narzędzie, pytaj siebie: co konkretnie się dzięki temu zmieni? Jeśli odpowiedź to “no wiesz, tak fajniej”, nie rób tego.

Ignorowania logów. Integracje rozmawiają z zewnętrznymi systemami. Coś może pójść nie tak: limit zapytań, zmieniona odpowiedź API, błąd autoryzacji. Regularnie sprawdzaj, czy Twoje integracje nie zgłaszają błędów.

Czego nauczyłeś się na tym etapie?

Integracje z narzędziami zmieniają charakter pracy z AI. Przestaje działać w abstrakcji. Zaczyna operować na Twoich realiach.

Cztery warstwy integracji:

API ręczne: pełna kontrola, ad hoc, dla rzadkich zadań
Gotowe węzły w workflow (n8n, Make): codzienne automatyzacje, bez kodu
MCP: interaktywna praca z AI, modelowi “widzi” Twoje narzędzia bez Twojej ingerencji
Hooki w kliencie AI: lokalne skrypty reagujące na zdarzenia (zapis pliku, edycja kodu, start sesji)

Każda integracja ma trzy operacje: czytanie (najbezpieczniejsze), szukanie, zapisywanie (najbardziej inwazyjne). Zacznij od czytania, rozszerzaj w miarę zaufania.

Dostęp do narzędzi daje się przez klucze API. Klucze trzymasz w bezpiecznym miejscu. Minimum uprawnień. Regularna rotacja.

Najczęstsza pomyłka początkujących: dawać AI pełne uprawnienia bo “łatwiej skonfigurować”. Im mniej dostępu, tym mniej ryzyka.

W następnej części zamykamy blok automatyzacji czymś konkretnym: pokażę jak AI pisze Ci własne skrypty. Gdy gotowe narzędzia nie pasują, budujesz swoje. Nie musisz być programistą. Piszesz co chcesz mieć, AI pisze kod.

Twój następny krok: zadanie na dzisiaj

Dwie rzeczy.

1. Wybierz jedną integrację do przetestowania. Z narzędzi, których używasz codziennie, wybierz jedno, z którym chciałbyś integrować AI. Kalendarz, mail, CRM, sklep, cokolwiek. Zaloguj się do panelu tego narzędzia, znajdź sekcję API/Developer, sprawdź czy masz do niej dostęp na swoim planie. Wygeneruj testowy klucz z minimalnymi uprawnieniami (tylko czytanie, jeśli taka opcja istnieje).

2. Zrób jedno zapytanie. Stwórz nowy workflow w n8n. Dodaj węzeł narzędzia, które wybrałeś (albo ogólny HTTP Request, jeśli nie ma gotowego). Wklej klucz. Skonfiguruj jedno proste zapytanie: pobierz dziesięć ostatnich maili, dziesięć ostatnich zamówień, wydarzenia z kalendarza na dziś. Uruchom. Jeśli dostajesz dane, masz pierwszy most między AI a narzędziem. Teraz tylko rozbudowa.

Zasoby

Dokumentacja API narzędzi, których używasz — każde większe narzędzie ma sekcję “API docs”. Nie trzeba jej czytać w całości. Wystarczy sekcja “Authentication” (jak się zalogować) i “List endpoints” (co można pobrać).
Oficjalna dokumentacja MCP — protokół ma dziś własną stronę i własne repozytorium, niezależne od pojedynczego dostawcy. Zacznij tam, jeśli chcesz rozszerzyć model o dostęp do Twoich narzędzi. Zaczynasz od prostego serwera: pliki, baza danych, API zewnętrzne. Instalacja zwykle jedna komenda.
Lista gotowych węzłów n8n — sprawdź, czy Twoje kluczowe narzędzia są już obsługiwane. Jeśli tak, oszczędzasz dni pracy. Jeśli nie, warto zobaczyć, czy społeczność nie napisała własnego rozwiązania.

Ten artykuł jest częścią cyklu “Od zera do kompletnego systemu AI w kwartał”. Krok po kroku opisuję jak zbudowałem system AI do zarządzania firmą i rozwojem osobistym, żebyś mógł wdrożyć podobny u siebie. W następnej części: jak AI pisze własne skrypty, gdy gotowe narzędzia nie pasują. Masz pytania? Napisz. Odpowiadam osobiście.

Żeby nie przegapić kolejnych części, zaobserwuj mój profil. Nowe artykuły publikuję regularnie.

Marcin Atamańczuk, Technologia w służbie życia, nie odwrotnie.