Zanim zacząłem budować ekosystem AI, musiałem wiedzieć co buduję.

Miałem sześć narzędzi do kodowania i cztery do pisania. Każde działało osobno. System nie rósł ze mną - ja rosłem obok niego.

Dziesięć zabawek, zero systemu

Składowe ówczesnego systemu to mix moich i cudzych rozwiązań. Działały, ale były odizolowanymi wyspami. Każde miało własną pamięć, własny kontekst i zero pojęcia o istnieniu pozostałych. Brakowało spójnego rdzenia, który łączyłby przepływ informacji.

Konsekwencje były bolesne i mierzalne - godziny zbędnego przekopiowywania i ręcznej synchronizacji. Narzędzia do pisania nie miały pojęcia, na jakie rozterki natknąłem się, tworząc nową funkcjonalność przy pomocy narzędzi do kodowania. Agent, z którym debugowałem problem w kodzie, nie przekazywał tej wiedzy agentowi, który pomagał mi napisać o tym problemie artykuł. Wiedza nie przepływała między domenami. Każda interakcja zaczynała się od zera, a ja byłem jedynym, kosztownym i zawodnym mostem między nimi.

Pytania przed pierwszą linijką

Zamiast szukać kolejnego, siódmego narzędzia do kodowania, które obiecywało rozwiązać wszystko, zatrzymałem się. Uznałem, że problem nie leży w braku funkcji, ale w braku fundamentu. Zanim napisałem pierwszą linijkę kodu nowego systemu, nazwanego później Cortex, musiałem odpowiedzieć na serię pytań architektonicznych.

• Jeden system czy osobne instancje per dziedzina? Budowa osobnych systemów do pisania i kodowania odtworzyłaby problem silosów, który próbowałem rozwiązać. Potrzebowałem jednego, spójnego systemu, zdolnego do transferu wiedzy między pozornie odległymi od siebie dziedzinami.
• Silnik przywiązany do jednego LLM czy uniwersalny? Przywiązanie się do API jednego dostawcy, np. OpenAI, to ogromny dług technologiczny. Modele zmieniają się co kilka miesięcy. Architektura musiała traktować LLM jako wymienialny komponent, a nie fundament.
• Jak oddzielić zasady pisania od kodowania, skoro AI widzi wszystko naraz? System musi rozumieć kontekst zadania. Potrzebowałem mechanizmu, który aktywuje inne zestawy reguł, instrukcji i umiejętności w zależności od tego, czy proszę o refaktoryzację kodu, czy o korektę akapitu.
• Co się stanie z wiedzą, gdy zmienię model za pół roku? Jeśli cała pamięć systemu będzie oparta na wektorach generowanych przez konkretny model, stanie się bezużyteczna po jego zmianie. Baza wiedzy musiała być trwała i niezależna od technologii jej przetwarzania.
• Buduję od razu cały system czy zaczynam od jednego elementu? Próba zbudowania wszystkiego naraz zwykle kończy się tym, że nic nie działa dobrze i kolejne godziny idą na naprawianie błędów zamiast na rozwój. Musiałem zidentyfikować absolutny rdzeń - minimalny, działający zestaw komponentów - i zbudować go jako pierwszy. Reszta miała powstać w odpowiedzi na realne potrzeby.
• Kto decyduje, co system pamięta - ja, AI, czy obaj z podziałem stref? Pełna automatyzacja zapisu prowadzi do zaśmiecenia bazy wiedzy. Pełna manualna kontrola jest nieefektywna. Potrzebowałem hybrydy: ja decyduję o trwałej, strukturalnej wiedzy, a AI zarządza pamięcią krótkotrwałą w ramach sesji.

Decyzje - rdzeń

Odpowiedzi na te pytania zdefiniowały architekturę rdzenia. Pierwszym elementem stał się Vault - system pamięci długoterminowej. Wybrałem pliki markdown z relacjami grafowymi, a nie popularny RAG (Retrieval-Augmented Generation). RAG jest świetny w wyszukiwaniu faktów, ale ja potrzebowałem relacji między nimi. Musiałem wiedzieć, że decyzja biznesowa X wpłynęła na funkcjonalność Y w kodzie, co z kolei stało się podstawą do napisania artykułu Z. Graf relacji to umożliwia. Zamiast bazy wektorowej postawiłem na pliki markdown. Dlaczego? Bo plik .md przetrwa każdą zmianę technologiczną. Jest czytelny dla człowieka i maszyny, łatwy do wersjonowania i niezależny od konkretnego narzędzia. Jako interfejs do wizualizacji i edycji tego grafu wybrałem Obsidiana.

