U hoeft geen workflow-instructie vanaf een leeg blad te schrijven. Begin met het uitvoeren van een echte taak samen met uw agent. Zodra het resultaat bruikbaar is, vraagt u de agent om de samen ontwikkelde methode om te zetten in een herbruikbare workflow.
De agent maakt de eerste versie. Uw rol is om de aannames te beoordelen en te bepalen waar de workflow duidelijkere grenzen nodig heeft, zodat een andere collega een betrouwbaar resultaat kan behalen.
Elke workflow hoort bij één agent. De agent levert de bredere rol en mogelijkheden; de workflow legt de procedure en beperkingen vast voor één herhaalbare taak.
Begin met een geslaagde run
Een workflow is eenvoudiger te maken nadat de agent de taak, het bronmateriaal, uw feedback en een acceptabel resultaat heeft gezien.
- Geef de agent een echte taak en de daadwerkelijke input die nodig is.
- Beoordeel het resultaat en corrigeer ontbrekende context, zwakke redenering of het verkeerde formaat.
- Wanneer het resultaat goed is, vraag de agent om de herhaalbare methode te extraheren.
- Laat de agent de workflownaam, beschrijving, instructie en eventuele aanbevolen referentiebestanden opstellen.
- Beoordeel samen het concept voordat u de workflow openbaar maakt.
U kunt vragen:
Zet wat we zojuist hebben gedaan om in een herbruikbare workflow voor het team. Stel de naam, beschrijving en instructie op. Scheid de herbruikbare methode van details die alleen op dit geval van toepassing zijn. Voordat we het afronden, som de aannames en beperkingen op die ik moet beoordelen.
Dit geeft de agent de taak om een concept te maken. U beslist welke onderdelen gecontroleerd moeten worden.
Instructie is een veelgebruikte plek voor beperkingen
De workflow-instructie reist mee met de workflow en geldt elke keer dat deze wordt uitgevoerd. Dit maakt het een van de meest voorkomende plekken om beperkingen te definiëren, zoals verplichte input, goedgekeurde bronnen, outputformaat, kwaliteitsnormen en acties die bevestiging vereisen.
Het is niet de enige controlerende laag:
| Laag | Wat wordt beperkt | Voorbeeld |
|---|---|---|
| Beschrijving | Wanneer de workflow geselecteerd moet worden | Gebruik voor nieuwe inkomende leads die onderzoek en kwalificatie nodig hebben; niet gebruiken voor bestaande kansen. |
| Instructie | Hoe de taak uitgevoerd moet worden | Controleer eerst het CRM, citeer openbare claims, volg de ICP-richtlijn en maak een concept in plaats van direct te verzenden. |
| Bestanden | De stabiele referenties die de methode moet volgen | ICP-richtlijn, goedgekeurde voorbeelden, rapporttemplate, productwoordenlijst |
| Agentmachtigingen | Welke externe acties de agent daadwerkelijk mag uitvoeren | CRM-gegevens lezen, e-mailconcept maken, maar geen e-mail verzenden |
| Run-verzoek | De input en scope voor dit specifieke geval | Kwalificeer deze lead, gebruik dit CRM-record en geef het resultaat terug in deze chat. |
| Automatisering | Wanneer de workflow draait en wie de run beheert | Draai elke werkdag om 09:00 en plaats het resultaat in een benoemd kanaal. |
Vertrouw niet alleen op de instructietekst als vervanging voor toegangscontrole. Als een actie technisch beperkt moet worden, gebruik dan agentautorisatie en machtigingen naast een duidelijke instructie.
Beoordeel het eerste concept van de agent
U hoeft niet elke zin te herschrijven. Richt uw beoordeling op de beslissingen die belangrijk zijn voor het team.
Wanneer moet het gebruikt worden?
- Welke aanvraag of situatie moet deze workflow selecteren?
- Wanneer mag de agent het niet gebruiken?
- Is de beschrijving specifiek genoeg om het te onderscheiden van vergelijkbare workflows?
Welke input is vereist?
- Wat moet een collega aanleveren voordat het werk begint?
- Welke ontbrekende input moet de agent aanleiding geven om een vraag te stellen?
- Welke details horen bij elke run in plaats van bij de permanente instructie?
Welke bronnen en regels zijn leidend?
- Wat is het bronsysteem?
- Welk bijgevoegd bestand bevat de goedgekeurde richtlijn of template?
- Als twee bronnen conflicteren, welke heeft dan voorrang?
- Hoe moet de agent feiten labelen die niet te verifiëren zijn?
Hoe moet de output eruitzien?
- Welke secties of velden zijn verplicht?
- Welk detailniveau is nuttig?
- Heeft de output bronvermeldingen, links of een vertrouwenslabel nodig?
- Waar moet het resultaat naartoe als er een bestemming is opgegeven?
Waar moet de agent stoppen?
- Welke acties vereisen bevestiging?
- Moet de agent een concept maken in plaats van direct te verzenden of publiceren?
- Welke gegevens mogen niet voorkomen in een openbare workflow of gedeeld resultaat?
Dit zijn de beperkingen die expliciet gemaakt moeten worden. Laat de agent de formulering verzorgen en controleer vervolgens of deze uw beslissing correct weergeeft.
Een structuur om samen te beoordelen
De agent kan de volgende structuur gebruiken voor het eerste concept. Zie het als een beoordelingskader, niet als een formulier dat u zelf moet invullen:
# Goal
State the single outcome this workflow must produce.
# Use this workflow when
Describe when to use it and any important exclusions.
# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.
# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.
# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.
# Output
Define the required sections, fields, format, and destination.
# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.
# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.
Een eenvoudige workflow heeft misschien maar een paar secties nodig. Een workflow met grote impact vraagt om explicietere bron-, validatie- en goedkeuringsregels. Vraag de agent om de instructie zo kort mogelijk te houden zonder beslissingen te verbergen waar het team op vertrouwt.
Voorbeeld: samen een leadkwalificatie-workflow maken
Stel, u vraagt de agent om één inkomende lead te onderzoeken en een antwoord op te stellen. Tijdens de run corrigeert u de bedrijfsgrootte, legt u uit dat het CRM het bronsysteem is, past u de ICP-richtlijn van het team toe en vraagt u om een kortere e-mail.
Na goedkeuring van het resultaat vraagt u de agent om het gesprek om te zetten in een workflow. De agent stelt de procedure op. U voegt vervolgens de beperkingen toe die ook na deze lead moeten blijven gelden:
- controleer het CRM voordat u openbaar onderzoek doet;
- gebruik de bijgevoegde ICP-richtlijn voor scoring;
- vermeld bronnen voor bedrijfsgrootte, locatie en huidige functie;
- label een niet-geverifieerd verplicht feit als Onbekend;
- geef Accountoverzicht, Bewijs, ICP-score, Risico's, Aanbevolen volgende stap en Antwoordconcept terug;
- maak een e-mailconcept en verzend deze nooit zonder bevestiging.
De agent kan deze beslissingen nu verwerken in de instructie. U hoeft niet elke onderzoekstap voor te schrijven. U moet de bronnen van het team, het outputcontract en de goedkeuringsgrens ondubbelzinnig maken.
Geef feedback op beperkingen in gewone taal
U kunt het concept aanscherpen door de agent te vertellen wat er moet veranderen:
- “Vraag om het CRM-record voordat je begint als het ontbreekt.”
- “Behandel het CRM als het bronsysteem wanneer bedrijfsnamen conflicteren.”
- “Elke feitelijke claim in het overzicht heeft een bronlink nodig.”
- “Houd het antwoord onder 150 woorden, maar pas de toon aan op het inkomende bericht.”
- “Maak de e-mail als concept. Verstuur deze nooit automatisch.”
- “Deze workflow mag niet draaien voor bestaande kansen.”
Vraag de agent om de workflow bij te werken en samen te vatten welke beperking elke wijziging adresseert. Zo is het eenvoudiger om een verkeerd begrepen regel of een fout geplaatste sectie te herkennen.
Houd de juiste zaken buiten de instructie
Sommige informatie hoort niet in de permanente workflowtekst:
- klantnamen, eenmalige deadlines en case-specifieke bestemmingen horen in het run-verzoek;
- wachtwoorden, tokens en privé-gegevens horen niet in een instructie of bijgevoegd bestand;
- planningen en gebeurtenissen horen bij een automatisering;
- technische toegangsgrenzen horen bij agentautorisatie en machtigingen;
- persoonlijke feedback die alleen op één resultaat slaat, kan in die chat blijven.
De instructie moet de herbruikbare methode en gedragsbeperkingen bevatten, niet elk detail rondom het werk.
Test en verbeter samen
Voer de workflow uit met minstens twee realistische inputs, bij voorkeur met een tweede collega. Vraag na elke run:
- Activeerde de workflow voor de juiste taak?
- Vroeg het om de benodigde input?
- Volgde het de bedoelde bronprioriteit?
- Was de output consistent zonder star te worden?
- Stopte het bij de vereiste goedkeuringsgrens?
- Is het probleem herhaalbaar, of geldt het alleen voor dit geval?
Vraag de agent om de instructie aan te passen voor herhaalbare hiaten. Houd eenmalige correcties in de run. Wanneer de methode werkt voor iemand anders dan de oorspronkelijke maker, deel de workflow met uw team.

