TL;DR

Context engineering (inżynieria kontekstu) to zarządzanie całym kontekstem (memory, tools, knowledge, guardrails) na każdym kroku wykonania agenta, nie tylko promptem
Trzy główne wyzwania: zamieszanie w kontekście (spadek accuracy do 30%), konflikt informacji (sprzeczne dane) i rozproszenie (przeciążenie danymi)
Badanie Stanford pokazuje, że po około 60 krokach context window się „psuje” i accuracy spada o 10 punktów procentowych
Product managerowie muszą zmienić podejście – od klasycznych PRD (Product Requirements Document) do 50-stronicowych user guides z tabelami kontekstu dla każdego kroku
Nowe metryki: wskaźnik zgodności z zamiarem (intent alignment score) i współczynnik szumu (noise ratio) zamiast fokusowania tylko na czasie odpowiedzi
Case study Legal Graph pokazuje, że zły kontekst może prowadzić do przegapienia krytycznych klauzul w umowach (unlimited indemnification)
Rola PM ewoluuje w stronę definiowania wymagań kontekstowych i metryk ewaluacji na poziomie poszczególnych kroków, nie tylko kompleksowej oceny całości

Wstęp

To są notatki z 157. sesji community prowadzonej przez Mahesha Sharmę w listopadzie 2025 roku. Sharma prowadzi te spotkania od trzech lat, osiągając liczbę niemal 160 sesji. Wszystkie przedstawione tu przemyślenia, obserwacje i rekomendacje pochodzą bezpośrednio od niego i jego doświadczeń z budowania systemów AI.

Tym razem temat brzmiał: „Context Engineering Challenges and Tips for PMs”. Według Sharmy branża przechodzi fundamentalną zmianę. Przez ostatnie lata wszyscy mówili o prompt engineering. Teraz jednak nadchodzi era context engineering (inżynierii kontekstu) – znacznie szerszego i bardziej złożonego zagadnienia.

Krótka historia – jak doszliśmy do agentów

Sharma rozpoczyna od krótkiego przeglądu historii programowania. 60 lat temu programiści mieli do dyspozycji język C. 20 lat temu pojawiły się DAG (Directed Acyclic Graphs) – struktury workflow bez cykli, gdzie można tylko iść do przodu bez możliwości cofania się po strzałkach. Większość aplikacji – od bankomatów po Facebooka – działa właśnie w oparciu o DAG.

Według Sharmy po raz pierwszy w historii coding agents pozwalają złamać ten paradygmat. Nie potrzebują z góry określonego DAG. System określa kolejny krok w czasie wykonania (runtime), nie na etapie projektowania.

Sharma ilustruje to konkretnym przykładem: użytkownik prosi o stworzenie strony z koszykiem. Agent analizuje request, następnie tworzy stronę index, potem pobiera obrazy, dodaje przyciski checkout, w końcu aktualizuje bazę danych. Każdy krok generuje nowy kontekst, który z kolei jest potrzebny do określenia następnego kroku.

Jak pracuje agent – podstawowa pętla

Sharma opisuje fundamentalną pętlę działania agenta w czterech krokach:

Zrozum zamiar i zainicjuj kontekst dla bieżącego kroku
Dobierz wiedzę i narzędzia, wykonaj akcje
Zaktualizuj kontekst wynikami
Sprawdź cel – jeśli nie osiągnięty, określ następny krok i kontynuuj

Ta pętla powtarza się, aż agent osiągnie zamierzony cel lub natrafi na błąd. Sharma podkreśla, że zarządzanie kontekstem na każdym z tych kroków to właśnie sztuka inżynierii kontekstu.

Czym właściwie jest inżynieria kontekstu

Nowa definicja roli PM

Sharma przywołuje kluczowy cytat od Aarona Leviego, CEO Box, który tydzień przed sesją napisał: „Zarządzanie produktem w erze agentów polega po prostu na ustaleniu, czego potrzebowałaby bardzo inteligentna osoba, zaczynająca od zera, żeby skutecznie wykonać zadanie.”

