O czym jest ten film
- Cała istniejąca infrastruktura Claude jest zaprojektowana pod jednego użytkownika: pamięć jest przypięta do konta, frameworki pamięci trzymają dane lokalnie, a połączenia MCP autoryzują cię osobiście.
- Autor pokazuje, jak z trzech gotowych narzędzi — Notion, Composio i Supermemory — zbudować „80% działającego zespołowego Claude za 20% wysiłku”, bez pisania czegokolwiek od zera.
- Warstwa wspólnego kontekstu opiera się na Notion jako „dysku współdzielonym” — z wbudowanym systemem uprawnień, które Claude respektuje automatycznie.
- Warstwa wspólnych narzędzi (CRM, skrzynki Gmail, księgowość) działa przez Composio — każdy loguje się jako on sam, a klucze API nigdy nie opuszczają skarbca platformy.
- Composio daje dostęp do ponad tysiąca aplikacji przez jeden konektor MCP i pozwala podłączyć kilka kont naraz (np. cztery skrzynki Gmail w jednym zadaniu).
- Dla wyjątkowych przypadków (współdzielony login bez osobnych miejsc w aplikacji) istnieje bramka MCP Composio, która tworzy adres URL z zawężonym dostępem do jednego narzędzia.
- Najtrudniejszy element — wspólna pamięć zespołu — rozwiązuje Supermemory: jeden współdzielony „kontener”, do którego cały zespół zapisuje i z którego czyta decyzje z sesji.
- Wbudowana pamięć Claude jest odrzucona, bo działa per konto, słabo wychwytuje informacje i wymaga ręcznej obsługi.
- Konfiguracja Supermemory wymaga zaproszenia członków do workspace przed utworzeniem przez nich kluczy i wskazania wszystkim tego samego tagu kontenera; najlepiej pracować z jednego wspólnego folderu projektu.
- Dwa istotne ograniczenia: dostęp do kontekstu „wycieka” przez pamięć nawet po odebraniu uprawnień w Notion, a wszystko trafia do jednego wspólnego kubła (brak podziału na prywatne i wspólne) — plus admin Supermemory widzi wszystkie pamięci.
Redakcyjne tłumaczenie
Problem: cała ta technologia jest „single player”
Kilka tygodni temu przeprowadziliśmy w naszej społeczności ankietę o pracy zespołowej wewnątrz aplikacji Claude i wyniki mnie zwaliły z nóg. Prawie 70% członków próbuje używać Claude w zespole, ale niemal nikt nie ma na to czystego sposobu. A kiedy przyjrzysz się dostępnej infrastrukturze, od razu widać dlaczego.
Sama pamięć Claude jest przypięta do twojego konkretnego konta. Zewnętrzne frameworki pamięci przechowują ustalenia na twojej własnej maszynie i są zbudowane wokół jednego użytkownika. Nawet twoje połączenia MCP autoryzują cię osobiście. Krótko mówiąc, każdy poważny element tego stosu technologicznego jest w istocie zaprojektowany dla jednego gracza. Nawet Y Combinator ma „infrastrukturę zespołową dla agentów” na swojej liście oczekiwanych startupów — a to znak, że nikt jeszcze nie zrobił tego dobrze.
(Informacja dodatkowa: Y Combinator to najbardziej znany amerykański akcelerator startupów; jego „Requests for Startups” to publiczna lista problemów, na które szuka założycieli — obecność tematu na tej liście oznacza, że rynek go jeszcze nie rozwiązał.)
Postanowiliśmy więc przestać czekać i sprawdzić, jak daleko da się zajść z narzędziami, których twój zespół już dziś używa: Notion, Claude i jednym współdzielonym łącznikiem pamięci. A nawet jeśli któregoś z nich nie używasz — na przykład Notion — możesz je podmienić na dowolne inne oprogramowanie do współdzielenia plików. Logika pozostaje ta sama. Na koniec tego filmu będziesz mieć system zespołowej pracy w Claude gotowy w 80% za jakieś 20% wysiłku.
Zmiana myślenia: kontekst jako infrastruktura
Cały ten pomysł wymaga zmiany sposobu myślenia. Musisz przestać traktować kontekst jako coś, co Claude każdej osoby posiada indywidualnie, a zacząć traktować go jako infrastrukturę, do której może się podłączyć cały twój zespół. Kompletną — z uprawnieniami, dostępem do wszystkich współdzielonych narzędzi oraz kontekstem wspólnej pamięci i wspólnych rozmów.
To fundamentalnie przyszły sposób pracy w zespole współpracującym z AI. Robisz to wewnątrz swoich dotychczasowych narzędzi, masz dostęp do tych samych dokumentów i tych samych narzędzi, bez dzielenia się kluczami. A cała konfiguracja jest naprawdę prosta:
- Notion trzyma wspólny kontekst oraz uprawnienia do wszystkich dokumentów. Traktuj to jak dysk współdzielony.
- Supermemory.ai trzyma to, czego zespół się uczy podczas pracy. To pamięć robocza, ale możliwa do przeszukania przez każdego w zespole. Jeśli pracowałeś nad projektem i wniosłeś w niego sensowne rzeczy, ktoś inny zrozumie kontekst, w jakim podejmowałeś decyzje — i to bezpośrednio w swojej aplikacji Claude desktop.
- Claude — używamy go w aplikacji desktopowej, bo interfejs jest przyjazny i nietechniczny, więc cały zespół po prostu wykonuje w nim pracę.
Zwróć uwagę, że w tej trójce nie ma niczego zbudowanego na zamówienie — chcieliśmy sprawdzić, jak daleko można cię popchnąć samymi narzędziami, których już używasz.
Warstwa 1: wspólny kontekst w Notion
Widziałem już kilka zespołów, które próbowały rozwiązać ten pierwszy element — wspólny kontekst — po prostu kopiując foldery robocze między maszynami. Ustawiasz sobie coś w rodzaju systemu operacyjnego: pliki Claude.md, projekty i tak dalej, a potem kopiujesz to wszystko na różne komputery. Działa to do pewnego momentu, ale trudno utrzymać taką konfigurację aktualną. Możesz oczywiście użyć GitHuba, ale to jest zaprojektowane dla użytkownika technicznego, nie dla przeciętnego pracownika biznesowego.
Chcemy więc mieć kontrolę nad tym, kto co widzi. Dlatego potrzebujemy interfejsu, który ma już wbudowane uprawnienia — takiego, z którym Claude może współpracować, do którego wielu użytkowników ma dostęp do tego samego zestawu dokumentów i utrzymuje go aktualnym, tak by każdy dostawał najnowszą wersję za każdym razem, gdy loguje się do Claude na swojej maszynie.
To nie jest nowa koncepcja. Kiedy jesteś częścią większego zespołu, po prostu używasz dysku współdzielonego. To jest odpowiednik tego dysku dla Claude. Dlatego jako źródło prawdy używamy Notion — bo rozwiązuje oba problemy naraz i wiele firm już z niego korzysta.
Każdy członek zespołu łączy Claude z Notion przez własny login, po prostu podłączając się przez MCP. Wchodzisz w ustawienia, przechodzisz do konektorów, przeglądasz je — Notion jest tam już dostępny jako gotowy konektor. Wystarczy się połączyć; autoryzuje to twój własny login. Kluczowe: Claude może odczytać tylko to, co ta osoba już widzi w Notion, i może zapisywać tylko tam, gdzie ma do tego uprawnienia. Nie musisz budować systemu uprawnień — masz go już w Notion.
(Informacja dodatkowa: MCP — Model Context Protocol — to standard łączenia asystentów AI z zewnętrznymi narzędziami i danymi. „Konektor” w Claude to gotowa wtyczka MCP.)
W demonstracji autor pokazuje stronę z kontaktami zespołu, zawierającą materiały marki — pozycjonowanie, elementy identyfikacji wizualnej — oraz plik markdown z „DNA głosu” marki, który zasila treści wszystkich piszących. Nie chce jednak, by cały zespół edytował profil głosu. Wchodząc w dany dokument, po prawej stronie może bezpośrednio ustawić uprawnienia. Domyślnie cała firma ma pełen dostęp — może edytować, komentować i przeglądać. Ale można to zmienić na stronę prywatną, dostępną tylko dla zaproszonych osób, i to natychmiast aktualizuje uprawnienia. Od tej chwili również wewnątrz Claude tylko zaproszone osoby mogą wprowadzać zmiany. Można też dać wszystkim poza wybranymi osobami dostęp wyłącznie do odczytu.
Żeby wszyscy mieli dostęp, wystarczy skopiować adres URL strony Notion i umieścić go w instrukcjach dla Claude — w ustawieniach albo bezpośrednio w pliku Claude.md. Wystarczy prosta linijka: „Przy dostępie do kontaktów lub plików zespołu najpierw sprawdź ten adres URL Notion”. Tak prosto daje się wszystkim dostęp i kontrolę uprawnień do dokumentów i kontaktów. I nie musi to być Notion — to samo zadziała z dokumentami Google Drive albo dowolnym hostingiem w chmurze z wbudowanymi uprawnieniami.
Warstwa 2: wspólne narzędzia bez dzielenia się kluczami
Dzielenie się narzędziami, ale nie kluczami, jest bardzo ważne. Klucze muszą w praktyce mieszkać w jednym miejscu, ale twój zespół musi mieć dostęp do wszystkich narzędzi, których ma używać — nigdy jednak do samego klucza. To kwestia bezpieczeństwa i utrzymania.
Testowaliśmy to na platformie Composio. Są dwie warstwy działania.
(Informacja dodatkowa: w automatycznym transkrypcie nazwa jest zapisywana jako „Composure” — chodzi o platformę Composio, popularną warstwę integracyjną łączącą asystentów AI z zewnętrznymi aplikacjami przez MCP.)
Warstwa pierwsza — konta osobiste. Każdy członek zespołu instaluje w Claude konektor Composio. Wchodzisz w konektory, dodajesz konektor niestandardowy, nazywasz go „Composio” i podajesz adres zdalnego serwera MCP. To autoryzuje cię w twoim koncie Composio. Każdy loguje się własnym loginem. Dodajesz ludzi do zespołu lub projektu w Composio, a przez ten jeden konektor Claude sięga po znacznie więcej aplikacji — dokładnie 1052 aplikacje — i każdy podłącza do nich własne konta. Jeśli ktoś potrzebuje przeskanować swoją skrzynkę Gmail, podłącza tę konkretną skrzynkę: dodaje ją do projektu, nadaje nazwę i loguje się bezpośrednio do aplikacji własnym uwierzytelnieniem. Każdy działa więc jako on sam, a żaden klucz nigdy nie opuszcza skarbca Composio. Auth ustawiasz raz, jako administrator, i nikt nie dzieli się loginem.
Warstwa druga — rzeczy współdzielone. Jeśli masz firmową skrzynkę, firmowe media społecznościowe albo oprogramowanie księgowe, do których dostęp potrzebuje wiele osób, najprostszym rozwiązaniem — o ile to możliwe — jest nadanie uprawnień bezpośrednio w samej aplikacji. Nadaj użytkownikowi odpowiednie uprawnienia w oprogramowaniu księgowym, a wtedy te delegacje zostaną przekazane do Composio, gdy się zaloguje. Potem stosują tę samą metodę: logują się bezpośrednio przez zestaw narzędzi, znajdują aplikację — powiedzmy Xero — logują się i mają przekazane uprawnienia. Wymaga to dodania ich jako osobnego miejsca (seat) w twoim narzędziu księgowym, ale dzięki temu każdy ma dostęp przez swój login Composio, a więc przez połączenie MCP Claude–Composio.
(Informacja dodatkowa: Xero to popularne, głównie anglojęzyczne oprogramowanie do księgowości online.)
To dużo potężniejsze niż wbudowane konektory Claude. Gdybym chciał podłączyć Gmaila bezpośrednio w Claude, jestem ograniczony do jednego konta. Tu mogę podłączyć cztery czy pięć różnych skrzynek Gmail z różnymi identyfikatorami i przeskanować je wszystkie w jednym zaplanowanym zadaniu.
Jest jeszcze jeden rzadszy przypadek: masz współdzielony login i brak osobnych miejsc w aplikacji — na przykład planer treści z jednym logowaniem, panel afiliacyjny albo firmowe konto LinkedIn, do którego nikogo nie dodano. Wtedy można pójść o krok dalej, używając bramki MCP Composio. Daje ona jeden adres URL na zespół z zawężonym dostępem do narzędzi. Jednym wywołaniem API do Composio tworzysz zawężony serwer zawierający dostęp tylko do jednego narzędzia — powiedzmy tylko do Stripe, tylko do QuickBooks albo tylko do GitHuba z określonymi uprawnieniami na danej gałęzi. Zwrotem z tego wywołania jest adres MCP. Tak jak wcześniej, wracasz do konektorów, dodajesz konektor niestandardowy i wklejasz ten adres — na przykład „zawężony QuickBooks Composio MCP”. To daje danej osobie wspólne uprawnienia do tego samego konta, mimo że nie ma w tej aplikacji własnego miejsca.
Obecnie nie da się tego zrobić z poziomu panelu Composio, więc jest to nieco bardziej techniczne — ale chcieliśmy zrozumieć wszystkie możliwości współdzielenia uprawnień bez dzielenia się samymi kluczami API. Dzielenie się kluczami niesie własną złożoność: ktoś odchodzi z zespołu i musisz odwołać klucz dla wszystkich i go redystrybuować.
A propos: cennik Composio zmienia się 15 sierpnia. Nowy darmowy plan to około 20 000 wywołań narzędzi miesięcznie plus trzech członków zespołu — to w całości pokryje wiele małych zespołów. Powyżej tego jest bardzo przystępnie: 29 dolarów miesięcznie za 50 000 wywołań z nieograniczoną liczbą członków zespołu.
(Informacja dodatkowa: podane ceny i limity odnoszą się do stanu z lipca 2026 i mogą się zmienić — sprawdź aktualny cennik przed wdrożeniem.)
Warstwa 3: wspólna pamięć — najtrudniejszy element
Mamy więc współdzielony kontekst i współdzielone narzędzia bez dzielenia się kluczami. Dochodzimy do najtrudniejszej części układanki — wspólnej pamięci.
Kiedy rozmawiasz z Claude, przyjmuje on historię twojej sesji i podjęte w niej decyzje. Skoro pracujemy z Claude wspólnie, chcemy móc przechowywać te decyzje tak, by inny członek zespołu mógł je później przywołać. To ogromna warstwa współpracy zespołowej, która pozwala wyjść z pracy w silosach. Używamy do tego usługi supermemory.ai. Do użytku zespołowego potrzebny jest plan pro za 19 dolarów miesięcznie, ale można też wypróbować ją za darmo.
Nie użyjemy tu wbudowanej funkcji Slacka, bo nie chcemy ograniczać cię do Slacka — choć jeśli będzie zainteresowanie, zrobię osobne demo, jak używać tego wewnątrz Slacka z segmentowanymi prywatnymi uprawnieniami.
Dlaczego zewnętrzne narzędzie, a nie wbudowana pamięć Claude? Wbudowana pamięć Claude działa per konto i — jak wiesz, jeśli oglądałeś moje wcześniejsze filmy o pamięci — jest dość słaba. Nie wychwytuje wielu informacji, a jej odzyskiwanie i zapisywanie jest bardzo ręczne. Budujemy więc niezależnie własny system pamięci, ale przyglądamy się też dobrym rozwiązaniom na rynku, jak supermemory.ai, zwłaszcza pod kątem pracy zespołowej.
Istotne założenia: chcemy, by każdy miał własną osobistą pamięć na swojej maszynie, ale też wnosił coś do wspólnej pamięci, gdy to istotne. Wspólna pamięć zespołu oznacza, że mogę wyciągnąć informacje kolegi i zobaczyć, jakie decyzje podjął, gdy dzielę z nim projekt. To podobne do współdzielonego dostępu do plików w Notion, tylko że tu masz dostęp do kontekstu rozmów — do tego, dlaczego podjęto określone decyzje. I to właśnie nazywamy pamięcią.
Dla prostoty zdecydowaliśmy się użyć supermemory.ai jako wtyczki z jednym kontenerem współdzielonym w zespole. Gdy zaczynasz pracę, wtyczka wciąga odpowiednie pamięci. Gdy kończysz, przechwytuje dokładnie to, czego się nauczyłeś i jakie rozmowy prowadziłeś. Wszystko dzieje się automatycznie — nie musisz mówić, co zapisać ani skąd przywołać, choć możesz to robić ręcznie. W panelu Supermemory pamięci trafiają do „kontenerów”, oznaczonych tagami. Kontenery mieszczą się w twoim workspace.
Konfiguracja. Wchodzisz w ustawienia, tym razem w sekcję wtyczek. Dodajesz marketplace, potem „dodaj z repozytorium” i wklejasz supermemoryai/claude-supermemory. Klient znajdzie repozytorium; synchronizujesz się z nim. Po synchronizacji dostajesz siedem różnych umiejętności (skills). Pierwszej użyjemy do konfiguracji projektu — podłączenia właściwego klucza API i upewnienia się, że piszemy do właściwego kontenera. Są też funkcje do ręcznego zapisywania i przeszukiwania pamięci.
Każda wysłana wiadomość trafia do kontenera projektu. Widać tam losowe ciągi znaków z różnych repozytoriów rozmów, ale też kontenery nazwane celowo. Właśnie taki utworzymy — o nazwie „team OS” — wspólny kontener, do którego wielu użytkowników może pisać i z którego może czytać. Zamiast polegać na automatycznym tworzeniu kontenerów, zmuszamy Claude desktop do zapisu właśnie do „team OS”. Wewnątrz widać wszystkie prowadzone rozmowy — dodane dokumenty, a w każdej sesji pamięć podzieloną na wektory, by dała się łatwo przeszukiwać przy późniejszym przywoływaniu.
W aplikacji Claude desktop wpisujesz /project config. Klient pyta, co chcesz ustawić. Występujemy tu jako administrator konta — to kroki admina, które potem trzeba powtórzyć dla każdego użytkownika. Musimy też zaprosić ich do workspace Supermemory, żeby nie tworzyli własnych osobnych kontenerów, tylko zasilali nasz kontener „team OS”. Podajemy klucz API (tworzysz go w Supermemory z pełnym dostępem, nazwą i datą wygaśnięcia), a następnie uruchamiamy polecenie ponownie, by dodać tag kontenera projektu. Na pytanie o wartość tagu podajemy na przykład „team OS demo”. Dla kontenerów wstawiamy myślnik zamiast spacji.
Ponieważ nie pracujemy w repozytorium GitHub, wartość zapisuje się do pliku konfiguracyjnego — można ją zmienić bezpośrednio, znajdując folder .claude. Ważne: jeśli zaczniesz pracować w repozytorium, musisz utworzyć w nim nowy tag kontenera, inaczej klient utworzy osobny tag dla każdej rozmowy. Ustawienie stałego tagu wymusza zapis do jednego, konkretnego kontenera.
Żeby coś zapisać, wpisujesz /supermemory i wybierasz „save” — na przykład „zapisz ten kod 1 2 3 4 5 6 7 8 9”. Po odświeżeniu w konsoli Supermemory pojawi się nowy tag kontenera. Jeśli trafisz na błąd, bo zapis jest zablokowany, przejdź do ustawień, do sekcji „capabilities”, przewiń w dół i dodaj api.supermemory.ai do listy dozwolonych domen — dzięki temu piaskownica w chmurze uzyska uprawnienie dostępu do tej domeny.
Uwaga o trwałości konfiguracji. Klient ostrzega, że konfiguracja żyje w bieżącym workspace sesji. Jeśli nie wrócisz do tej samej sesji, tag kontenera nie przetrwa między sesjami. Dlatego warto pracować z folderu projektu, w którym uruchomisz project config — wtedy za każdym razem, gdy pracujesz z tego folderu, klient wie, że pisze do konkretnego kontenera. Innymi słowy: cały zespół powinien pracować z jednego folderu projektu. To domyka koło i wraca do pracy z tych samych dokumentów Notion — powinniśmy pracować z tego samego zestawu plików i folderów.
Dostęp dla zespołu. Żeby dać dostęp innym, wchodzisz w zakładkę zespołu i zapraszasz członków. Gdy dołączą, tworzą własny klucz API i uruchamiają dokładnie tę samą konfigurację: project config, swój klucz API i dokładnie ten sam tag kontenera „team OS demo”, jeśli mają pisać do tego samego kontenera. Dzięki temu współpracownik może przywołać wszystkie informacje z pamięci moich rozmów, bo ma bezpośredni dostęp do „team OS demo”. Kierujesz więc wszystkich na ten sam tag kontenera w workspace, każdy z własnym kluczem API — i masz jeden wspólny mózg, do którego cały zespół pisze i z którego czyta.
Na początku bywa to mylące: jeśli członek zespołu zarejestruje się w Supermemory samodzielnie i utworzy klucz, dostaje własny prywatny workspace. Trzeba więc najpierw ich zaprosić, a dopiero potem konfigurują klucze. Dzięki systemowi kontenerów możesz dzielić kontekst tam, gdzie trzeba, i trzymać go prywatnie tam, gdzie nie chcesz się nim dzielić — po prostu nie publikując go do kontenera „team OS”.
Jest jednak zastrzeżenie: administrator w Supermemory wydaje się mieć dostęp do absolutnie wszystkich informacji, także prywatnych pamięci — co jest pewnym problemem. Ale w małym zespole, gdzie jesteś uczciwy wobec ludzi co do tego, jak przechowywane są dane, to niewielka cena za moc tej konfiguracji wspólnej pamięci, którą uruchamiasz w kilka minut.
Gdzie ten układ zawodzi — dwa ograniczenia
Pracując z tym w zespole, zauważyliśmy dwa kluczowe ograniczenia, o których powinieneś wiedzieć — poza tymi już wspomnianymi.
Pierwsze dotyczy tego, jak pamięć wchodzi w interakcję z kontekstem z Notion. Jeśli udostępniłeś coś użytkownikowi, on wciągnął ten kontekst z Notion w danej sesji, a następnie zapisał na jego podstawie pamięć — to technicznie nadal będzie miał dostęp do tego kontekstu przez system pamięci, nawet jeśli później odbierzesz mu uprawnienia w Notion. Bo ma dostęp do pamięci, która wciągnęła i zapisała ten kontekst.
Drugie, powiązane: wszystko w tym układzie trafia do jednego wspólnego kubła. Wtyczka automatycznie przechwytuje wszystkie informacje na końcu każdej sesji i wrzuca je prosto do kontenera „team OS”. Nie ma podziału na prywatne i wspólne. To raczej ostrzeżenie: bądź świadomy tego, z których folderów uruchamiasz tę konfigurację, i trzymaj wrażliwą pracę dla klientów poza tą pamięcią zespołu.
To są ograniczenia, które naprawiłbym w pierwszej kolejności. Chcemy, żebyś mógł pracować w prostym interfejsie Claude desktop, ale z mocą wspólnej pamięci — zachowując przy tym prywatność własnych rozmów. Dlatego wciąż budujemy własny zespołowy system operacyjny, który to rozwiąże. Jeśli chcesz zgarnąć całą konfigurację w gotowym przewodniku krok po kroku, jest ona dostępna w płatnej społeczności podlinkowanej w opisie; wprowadziliśmy tam też trzech trenerów Claude z codziennym trzygodzinnym wsparciem na żywo jeden na jeden.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Traktuj kontekst jako współdzieloną infrastrukturę, nie własność jednego Claude
Na czym polega: Domyślne narzędzia (pamięć Claude, frameworki pamięci, połączenia MCP) są zaprojektowane dla jednego użytkownika. Zespołowa praca wymaga przesunięcia kontekstu, uprawnień, narzędzi i pamięci do wspólnej warstwy, do której każdy się podłącza.
Jak stosować: Zanim zaczniesz kupować narzędzia, rozdziel problem na trzy warstwy — wspólne dokumenty, wspólne narzędzia, wspólna pamięć — i dla każdej wskaż jedno źródło prawdy dostępne dla całego zespołu.
Na co uważać: Nie próbuj rozwiązać tego kopiowaniem folderów między maszynami — działa krótko i szybko się rozjeżdża. Potrzebujesz warstwy z wbudowanymi uprawnieniami.
2.Użyj Notion (lub Google Drive) jako warstwy wspólnego kontekstu z uprawnieniami
Na czym polega: Notion pełni rolę dysku współdzielonego. Claude podłączony przez MCP widzi tylko to, co dana osoba widzi w Notion, i zapisuje tylko tam, gdzie ma uprawnienia. Nie budujesz systemu uprawnień — dziedziczysz istniejący.
Jak stosować: Podłącz każdego użytkownika przez jego własny login Notion, a adres URL wspólnej strony umieść w Claude.md lub instrukcjach: „Przy dostępie do plików zespołu najpierw sprawdź ten URL”. Uprawnieniami do stron sterujesz zwykłym panelem Notion.
Na co uważać: To zadziała z dowolnym hostingiem z uprawnieniami (np. Google Drive), więc nie kupuj Notion tylko po to. Pamiętaj też, że zmiana uprawnień w Notion propaguje się do Claude, ale nie odbiera już zapisanych pamięci (patrz punkt 9).
3.Dziel się narzędziami, nie kluczami API — przez warstwę pośredniczącą
Na czym polega: Composio trzyma klucze w skarbcu, a zespół loguje się własnymi kontami. Jeden konektor MCP daje Claude dostęp do ponad tysiąca aplikacji, a żaden klucz nie opuszcza platformy.
Jak stosować: Jako admin ustaw auth raz, zaproś zespół do workspace Composio i dodaj konektor niestandardowy w Claude. Każdy podłącza swoje własne konta aplikacji (np. własną skrzynkę Gmail) do swojego projektu.
Na co uważać: To eliminuje koszmar rotacji kluczy przy odejściu pracownika. Sprawdzaj jednak aktualny cennik — limity darmowego planu (ok. 20 000 wywołań, 3 osoby) i zmiany od 15 sierpnia 2026 mogą już nie obowiązywać.
4.Podłączaj wiele kont tego samego typu naraz
Na czym polega: Wbudowany konektor Claude ogranicza cię do jednego konta Gmail. Przez Composio podłączysz cztery–pięć skrzynek z różnymi ID i przeskanujesz je wszystkie w jednym zaplanowanym zadaniu.
Jak stosować: Wykorzystaj to do zadań agregujących — przegląd wielu firmowych skrzynek, wielu kont CRM czy paneli — których pojedynczy natywny konektor nie obsłuży.
Na co uważać: Każde konto musi być podłączone przez uwierzytelnienie właściwej osoby; nie obchodź tego współdzielonymi loginami, jeśli aplikacja oferuje osobne miejsca (seats).
5.Dla współdzielonych zasobów najpierw nadaj uprawnienia w samej aplikacji
Na czym polega: Gdy wiele osób potrzebuje dostępu do firmowej skrzynki czy księgowości (np. Xero), najprościej nadać im miejsce i uprawnienia bezpośrednio w tej aplikacji — Composio przekaże te delegacje przy logowaniu.
Jak stosować: Dodaj osobę jako seat w narzędzie księgowe z właściwym poziomem uprawnień; potem loguje się przez Composio i dziedziczy dokładnie te uprawnienia — bez współdzielenia hasła.
Na co uważać: Wymaga to płatnego miejsca w docelowej aplikacji. Jeśli aplikacja nie oferuje seatów, przejdź do punktu 6.
6.Bramka MCP Composio dla przypadków „jeden login, brak miejsc”
Na czym polega: Dla narzędzi z jednym współdzielonym loginem (planer treści, LinkedIn firmy, panel afiliacyjny) jedno wywołanie API do Composio tworzy zawężony serwer MCP z dostępem tylko do wybranego narzędzia i zwraca gotowy adres URL do dodania jako konektor.
Jak stosować: Użyj, gdy chcesz dać komuś zakres uprawnień (np. tylko QuickBooks albo tylko GitHub na konkretnej gałęzi) bez wydawania mu klucza i bez pełnego dostępu do konta.
Na co uważać: Nie da się tego zrobić z panelu Composio — to krok techniczny wymagający wywołania API. Zawężaj dostęp tak wąsko, jak się da.
7.Odrzuć wbudowaną pamięć Claude na rzecz Supermemory dla zespołu
Na czym polega: Pamięć Claude jest per konto, słabo wychwytuje informacje i wymaga ręcznej obsługi. Supermemory automatycznie wciąga istotne pamięci na starcie sesji i przechwytuje wnioski na koniec, a treść jest wektoryzowana pod wyszukiwanie.
Jak stosować: Zainstaluj wtyczkę z repozytorium supermemoryai/claude-supermemory, skonfiguruj przez /project config i wskaż jeden wspólny kontener. Do użytku zespołowego potrzebny jest plan pro (19 USD/mies. wg stanu z lipca 2026).
Na co uważać: Zapisy mogą być blokowane, dopóki nie dodasz api.supermemory.ai do listy dozwolonych domen w ustawieniach „capabilities”.
8.Jeden wspólny kontener + kolejność zapraszania to sedno konfiguracji zespołowej
Na czym polega: Cały zespół musi celować w ten sam tag kontenera (np. „team OS”), każdy z własnym kluczem API. Wtedy jeden pisze pamięć, a inny może ją przywołać — jeden wspólny mózg.
Jak stosować: Najpierw zaproś ludzi do workspace Supermemory, a potem niech utworzą klucze i uruchomią project config z dokładnie tym samym tagiem kontenera. Odwrotna kolejność tworzy im osobne, prywatne workspace.
Na co uważać: Konfiguracja żyje w workspace sesji — by tag przetrwał, pracujcie wszyscy z jednego wspólnego folderu projektu i tam uruchamiajcie project config. W repozytorium GitHub trzeba jawnie ustawić nowy tag, inaczej powstanie osobny kontener na każdą rozmowę.
9.Uprawnienia „wyciekają” przez pamięć — odebranie dostępu w Notion nie cofa zapisanej pamięci
Na czym polega: Jeśli ktoś wciągnął kontekst z Notion i zapisał go jako pamięć, zachowa dostęp do tego kontekstu przez Supermemory nawet po odebraniu mu uprawnień w Notion.
Jak stosować: Planuj dostęp z wyprzedzeniem — zakładaj, że każdy kontekst, który raz trafi do wspólnej pamięci, jest tam trwale dla wszystkich z dostępem do kontenera.
Na co uważać: Nie traktuj uprawnień Notion jako mechanizmu wycofania danych z pamięci. To dwie rozłączne warstwy; odwołanie w jednej nie czyści drugiej.
10.Brak podziału prywatne/wspólne i pełny wgląd admina — trzymaj wrażliwą pracę osobno
Na czym polega: Wtyczka automatycznie zrzuca wszystko z końca każdej sesji do wspólnego kontenera — nie ma rozdziału na pamięć prywatną i zespołową. Dodatkowo admin Supermemory widzi wszystkie pamięci, także prywatne.
Jak stosować: Bądź celowy co do tego, z których folderów uruchamiasz tę konfigurację. Wrażliwą pracę dla klientów prowadź z folderów niepodłączonych do wspólnego kontenera.
Na co uważać: To układ dla małego, zaufanego zespołu, w którym jesteś transparentny co do przechowywania danych. Nie nadaje się tam, gdzie potrzebna jest twarda izolacja danych klientów czy zgodność regulacyjna — do tego trzeba czekać na dojrzalsze rozwiązania albo budować własne.