Każdy system agentowy mierzy się z tym samym niewygodnym kompromisem. Chcesz mieć głęboką, dobrze zorganizowaną bazę wiedzy, która przetrwa przeglądy kodu i historię git. Potrzebujesz jednak, aby runtime działał szybko i pozostawał skoncentrowany. Te dwie potrzeby wzajemnie się wykluczają. Im więcej instrukcji przechowujesz, tym bardziej kusi, by wrzucić je wszystkie do promptu i liczyć na najlepsze. Ta nadzieja jest kosztowna.

W ekosystemie Agent Project Context to napięcie rozdziela się wyraźnie na dwie warstwy. APC odpowiada za trwałość. APX odpowiada za szybkość. Zrozumienie tego, jak ze sobą współpracują — i dlaczego APX odmawia wczytywania z wyprzedzeniem każdej definicji umiejętności (skill definition) — mówi o inżynierii promptów więcej, niż podadzą Ci większość przewodników po optymalizacji.

Archiwum i silnik

Zadaniem APC jest trwałość. Przechowuje on reużywalne pliki umiejętności w .apc/skills/ jako zwykłe dokumenty Markdown. Ponieważ pliki te znajdują się wewnątrz Twojego repozytorium, podróżują wraz z kontrolą wersji. Możesz otworzyć pull request zmieniający procedurę wdrożenia. Możesz porównać (diff) wycofanie polityki bezpieczeństwa sprzed sześciu tygodni. Możesz dokładnie zaaudytować, co agent miał wiedzieć i kiedy. Taka możliwość weryfikacji jest kluczowa, gdy wdrożenie pójdzie nie tak lub gdy audytor zgodności zacznie zadawać pytania.

APX z kolei żyje chwilą. Zarządza on rzeczywistą konwersacją między Tobą a modelem. Jego celem nie jest archiwizowanie wiedzy, lecz precyzyjne jej wykorzystanie. Gdy APX traktuje umiejętności jako stały bagaż, cały system zwalnia. Okno kontekstowe zapełnia się. Koszty tokenów rosną. Co gorsza, uwaga modelu rozprasza się na instrukcjach, które nie mają nic wspólnego z bieżącym zapytaniem.

Dlatego też treści umiejętności (skill bodies) są ładowane na żądanie.

Prawdziwy koszt przeładowanego promptu

Większość zespołów rozumie, że tokeny kosztują pieniądze. Mniej zespołów zdaje sobie sprawę, że nieistotne tokeny kosztują dokładność.

Gdy APX wstrzykuje każdą dostępną umiejętność do każdej tury, prompt staje się zaszumiony. Model otrzymuje jednocześnie runbook wdrożeniowy, przewodnik bezpieczeństwa, referencję stylu API, listę kontrolną testów i FAQ wdrożeniowe. Nawet przy dużym oknie kontekstowym jakość rozumowania spada, gdy model musi najpierw przedzierać się przez szum, aby odnaleźć sygnał. Może on skupić się na wymaganiu bezpieczeństwa przeznaczonym dla wdrożeń produkcyjnych, odpowiadając na pytanie o lokalną konfigurację testów. Może halucynować kroki z listy kontrolnej wydania podczas prostej poprawki błędu. Każdy dodatkowy akapit niepowiązanej treści to rozpraszacz czekający na swoją kolej.

Matematyka jest prosta. Większość tur nie wymaga większości umiejętności. Jeśli prosisz o szybką poprawkę błędu w logach, nie potrzebujesz pełnego tekstu runbooka wdrożeniowego ani przewodnika wzmacniania bezpieczeństwa. Potrzebujesz, aby model zobaczył błąd, zrozumiał konwencje Twojego projektu i edytował właściwy plik. Ładowanie nieistotnych treści umiejętności nie pomaga modelowi w tym zadaniu. Zmusza go jedynie do filtrowania bezużytecznych danych, zanim w ogóle zacznie pracować nad Twoim rzeczywistym problemem.

