Elk agentsysteem staat voor hetzelfde ongemakkelijke dilemma. Je wilt een diepe, goed georganiseerde kennisbank die bestand is tegen code reviews en git-geschiedenis. Maar je wilt ook dat de runtime snel is en gefocust blijft. Deze twee behoeften werken elkaar tegen. Hoe meer instructies je bewaart, hoe verleidelijker het wordt om ze allemaal in de prompt te dumpen en te hopen op het beste. Dat hopen is kostbaar.

In het Agent Project Context-ecosysteem wordt deze spanning helder verdeeld over twee lagen. APC verzorgt de duurzaamheid. APX verzorgt de snelheid. Begrijpen hoe ze met elkaar interageren — en waarom APX weigert om elke skill-definitie vooraf te laden — onthult meer over prompt engineering dan de meeste optimalisatiegidsen je zullen vertellen.

Het archief en de motor

De taak van APC is permanentie. Het slaat herbruikbare skill-bestanden op onder .apc/skills/ als gewone Markdown-documenten. Omdat deze bestanden in je repository staan, gaan ze mee met het versiebeheer. Je kunt een pull request indienen die een deployment-procedure wijzigt. Je kunt een rollback van een beveiligingsbeleid van zes weken geleden diffen. Je kunt precies auditeren wat de agent had moeten weten en wanneer. Die controleerbaarheid is essentieel wanneer een slechte deployment live gaat of wanneer een compliance-auditor vragen begint te stellen.

APX leeft daarentegen in het moment. Het beheert het eigenlijke gesprek tussen jou en het model. Het doel is niet om kennis te archiveren, maar om deze precies te gebruiken. Wanneer APX skills behandelt als permanente bagage, vertraagt het hele systeem. Het context window raakt vol. De tokenkosten stijgen. Erger nog, de aandacht van het model versnippert over instructies die niets te maken hebben met de huidige aanvraag.

Dit is waarom skill-bodies on demand worden geladen.

De werkelijke kosten van een opgeblazen prompt

De meeste teams begrijpen dat tokens geld kosten. Minder teams beseffen dat irrelevante tokens ten koste gaan van de nauwkeurigheid.

Wanneer APX elke beschikbare skill in elke beurt injecteert, wordt de prompt ruisachtig. Het model ontvangt tegelijkertijd het deployment runbook, de security guide, de API style reference, de testchecklist en de onboarding FAQ. Zelfs met een groot context window verslechtert de kwaliteit van het redeneren wanneer het model eerst door de ruis heen moet zoeken naar het signaal. Het kan zich vastklampen aan een beveiligingseis die bedoeld is voor productie-deployments terwijl het een vraag beantwoordt over een lokale testopstelling. Het kan stappen uit een releasechecklist hallucineren in een eenvoudige bugfix. Elke extra paragraaf met ongerelateerde tekst is een afleiding die wacht om te gebeuren.

De rekensom is eenvoudig. De meeste beurten hebben de meeste skills niet nodig. Als je vraagt om een snelle oplossing voor een error log, heb je niet de volledige tekst van een deployment runbook of een security hardening guide nodig. Je wilt dat het model de fout ziet, jouw projectconventies begrijpt en het juiste bestand bewerkt. Het laden van irrelevante skill-bodies helpt het model hier niet bij. Het dwingt het model om nutteloze data weg te filteren voordat het überhaupt aan je eigenlijke probleem kan beginnen.

Hoe on-demand laden werkt

Het mechanisme is simpel maar doelbewust. APC blijft de ground truth vasthouden. Je skill-definities blijven waar ze horen: in .apc/skills/<name>.md.

APX spiegelt die bestanden niet naar het actieve geheugen. In plaats daarvan stelt het een compact register van skill-namen samen. Het model ziet deze lijst en begrijpt dat er een catalogus bestaat. Als het door de mogelijkheden wil bladeren of wil bevestigen welke capabilities beschikbaar zijn, kan het een list_skills-aanroep uitvoeren. Dit geeft het model zichtbaarheid zonder omvang.

Wanneer de taak daadwerkelijk de exacte syntaxis, de gedetailleerde stappen of de specifieke beperkingen vereist die in een skill-bestand zijn gecodeerd, roept het model load_skill aan. Op dat moment, en alleen op dat moment, haalt APX de volledige Markdown-body op uit APC en injecteert deze in de context. De instructie komt direct binnen, wordt één keer gebruikt voor het beoogde doel, en het systeem voorkomt dat het als dood gewicht wordt meegesleept.

Denk aan het verschil tussen het importeren van een bibliotheek en het plakken van elke functiedefinitie in je hoofdbestand. De ene aanpak houdt je codebase navigeerbaar. De andere creëert een puinhoop die alleen per ongeluk compileert.

Wie wint wanneer skills botsen

APX handhaaft ook een duidelijke prioriteitsvolgorde wanneer het skills laadt. Niet elke omgeving is hetzelfde, en algemeen advies mag nooit lokale kennis overschrijven.

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.