Spotify wprowadza inżynierię kontekstu – nowa era dla agentów kodujących

Czy agent może w tle przepisać tysiące repozytoriów, nie gubiąc wątku po drodze i bez pytania „a o co chodziło?” co kilka minut?

Spotify twierdzi, że tak – pod warunkiem, że zrobisz nie prompt engineering, a context engineering. W drugiej części swojej serii o background coding agents firma pokazuje, jak zapanować nad pamięcią i zakresem działania tak, by agent dowoził mergeowalne PR-y w skali. Zaskoczenie? Największy zysk nie pochodzi z bardziej „kreatywnych” promptów, tylko z lepszego doboru tego, co w ogóle trafia do okna kontekstu.

W praktyce chodzi o jedno: agent to nie magiczna maszyna do tekstu, tylko autonomiczny wykonawca z ograniczoną pamięcią roboczą. Jeśli wrzucisz mu do głowy wszystko, skończy w przeciążeniu – kontekst puchnie, uwaga się rozmywa, a wyniki rotują w stronę chaosu. Dlatego rośnie nowa dyscyplina: inżynieria kontekstu. Zamiast upychać więcej tokenów, budujesz system, który selekcjonuje, kompiluje i utrwala tylko to, co naprawdę potrzebne w danym kroku.

O co chodzi

Spotify zaczęło od zachwytu nad otwartymi agentami (Goose, Aider). Na małych zadaniach było „wow”: agent potrafił sam przeszukać repo, znaleźć miejsca do zmiany, podedytować pliki. Schody pojawiły się przy skali. Trudno było wymusić PR-y, które przejdą testy i przegląd – zwłaszcza gdy tych PR-ów miały być tysiące.

Zbudowali więc własną pętlę agentową na LLM-ach. Każde zadanie miało trzy części: użytkownik dawał prompt i listę plików w zasięgu, agent robił kilka tur edycji z feedbackiem z buildu/testów, a całość kończyła się po pozytywnym teście lub osiągnięciu limitów (10 tur na sesję, łącznie do trzech podejść). Proste zmiany? OK. Kaskadowe modyfikacje między plikami? Agent gubił się po zapełnieniu kontekstu, zapominał o celu i dojeżdżał do limitów tur. A wymaganie, by użytkownik sam składał git grepy, by „wlać” właściwe pliki do kontekstu, było zbyt kruche: za szeroko – model się przepełnia; za wąsko – brakuje mu informacji do działania. [6]

Kontekst, nie poezja promptów

W tym miejscu wchodzi context engineering. Anthropic dość klarownie rozdziela pojęcia: prompt engineering to sztuka pisania instrukcji, context engineering to sztuka kurateli nad całym stanem, który trafia do okna kontekstu – od system promptu, przez historię rozmowy i wyniki narzędzi, po dane z zewnątrz. Modele mają „budżet uwagi” i wraz ze wzrostem liczby tokenów rośnie ryzyko tzw. context rot: pamięć się rozmywa, precyzja spada. Większe okna pomagają, ale nie rozwiązują problemu u źródła. [8]

Google popycha to jeszcze dalej w Agent Development Kit: kontekst to nie jeden wielki bufor tekstu, tylko skompilowany widok nad bogatszym, stanowym systemem. Oddzielasz magazyn od prezentacji i na każde wywołanie budujesz efemeryczny „Working Context” z instrukcji, wybranych zdarzeń sesji i ewentualnej pamięci. Całość składa się przez potoki procesorów – coś jak kompilator: określona kolejność transformacji decyduje, co faktycznie trafi do modelu. To nie jest zabawa promptami, to inżynieria systemowa.

Jak to się robi w praktyce

Spotify finalnie przesiadło się na Claude Code. Powód: agent lepiej interpretuje cele, sam zarządza zadaniami typu Todo, potrafi tworzyć subagentów, a użytkownik może mówić o rezultacie, nie o ścieżce do niego. Efekt? Claude Code został ich topowym agentem do migracji – użyli go już do około 50 zadań, a większość zmergowanych w produkcję PR-ów pochodzi właśnie stamtąd. Anthropic doceniło to wprost: klucz był w opanowaniu promptów i zarządzaniu kontekstem.

Głębiej pod maską widać powtarzalne wzorce z innych narzędzi:

