Cairn

Self-hosted panel, w którym wiedza o projekcie przeżywa agentów, którzy nad nim pracują. Log koordynacyjny, nie runner: agenci czytają briefing i raportują wynik, a Ty nie tłumaczysz każdemu tego samego od nowa. Dla zespołów puszczających kilku agentów na ten sam kod.

Cairn
TL;DR

Cairn to self-hosted panel, w którym wiedza o projekcie przeżywa agentów AI, którzy nad nim pracują. To log koordynacyjny, nie runner: agent czyta briefing, robi swoje i raportuje wynik, a Ty nie tłumaczysz kolejnemu tego samego od zera. Dla zespołów, które puszczają kilku agentów na ten sam kod i mają dość tego, że pamięć projektu ginie razem z sesją.

Wprowadzenie

Kiedy nad jednym repo pracuje kilku agentów AI, wiedza o projekcie ma paskudny zwyczaj umierania razem z sesją, która się skończyła. Pierwszy agent poznał ukryte zależności, dowiedział się, która część kodu jest krucha, i ustalił, jak się tu deployuje. Potem sesja gaśnie i ta wiedza znika. Następnemu agentowi tłumaczysz to samo od początku, i kolejnemu, i jeszcze raz, aż stajesz się wąskim gardłem dla wiedzy o własnym projekcie.

To nie jest problem mocy obliczeniowej ani modelu. Żaden mocniejszy agent tego nie naprawi, bo to problem pamięci między sesjami, a nie w obrębie jednej. Cairn celuje dokładnie w to miejsce: trzyma briefing i historię ustaleń w jednym miejscu, które nie znika, kiedy agent kończy pracę. Cała reszta tego case study to opowieść o tym, dlaczego świadomie jest to log, a nie kolejny orchestrator.

Wiedza, która umiera z sesją

Sesja agenta jest z natury ulotna. Zbiera kontekst, buduje na nim swoją pracę, a potem kończy się i cały ten kontekst paruje. Przy jednym agencie to żaden problem: pamiętasz go Ty. Przy pięciu, które wchodzą w to samo repo jeden po drugim albo równolegle, każdy zaczyna od zera i każdy odkrywa te same miny na nowo. Tę samą kruchą migrację, ten sam nieoczywisty deploy, tę samą zależność, która wywala się tylko w pewnej kolejności.

Naturalny odruch to spisać to w README albo wkleić w prompt. Tyle że README szybko się starzeje, a prompt ginie razem z oknem czatu. Potrzebne było miejsce, które rośnie razem z projektem i przeżywa poszczególne sesje: coś, do czego agent zagląda po kontekst na wejściu i do czego dopisuje, co zrobił, na wyjściu.

i
Informacja

Cairn świadomie nie jest runnerem. Nie odpala agentów, nie zarządza ich procesami i nie próbuje być ich środowiskiem. Jest logiem koordynacyjnym: miejscem, do którego agent zagląda po kontekst i do którego zapisuje, co zrobił. Ta granica jest całą jego siłą.

Log, nie runner

Łatwo było zrobić z tego kolejny orchestrator, który sam odpala agentów i próbuje nimi dyrygować. Odpuściliśmy to celowo, bo runnery mają przewidywalny los: wpinają się głęboko w twoje środowisko, zakładają o nim coraz więcej i szybko stają się rzeczą, która sama wymaga utrzymania. Zamiast dawać pamięć, zabierają czas.

Log koordynacyjny jest odwrotnie: prosty, pasywny i nie wchodzi nikomu w drogę. Agent nadal żyje tam, gdzie zwykle, w twoim terminalu czy pipeline, robi swoje we własnym środowisku, a Cairn tylko daje mu pamięć i miejsce na raport. Nie ma tu magii orchestracji, która działa na demie i sypie się na prawdziwym projekcie, bo nie ma orchestracji w ogóle.

Co trzyma, a czego świadomie nie

RolaCairn robi toCairn tego nie robi
Konteksttrzyma briefing i historię ustaleńnie zgaduje kontekstu za Ciebie
Koordynacjalog wpisów per projekt, po koleinie odpala i nie zarządza procesami agentów
Hostingstawiasz u siebie, dane zostają Twojenie wysyła Twojego kodu do cudzej chmury
Widocznośćjedno miejsce na to, co zrobione i otwartenie zastępuje Twojego repo ani CI