To fundamentalnie nowa definicja pracy PM. Nie chodzi już o features ani user stories, lecz o zaprojektowanie kompletnego kontekstu, który pozwoli agentowi działać jak bardzo inteligentna osoba rozpoczynająca zadanie bez żadnej wcześniejszej wiedzy.

Sharma dodaje, że każde debugowanie agentów sprowadza się teraz do jednego pytania: czy dostarczyliśmy właściwy kontekst? Levie zauważa, że kiedy cokolwiek się psuje w agentach, to nie LLM zawodzi – to kontekst jest źle skonstruowany. Sharma to podsumowuje wprost: „Dobre debugowanie agenta to debugowanie kontekstu.”

Ewolucja języka, ewolucja wartości

Sharma dzieli się obserwacją o tym, jak zmiana terminologii wpływa na postrzeganą wartość PM. Według niego PM mówiący o „danych” jest postrzegany jako junior z minimalnym wynagrodzeniem. Ten mówiący o „wiedzy” ma już większą wartość – około 100 tysięcy. Natomiast PM swobodnie operujący pojęciem „kontekstu” i „in-context learning” jest postrzegany jako ekspert wysokiego poziomu wart milion i więcej.

To nie jest tylko żart. Sharma przyznaje, że był na rozmowie z inwestorem, który użył terminu „in-context learning” nie mając pojęcia, co to znaczy. Sharma nie korygował go – potrzebował pieniędzy dla swojej firmy, więc po prostu przytaknął i przeszedł dalej. To pokazuje, że modne hasła branżowe działają nawet wtedy, gdy nikt nie wie, co faktycznie oznaczają.

Siedem elementów kontekstu

Sharma zadaje pytanie: czym różni się inżynieria kontekstu od prompt engineering? Odpowiedź brzmi: prompt to tylko część kontekstu. Pełny kontekst składa się z siedmiu kluczowych elementów:

User prompt (zapytanie użytkownika) – co użytkownik wysłał
System prompt (instrukcje systemowe) – wbudowane wytyczne
Knowledge (wiedza) – dokumenty, bazy danych
Tools (narzędzia) – API, narzędzia do wywołania
Memory (pamięć) – historia konwersacji
Signals (sygnały) – dane o użytkowniku, preferencje (np. status FTE vs contractor)
Guardrails (zabezpieczenia) – limity i reguły bezpieczeństwa

Każdy z tych elementów musi być odpowiednio zarządzany na każdym kroku wykonania agenta.

Limity context window

Sharma wyjaśnia pojęcie context window (okna kontekstu) jako limit informacji, którą można wysłać w jednym zapytaniu do modelu. GPT-4 ma limit około 1 miliona tokenów – odpowiednik około 500 stron tekstu.

Dobry agent wypełnia te 500 stron właściwym kontekstem. Zły agent wypełnia je „śmieciami”, jak określa to Sharma. Ta różnica decyduje o jakości odpowiedzi.

Przykład z praktyki: Legal Graph

Sharma przedstawia konkretny przykład z własnego doświadczenia. Legal Graph to narzędzie, które analizuje kontrakty i identyfikuje ryzyka.

W pierwszej wersji system przeanalizował NDA i odpowiedział, że wygląda w porządku, są pewne kwestie odpowiedzialności, ale nic poważnego. System uznał, że umowę można podpisać.

Po dodaniu pełnego kontekstu (company policies, retrieved knowledge, tool outputs) system radykalnie zmienił zdanie. Wykrył unlimited indemnification clause – klauzulę pozwalającą obciążyć firmę nieograniczoną odpowiedzialnością finansową. W skrajnym przypadku prowadzi to do bankructwa. Wykrył również automatyczne odnawianie umowy, które wiąże firmę „in perpetuity” – na zawsze, nawet po latach bez kontaktu.

