Je eerste agent-workflow begint met één prompt en een paar tools. Het beantwoordt vragen. Het zoekt de status van een bestelling op. Het werkt, dus je levert het op.

Dan groeit het product. Sales vraagt om een CRM-updater die vergadernotities synchroniseert. Support heeft een refund-workflow nodig die drie interne systemen raakt. Engineering voegt browseracties toe om vendor-formulieren in te vullen. Elke aanvraag lijkt klein. Elke aanvraag krijgt zijn eigen prompt-bestand, zijn eigen Slack-thread, zijn eigen "quick fix". Zes maanden later is je agent niet langer één systeem. Het is een verspreide bende van gekopieerde prompts, verborgen bedrijfsregels en beslissingen die in oude chat-threads zijn genomen die niemand meer kan vinden. Dat is prompt sprawl. Het maakt je AI-product moeilijk te testen, moeilijk te beoordelen en onmogelijk om met vertrouwen terug te draaien.

De oplossing is een AI agent skill registry.

Wat een skill eigenlijk is

Een skill is niet zomaar een prompt die in een map is opgeslagen. Het is een versieversieerd, testbaar pakket dat definieert wat de agent doet, welke tools hij kan aanroepen en wat hij nooit mag doen. Zie het als een contract tussen jouw team en de machine. Wanneer een agent een skill laadt, moet hij precies weten waar zijn grenzen liggen en hoe succes eruitziet.

Zonder deze structuur wordt elke prompt een klein, niet-gedeclareerd productiesysteem. Het bevat verborgen permissies, ingebedde bedrijfsregels en kostenimpacts die niemand bijhoudt. Het raakt losgekoppeld van het eigenlijke product omdat de product-roadmap verschoof terwijl de prompt achterbleef. Het ergste is nog dat het wordt gekopieerd. Iemand forkt het voor een demo, of plakt het in een nieuwe microservice, en nu heb je twee sources of truth die in het duister van elkaar afwijken.

Waarom prompts alleen niet volstaan

Prompts zien eruit als tekst, dus teams behandelen ze als configuratie. In werkelijkheid zijn ze echter dichter bij code dan men wil toegeven. Een productie-prompt bevat meestal logica over volgorde, formattering, foutafhandeling en toegangscontrole. Wanneer die logica alleen in natuurlijke taal bestaat, ontstaat er ambiguïteit. Heeft de agent toestemming om de CRM bij te werken, of suggereerde de prompt dat alleen maar? Als de billing API uitvalt, weet de prompt dan hoe hij veilig moet falen, of hallucineert hij een succesmelding?

Kosten zijn een andere stille killer. Een prompt die de agent vraagt om "stap voor stap na te denken en uitgebreid te zoeken" kan bij elke run enorme hoeveelheden tokens verbruiken. Wanneer die prompt wordt gekopieerd naar een support-flow met veel verkeer, verdubbelt je maandelijkse inference-rekening en weet niemand waarom.

Drift ontstaat wanneer het bedrijf verandert, maar de tekst niet. Je refund-beleid vereist nu goedkeuring van een manager boven een bepaalde drempel. Als die regel in een prompt leeft in plaats van in een beleidslaag, moet je door elke deployment zoeken om de kopieën te vinden die bijgewerkt moeten worden. Mis je er één, dan heb je agents die geld uitkeren dat ze niet zouden mogen geven.

Anatomie van een productie-skill

