Agenci AI (Claude Code, Codex, Cursor, Gemini CLI) najlepiej pracują w terminalu. Wpisują polecenie, czytają wynik, poprawiają się i próbują dalej. Dlatego w ostatnim roku duże firmy SaaS dołożyły do swoich produktów narzędzie wiersza poleceń, czyli CLI, albo mocno przebudowały to, które już miały. Intum też ma takie narzędzie: intum.
Poniżej zestawienie, jak to zrobili inni i jak to działa u nas.
Dlaczego CLI, a nie tylko MCP
MCP to protokół, przez który agent dostaje od systemu listę narzędzi. Działa, ale ma swój koszt. Na starcie każdej rozmowy agent wczytuje opisy wszystkich narzędzi, nawet jeśli użyje jednego. W porównaniach opublikowanych przez Firecrawl i Scalekit te same zadania na GitHubie wykonane przez CLI zużywały od 4 do 32 razy mniej tokenów niż przez serwer MCP i częściej kończyły się sukcesem.
CLI nic nie kosztuje, dopóki agent go nie wywoła. Wynik można przefiltrować, zanim trafi do modelu, a kilka poleceń połączyć w jedną pętlę zamiast stu osobnych wywołań.
MCP nadal jest potrzebny tam, gdzie agent nie ma terminala, na przykład w czacie w przeglądarce. Dlatego większość firm ma dziś oba kanały. Zaczynają jednak od CLI, a MCP dokładają jako cienką warstwę na tym samym logowaniu.
Jak to robią inni
Basecamp (37signals)
To przypadek najbliższy Intum: jedna firma, kilka produktów, konta klientów pod własnymi adresami. 25 marca 2026 roku 37signals ogłosiło, że Basecamp jest dostępny dla agentów. W paczce było przebudowane API, nowe CLI i gotowy skill dla agentów. Serwera MCP w pierwszej wersji celowo nie było. DHH napisał wtedy, że agenci stali się “killer app” dla AI. MCP doszło kilka miesięcy później jako polecenie basecamp mcp, wbudowane w CLI i korzystające z tego samego logowania.
Co jest w środku:
- program w Go, instalowany jednym poleceniem albo przez Homebrew, Scoop i apt, aktualizowany przez
basecamp upgradez weryfikacją podpisu - logowanie przez przeglądarkę, tokeny osobiste dla skryptów i CI oraz osobny rodzaj dostępu dla agentów pracujących bez człowieka
- profile, gdy ktoś ma kilka kont
- polecenia w stylu
basecamp todos create "Poprawić stopkę" --in 12345 - w terminalu czytelny widok, w potoku JSON. Odpowiedź w JSON ma pole z podpowiedzią, jakie polecenie wykonać dalej - agent nie musi zgadywać
-
basecamp commands --jsonzwraca pełny katalog poleceń, z którego agent uczy się, co może zrobić
Szkielet (logowanie, profile, format wyników) 37signals wydzieliło do wspólnej biblioteki. Na niej stoją też CLI do HEY i do Fizzy.
GitHub
gh to wzorzec, na który powołują się prawie wszyscy. Polecenia czyta się jak zdanie: gh pr create, gh issue list. Każda lista przyjmuje --json z wyborem pól. Najważniejszy jest jednak gh api - surowe zapytanie do dowolnego miejsca API, z automatycznym logowaniem. Dzięki temu CLI nie musi mieć osobnego polecenia na każdą funkcję GitHuba.
Logowanie odbywa się przez przeglądarkę z jednorazowym kodem, token trafia do pęku kluczy systemu, a w CI wystarczy zmienna środowiskowa.
Stripe
Stripe generuje polecenia do zasobów automatycznie ze specyfikacji swojego API. Nowe pole w API od razu pojawia się w CLI, bez ręcznej pracy. Obok są stripe get, stripe post i stripe delete na dowolną ścieżkę oraz stripe listen, które przekazuje webhooki na komputer programisty.
Pozostali
- Vercel zwraca błędy w JSON z polem
next, w którym jest gotowe polecenie naprawiające problem. - Cloudflare i Supabase mają wspólne logowanie i uprawnienia dla CLI i MCP.
- Linear poszedł w drugą stronę. Nie ma oficjalnego CLI, jest tylko serwer MCP. Lukę wypełniły narzędzia pisane przez społeczność, wprost pod agentów.
- Sentry trzyma skille, konfigurację MCP i polecenia dla agentów w jednym repozytorium, żeby nie rozjeżdżały się między sobą.
Wspólny mianownik jest krótki: JSON na żądanie w każdym poleceniu, furtka do surowego API, logowanie przez przeglądarkę plus token dla automatów i skill dla agenta dostarczany razem z CLI.
Jak to działa w Intum
intum korzysta z tego, co w systemie już było: API w każdym module, tokenów z uprawnieniami i opisów API, z których od dawna korzystają AI button i asystent Noe.
Logowanie
Po zainstalowaniu wystarczy jedno polecenie:
intum login
intum login nie pyta o adres konta. Otwiera przeglądarkę, logujesz się jak zwykle i potwierdzasz dostęp. CLI od razu pracuje na Twoim domyślnym koncie, czyli tym, na które trafiasz po zalogowaniu w przeglądarce.
CLI dostaje własny token, widoczny na liście tokenów API konta jak każdy inny. Token działa tylko na tym jednym koncie i można go w każdej chwili wyłączyć. Token jest zapisany w pęku kluczy systemu, nie w pliku tekstowym. Na serwerach i w CI zamiast logowania ustawia się zmienną INTUM_TOKEN.
Kilka kont
Jedno logowanie daje dostęp do jednego konta. Na każde kolejne konto logujesz się osobno, nawet jako ten sam użytkownik:
intum login -a klient
intum accounts
intum switch klient
Tak jest bezpieczniej: token wyciekły z jednego komputera nie otwiera wszystkich kont naraz, a każde konto samo decyduje, czy wpuszcza CLI. W ustawieniach konta, w sekcji bezpieczeństwa, jest przełącznik Dostęp przez Intum CLI. Po jego wyłączeniu nie da się zalogować CLI na to konto, a już zalogowane programy przestają działać. Po ponownym włączeniu działają znowu, bez nowego logowania.
intum accounts pokazuje listę Twoich kont, zaznacza bieżące i te, na które CLI jest już zalogowane. intum switch przełącza bieżące konto na inne zalogowane, na stałe, aż do kolejnego przełączenia. Gdy potrzebujesz innego konta tylko na jedno polecenie, dopisz --account:
intum tasks list --account klient
Lista obejmuje też konta w innych produktach na platformie, na przykład w inConnectorze.
Polecenia
Najczęstsze rzeczy mają własne polecenia, pisane w kolejności “moduł, obiekt, czynność”:
intum tasks list --user me --open
intum tasks create "Poprawić eksport do JPK" --project 12
intum tasks comment 1535 "Sprawdzone na produkcji"
intum crm clients search "Kowalski"
intum kb entries create --kb 1177 --file wpis.md
Wszystko inne robi się przez intum api, podobnie jak w gh api. Działa na każdej ścieżce, którą obsługuje API, więc nowy moduł jest dostępny od pierwszego dnia, zanim ktokolwiek napisze do niego osobne polecenie.
Wyniki dla ludzi i dla agentów
W terminalu wyniki mają postać tabeli. Gdy wynik idzie dalej potokiem albo dopiszesz --json, dostajesz JSON w stałym formacie: czy się udało, dane, krótkie podsumowanie i podpowiedź następnego kroku. Błędy mają ten sam kształt i mówią, czy warto spróbować jeszcze raz.
intum docs organize wyświetla opis API modułu, ten sam, z którego korzysta AI button. Agent nie musi więc szukać dokumentacji w internecie. intum commands --json zwraca katalog wszystkich poleceń.
Agenci
intum skill install instaluje skill dla Claude Code, Codexa i innych narzędzi, które obsługują standard Agent Skills. CLI uruchomione przez agenta samo oznacza swoje zapytania, więc to, co agent dopisze w zadaniu, trafia do zwiniętych “Treści od AI” (więcej: Treści z AI w zadaniach).
Agent loguje się własnym tokenem, z własną, węższą rolą. Taki token wygasa po trzech miesiącach. Zasady bezpieczeństwa są te same co przy agentach pracujących w systemie: Agent AI w imieniu użytkownika - prompt injection i jak zabezpieczamy agenty w Intum.
MCP
intum mcp uruchamia lokalny serwer MCP na tym samym logowaniu co CLI. To rozwiązanie dla narzędzi, które nie mają terminala. Serwer MCP wbudowany w Intum działa dalej, bez zmian.
Czego celowo nie robimy
CLI nie ma własnych uprawnień ani logiki. Wszystko sprawdza serwer, tak samo jak przy pracy w przeglądarce. Token z CLI może mieć najwyżej takie uprawnienia jak użytkownik, który go utworzył, a zwykle ma węższe.
Nie piszemy osobnego polecenia do każdej akcji w systemie. Rzadziej używane rzeczy obsługuje intum api i to jest świadoma decyzja, a nie brak.
Nie ma logowania hasłem w terminalu. Zawsze przez przeglądarkę albo tokenem.