Il tuo primo workflow di agent inizia con un singolo prompt e pochi strumenti. Risponde alle domande. Verifica lo stato di un ordine. Funziona, quindi lo rilasci.

Poi il prodotto cresce. Il team Sales chiede un aggiornatore CRM che sincronizzi gli appunti delle riunioni. Il Supporto ha bisogno di un workflow per i rimborsi che interagisca con tre sistemi interni. L'Engineering aggiunge azioni nel browser per compilare i moduli dei fornitori. Ogni richiesta sembra piccola. Ognuna riceve il proprio file di prompt, il proprio thread Slack, la propria "soluzione rapida". Sei mesi dopo, il tuo agent non è più un unico sistema. È un insieme disperso di prompt copiati, regole di business nascoste e decisioni prese in vecchi thread di chat che nessuno riesce a trovare. Questo è il prompt sprawl. Rende il tuo prodotto AI difficile da testare, difficile da revisionare e impossibile effettuare il rollback con sicurezza.

La soluzione è un registro delle skill per agent AI.

Che cos'è realmente una skill

Una skill non è un prompt salvato in una cartella. È un pacchetto versionato e testabile che definisce cosa fa l'agent, quali strumenti può chiamare e cosa non deve mai fare. Pensala come un contratto tra il tuo team e la macchina. Quando un agent carica una skill, dovrebbe sapere esattamente dove sono i suoi confini e qual è l'esito positivo.

Senza questa struttura, ogni prompt diventa un piccolo sistema di produzione non dichiarato. Porta con sé permessi nascosti, regole di business incorporate e impatti sui costi che nessuno ha monitorato. Si allontana dal prodotto reale perché la roadmap del prodotto è andata avanti mentre il prompt è rimasto indietro. Peggio di tutto, viene copiato. Qualcuno lo clona per una demo o lo incolla in un nuovo microservizio, e ora hai due fonti di verità che divergono nell'oscurità.

Perché i soli prompt non bastano

I prompt sembrano testo, quindi i team li trattano come configurazioni. In realtà, sono più vicini al codice di quanto chiunque voglia ammettere. Un prompt di produzione solitamente codifica la logica relativa alla sequenza, alla formattazione, alla gestione degli errori e al controllo degli accessi. Quando quella logica vive solo nel linguaggio naturale, si crea ambiguità. L'agent ha il permesso di aggiornare il CRM o il prompt lo ha solo suggerito? Se l'API di fatturazione va giù, il prompt sa come gestire l'errore in modo sicuro o allucina un messaggio di successo?

Il costo è un altro killer silenzioso. Un prompt che chiede all'agent di "pensare passo dopo passo e cercare estensivamente" può consumare una quantità enorme di token ad ogni singola esecuzione. Quando quel prompt viene copiato in un flusso di supporto ad alto traffico, la tua bolletta mensile per l'inferenza raddoppia e nessuno sa perché.

Il drift avviene quando il business cambia ma il testo no. La tua politica di rimborso ora richiede l'approvazione di un manager sopra una certa soglia. Se quella regola vive all'interno di un prompt invece che in uno strato di policy, dovrai setacciare ogni deployment per trovare le copie che devono essere aggiornate. Se ne salti una, avrai agent che distribuiscono denaro che non dovrebbero.

Anatomia di una skill di produzione

Se vuoi sfuggire a questo caos, tratta ogni skill come un artefatto software. Una skill di produzione utile include molto più del semplice testo. Ha bisogno di:

  • Nome e scopo. Non "prompt_v3_final", ma "process_standard_refund" con una descrizione chiara dell'obiettivo di business.
  • Schema di input e contesto richiesto. Definisci i campi esatti che la skill si aspetta. Ha bisogno di un ID utente, della cronologia della conversazione, di un identificatore del tenant? Una tipizzazione forte qui impedisce all'agent di fare supposizioni.
  • Permessi degli strumenti e limiti di sicurezza. Elenca esplicitamente quali strumenti la skill può invocare. Imposta dei guardrail su tentativi (retries), limiti di spesa e limiti di frequenza (rate caps). Se la skill non deve toccare l'API di eliminazione utente, dillo nel codice, non solo in prosa.
  • Criteri di successo e casi di test. Una skill non "funziona" solo perché viene eseguita. Definisci cosa deve contenere l'output. Per una skill di rimborso, il successo potrebbe significare un record di transazione validato, l'invio di una conferma via email e la creazione di una voce nel registro di audit.
  • Cronologia delle versioni e proprietario. Qualcuno deve esserne responsabile. Un changelog dovrebbe spiegare perché esiste la v2.3 e cosa si è rotto nella v2.2.

Separa i tuoi livelli

L'errore più grande che commettono i team è infilare tutto in un unico prompt. Mescolano guida amichevole, documentazione degli strumenti, policy di sicurezza e gestione degli errori in un muro di testo. È impossibile da mantenere.

Dividilo:

  • 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.