Als je uit deze chaos wilt ontsnappen, behandel elke skill dan als een software-artefact. Een nuttige productie-skill bevat meer dan alleen tekst. Het heeft nodig:

  • Naam en doel. Niet "prompt_v3_final", maar "process_standard_refund" met een duidelijke beschrijving van het bedrijfsdoel.
  • Input-schema en vereiste context. Definieer de exacte velden die de skill verwacht. Heeft het een user ID, een gesprekshistorie of een tenant-identifier nodig? Sterke typering voorkomt hier dat de agent aannames doet.
  • Tool-permissies en veiligheidslimieten. Specificeer expliciet welke tools de skill kan aanroepen. Stel guardrails in voor retries, bestedingslimieten en rate caps. Als de skill de user deletion API niet mag aanraken, leg dat dan vast in code, niet alleen in tekst.
  • Succescriteria en testgevallen. Een skill "werkt" niet alleen omdat hij draait. Definieer wat de output moet bevatten. Voor een refund-skill kan succes betekenen: een gevalideerd transactieoverzicht, een verzonden e-mailbevestiging en een aangemaakt auditlog-item.
  • Versiegeschiedenis en eigenaarschap. Iemand moet hiervoor verantwoordelijk zijn. Een changelog moet uitleggen waarom v2.3 bestaat en wat er misging in v2.2.

Scheid je lagen

De grootste fout die teams maken, is alles in één prompt proppen. Ze mengen vriendelijke instructies, tool-documentatie, beveiligingsbeleid en foutafhandeling tot een muur van tekst. Dat is onhoudbaar.

Splits het op:

  • Instructions are guidance for the agent. They explain tone, format, and general approach.
  • Tool Rules tell the agent which tools exist and what they do. This is discovery, not permission.
  • Policy is enforced by code, not by hope. If a refund over $500 needs a second pair of eyes, that check lives in a validation function that runs before the tool is ever called.
  • Evals are tests that prove the skill still works after any change.

For example, do not write, "Please never expose the customer's full credit card number." Instead, build a data formatter that redacts PANs before the agent sees them. Policy belongs in code because code cannot be talked out of its job by a clever user input.

Stop Pointing Production at "Latest"

Nothing destroys a Friday evening like a silent prompt update. If your production agent always pulls the "latest" version of a skill, then every merge to main is a potential live incident. You need aliases such as dev, staging, and prod. Promote a known, tested version through these stages. When prod points to v2.1.4, you can watch it run, measure its behavior, and sleep soundly. If something goes wrong, you move the alias back. You do not debug natural language at midnight under pressure.

This discipline also forces your team to think about backwards compatibility. Can v2.2 handle the same input shape as v2.1? If not, the promotion fails in staging, and you catch it before a customer does.

Security Starts Inside the Package

A registry full of unaudited prompts is a vulnerability waiting to happen. You need to scan your skills for the same risks you would scan in code.

Look for hardcoded secrets or API keys buried in prompt templates. Check for external webhooks or shell commands that exfiltrate data. Watch for attempts to override system policy, such as prompts that contain "ignore previous instructions" or ask the agent to reveal its own configuration. These are not just theoretical. They are common patterns in prompt-injection attacks, and they are dangerous because they often ride along with copied text that no one reviewed.

Run your skill packages through static analysis. If a skill file contains a URL that is not on an allowlist, fail the build. If it references a tool that is not in the approved manifest, reject it.

If You Can't Test It, You Can't Trust It

A registry without evaluations is just a folder of prompts. Each skill needs a test set that exercises the happy path, the edge cases, and the failure modes. For high-risk skills, you need more than functional tests. You need to probe permission boundaries to make sure the agent cannot see another user's data. You need refusal behavior checks to confirm it says no when policy blocks an action. You need prompt-injection resistance tests to verify that adversarial inputs do not bypass your code-level protections.

Name your tests explicitly. A test called "refund_skill_rejects_negative_amount" tells the next engineer exactly what behavior is protected. When a test fails during a version promotion, you have hard evidence that the candidate build is unsafe.

The Real Goal Is Control

Reuse is nice, but control is what keeps you employed. A skill registry lets your team state, with certainty: this is the approved workflow. This is the version running in production. These are the tools it can use. This is exactly how we roll it back.

That clarity moves you from shipping clever demos to operating dependable software. Demos impress stakeholders for ten minutes. Dependable software runs at three in the morning, handles exceptions gracefully, and does not change behavior just because someone merged a pull request on Tuesday afternoon.

Build your registry. Version your skills. Enforce your policies in code. Test like your sleep schedule depends on it. Your future self will thank you.