Model językowy sam z siebie nie zna Twojego CRM, nie widzi skrzynki i nie wie, ile przyszło wczoraj na konto. Integracja LLM z systemami firmy to podłączenie modelu do tych miejsc tak, żeby mógł czytać dane i wykonywać operacje w Twoim imieniu. Technicznie to dziś najprostsza część wdrożenia. Trudniej jest ustalić, co agent może zrobić sam, a przy czym musi zapytać człowieka. Ten tekst pokazuje, jak robimy to w naszym własnym systemie agentowym, na którym pracują sprzedaż i finanse 200IQ LABS.

Krótka odpowiedź

Integracja LLM z systemami firmy polega na daniu modelowi narzędzi: każde narzędzie wykonuje jedną operację w jednym systemie, na przykład odczyt rekordu z CRM albo utworzenie szkicu maila. O tym, czy agent może użyć narzędzia sam, decyduje klasa operacji, a nie model. Odczyty i operacje, które da się cofnąć, agent wykonuje sam. O wysyłce, usunięciu, publikacji i płatności zawsze decyduje człowiek: robi to sam albo zatwierdza każde takie wywołanie z osobna.

Trzy sposoby podłączenia modelu do systemów firmy

SposóbJak działaKiedy pasuje
Wywołanie modelu z własnego koduaplikacja wysyła do modelu dane przez API i sama zapisuje wynikprodukt albo proces o stałym przebiegu, w którym model robi jeden krok
Platforma automatyzacjiscenariusz uruchamia kolejne kroki według reguł, model jest jednym z nichprzepływ, który za każdym razem wygląda tak samo
Agent z narzędziami (MCP)agent sam wybiera, które narzędzie wywołać, i składa wynik z kilku systemówpraca, w której trzeba coś ocenić: do kogo dziś napisać, jak zaklasyfikować transakcję

Pierwszy sposób znamy z naszego produktu: Qamera AI wywołuje modele generowania obrazu i wideo z własnego backendu, a człowiek zatwierdza wynik. Ten tekst dotyczy głównie trzeciego, bo to on daje modelowi najwięcej swobody i to przy nim najłatwiej o błąd.

MCP (Model Context Protocol) to otwarty standard, w którym system firmy udostępnia agentowi narzędzia: nazwane operacje z opisem i parametrami. Agent widzi listę narzędzi i wywołuje te, których potrzebuje. Gotowe serwery MCP istnieją dla wielu popularnych systemów, a dla reszty piszemy własne. Czym różni się agent od automatyzacji i czatbota, opisujemy szerzej we wpisie system agentowy: co to jest.

Pięć klas operacji

Każda operacja, którą agent może wykonać, ma u nas jedną z pięciu klas. Klasę liczy skrypt z nazwy narzędzia i jego parametrów, a nie model. Gdyby oceniał ją model, to model decydowałby, czy w ogóle zapytać człowieka.

KlasaCo to jestPrzykładAgent pracujący bez nadzoru
1odczyt na komputerzeplik bazy wiedzy, konfiguracjatak
2zapis we własnych folderach agentabrief, plik stanutak
3operacja na zewnątrz, którą da się cofnąć albo która nic nie zmienia, także odczyt danych spoza komputeraszkic maila, zapis w CRM, odczyt skrzynkitylko wąskim narzędziem, które dodaje człowiek
4operacja na zewnątrz, której nie da się cofnąćwysyłka, usunięcie, publikacja, płatnośćnigdy, decyduje człowiek
5zmiana kodu, ról, umiejętności albo ustawień systemunowa reguła, zmiana narzędzianigdy, idzie przez bramkę zmian

Pięć klas operacji agenta: klasy 1 i 2 to odczyt i zapis we własnych folderach, które agent robi sam; klasa 3 to operacja na zewnątrz, którą da się cofnąć, wykonywana wąskim narzędziem; klasa 4 to operacje nieodwracalne, które wymagają zgody człowieka, a klasa 5 to zmiany systemu, które idą przez bramkę zmian