Sharma podkreśla: bez właściwego kontekstu agent przegapił krytyczne klauzule. To właśnie pokazuje różnicę między przeciętnym a doskonałym produktem.

Trzy główne wyzwania

1. Context confusion – zamieszanie w kontekście

Im więcej kontekstu dodajemy, tym częściej model się myli. Sharma przywołuje konkretne dane: accuracy wyboru właściwego narzędzia spadła z 100% do 30%. Dlaczego? W poprzednim kroku agent użył narzędzia A, jednak ta informacja trafia do kontekstu. W następnym kroku model myśli: „Może znowu powinienem użyć A?”. W rezultacie powstaje zamieszanie.

2. Context clash – konflikt informacji

W kontekście pojawiają się sprzeczne informacje. Pierwszy krok określa użytkownika jako contractor. W międzyczasie system wykonuje search, a wyniki zawierają informacje o rabatach dla full-time employees. Przy rezerwacji biletów system może zastosować niewłaściwy rabat. Sharma zauważa: nie mamy kontroli nad tym, która informacja „wygra”.

3. Distraction – rozproszenie i przeciążenie informacjami

To problem obfitości. Wysyłamy 500 stron kontekstu z 20-słownym zapytaniem użytkownika, w związku z czym model gubi się w nadmiarze informacji.

Sharma dzieli się anegdotą: jego czteroletni syn bawił się z ChatGPT przez 30 minut. Grali w quizy o zwierzętach i owocach. Nagle ChatGPT zapytało: „How can I help you?”. Straciło cały kontekst rozmowy. Teść Sharmy powiedział mu kiedyś: „Im większa głowa, tym większy ból głowy”. Im większy kontekst, tym większy problem z jego zarządzaniem.

Badanie Stanford – kiedy context się psuje

Sharma przywołuje paper ze Stanford o agent context engineering. Badacze pokazali, że przy 60. kroku wielkość kontekstu osiąga 18,000 tokenów, a accuracy spada o 10 punktów procentowych. Po przekroczeniu tego progu system musi zaczynać od zera.

Dla użytkownika to zaskakujące doświadczenie – agent nagle „zapomina” wszystko. To fundamentalne ograniczenie obecnych systemów, jednak nie da się go obejść przez samo zwiększanie context window. Problem leży w zarządzaniu kontekstem, nie w jego wielkości.

Memory: short-term vs long-term

Short-term memory (pamięć krótkoterminowa)

Sharma wyjaśnia różnicę między typami pamięci w agentach. Short-term memory to po prostu ostatnie 5-10 konwersacji. System może je przekazać bez zmian lub podsumować.

Przykład: użytkownik prosi o rezerwację w Cancun. Agent pyta o budżet i dzieci. Bez memory następne zapytanie („just do what I told you”) nie zadziała – agent nie pamięta poprzedniej rozmowy.

Przykład z n8n

Sharma przywołuje konkretne narzędzie automatyzacji workflow – n8n. Pokazuje, jak działa memory w praktyce: bez modułu pamięci agent nie utrzymuje ciągłości między wymianami. Po dodaniu modułu memory poprzednie wymiany są automatycznie dołączane do kontekstu. To prosty, ale skuteczny sposób na zobaczenie, jak memory wpływa na działanie agenta.

Long-term memory (pamięć długoterminowa)

Long-term memory to znacznie większe wyzwanie. ChatGPT przechowuje wszystkie interakcje użytkownika. Sharma żartuje, że jego rodzina (włącznie z czteroletnim synem) zrobiła już „milion konwersacji”. Jak zarządzać takim kontekstem?

Sharma wymienia dwa główne podejścia:

RAG (Retrieval Augmented Generation) – system pobiera tylko relevantny kontekst na podstawie aktualnego zapytania i filtruje niepotrzebne informacje.

Episodic Memory (Pamięć Epizodyczna) – inspirowane działaniem ludzkiego mózgu. System grupuje wspomnienia w epizody. Przykład: Sharma prowadzi cohort. W cohorcie 2 była Sumitra. To jeden epizod, dlatego system pamięta „cohort 2 + Sumitra”, nie każdą pojedynczą interakcję.