Pętla briefing, praca, raport

Sercem jest log koordynacyjny per projekt. Zamiast trzymać wiedzę w głowie jednego agenta albo w jednej sesji czatu, zapisujesz ją raz jako briefing, a każdy kolejny agent zaczyna od jej przeczytania. Po skończonej pracy dopisuje własny wpis: co zrobił, jaki jest stan, co zostało otwarte dla następnego. Log rośnie i staje się pamięcią projektu, która nie zależy od tego, która sesja akurat żyje.

1
Briefing

zakładasz projekt i opisujesz go raz: co to jest, gdzie są granice, na co uważać.

2
Agent czyta

każdy nowy agent zaczyna od tego samego kontekstu, bez powtarzania go ręcznie.

3
Agent pracuje

robi swoje zadanie we własnym środowisku, bo Cairn go nie odpala ani nie ogranicza.

4
Agent raportuje

dopisuje wynik do logu: co zmienił, co działa, co zostało do zrobienia.

5
Następny kontynuuje

kolejny agent czyta briefing plus wszystkie raporty i wchodzi w pracę z pełnym obrazem.

Klucz jest w tym, że wpis nie jest swobodnym tekstem, tylko krótką strukturą ze stanem i listą tego, co otwarte dla następnego. Dzięki temu log da się czytać przez maszynę i przez człowieka tak samo szybko, a kolejny agent nie musi domyślać się, na czym stanęła poprzednia tura.

entry.ts · ts
type LogEntry = {
  project: string;
  agent: string;
  at: string;
  did: string;
  state: 'done' | 'partial' | 'blocked';
  openForNext: string[];
};

function contextFor(project: string): string {
  const brief = readBrief(project);
  const history = readEntries(project);
  return [brief, ...history.map(render)].join(SECTION_BREAK);
}

Skala, która rośnie z projektem

Różnica robi się widoczna dopiero na dystansie. Bez wspólnej pamięci koszt wprowadzenia każdego kolejnego agenta rośnie, bo za każdym razem tłumaczysz ręcznie coraz dłuższą historię projektu. Z Cairnem ten koszt jest płaski: pierwszy agent i dziesiąty czytają to samo źródło, więc wchodzą w pracę z tym samym obrazem, niezależnie od tego, który są po kolei.

Czas wprowadzenia kolejnego agenta (orientacyjnie, minuty)

Agent 1Agent 2Agent 3Agent 4Agent 5

To jest cała różnica między zespołem, który skaluje liczbę agentów, a zespołem, który tonie we własnym onboardingu. Pamięć, która przeżywa sesje, zamienia wiedzę o projekcie z czegoś, co trzeba za każdym razem odtworzyć, w coś, co po prostu jest.

1 briefing
pisany raz, czytany przez każdego agenta
1 log per projekt
pamięć, która przeżywa sesje
0
odpalanych procesów, bo to nie runner
self-hosted
dane i kod zostają u Ciebie

Cicha warstwa pamięci

Najlepsze narzędzia nie są te, które robią najwięcej. To te, które robią jedną rzecz i schodzą z drogi.

Zespół, który puszcza kilku agentów na ten sam kod, przestaje być wąskim gardłem dla własnej wiedzy. Briefing piszesz raz, a nie przy każdym nowym oknie czatu. Agent, który wchodzi jako trzeci, wie tyle samo co pierwszy, bo czyta to samo. Cairn nie jest efektowny i nie stara się być: jest cichą warstwą pamięci, której wcześniej brakowało między sesjami.

➜
Wskazówka

Trzymaj briefing krótki i twardy: granice projektu, rzeczy kruche, sposób deployu. Resztę dopisują agenci w swoich raportach. Briefing, który próbuje opisać wszystko, starzeje się tak samo szybko jak README, które miał zastąpić.

Ponieważ stawiasz go u siebie, ani kod, ani historia ustaleń nie wychodzą do cudzej chmury. Pamięć projektu zostaje tam, gdzie projekt: u Ciebie. To niepozorna warstwa, ale kiedy raz zaczniesz puszczać agentów seriami, trudno bez niej wrócić.

Więcej projektów

Inne realizacje z tej samej kategorii - zobacz, jak podchodzimy do podobnych wyzwań.

Masz podobny projekt?

Napisz do nas - wycena jest bezpłatna i wraca w godzinę.