Otwórz schemat w pełnym rozmiarze

Narzędzie klasy 4 albo 5 może istnieć, ale żaden agent działający w tle go nie dostanie. Blokuje to hook, który sprawdza wywołanie, zanim się wykona. Jedyny wyjątek to praca interaktywna: gdy człowiek rozmawia z głównym agentem, agent może wywołać takie narzędzie, ale dopiero po zgodzie człowieka na to jedno wywołanie, a walidator zgłasza każde ustawienie, które próbowałoby to pytanie pominąć. Wykonuje wtedy agent, ale decyduje człowiek. Maile do klientów i tak wysyłamy sami, prosto ze skrzynki.

Wąskie narzędzia zamiast szerokiego dostępu

Najprostsza integracja to dać agentowi pełny dostęp do API systemu albo do wiersza poleceń. Wtedy agent może zrobić wszystko, co może zrobić klucz, a lista dozwolonych komend chroni tylko tekst komendy, a nie to, co ona robi.

Dlatego agent, który pracuje bez nadzoru, nie dostaje u nas wiersza poleceń, tylko wąskie narzędzia: narzędzia MCP, które potrafią wykonać jedną operację i nic więcej. Narzędzie do skrzynki, które listuje wiadomości, czyta je i tworzy szkice, to trzy osobne narzędzia, a żadne z nich nie wysyła. Granicą jest wtedy kod narzędzia, więc ten kod musi być tym, który ktoś przejrzał: serwer uruchamia narzędzie tylko wtedy, gdy jego pliki są dokładnie takie jak w ostatnim zatwierdzonym commicie.

Skąd wiadomo, jakie narzędzia zbudować? System sprawdza, które narzędzia agenci wywołują często, których szukali, a nie znaleźli, i które leżą nieużywane. Operacja, która się powtarza, staje się kandydatem na nowe wąskie narzędzie, a jego dodanie zatwierdza człowiek.

Klucze nie trafiają do repozytorium ani do modelu

Klucze do systemów firmy leżą tylko na stanowisku, które z nich korzysta, w lokalnej rejestracji serwera. Wspólny plik konfiguracji w repozytorium zawiera wyłącznie odwołanie do nazwy klucza, a narzędzie odczytuje wartość samo, przy uruchomieniu. Klucz nie trafia więc do rozmowy z modelem, a agent działający w tle nie może czytać plików, w których są klucze.

Każdy dział deklaruje też własne serwery MCP. Stanowisko ładuje serwery działów, w których pracuje osoba przy tym stanowisku, więc narzędzi innego działu nie ma w sesji, dopóki ta osoba sama ich nie włączy.

Jak to wygląda u nas: sprzedaż

Dane o firmach i kontaktach są w CRM w Airtable, a system trzyma ich kopię obok reszty wiedzy działu. Tak wygląda dzień wysyłki z podziałem na klasy:

Dzień wysyłki z klasami operacji: agent czyta skrzynkę i CRM (klasa 3), zapisuje brief i zestawienie w folderze działu (klasa 2), człowiek akceptuje zestawienie, system tworzy drafty w skrzynce (klasa 3), człowiek sam wysyła (klasa 4), a CRM dostaje zapis tego, co wyszło (klasa 3)

Otwórz schemat w pełnym rozmiarze

Szkic w skrzynce to klasa 3, bo da się go usunąć i nic jeszcze nie wyszło do klienta. Wysyłka to klasa 4, więc robi ją Przemek, który prowadzi u nas sprzedaż. Między propozycją agenta a draftem stoi jeszcze prawie 40 bramek z regułami firmy, o których piszemy we wpisie agenci AI w sprzedaży.

Jak to wygląda u nas: zamykanie miesiąca