Session vs project – techniczna dystynkcja

Sharma wyjaśnia też kluczową różnicę techniczną pokazującą, dlaczego context nie kumuluje się w nieskończoność. Każdy użytkownik ma swój „project” (w przypadku ChatGPT to subskrypcja użytkownika). W ramach tego projektu każde otwarcie ChatGPT tworzy nową „session” (sesję).

Context jest zarządzany w ramach sesji, nie projektu. To dlatego context nie miesza się między różnymi konwersacjami, a także dlatego możesz mieć czystą kartę, otwierając nową rozmowę.

Rola product managera w nowej erze

Od PRD do user guide

Sharma cytuje dyrektora z Databricks, który twierdził, że przestali pisać PRD (Product Requirements Documents – dokumenty wymagań produktowych). Sharma odpowiedział, że oni teraz piszą 50-stronicowe user guides (przewodniki użytkownika). Ten komentarz zebrał więcej lajków niż oryginalny post.

Co to oznacza w praktyce? PM pisze szczegółowy przewodnik, w którym dla każdego kroku konwersacji tworzy tabelę z wymaganym kontekstem: jaka knowledge jest potrzebna, które tools mają być wywołane, co powinno trafić do memory, jakie signals są wymagane.

Scenariusz „Cancún” krok po kroku

Sharma pokazuje metodę z poprzedniej pracy w „large search engine company” na konkretnym przykładzie rezerwacji wakacji:

Krok 1: Policz dostępne urlopy

Wiedza: polityka HR firmy
Narzędzia: wyszukiwanie w systemie HR
Signals: status pracownika (FTE vs contractor)
Wynik: liczba dostępnych dni urlopu

Krok 2: Wyszukaj opcje zgodne z preferencjami

Memory: poprzednia wymiana (liczba urlopów)
Signals: dzieci, preferencje dietetyczne, budżet
Narzędzia: API wyszukiwarek hoteli/rezerwacji
Wynik: lista dopasowanych opcji

Krok 3: Sprawdź cel i przedstaw propozycje

Kontekst: wszystkie poprzednie wyniki
Guardrails: potwierdzenie przed rezerwacją
Wynik: rekomendacje dla użytkownika

Lewa kolumna zawierała user query i oczekiwaną odpowiedź systemu. Prawa kolumna to szczegółowa tabela z rozpisaniem wszystkich elementów kontekstu dla tego kroku. Zespół przygotował takie tabele dla 5 najczęstszych scenariuszy.

Nowe metryki dla PM

Sharma proponuje dwie kluczowe metryki, które powinny zastąpić fokus na timing:

Wskaźnik zgodności z zamiarem (Intent Alignment Score) – pokazuje, jak często kontekst jest zgodny z intencją użytkownika. PM definiuje pytania sprawdzające alignment, system automatycznie ewaluuje odpowiedzi, a agregacja daje ogólny score.

Współczynnik szumu (Noise Ratio) – określa, jaki procent tokenów w context window jest rzeczywiście relevantny. Cel: minimalizować noise, maksymalizować signal.

Sharma zauważa, że większość zespołów skupia się na timing i response time. Te metryki są ważne dla UX, jednak dla jakości agentów kluczowe są metryki kontekstowe.

Framework: What → So What → Now What

Sharma dzieli się metodą, którą wykształcił w poprzedniej firmie. Dyrektor ciągle rzucał na Slack linki do nowych technologii i oczekiwał analiz w formacie:

What (Co to jest) – definicja, podstawy, jak działa
So What (Dlaczego to ważne) – implikacje, zastosowania, ryzyko ignorowania
Now What (Co dalej) – co powinniśmy zrobić: zmiany w strategii, akcje, lub uzasadnienie ignorowania

