My Architect, część 1: pamięć i plan dla agenta AI

To pierwszy wpis z serii o My Architect — systemie, w którym projekt żyje między sesjami agenta AI. Człowiek widzi i edytuje całość przez interfejs wizualny, agent zarządza tym samym projektem przez MCP. Seria ma siedem części; plan znajdziesz na końcu wpisu.

Problem: agent jest genialny i nic nie pamięta

Claude Code w pół godziny rozwiązuje zadanie, na które senior poświęciłby cały dzień. Potem sesja się kończy. Następnego ranka agent nie pamięta, dlaczego wybraliście Postgresa, które funkcje odłożyliście do drugiego release'u ani na czym skończyliście wczoraj o ósmej wieczorem.

Okno kontekstu jest skończone. Długa rozmowa zostaje skompresowana i jako pierwsze wypadają z niej właśnie decyzje sprzed dwóch tygodni, na których wszystko się opiera. Tłumaczysz wszystko od nowa, agent „zmienia zdanie” w sprawach dawno ustalonych, a czasem przerabia to, co działało.

Czym się to zwykle leczy:

CLAUDE.md i notatki w repozytorium. Działa, dopóki plik jest krótki. Przy setnej linijce zamienia się w śmietnik, w którym reguły lintera leżą obok przełomowych decyzji architektonicznych.
Plany w plikach markdown. PLAN.md, ROADMAP.md, TODO.md — każdy żyje własnym życiem, przeczy sąsiadom, a agent sam decyduje, który z nich uznać za prawdę.
Jira albo Linear. Zrobione dla ludzi i procesów. Agent dostaje tam w najlepszym razie dostęp przez API, bez struktury, którą wygodnie mu się czyta: ani dziedziczenia wymagań, ani pojęcia „weź następne zadanie z uwzględnieniem release'u i głębokości drzewa”.

Wspólna bolączka całej trójki: nie ma jednego miejsca, które byłoby równie wygodne dla człowieka i dla agenta.

Pomysł: jedno źródło prawdy, dwa interfejsy

My Architect przechowuje projekt jako hierarchię węzłów: Epic → Feature → Story → Task (do wyboru schemat SAFe albo uproszczony). Do węzłów podpina się wymagania, dokumenty i diagramy. Pod maską to zwykłe pliki YAML i Markdown — żadnej zamkniętej bazy, dane przeżyją każde narzędzie.

Nad jednym magazynem danych stoją dwa równorzędne wejścia.

Dla człowieka — canvas: drzewo WBS z automatycznym układem, User Story Map z release'ami w poziomie, drag-and-drop do przepinania węzłów, statusy oznaczone kolorem. Przeciągasz story do innego release'u — plik się zmienia.

Dla agenta — ponad 30 narzędzi MCP. Typowa sesja wygląda tak:

get_project_context(pid)   → hierarchia, backlog, release'y — jednym wywołaniem
get_next_task(pid)         → zadanie dobrane z uwzględnieniem release'u i głębokości drzewa
start_task(pid, node-42)   → status in-progress, agent przypisany
create_doc(...)            → specyfikacja podpięta wprost do węzła
complete_task(pid, node-42, summary)
                           → done, statusy rodziców przeliczone,
                             w odpowiedzi od razu następne zadanie

Synchronizacja działa na żywo: agent zamyka zadanie — węzeł na canvasie szarzeje jeszcze w trakcie sesji, bez przeładowania. Zadziałał file watcher: backend zauważył zmianę YAML-a na dysku i rozesłał zdarzenie do przeglądarki przez WebSocket.

Co agent pamięta między sesjami

Nowa sesja nie zaczyna się od czystej kartki, tylko od jednego wywołania get_project_context: cała hierarchia, backlog, release'y, statystyki. Od tego momentu agent dokładnie wie, co jest zrobione, co jest zablokowane i dlaczego oraz co brać jako następne.

Decyzje nie są przechowywane w tekście rozmowy, tylko jako wymagania czterech typów: funkcjonalne (FR), niefunkcjonalne (NFR), architektoniczne (SAR) i ograniczenia (CON). Wymagania są dziedziczone w dół drzewa: NFR „odpowiedź poniżej 200 ms” zawieszony na epicu jest widoczny z każdego zagnieżdżonego zadania. Agent, biorąc zadanie z trzeciego poziomu, dostaje zarówno jego własne wymagania, jak i wszystko, co nazbierało się u przodków.

Pamięć agenta to nie okno kontekstu. To struktura projektu, którą czyta jednym wywołaniem na początku każdej sesji.

Dlaczego MCP, a nie kolejna integracja

MCP to otwarty protokół, a My Architect był budowany wokół niego od pierwszego dnia, nie jako nakładka. Podpina się każdy zgodny agent: Claude Code, agenty na Anthropic SDK, cokolwiek pojawi się jutro. Konfiguracja to pięć linijek w .mcp.json.

Druga strona tej samej monety: i UI, i narzędzia MCP przechodzą przez jeden backend i jedną logikę domenową. Agent nie może zepsuć tego, co widzi człowiek — fizycznie współdzielą te same pliki i te same reguły wprowadzania zmian.

Drobiazg, który jest wart bardzo wiele

System nie pozwoli agentowi nazwać węzła „Implement login” ani „Fix bug in auth”. Węzły nazywa się jak byty: „Login system”, „Auth flow”. Wbudowany linter odrzuca czasowniki, tryb rozkazujący i sformułowania w stylu kryteriów akceptacji już na etapie build_hierarchy.

Wygląda na czepialstwo. Ale po miesiącu pracy backlog z dwustu węzłów czyta się jak mapę produktu, a nie jak rejestr poleceń — i człowiekowi, i agentowi.

Wszystkie części serii

Pamięć i plan dla agenta AI — ten wpis.
Architektura bez bazy danych — pliki YAML jako źródło prawdy, atomowy zapis, mutex na projekt i synchronizacja na żywo przez WebSocket. Plus historia o tym, jak równoległe zapisy gubiły 85% zmian.
Model planowania — hierarchia, wymagania z dziedziczeniem, User Story Map i release'y: jak sprawić, żeby agent planował jak architekt, a nie jak generator todosów.
Cykl pracy agenta — od get_next_task do complete_task: dokumentacja jako część zadania, living source of truth i konfrontowanie planu z realnym kodem.
Dystrybucja przez marketplace Claude Code — plugin, który jedną komendą instaluje i skill, i serwer MCP: jak działa marketplace, wersjonowanie i dlaczego skill mieszka w publicznym repozytorium.
Strona człowieka — WBS, Building Blocks i User Story Map — jak architekt używa narzędzia ręcznie: WBS na building blocks, User Story Map do priorytetyzacji i diagram, który wykonuje agent.
Obsidian, Claude Code docs i OpenClaw — notatki z pola — jaką pracę wykonują cudze narzędzia przechowywania wiedzy, gdzie każde ma sufit i dlaczego prowadzenie projektu z agentem to inna praca.

My Architect możesz wypróbować na my-architect.app. Pytania i zastrzeżenia — napisz do mnie; najciekawsze omówię osobno.