Drugim elementem rdzenia jest Engine. Obecnie jest oparty na Claude Code, ale został zaprojektowany z myślą o uniwersalności. Sam LLM jest tylko wykonawcą. Prawdziwa wartość Engine leży w warstwie abstrakcji, którą wokół niego zbudowałem: w systemie skilli, hooków i skryptów. Te elementy są niezależne od modelu. Gdy jutro pojawi się lepszy LLM, wymienię tylko “silnik” w samochodzie, ale cała karoseria, układ kierowniczy i deska rozdzielcza pozostaną te same. To one definiują, jak system działa, a nie konkretny model językowy.

Pamięć bez silnika to archiwum. Silnik bez pamięci to amnezja. Vault i Engine to nierozłączna para. To one realizują podstawową pętlę: pobranie kontekstu z trwałej pamięci, przetworzenie go i wygenerowanie odpowiedzi, a następnie ewentualna aktualizacja pamięci o nowe wnioski.

Co jeszcze składa się na ekosystem

Od samego początku wiedziałem, że muszę mierzyć to, co buduję. Dlatego trzecim kluczowym elementem, wymaganym od dnia zero, jest Observer. To system monitorujący, który śledzi każdą interakcję z Engine. Rejestruje liczbę tokenów, dokładny kontekst wysłany do modelu i otrzymaną odpowiedź. Bez pomiaru nie wiedziałbym, czy informacje z Vault faktycznie trafiają do kontekstu AI i czy robią to efektywnie. Observer to mój panel diagnostyczny, bez którego optymalizacja byłaby zgadywaniem.

Pozostałe komponenty, takie jak Cron i Dictate, powstały później, z konkretnych potrzeb. Cron pozwala na zdalne uruchamianie sesji z AI, optymalizację kosztów przez grupowanie zadań i pracę z dowolnego urządzenia, nawet telefonu. Dictate to system sterowania komputerem za pomocą głosu, pozwalający na dyktowanie tekstu i wydawanie komend głosem. Każdy z tych elementów rozwiązuje realny problem i wpina się w istniejący rdzeń.

Ta seria wpisów skupi się jednak na absolutnym fundamencie: trójcy Vault, Engine i Observer. To one stanowią architektoniczną podstawę, bez której reszta nie mogłaby istnieć. Pozostałe elementy to materiał na przyszłe opowieści.

Ograniczenia jako architektura

Projektując system, równie ważne jak zdefiniowanie tego, co ma robić, jest określenie, czego ma nie robić. Przyjąłem trzy fundamentalne ograniczenia, które stały się częścią architektury.

Pierwsze: koszt. Prowadzenie systemu kosztuje - tokeny, czas na utrzymanie, uwagę. Ten rachunek nie może przewyższyć zysków z jego istnienia.

Drugie: szum informacyjny. System, który zaciąga do kontekstu za dużo nieistotnych informacji, jest gorszy niż brak systemu. Prowadzi do halucynacji i błędnych odpowiedzi. Dlatego zasada brzmi: mniej, ale trafniej. Lepszy jest precyzyjny fragment wiedzy niż dziesięć stron ogólnego szumu. Cały mechanizm pobierania danych z Vault jest zaprojektowany z myślą o tej precyzji.

Trzecie: strefy kontroli. Musi istnieć jawna, twarda granica między tym, co kontroluje AI, a co kontroluję ja. Ja zarządzam architekturą, długoterminową pamięcią (Vault) i strategicznymi celami. AI zarządza wykonaniem zadań w ramach jasno zdefiniowanych umiejętności i pamięci krótkotrwałej. Ta granica zapobiega utracie kontroli i zapewnia, że system pozostaje narzędziem, a nie autonomicznym bytem.

Zamknięcie

Architektura Cortex nie jest skończona i nigdy nie będzie. Nie powstała na podstawie wielkiego, spisanego z góry planu. Każdy element, każda decyzja i każde ograniczenie wyniknęły z konkretnej, zidentyfikowanej potrzeby i próby odpowiedzi na fundamentalne pytania postawione na samym początku.

Rdzeń istnieje. Jak sprawdzić, czy działa w praktyce? O tym w następnym wpisie.

W newsletterze rozwijam tego rodzaju tematy głębiej. Zapisz się.