PM-owie ścigali się, kto pierwszy napisze taką analizę. Sharma zaczął używać AI do tworzenia pierwszych wersji i w większości przypadków wygrywał. Teraz używa tego frameworka w odwrotną stronę – do dzielenia się wiedzą z community. Każda sesja pokrywa te trzy elementy.

Orchestration – największe wyzwanie 2026

Na pytanie o jedno życzenie na 2026 rok Sharma odpowiedział: „Lepsza orchestration (orkiestracja) dla agentów”. Orchestration layer to system, który zarządza całym cyklem przed określeniem następnego kroku.

Cztery kroki orkiestracji

Sharma opisuje konkretny proces, który musi zachodzić przed każdym „determine next step” (określ następny krok):

Pobierz kontekst z poprzednich kroków
Sprawdź kolizje (sprzeczne informacje, konflikty sygnałów)
Oczyść szum (usuń nieistotne tokeny)
Skoryguj pod zamiar (upewnij się, że kontekst wspiera cel użytkownika)

Dopiero po tym cyklu system może bezpiecznie określić następny krok. Sharma twierdzi, że obecne narzędzia (n8n, Azure, AWS) nie radzą sobie z tym dobrze. Łatwo zbudować prosty workflow, jednak gdy agent staje się złożony, orchestration staje się bottleneckiem. Brak gotowych rozwiązań – każdy zespół musi to rozwiązać sam. To największa bariera w skalowaniu agentów.

Ewaluacja na każdym poziomie

Sharma podkreśla fundamentalną zmianę: ewaluacja nie może być tylko kompleksowa. PM musi oceniać każdy krok osobno. Jak dobrze działa knowledge retrieval? Jaki jest noise ratio? Czy wybraliśmy właściwe tool? Czy memory zawiera relevantne informacje?

Dopiero agregacja tych metryk daje obraz wydajności całego agenta. Gdy agent nie działa, PM może zidentyfikować, który konkretnie krok zawodzi. Inżynierowie oceniają timing i komponenty, natomiast PM powinien oceniać zgodność z zamiarem i jakość kontekstu.

Sharma zauważa też, że dla naprawdę złożonych zapytań wymagających 100+ źródeł obecne systemy nie wystarczą. W takich przypadkach zaleca użycie narzędzi typu „Advanced Research”, które mogą wykonywać 10+ minut głębszej analizy.

Wyzwanie skali

Sharma porusza też praktyczny problem skali pokazujący, dlaczego inżynieria kontekstu jest tak krytyczna. ChatGPT obsługuje około 700 milionów użytkowników. Każdy z tych użytkowników tworzy miesięcznie 10x więcej sesji niż poprzednio.

To oznacza potrzebę masywnej ilości GPU do obsługi wszystkich tych sesji, zarządzania kontekstem dla miliardów równoległych konwersacji, izolacji kontekstu między użytkownikami i sesjami oraz efektywnego wykorzystania zasobów (stąd importance noise ratio).

Sharma podkreśla: to dlatego hosting różnych modeli i dystrybucja sesji między nimi jest tak krytyczna. Nie możemy pozwolić sobie na marnowanie tokenów na „śmieciowy” kontekst, gdy obsługujemy taką skalę.

Praktyczna checklist dla PM

Sharma definiuje pięć obszarów, które PM musi określić przed rozpoczęciem pracy nad agentem:

1. Memory management (zarządzanie pamięcią)

Typ memory (short-term vs long-term)
Ile konwersacji przechowywać i jak je summaryzować
Sposób retrievalu z long-term memory
Reguły odświeżania lub ograniczania kontekstu w długich sesjach

2. Context size i structuring (rozmiar i struktura kontekstu)

Maksymalny rozmiar context window dla każdego kroku
Priorytetyzacja elementów kontekstu
Strategia kompresji przy przekroczeniu limitu
Minimalny pakiet kontekstu dla każdego typu zadania

3. Tools i knowledge (narzędzia i wiedza)

Lista dostępnych tools z kryteriami wyboru
Format input/output dla każdego tool
Definicja source attribution dla każdego elementu kontekstu
Reguły rozstrzygania konfliktów między źródłami

