Przez ostatnie półtora roku zbudowałem kilkanaście produkcyjnych integracji z LLM - od asystenta osobistego z sześcioma wyspecjalizowanymi agentami, przez pipeline analizujący 230 godzin webinarów rocznie, po MCP serwery spinające Garmina, kalendarz i własne bazy klientów. W każdym z tych projektów był ten sam moment: prompt który działał idealnie na 50 przykładach, padał na 51. Nie dlatego, że był źle napisany. Dlatego, że model dostawał za mało, za dużo, albo nie ten kontekst.
Termin "context engineering" zaczął eksplodować w Q1 2026. Pisali o tym wszyscy - Neo4j, Firecrawl, The New Stack, podcast Lenny'ego. Według raportu Gartner z marca 2026 82% liderów IT odpowiedzialnych za wdrożenia AI mówi wprost, że samo promptowanie przestało im wystarczać. Nie dziwi mnie to. Dziwi mnie tylko, że zajęło tak długo, zanim ktoś nazwał to po imieniu.
Ten wpis nie jest tutorialem "10 trików na lepsze prompty". To opis tego, jak myślę o kontekście, kiedy projektuję system z LLM, który ma działać miesiącami bez mojego ręcznego strojenia. Pokażę cztery warstwy, które trzeba projektować osobno, własny pattern z Claude Code, który stosuję u siebie i u klientów, oraz konkretne błędy, które najczęściej widzę w cudzych projektach.
Co naprawdę znaczy "context engineering"
Prompt engineering to optymalizacja jednego stringa. Dobierasz słowa, kolejność, few-shot przykłady, system prompt. Działa świetnie, kiedy zadanie jest jednorazowe i samowystarczalne - klasyfikacja maila, podsumowanie raportu, generowanie wariantu copy.
Context engineering to projektowanie wszystkiego, co model widzi w momencie odpowiedzi. Prompt jest tylko jednym z kilku komponentów. Reszta to: pamięć trwała (co model wie o użytkowniku, projekcie, historii), wiedza pobrana on-demand (RAG, MCP, search), i sesja - czyli to, co już padło w bieżącej konwersacji. Wszystko razem musi się zmieścić w oknie kontekstu modelu i nie pochłonąć budżetu na tokeny.
Różnica jest taka, jak między pisaniem dobrej funkcji a projektowaniem architektury. Dobra funkcja w bałaganiarskiej architekturze nie uratuje systemu. Dobry prompt w bałaganiarskim kontekście produkuje halucynacje, niespójności i odpowiedzi typu "jako model językowy nie mam dostępu do tej informacji" - mimo że informacja siedzi trzy katalogi obok.
Pisałem o pokrewnym temacie w protokole zero halucynacji. Tam chodzi o reguły zachowania modelu. Context engineering to o jeden poziom niżej: jak zorganizować wiedzę, której model używa, żeby tych halucynacji w ogóle nie było skąd produkować.
Cztery warstwy kontekstu
Kiedy patrzę na produkcyjny system LLM, rozkładam kontekst na cztery niezależne warstwy. Każda ma inny czas życia, inny koszt i inne reguły aktualizacji.
Warstwa 1: System prompt i reguły
To, co model dostaje na początku każdej rozmowy. Kim jest, jak ma odpowiadać, czego nie wolno mu robić, jakie ma narzędzia. U mnie ta warstwa jest praktycznie zamrożona - zmieniam ją raz na kilka tygodni, kiedy odkrywam systemowy błąd zachowania. Przykład z mojego osobistego asystenta: reguła "ZAWSZE wywołaj get-current-time na początku sesji - NIE polegaj na dacie z env" weszła do system promptu, kiedy złapałem trzeci raz halucynacyjną datę w raporcie.
System prompt jest najdroższy w sensie wpływu na jakość - błąd w jednej linii propaguje się na każdą odpowiedź. I jest najtańszy w sensie tokenów, bo cache'uje się świetnie. Anthropic od końca 2025 daje 90% rabat na cache hit dla prompt cachingu, a system prompt to dokładnie ten kawałek, który chcesz cache'ować na maksa.
Warstwa 2: Pamięć trwała
Wiedza, która ma żyć dłużej niż jedna sesja. U klientów to zwykle: profil użytkownika, historia decyzji, konwencje projektu, fakty zewnętrzne (cennik, polityka zwrotów, struktura zespołu). U mnie - DATA/profil.md, DATA/WIZJA/kariera.md, memory/MEMORY.md i kilkanaście innych plików tematycznych.
Kluczowa decyzja w tej warstwie: ładujesz całość zawsze, czy dociągasz selektywnie? Odpowiedź zależy od rozmiaru. Jeśli pamięć mieści się w 5-10 tysiącach tokenów - ładuj zawsze, bo overhead retrievalowy jest droższy niż dodatkowe tokeny w kontekście. Jeśli idzie w setki tysięcy - musisz mieć indeks i strategię wyboru.
Mój pattern: trzymam indeks (jednolinijkowy spis "co gdzie leży") w głównym CLAUDE.md i ładuję tylko go. Jeśli model w trakcie sesji potrzebuje konkretnego pliku, sięga po Read. Indeks ma 200 linii, sumarycznie pamięć ma kilkaset tysięcy tokenów. Bez indeksu model albo halucynowałby ścieżki, albo musiałbym wpychać wszystko hurtem.
Warstwa 3: Wiedza pobrana on-demand
RAG, MCP, web search, query do bazy. Wszystko, co model dociąga w trakcie konkretnego zadania, bo akurat tego potrzebuje. Tutaj projektowanie kontekstu robi największą różnicę między systemem, który halucynuje, a systemem, który nie.
Trzy zasady, które sobie wypracowałem:
- Pobieraj minimum potrzebne do zadania, nie maksimum dostępne. Jeśli pytanie brzmi "jaki był margin Acme w marcu", nie ładuj całego raportu kwartalnego. Wyciągnij sekcję, jeden numer, kontekst porównawczy.
- Oznaczaj źródło każdego fragmentu. Model musi wiedzieć, że "to przyszło z PDF strona 14", a nie "to mu się wydaje". Ja prefiksuję każdy retrieved chunk frazą
[ZRODLO: profil.md, sekcja Bieganie]- banał, ale eliminuje połowę halucynacji. - Dawaj timestamp, kiedy wiedza może być stara. Cennik z 2024 nie powinien wchodzić do kontekstu bez "stan na 2024-03-15".
Warstwa 4: Kontekst sesji
To, co już padło w bieżącej konwersacji - poprzednie tury, wyniki tooli, intermediate kroki. Tutaj największą trudnością jest kompresja. Sesja, która trwa godzinę i ma 30 wywołań tooli, zjada okno kontekstu w mig.
Claude od wersji Sonnet 4.6 robi automatyczną kompaktację, ale to kompromis. Lepiej projektować kompresję świadomie - po każdym kompletnym etapie zadania zapisać do pamięci trwałej "co zostało zrobione, jaki jest stan", a w aktywnym kontekście trzymać tylko ostatnie 2-3 tury i wskaźnik na podsumowanie.
Jak organizuję to w Claude Code
Mój asystent osobisty to sześciu wyspecjalizowanych agentów (CEO, planista, doradca inwestycyjny, trener biegowy, content manager, ghost) plus warstwa orkiestracji. Każdy ma własny skill w .claude/skills/, własną pamięć, własne reguły. Razem zjadają dziesiątki MB notatek, planów, danych z Garmina i historii decyzji. Bez świadomej architektury kontekstu by się zatkało po tygodniu.
Wygląda to tak:
- Główny CLAUDE.md (warstwa 1). Reguły zachowania, styl komunikacji, lista dostępnych ról, mapa kluczowych plików. 700 linii. Zmieniam co kilka tygodni.
- Pliki per dziedzina (warstwa 2).
DATA/profil.md,DATA/BIEGANIE/strefy-lt.md,DATA/INWESTYCJE/playbook.mdi tak dalej. Każdy plik to jeden temat. Zasada "JEDEN TEMAT = JEDEN PLIK" jest egzekwowana protokołem - przed utworzeniem nowego pliku model robi Grep, czy temat już gdzieś żyje. - Skille jako kontekstowe role (warstwa 1+2 dla podagentów). Każda specjalizacja ma własny skill z własnymi referencjami, danymi, narzędziami. CEO ładuje agendy i priorytety, doradca ładuje portfel i playbook, trener biegowy ładuje strefy LT i historię treningów. Główny agent decyduje, kogo zawołać, i nie wpycha całej wiedzy do każdej sesji.
- MCP serwery (warstwa 3). Garmin, Google Calendar, Tasks, Open-Meteo. Model dostaje świeże dane na żądanie - tętno z dziś rano, wydarzenia z jutra, prognozę pogody. Nie trzymam kopii w pamięci, bo by się przeterminowała.
- Kompaktacja (warstwa 4). Po każdej dużej sesji raportującej (np. "morning check-in") agent zapisuje wynik do pamięci trwałej w odpowiednim pliku. Następna sesja startuje czysto, ale z dostępem do historii.
Efekt: agent pamięta o moim badaniu lab z grudnia 2025, wie że we wtorki jeżdżę interwały, zna mój portfel inwestycyjny i nie myli go z portfelem znajomego, którego mu kiedyś opisałem - bo każdy z tych faktów żyje w innym pliku, ładowany kiedy trzeba.
Pełniejszy opis tej architektury napisałem w case study osobistego asystenta. Tam są też metryki - ile tokenów zjada, jak długo trwa typowa sesja, gdzie najczęściej się wywala.
Token budget jako problem inżynierski
Okno kontekstu Claude Sonnet 4.6 to 200K, Opus 4.7 podbił do miliona. Brzmi jak dużo, dopóki nie przeliczysz.
Typowa produkcyjna sesja u klienta wygląda tak:
- System prompt + reguły: 5-15K tokenów
- Pamięć trwała załadowana na start: 10-50K
- Wynik 5 wywołań MCP/RAG: 20-100K
- Historia rozmowy po godzinie pracy: 30-200K
- Output modelu: 5-30K
To ma sens, dopóki ktoś nie próbuje wepchnąć tam dodatkowo całej dokumentacji projektu (1M tokenów), historii ticketów Jira (2M) i transkrypcji z 10 spotkań (500K). Wtedy albo ekonomia leci do diabła (Opus 4.7 z 1M kontekstu kosztuje fortunę przy każdym wywołaniu), albo latency idzie do 30 sekund per odpowiedź, albo i jedno i drugie.
Trzy taktyki, którymi zarządzam tym budżetem u klientów:
- Routing modelu po koszcie. Klasyfikacja, formatowanie, proste extraction - Haiku 4.5. Średnio złożone zadania - Sonnet 4.6. Strategiczne decyzje, długie reasoningi, multi-step planning - Opus 4.7. Nie bierz armaty na komara.
- Batch API gdzie się da. Anthropic daje 50% rabat na batch processing, jeśli możesz poczekać do 24h na wynik. Generowanie raportów nocnych, analiza historyczna, ewaluacja - wszystko leci batchem.
- Prompt caching agresywny. System prompt, częsta pamięć, dokumentacja narzędzi - wszystko z markerem cache. 90% rabat na cache hit przy Anthropic, do 5 minut TTL. W aktywnej sesji to oszczędność rzędu 70-80% kosztów.
Przykład z projektu: agent biegowy
Konkretny case z mojego asystenta. Agent biegowy ma jedno zadanie: analizować mój trening, rekomendować kolejne, pilnować polaryzacji intensywności. Brzmi prosto, dopóki nie policzysz, ile danych musi zobaczyć, żeby cokolwiek powiedzieć sensownie.
Co potrzebuje na każdą sesję analizy:
- Mój profil biegacza (waga, VO2max z badań lab, progi LT1/LT2) - 200 linii
- Strefy tętna i polityka polaryzacji - 100 linii
- Plan treningowy na bieżący tydzień - 80 linii
- Historia 14 ostatnich treningów z Garmina - dociąga MCP, ~5K tokenów
- Status recovery (sen, HRV, body battery) - dociąga MCP, ~1K tokenów
- Zasady analizy (jak liczyć drift HR, kiedy ostrzec o overtraining) - 300 linii
Wczesna wersja ładowała wszystko na start każdej rozmowy. Wynik: 30K tokenów na każdym pytaniu, koszt rósł niezależnie od tego, czy pytałem "jak mi szło wczoraj" (potrzeba: jeden trening), czy "zaplanuj mi tydzień" (potrzeba: cała historia + plan + recovery).
Refaktor: główny system prompt agenta biegowego ładuje tylko reguły zachowania i zasady analizy (~5K). Dane konkretne - profil, strefy, plan - są w plikach, a agent czyta je tylko jeśli bieżące pytanie ich wymaga. Historia treningów leci przez MCP na żądanie, z parametrem "ile dni wstecz". Recovery podobnie.
Po refaktorze średni koszt sesji spadł o 60%, latency o 40%, jakość odpowiedzi wzrosła - bo model nie ginie w 30K tokenów wiedzy, której akurat nie potrzebuje. Nie trzeba było zmieniać ani jednego prompta. Zmieniła się architektura kontekstu.
Częste błędy, które widzę u klientów
Trzy wzorce powtarzają się u prawie każdego, kto zaczyna budować coś poważniejszego niż chatbot demo.
Błąd 1: kontekst-wszystko. Ktoś wpycha do system promptu całą dokumentację firmy, FAQ, polityki, regulaminy, historie ticketów. Model dostaje 80K tokenów na start każdej rozmowy, koszt rośnie liniowo z liczbą rozmów, a jakość spada, bo model ginie w szumie. Fix: przenieś 95% tej wiedzy do RAG/MCP, zostaw w system prompcie tylko reguły zachowania i indeks "co gdzie szukać".
Błąd 2: zerowa pamięć. Każda rozmowa startuje czysto. Klient pyta to samo trzeci raz, model odpowiada inaczej trzeci raz. Brak pamięci = brak ciągłości = ciągła frustracja użytkownika. Fix: minimalna persistent memory per user (preferencje, historia 5 ostatnich interakcji, ważne fakty), ładowana na start sesji.
Błąd 3: źle posortowany kontekst. Najnowsze i najważniejsze informacje są pogrzebane na 30 stronie kontekstu. Modele LLM mają udokumentowany "lost in the middle" - słabiej trafiają w środkową część długiego kontekstu. Fix: ważne na początek lub na koniec, mniej ważne w środku, jasne sekcje z nagłówkami.
Czwarty, bardziej subtelny błąd: nie projektowanie aktualizacji. Wiedza się starzeje. Cennik się zmienia. Polityka zwrotów dostaje aneks. Jeśli nie masz mechanizmu aktualizacji pamięci trwałej - po pół roku model będzie kłamał z pełnym przekonaniem, bo trzyma stan ze stycznia.
Kiedy promptowanie wystarcza, a kiedy nie
Nie każdy projekt potrzebuje pełnej architektury kontekstu. Jeśli budujesz:
- Jednorazowy generator (np. tytułów, opisów, podsumowań pojedynczych dokumentów)
- Klasyfikator (sentiment, kategoria, intent)
- Translator albo formatter
- Demo na hackatonie, które ma żyć tydzień
- prompt engineering wystarczy. Dobierz model, napisz solidny system prompt, dodaj 3-5 few-shot przykładów, gotowe.
Context engineering staje się konieczny w momencie, kiedy:
- System ma żyć dłużej niż jedna rozmowa (asystent, agent, copilot)
- Wiedza jest większa niż okno kontekstu (dokumentacja firmy, baza klientów, dłuższe projekty)
- Odpowiedzi muszą być spójne między sesjami (pamiętać poprzednie decyzje, konwencje, preferencje)
- Wiedza się aktualizuje (zewnętrzne dane, ceny, kalendarze, dane operacyjne)
- Koszty zaczynają boleć (powyżej kilku dolarów dziennie per użytkownik to sygnał)
Granica jest płynna. Najczęściej projekt zaczyna się jako prompt engineering ("napiszemy fajny prompt do Claude i wystawimy w API"), a po dwóch miesiącach okazuje się, że potrzebujesz pełnej warstwy pamięci, bo użytkownicy wracają, kontekstu narastają i prompty stają się 8-stronicowe.
Patrząc na to, co dzieje się w 2026 - eksplozja MCP serwerów (ponad 7 tysięcy publicznych), upowszechnienie agentów multi-step, tańszy 1M-tokenowy kontekst Opusa 4.7 - granica przesuwa się w stronę context engineering. Coraz więcej zastosowań, które rok temu robiło się promptem, dziś wymaga architektury. Nie dlatego, że promptowanie się zepsuło. Dlatego, że oczekiwania wobec tych systemów urosły.
Jeśli budujesz system, który ma działać sześć miesięcy, obsługiwać tysiąc użytkowników i nie wymagać codziennego strojenia - prompt engineering nie wystarczy. Niezależnie od tego, jak dobry jest twój prompt.
Budujesz produkcyjny system z LLM i czujesz że samym promptowaniem nie da się utrzymać jakości? Napisz do mnie - pomogę zaprojektować architekturę kontekstu pod twój use case.
