Herbruikbare promptactie

Wat is een herbruikbare promptactie?

Een herbruikbare promptactie is een bewaarde prompt met een naam, vastgelegde inputs en een vastgelegde output, op een plek waar je systemen ze kunnen oproepen. Een flow draait ze als stap. Een agent mag ze aanroepen als tool. De instructie is elke run dezelfde en staat op één plaats, niet in de chatgeschiedenis van zes collega's.

Een prompt template geeft je al de invulvelden. Een actie voegt daar de stukken aan toe die haar oproepbaar maken: een naam waar andere systemen naar verwijzen, een outputvorm waar de volgende stap op kan rekenen, en een bewaarplaats met een eigenaar. Een agent skill zit een niveau hoger, want die beschrijft hoe een agent een hele procedure aanpakt. Een promptactie is één afgebakende taak daarbinnen.

De prompt builder van Microsoft, de AI Builder-functie die je in Power Apps en Power Automate via de AI hub opent, toont die vorm het duidelijkst. De documentatie beschrijft een omgeving waarin makers herbruikbare prompts bouwen, testen en bewaren, en die je daarna kan delen en gebruiken in agents, workflows of apps. In een cloud flow verschijnt de bewaarde prompt als een Power Automate-actie met de naam Run a prompt. In Copilot Studio voeg je hetzelfde object toe onder Tools, en een prompt die je daar maakt, werkt in elke agent en elk topic.

Vier dingen maken van een goed geschreven instructie een actie.

• Een naam. Iets als classificeer-leveranciersmail. Een flow verwijst naar die naam en een collega zoekt erop. "De mailprompt van Jan" is geen naam.

• Vastgelegde inputs. In prompt builder is elke input tekst of een afbeelding of document, en je typt er een voorbeeldwaarde bij. Dat voorbeeld is meteen de eerste test die de prompt krijgt.

• Een vastgelegde output. Tekst is de standaard. JSON met benoemde velden is wat het antwoord bruikbaar maakt voor de stap erna.

• Een bewaarplaats met een levenscyclus. In Power Platform is een prompt een solution component, dus ze reist van een ontwikkelomgeving naar productie in een solution, en Microsoft raadt af om een geïmporteerde prompt daarna nog aan te passen.

Dezelfde prompt in zes flows

Neem een prompt die bepaalt of een binnenkomende mail een bestelling is, een factuur of iets anders. Ze werkt, dus ze wordt in de mailboxflow geplakt, daarna in de flow voor het leveranciersportaal, daarna in een tweede mailbox voor de Franse entiteit, waar een collega er een regel over creditnota's aan toevoegt en er niets over zegt.

Je hebt nu zes prompts die als één begonnen zijn, en geen enkele draagt het label kopie. Als iemand meldt dat creditnota's als facturen geboekt worden, kan niemand zeggen welke prompt dat antwoord gaf, en het exemplaar dat je vindt en herstelt, laat de andere ongemoeid. Het loopt saai mis: kopieën die in acht maanden uit elkaar groeien, en vreemde resultaten die niemand kan herleiden.

Het verschil komt pas echt boven op de dag dat de prompt aangepast moet worden.

• Een prompt die in elke flow geplakt staat. Je past elke kopie aan die je terugvindt, de exemplaren die je mist draaien verder op de oude tekst tot iemand het merkt, en achteraf blijft het gissen welke kopie dat vreemde antwoord gaf.

• Een benoemde promptactie. Je past één object aan, elke flow die ze oproept pikt de wijziging op bij haar volgende run, en er is één tekst, één versie en één testresultaat om naar te wijzen.

Daarom verdient een wijziging aan een actie ook eerst een test: ze landt overal tegelijk.

Ontwerpregels voor een promptactie in een flow

Vraag één ding. Een prompt die de mail classificeert, een antwoord opstelt en beslist of er geëscaleerd moet worden, is drie acties in één jas, en de formulering van het antwoord aanpassen zet meteen de classificatie op het spel. Splits ze, en de flow roept de tweede actie enkel op als de eerste zegt dat het nodig is.

Leg de output vast als een beperkte lijst waarden of een kleine structuur, niet als vrije tekst. Een veld category met vijf toegelaten waarden geeft de flow iets om op te vertakken. Een alinea geeft ze een parseerprobleem. De performantierichtlijnen van Microsoft wijzen dezelfde kant op voor JSON-output: hou de structuur eenvoudig, beperk het aantal keys, en vraag enkel een reden-veld als een mens of een audittrail het ook echt leest.

Schrijf op wat er moet gebeuren als de input niet past. Prompts worden geschreven voor het nette geval en botsen daarna op een lege mailtekst, een scan zonder leesbare tekst, een bericht in het Portugees of een doorgestuurde conversatie met vier mails in elkaar. Zet die regel in de instructie zelf: past het bericht in geen enkele categorie, geef dan other terug en zet needs_review op true.

Laat ze nooit een waarde verzinnen die de volgende stap voor waar aanneemt. Staat het factuurnummer niet in het document, dan is een leeg veld het juiste antwoord en is een geloofwaardig ogend nummer een boekingsfout. Schrijf dat in de instructie, laat null toe, en laat de flow null behandelen als een routeringsbeslissing in plaats van als een fout.

Een uitgewerkt voorbeeld: leveranciersmails sorteren

Een groothandel krijgt een paar honderd leveranciersmails per week binnen. De actie heet classificeer-leveranciersmail. Ze neemt twee inputs, subject en body, allebei tekst. Ze geeft dit terug en niets anders:

{
  "category": "order_confirmation",
  "supplier_reference": "PO-88213",
  "needs_review": false
}

category mag maar vijf waarden aannemen: order_confirmation, invoice, delivery_note, price_change of other. supplier_reference is de referentie zoals ze letterlijk in de mail staat, of null als er geen in staat. needs_review is true wanneer het model op other moest terugvallen, wanneer de referentie ontbreekt bij een categorie die er normaal een heeft, of wanneer de mail duidelijk over meer dan één documenttype gaat.

Het faalpad is het stuk dat mensen overslaan. Voor de flow iets met het antwoord doet, voert ze drie controles uit: het antwoord parseert als JSON, category bevat een van de vijf toegelaten waarden, en supplier_reference is null of past op het referentiepatroon van het ERP. Loopt een van die controles mis, dan gaat de mail naar een wachtrij voor manuele controle, met de ruwe modeloutput erbij, en stopt de flow daar. Ze probeert niet stilletjes opnieuw en ze maakt geen record aan met een gegokte categorie. Iemand kijkt die mail dezelfde dag na, en het geval gaat mee in de testset.

Ligt de vorm van de output echt vast?

Of een structured output afgedwongen wordt of alleen maar gevraagd, hangt af van het product, en dat bepaalt hoeveel controlewerk je flow zelf nog moet doen. Roep je een model-API rechtstreeks aan, dan kan de vorm echt afgedwongen worden. De structured outputs van OpenAI beperken het decoderen aan de hand van het JSON-schema dat je meegeeft, en de documentatie zegt dat het model altijd antwoorden genereert die zich aan dat schema houden, zodat een ontbrekende verplichte key of een verzonnen enum-waarde geen zorg meer is. Anthropic doet dezelfde belofte via constrained decoding. Geen van beide garanties houdt stand bij een antwoord dat nooit afgeraakt: een weigering of een tokenlimiet kan het afbreken voor het schema rond is.

Low-code prompt builders werken anders. In de prompt builder van Microsoft schrijf je helemaal geen schema: je plakt een voorbeeld van de JSON die je wil, de tool leidt het formaat daaruit af, dat formaat wordt vastgelegd zodra je bewaart, en het gegenereerde schema kan je niet aanpassen. De documentatie vermeldt ook een foutmelding die je tijdens het testen kan tegenkomen, "A JSON could not be generated". Dat is een controle die een misvormd antwoord opvangt, en dat is iets anders dan de garantie dat een misvormd antwoord onmogelijk is.

Dat verschil legt de zwakke plek van deze vorm bloot. Een output die vijfennegentig keer op honderd klopt, klinkt uitstekend en is een gebroken flow in één run op twintig. Bij driehonderd mails per week zijn dat vijftien runs waarin de volgende stap iets krijgt waar ze niets mee kan. De actie hoeft niet perfect te zijn. De flow moet een plaats hebben voor de run waarin ze dat niet was: een tak voor het antwoord dat niet parseert, voor een waarde buiten de toegelaten lijst, voor een verplicht veld dat leeg binnenkomt. Het denkwerk zit in de vraag waar die wachtrij staat en wie ze voor vrijdag nakijkt.

Een bewaarde promptactie testen

De testknop in een prompt builder bewijst dat de prompt draait. Ze zegt niets over de vraag of ze vaak genoeg juist zit om ze zonder toezicht te laten draaien. Dat weet je pas met een kleine reeks gekende inputs en het verwachte antwoord ernaast: dertig tot honderd echte mails, elk met hun juiste categorie en referentie, in een bestand dat bij de actie hoort. Draai de actie over die reeks, tel de treffers, en je hebt een cijfer om de volgende keer mee te vergelijken. Dat is een evalset, en op deze schaal is het een spreadsheet en een namiddag.

Draai ze opnieuw als je de instructie aanpast, als je van model wisselt, en als het model verandert zonder dat je erom gevraagd hebt. Dat laatste geval wordt het vaakst gemist. In de modellijst van prompt builder schrijft Microsoft het zelf: het standaardmodel wordt periodiek geüpgraded zodra er nieuwe, capabelere modellen algemeen beschikbaar worden. Je prompt is niet veranderd, je flow is niet veranderd, en je resultaten kunnen toch verschuiven. Pin het model vast op alles wat ertoe doet, en behandel een upgrade als een wijziging die evenveel bewijs vraagt als een aanpassing van de tekst.

Promptacties een naam en een eigenaar geven

De meeste kleine bedrijven hebben er nooit vijftig nodig. Kijk naar wat een bedrijf van twintig mensen echt automatiseert met AI en je komt op drie of vier uit: sorteren wat binnenkomt, de velden uit een document halen, een eerste antwoord opstellen in de huistoon, en een lange conversatie samenvatten voor wie moet beslissen. De rest blijkt een variant te zijn, en een variant is meestal één extra toegelaten waarde.

Net dat kleine aantal is het argument om ze als bedrijfsmiddelen te behandelen in plaats van als persoonlijke trucjes. Elke actie krijgt een naam, één regel over wat ze beslist, een eigenaar met naam in de afdeling die met het resultaat leeft, en haar testset. Finance is eigenaar van de factuurextractie, niet degene die toevallig de flow gebouwd heeft. Verandert een leverancier zijn factuurlayout, dan is die eigenaar de persoon die het merkt. De geschiedenis van die aanpassingen bijhouden is een discipline op zich, en daar hoort promptversiebeheer thuis: waarop elke versie getest is, op welk model ze draaide, en hoe je de vorige terugzet.