4. Metryki i observability (metryki i obserwowalność)

Intent alignment score (jak mierzymy, co jest threshold)
Noise ratio (jaki procent jest akceptowalny)
Dashboardy dla cross-functional teams
Dzienniki zdarzeń na każdy krok (co i dlaczego zasiliło kontekst)

5. Safety i guardrails (bezpieczeństwo i zabezpieczenia)

Jakie PII mogą być w kontekście
Limity na wywołania tools
Fallback behavior przy błędach
Warunki zakończenia dla każdego typu zadania

Sharma zaleca stworzenie minimum 5 sample conversations. Dla każdej: rozpisać user intent, określić oczekiwany outcome, zdefiniować kontekst dla każdego kroku i ustalić kryteria sukcesu.

Praktyczne prompty dla PM

Sharma dzieli się zestawem gotowych promptów, które PM może wykorzystać w swojej pracy. Te szablony powstały z jego doświadczenia i zostały przetestowane w rzeczywistych projektach.

1. Sprawdź, czy osiągnęliśmy cel

Intencja: Zwróć TAK/NIE i krótkie uzasadnienie
Kiedy stosować: Po każdym działaniu, przed kolejnym krokiem
Przykład: „Cel użytkownika: zarezerwować hotel w Cancun dla rodziny z dziećmi w budżecie $10,000. Dotychczasowe działania: [lista]. Czy cel został osiągnięty? Odpowiedz TAK lub NIE z uzasadnieniem.”

2. Określ następny krok

Intencja: Zaproponuj jeden wykonalny krok z uzasadnieniem i wymaganymi wejściami/wyjściami
Kiedy stosować: W orkiestracji wieloetapowej
Przykład: „Bieżący kontekst: [opis]. Cel: [cel]. Jakie jest najbardziej logiczne następne działanie? Podaj: (1) działanie, (2) dlaczego to działanie, (3) jakie dane wejściowe są potrzebne, (4) co otrzymamy na wyjściu.”

3. Analiza NDA pod kątem ryzyk

Intencja: Sprawdź odpowiedzialność odszkodowawczą (czy ma limit), automatyczne odnawianie, odpowiedzialność stron
Kiedy stosować: Ocena umów w trybie „red flags”
Przykład: „Przeanalizuj poniższe NDA pod kątem: (1) czy indemnification ma określony limit kwotowy, (2) czy umowa odnawia się automatycznie, (3) jakie są warunki odpowiedzialności każdej ze stron. Wypisz wszystkie znalezione ryzyka.”

4. Pakiet pełnego kontekstu

Struktura: Instrukcje systemowe; wejście użytkownika; krótka historia; polityki firmowe; wiedza pozyskana; opis narzędzi; wyniki narzędzi
Kiedy stosować: Gdy odpowiedź zależy od wielu artefaktów
Przykład szablonu:

INSTRUKCJE SYSTEMOWE: [rola, ton, ograniczenia]
WEJŚCIE UŻYTKOWNIKA: [ostatnie zapytanie]
HISTORIA: [ostatnie 3 wymiany]
POLITYKI: [relevantne polityki firmowe]
WIEDZA: [wyciągi z dokumentów]
NARZĘDZIA DOSTĘPNE: [lista z opisami]
WYNIKI NARZĘDZI: [output z poprzednich wywołań]

5. Ustal i rozstrzygaj kolizje sygnałów

Intencja: Wykryj sprzeczności (np. FTE vs contractor); zastosuj regułę; wskaż ścieżkę
Kiedy stosować: Gdy sygnały są sprzeczne
Przykład: „W kontekście znajdują się sprzeczne informacje: użytkownik określony jako 'contractor’ w kroku 1, ale wyniki search wskazują na zniżki dla 'full-time employees’. Ustal: (1) która informacja jest wiarygodniejsza, (2) jaką regułę zastosować, (3) którą wartość użyć w dalszych krokach.”