Jak działa ładowanie na żądanie

Mechanizm jest prosty, ale celowy. APC nadal stanowi źródło prawdy (ground truth). Twoje definicje umiejętności pozostają tam, gdzie ich miejsce: w .apc/skills/<name>.md.

APX nie kopiuje tych plików do pamięci aktywnej. Zamiast tego tworzy kompaktowy rejestr nazw umiejętności. Model widzi tę listę i rozumie, że istnieje katalog. Jeśli musi przejrzeć lub potwierdzić dostępne możliwości, może wywołać funkcję list_skills. Daje mu to widoczność bez nadmiaru danych.

Gdy zadanie faktycznie wymaga dokładnej składni, szczegółowych kroków lub specyficznych ograniczeń zakodowanych w pliku umiejętności, model wywołuje load_skill. Wtedy, i tylko wtedy, APX pobiera pełną treść Markdown z APC i wstrzykuje ją do kontekstu. Instrukcja dociera „na gorąco”, zostaje użyta raz do zamierzonego celu, a system unika noszenia jej ze sobą jako zbędnego balastu.

Pomyśl o różnicy między importowaniem biblioteki a wklejaniem definicji każdej funkcji do swojego głównego pliku. Jedno podejście sprawia, że Twój kod pozostaje czytelny. Drugie tworzy bałagan, który kompiluje się jedynie przez przypadek.

Kto wygrywa, gdy umiejętności się kolidują

APX wymusza również jasną kolejność priorytetów podczas ładowania umiejętności. Nie każde środowisko jest takie samo, a ogólne porady nigdy nie powinny nadpisywać lokalnej wiedzy.

Project skills take the top priority. These files live in your current repository under .apc/skills/. They capture your team’s specific conventions, your custom wrappers, your legacy naming standards, and your particular toolchain. If your project defines its own way of handling database migrations, that definition wins.

Global skills come next. These cover organization-wide patterns that apply when the project itself stays silent. They act as a standard library.

Built-in runtime skills sit at the bottom as the fallback. They handle generic capabilities that every agent should understand but that no specific project has bothered to redefine.

This layered approach means your repository keeps control over its own behavior. A global or built-in skill cannot accidentally hijack a workflow that your team has intentionally customized.

What This Looks Like in Practice

Picture a typical maintenance task. A teammate pastes an error log into the chat. The traceback points to a single null reference in a utility module. The fix is likely two lines of defensive coding.

In a system without on-demand loading, APX would stuff the context with every skill it knows. The model now has forty pages of text to consider before touching those two lines. It sees the release checklist and wonders if it should bump a version. It sees the security guide and contemplates input validation on a function that just needs a null check. It sees the deployment runbook and starts thinking about staging environments. The model drifts. The response takes longer. The token meter spins.

With APX’s on-demand design, the model sees only the names. It knows that [release-checklist], [security-guide], [deployment-runbook], and [error-handling] exist. It ignores the first three. It might load [error-handling] if your project’s conventions for null safety are specific. It fixes the bug. The unrelated skills never entered the context window. The model stayed focused because the prompt stayed clean.

The same logic holds when the task actually is complex. If you later ask the agent to prepare a production deployment, it can load the deployment runbook, consult the security guide, and follow the release checklist exactly when those steps become relevant. The knowledge was always there. It simply waited for the right moment.

Prompt Discipline as Architecture

The separation between APC and APX is not just an implementation detail. It is a philosophy of prompt discipline. APC preserves knowledge forever, making it reviewable, versioned, and safe. APX decides how much of that knowledge earns a place in the active context right now.

A rich skill catalog is an asset. A bloated prompt is a liability. The goal is to keep your context portable without making it always active. Your repository should contain every instruction your team has ever written, but the agent should read only the ones that help with the immediate task.

If your system forces the model to carry every skill body into every turn, you are not building an intelligent assistant. You are building a librarian who drags the entire archive to every reference desk question. Store everything. Load what matters. That is how you keep agents fast, context clean, and reasoning sharp.