• Kompresja i offload. W Deep Agents od LangChain duże wyniki narzędzi (np. odczyty wielkich plików, długie odpowiedzi API) są wyrzucane do systemu plików i zastępowane krótkim podglądem oraz ścieżką. Kiedy bieżąca sesja zbliża się do 85% limitu, stare argumenty zapisów/edycji plików też lecą na dysk jako wskaźniki. Gdy to nie wystarcza, wchodzi podsumowanie: syntetyczny, strukturalny skrót historii w kontekście + pełny log w plikach do ewentualnego dogrania na żądanie.
• Izolacja przez subagentów. Deep Agents wspiera podzlecanie pracy wyspecjalizowanym agentom z własnym oknem kontekstu. Dzięki temu główny agent dostaje z powrotem wynik, a nie 20 pośrednich wywołań narzędzi, które zapchałyby mu pamięć. To sposób na przeciążenie przy złożonych, wieloetapowych zadaniach.
• Pamięć między sesjami. Anthropic w swoim SDK rozbija długie prace na parę: agent inicjalizujący przygotowuje środowisko (np. skrypt init.sh, plik logu postępów), a agent kodujący w każdej sesji robi inkrementalny krok do przodu i zostawia czytelne artefakty (np. claude-progress.txt). Dwie rzeczy to zabijają: próba zrobienia wszystkiego „na raz” oraz agent, który po kilku funkcjach uznaje, że „już gotowe”.
• Zewnętrzna „pamięć długotrwała”. W praktyce świetnie sprawdzają się proste magazyny jak Beads (SQLite + Git) odwzorowujące backlog i kontekst na poziomie epików i plików. Z takim rusztowaniem autor zrefaktoryzował 315 plików frontendu w 12 godzin: agent miał jasne instrukcje i granice, a człowiek tylko domykał krawędzie. Wspólny mianownik: spec-first, akceptacja kryteriów, atomowe zadania, Git jako źródło prawdy.

W tle pracuje jeszcze inny wzorzec, który Spotify rozwija w dalszej części serii: pętle weryfikacji. Zamiast kazać agentowi „rozumieć” każdy system buildów i testów, wystawiasz mu zunifikowane weryfikatory przez MCP. Jeśli w repo leży pom.xml, zapala się weryfikator Maven. Komunikaty błędów są parsowane i sprowadzane do esencji, sukces – do krótkiego „OK”. Agent nie marnuje kontekstu na szum, a ty zyskujesz przewidywalność.

Komentarz

Wszędzie wychodzi ta sama prawda: większe okna są miłe, ale nieskalowalne jako jedyna strategia. Trzeba projektować dietę informacyjną agenta. Dajesz mu dokładnie to, co powinien „widzieć” w danym momencie – resztę zapisujesz, indeksujesz, streszczasz lub delegujesz. I – co równie ważne – rozbijasz cele na kroki, które da się zrealizować w jednej, dwóch sesjach, zostawiając po sobie czyste, zrozumiałe ślady. Młotek może być większy, ale od samego machania gwoździe nie układają się w katedry.

Na koniec

Jeśli budujesz agenta do utrzymania kodu, zapytaj siebie: czy potrafiłbyś wydrukować jego „Working Context” na jednej stronie A4 i dalej mieć sens? Jeśli nie – czas na kompilację kontekstu, nie jego kopiowanie. Ci, którzy to robią, już dziś automatyzują to, na co kiedyś szły sprinty.

FAQ

Czy większe okno kontekstu rozwiązuje problemy długich zadań agentów?

Nie. Większe okno pomaga, ale nie usuwa context rot i ograniczeń „budżetu uwagi”. Potrzebne są selekcja, kompresja i zewnętrzna pamięć.

Jak Spotify ograniczało „gubienie celu” przez agenta?

Limity tur (10 na sesję, do trzech podejść) i ścisła pętla: edycje → build/test → feedback. Później przejście na agenta, który sam zarządza zadaniami i subagentami.

Kiedy warto użyć subagentów w systemie wieloagentowym?

Gdy pojedyncze zadanie generuje dużo pośrednich wywołań narzędzi lub wymaga specjalizacji. Subagent izoluje kontekst i oddaje zwięzły wynik, a nie cały śmietnik po drodze.

Jak praktycznie „odciążyć” kontekst podczas pracy na plikach?

Offloaduj duże wyniki narzędzi do systemu plików (np. powyżej około 20 tys. tokenów) i zamieniaj stare wpisy narzędzi na wskaźniki, gdy sesja zbliża się do około 85% limitu. Gdy to za mało – streszczaj historię, a pełny log trzymaj na dysku.

Jak utrzymać ciągłość między sesjami długiego zadania?

Użyj agenta inicjalizującego do przygotowania środowiska i artefaktów (np. init.sh, dziennik postępu), a agenta kodującego do inkrementalnych kroków i zostawiania czytelnych śladów dla następnego biegu.

Źródła

• [1] https://engineering.atspotify.com/2025/12/feedback-loops-background-coding-agents-part-3/
• [2] https://blog.langchain.com/context-management-for-deepagents/
• [3] https://developers.googleblog.com/architecting-efficient-context-aware-multi-agent-framework-for-production/
• [4] https://devblogs.sh/posts/long-running-agentic-work-with-beads
• [5] https://anthropic.com/engineering/effective-harnesses-for-long-running-agents
• [6] https://engineering.atspotify.com/2025/11/context-engineering-background-coding-agents-part-2/
• [7] https://blog.langchain.com/building-multi-agent-applications-with-deep-agents/
• [8] https://anthropic.com/engineering/effective-context-engineering-for-ai-agents