6. Odświeżenie kontekstu w długiej sesji

Intencja: Wykryj utratę wątku; zrób skróconą rekapitulację celu i minimalny pakiet
Kiedy stosować: Przy spadku trafności po wielu krokach (>60)
Przykład: „Ta sesja trwa już 65 kroków. Zrób rekapitulację: (1) jaki był pierwotny cel użytkownika, (2) co zostało już osiągnięte, (3) co jeszcze pozostało do zrobienia. Następnie zredukuj kontekst do minimum niezbędnego do kontynuacji.”

7. Minimalny pakiet kontekstu

Intencja: Zredukuj kontekst do tego, co niezbędne dla aktualnego zamiaru; wypisz, co zostaje i co odrzucasz
Kiedy stosować: Gdy rośnie szum
Przykład: „Obecny kontekst zawiera [X] tokenów. Następny krok to: [działanie]. Wybierz tylko te elementy kontekstu, które są bezpośrednio potrzebne do wykonania tego kroku. Wypisz: ZOSTAJE: [lista], ODRZUCAM: [lista z uzasadnieniem].”

8. Dopytania domenowe przed akcją

Intencja: Wygeneruj krytyczne pytania; wstrzymaj akcję do czasu odpowiedzi
Kiedy stosować: Domeny z wysokim kosztem błędu (prawo, finanse, podróże)
Przykład: „Użytkownik prosi o rezerwację. Zanim wykonasz rezerwację, wygeneruj listę krytycznych pytań, na które MUSISZ znać odpowiedź. Nie wykonuj akcji, dopóki nie otrzymasz tych informacji.”

9. Tabela kontekstu dla PRD

Intencja: Zwróć tabelę: wejście, wynik, wiedza, narzędzia (wejścia/wyjścia), pamięć, zabezpieczenia, warunek zakończenia
Kiedy stosować: Specyfikowanie najczęstszych ścieżek dla deweloperów
Przykład formatu:

KROK: [nazwa kroku]
WEJŚCIE: [user query]
OCZEKIWANY WYNIK: [odpowiedź systemu]
WIEDZA: [jakie dokumenty/bazy]
NARZĘDZIA: [które API, input, output]
PAMIĘĆ: [co zapisać, co odczytać]
GUARDRAILS: [limity, walidacje]
WARUNEK ZAKOŃCZENIA: [kiedy uznajemy sukces]

Dlaczego mali gracze mogą wygrać

Sharma kończy sesję osobistą refleksją. Uważa, że mali gracze mogą pokonać gigantów w nowej erze AI. Duże firmy skupiają się na wielkości, nie jakości, w rezultacie często nie dbają o detale kontekstu. Mają zasoby, ale brakuje im precyzji.

Mały zespół może zrobić to lepiej: precyzyjnie zdefiniować kontekst dla każdego kroku, iterować szybciej na podstawie metryk, budować mniejsze ale lepiej zarządzane context windows, skupić się na zgodności z zamiarem zamiast liczby funkcjonalności.

Sharma dzieli się też, że to pierwsza wakacja w 10 lat. Cały rok był wypełniony cohortami bez przerwy, dlatego bierze 4 dni wolnego w Cancun – miejsce, które przewijało się przez całą sesję jako przykład w scenariuszach.

Meta-obserwacja: ewolucja community

Pod koniec sesji Kritika zauważa coś ważnego, co Sharma potwierdza: typ dyskusji, które prowadzą na forum, podniósł poziom całej grupy. Na początku były to proste rozmowy, teraz jednak community jest w stanie prowadzić głębokie, techniczne dyskusje o orkiestracji, zarządzaniu kontekstem i architekturze agentów.

To ważna obserwacja – jako branża kolektywnie podnosi się poziom dyskusji i zrozumienia. Inżynieria kontekstu nie była nawet terminem rok temu, natomiast teraz jest kluczową kompetencją dla PM pracujących z AI.

Zasoby i co dalej