Agent pobiera transakcje z banku, przychody ze Stripe'a i faktury kosztowe z systemu do faktur. Wszystkie trzy operacje to odczyty: agent w banku ani w Stripe niczego nie zmienia. Klasyfikację robi najpierw regułami, a dopiero gdy żadna nie pasuje, modelem z przykładami. To, czego nie da się rozstrzygnąć, trafia do przeglądu z człowiekiem, a jego poprawki wracają jako nowe reguły. Cały proces od środka pokazujemy w tekście jak sami pracujemy na systemie agentowym.

Od czego zacząć integrację LLM w firmie

  1. Zacznij od procesu, nie od systemu. Najpierw wybierz pracę, którą agent ma przejąć, a dopiero potem ustal, do których systemów potrzebuje dostępu. Często na start wystarczą pliki firmy, bez żadnej integracji. Jak je ułożyć, opisujemy we wpisie baza wiedzy firmy dla agentów AI.
  2. Wypisz operacje i nadaj im klasy. Dla każdego systemu: co agent ma czytać, co może tworzyć jako szkic, a czego nie może robić nigdy.
  3. Podłączaj od odczytów. Odczyt z CRM albo z banku niczego nie psuje, a już pozwala sprawdzić, czy agent dobrze rozumie dane.
  4. Szkice przed wysyłką. Gdy wynik agenta ma wyjść na zewnątrz, niech najpierw powstaje jako szkic, który człowiek czyta i wysyła.
  5. Buduj wąskie narzędzia z tego, co się powtarza. Zamiast szerokiego dostępu na zapas dodawaj narzędzia dla operacji, których agent naprawdę używa.

Przebieg całego wdrożenia, od pierwszego spotkania po dalszą współpracę, opisujemy we wpisie jak wygląda wdrożenie agentów AI.

Najczęstsze pytania

Co to jest integracja LLM z systemami firmy?

To podłączenie modelu językowego do systemów, w których firma trzyma dane i pracuje, na przykład CRM, poczty, systemu do faktur albo płatności, tak żeby model mógł czytać dane i wykonywać wybrane operacje.

Czy agent AI może sam wysyłać maile albo robić przelewy?

Sam nie. Wysyłka, usunięcie, publikacja i płatność to operacje, których nie da się cofnąć, więc wykonuje je człowiek albo agent w rozmowie z człowiekiem, po jego zgodzie na każde wywołanie. Maile do klientów wysyłamy sami. Agent może przygotować szkic, który człowiek sprawdza i wysyła.

Czy do integracji potrzebny jest MCP?

Nie zawsze. Proces o stałym przebiegu można zbudować na wywołaniu modelu z własnego kodu albo na platformie automatyzacji. MCP przydaje się wtedy, gdy agent ma sam wybierać, z którego systemu skorzystać i jaką operację wykonać.

Czy model widzi nasze hasła i klucze API?

Nie powinien. U nas klucze leżą tylko w lokalnej rejestracji na stanowisku, repozytorium zawiera samo odwołanie do nazwy klucza, a narzędzie odczytuje wartość przy uruchomieniu.

Ile kosztuje integracja agentów AI z systemami firmy?

Wdrożenie pierwszego procesu kosztuje od 9 000 zł netto i często nie wymaga żadnej integracji. Integracje z CRM, skrzynką czy kalendarzem dokładamy, gdy proces ich potrzebuje, i wyceniamy osobno. Składniki ceny rozpisujemy we wpisie ile kosztuje wdrożenie agenta AI.

Podsumowanie

Podłączenie modelu do CRM czy skrzynki zajmuje dziś niewiele pracy. Na wdrożenie składa się głównie decyzja, co agent może zrobić sam: odczyty i szkice tak, wysyłka i płatność nie. Tę decyzję podejmuje skrypt według klasy operacji, a nie model, a agent dostaje wąskie narzędzia zamiast pełnego dostępu. Tak samo podłączamy agentów w firmach, w których wdrażamy system agentowy.

Chcesz sprawdzić, które systemy u Ciebie warto podłączyć do agentów i od czego zacząć? Umów spotkanie w dogodnym terminie. Trwa około godziny i kończy się wyborem pierwszego procesu. Wolisz najpierw napisać? hello@200iqlabs.io.