Sharma poleca kilka papers: Stanford paper o agent context engineering (pokazujący spadek accuracy po 60 krokach), badania o RAG accuracy (spadek 20-40% przy złym kontekście), analizy enterprise AI failures (60-70% błędów wynika ze złego zarządzania kontekstem).

Następna sesja community będzie o Transformers. Sharma zapowiada, że spróbuje wyjaśnić paper „Attention Is All You Need” w przystępny sposób. To foundation dla całej obecnej rewolucji AI.

Podsumowanie

Inżynieria kontekstu nie jest już nice-to-have. To kluczowa umiejętność dla PM-ów pracujących z AI. Sharma pokazuje, że różnica między dobrym a złym agentem leży w zarządzaniu kontekstem.

Wyzwania są realne i mierzalne: zamieszanie, konflikt, rozproszenie. Badania pokazują konkretne limity – po 60 krokach accuracy spada o 10%. Rola PM ewoluuje od PRD do szczegółowych przewodników użytkownika z tabelami kontekstu, w związku z czym nowe metryki (zgodność z zamiarem, współczynnik szumu) są ważniejsze niż tylko timing. Ewaluacja musi być wielopoziomowa, nie tylko kompleksowa.

Aaron Levie najlepiej to ujął: PM w erze agentów musi zaprojektować kontekst, który pozwoli bardzo inteligentnej osobie wykonać zadanie od zera. To fundamentalnie inna praca niż pisanie user stories czy specyfikacji funkcjonalności.

Sharma wierzy, że zespoły, które opanują inżynierię kontekstu, zbudują następną generację produktów AI. Nie chodzi o największy model, lecz o najlepiej zarządzany kontekst.

Kluczowy insight

Paradoks kontekstu – mniej znaczy więcej

Standardowo myślimy: Im więcej kontekstu dodamy do agenta, tym lepsze decyzje będzie podejmował. To intuicyjne – więcej informacji powinno prowadzić do lepszych wyników. Warto trzymać całą historię i wszystkie znaleziska „na wszelki wypadek”.

W praktyce okazuje się, że: Accuracy tool selection spada z 100% do 30% wraz z dodawaniem kontekstu. RAG accuracy spada o 20-40%. Po 60 krokach system traci 10 punktów procentowych w ogólnej accuracy. To nie jest kwestia większego context window – GPT-5 ma już 1M tokenów. Problem leży w tym, że większość zespołów optymalizuje pod ilość, nie jakość kontekstu. Agresywna selekcja do minimalnego pakietu pod bieżący zamiar poprawia wybór narzędzi i stabilność odpowiedzi.

Dlaczego to jest istotne: 60-70% niepowodzeń w enterprise AI wynika właśnie ze złego zarządzania kontekstem. Debugowanie agentów to nie tuning modelu – to zawsze problem z kontekstem. Przeładowanie prowadzi do zamieszania, konfliktów i rozproszenia oraz realnych błędów decyzji. Selekcja kontekstu na każdym kroku podnosi trafność bez zmiany modelu.

Test na jutro: Następnym razem gdy twój agent się myli lub tool calling nie działa, zamiast dodawać więcej kontekstu do prompta, przekaż tylko: (1) zamiar w jednym zdaniu, (2) ostatnie pytanie użytkownika, (3) 1-3 fakty ściśle związane z zadaniem ze źródłami, (4) opis wybranego narzędzia z wymaganymi wejściami/wyjściami, (5) ostatni zweryfikowany wynik. Porównaj na serii zadań skuteczność wyboru narzędzia, odsetek zbędnych tokenów i czas odpowiedzi. Większość zespołów odkryje, że mniejszy, ale precyzyjnie dobrany kontekst daje lepsze rezultaty niż „wszystko co mamy”.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Context Engineering Challenges & Tips

Tag: Orkiestracja

Context Engineering (Inżynieria Kontekstu) – Nowa Era Zarządzania Kontekstem w Systemach AI #EN349