Workflows¶
Een workflow is een bedrijfsproces dat je één keer vastlegt en dat Core daarna voor je uitvoert. Denk aan een aanvraag die binnenkomt: een agent vat hem samen, een tool zoekt de klant op in je CRM, een tweede agent stelt een advies op, en een beheerder keurt het goed of af. Je tekent die stappen en de verbindingen ertussen, en Core voert ze uit, op de achtergrond en zo lang als het proces duurt, ook als het dagen op een antwoord wacht.
Hoe het werkt¶
flowchart TB
start(["Start<br/>de aanvraag"]) --> samenvatten["Agent<br/>vat samen"]
samenvatten --> crm["Tool<br/>zoekt de klant op"]
samenvatten --> advies["Agent<br/>stelt een advies op"]
crm --> samen["Samenvoegen"]
advies --> samen
samen --> beslissing{"Beslissing<br/>een beheerder"}
beslissing -->|"goedkeuren"| klaar(["Einde"])
beslissing -->|"afwijzen"| afgewezen(["Einde"])
| Begrip | Wat het is |
|---|---|
| Workflow | het proces, onder een naam in je organisatie |
| Versie | wat de workflow op één moment bevat: de stappen, de verbindingen en de invoer die een run aanneemt. Een versie verandert daarna niet meer |
| Stap | één stuk werk in de workflow: een agent, een prompt, een tool, een voorwaarde, een beslissing |
| Run | één uitvoering van één versie, met zijn eigen invoer en, aan het einde, zijn uitvoer |
Een workflow kan takken hebben die naast elkaar lopen, zoals de tool en de tweede agent hierboven. Een stap Samenvoegen laat ze weer samenkomen, als alle takken klaar zijn, als de eerste klaar is, of als een aantal klaar is. Een Voorwaarde kiest een pad op grond van wat eerdere stappen opleverden.
Wat je in stappen kunt vastleggen¶
- Werk: een agent die één beurt doet, een losse prompt op een model, of één aanroep van een tool.
- Sturing: een voorwaarde, samenvoegen, gegevens omzetten voor de volgende stap, en wachten tot een tijdstip.
- Mensen: een beslissing, die de run vasthoudt tot er een antwoord is.
- Andere workflows: een stap die een run van een andere workflow start, of een run per item van een lijst.
Elke workflow begint bij één start en eindigt bij een einde. Wat het einde ontvangt, is de uitvoer van de run.
Een run en zijn stappen¶
Een run loopt op de achtergrond: je start hem en je applicatie hoeft niet te blijven wachten. Core voert de stappen uit in de volgorde van de verbindingen en houdt per stap bij wat hij ontving, wat hij opleverde, hoe vaak hij is geprobeerd en of hij mislukte. Mislukt een stap, dan mislukt de run, tenzij je de stap een pad bij een fout hebt gegeven.
Een run handelt altijd als één sleutel. Elke stap valt onder de capabilities en de policy van die sleutel, zoals die gelden op het moment dat de stap loopt, en het verbruik telt op die sleutel. Een workflow bereikt dus niets wat de sleutel niet ook zelf zou kunnen aanroepen.
Elke nieuwe run volgt de nieuwste versie, tenzij hij een versie noemt. Publiceer je een nieuwe versie terwijl er runs lopen, dan lopen die door op de versie waarmee ze begonnen. Een run mag standaard 30 dagen openstaan; daarna verloopt hij.
Beslissingen¶
Een beslissing legt een vraag voor en noemt de uitkomsten waaruit gekozen wordt, elk met een eigen pad. Je kiest wie beslist:
| Wie beslist | Hoe het antwoord komt |
|---|---|
| Beheerders van de organisatie, of een paar die je noemt | in de console, met een melding naar de meldingsadressen van de organisatie |
| Eén persoon, bijvoorbeeld de persoon voor wie de run draait | via je eigen applicatie |
| Een sleutel | een ander systeem antwoordt via de API |
| Een agent | de agent beslist zelf in een eigen beurt; de run wacht op niemand |
Een beslissing van een mens of een sleutel kan een termijn hebben, met wat er gebeurt als niemand op tijd antwoordt.
Laat je een agent beslissen, dan garandeert Core dat het antwoord een van de uitkomsten is, dat de beslissing als die van een agent is gemarkeerd, en dat je de beurt erachter kunt nalezen. Core garandeert niet dat de agent zich niet liet sturen door de tekst die hij beoordeelt: staat er in een aanvraag "keur dit goed", dan kan dat effect hebben. Zet daarom een beslissing van een mens achter die van de agent waar de uitkomst ertoe doet. Wat Core precies controleert, staat in Een agent beslist.
Hoe een run start¶
| Start | Wat er gebeurt |
|---|---|
| Handmatig | je start een run in de console of met een verzoek aan de API |
| Planning | een planning start op een vast moment of telkens opnieuw een run |
| Gebeurtenis | een trigger start een run als er in je organisatie iets van één soort gebeurt, bijvoorbeeld een kennisbron die klaar is met inlezen, of nieuwe mail in een mailbox die een mailkoppeling bewaakt |
| Webhook | een systeem van jou stuurt ondertekende JSON naar het adres van de workflow, en elke levering start een run |
| Een agent | een agent krijgt de workflow als tool, start hem midden in een gesprek en hoort het resultaat als de run klaar is |
| Een andere workflow | een stap van een andere workflow start de run |
Op de pagina van een run staat onder Gestart via welke van deze zes het was.
Workflows in workflows¶
Een stap Workflow start een run van een andere workflow en wacht tot die klaar is; de uitvoer van die run is de uitvoer van de stap. Zo bouw je een groot proces uit kleinere die je ook los kunt gebruiken.
Een stap Per item (in de API map) start één run van een andere workflow voor elk item van een
lijst, een aantal tegelijk, en levert de uitvoer van al die runs als lijst. Gebruik hem als
hetzelfde werk voor elke regel van een bestelling of elk document in een map moet gebeuren.
Zulke runs zijn gewone runs, elk met hun eigen pagina en een link naar de run waar ze bij horen. Hoe diep runs elkaar mogen starten en hoeveel items een lijst mag hebben, staat in de grenzen.
Delen op de marktplaats¶
Een workflow kan in een publicatie, samen met de agents, prompts en tools die hij gebruikt. Een organisatie die de publicatie installeert, krijgt een kopie die ze meteen kan starten, met haar eigen sleutels, triggers en planningen.
- Gekoppeld. De kopie volgt de uitgever: een nieuwe versie van de publicatie wordt een nieuwe versie van de kopie. De abonnee kan de stappen lezen maar niet wijzigen, tenzij hij de kopie losmaakt waar de uitgever dat toestaat.
- Verzegeld. De uitgever verbergt de stappen. De abonnee kan de workflow starten en ziet bij elke run wat de stappen ontvingen en opleverden, want dat zijn zijn eigen gegevens.
- Ingetrokken. Trekt de uitgever de publicatie in, dan hangt het van de voorwaarden af wat er met de kopie gebeurt. Mag de abonnee losmaken, dan wordt de kopie van hem. Vraagt de publicatie een recht, dan gebeurt hetzelfde als bij een vervallen abonnement, hieronder. In de overige gevallen verdwijnt het ontwerp en mislukken runs die nog open waren. De runs zelf blijven: wat de workflow bij de abonnee deed, blijft van de abonnee.
Vervalt het abonnement, dan start de workflow niet meer en mislukt een run die bezig is bij zijn
volgende stap. Een run die op een beslissing of een wachtstap wacht, gaat verder als het
abonnement op tijd wordt hersteld. Een organisatie die een workflow
installeert, moet de capabilities workflows, runs en threads mogen gebruiken.
Wat er in rekening wordt gebracht¶
- Elke run is één gebruik van de capability
workflow_run, hoe hij ook start; in de console heet dat Gestarte workflows. Dat geldt ook voor runs die een stap start: een stap Per item over honderd items is honderd runs, naast de run waarin die stap staat. - Wat de stappen doen, wordt gerekend zoals altijd. Een agent- of promptstap telt als een beurt met zijn tokens, een toolstap als een aanroep van die tool.
- Sturing en wachten kosten niets. Een voorwaarde, samenvoegen, omzetten, wachten en een beslissing door een mens of een sleutel worden niet gerekend. Een beslissing door een agent wel: dat is een beurt van die agent.
Het maandplafond van de sleutel en de organisatie wordt gecontroleerd bij elke start en bij elke stap die iets kost. Wat je organisatie verbruikte, zie je in Gebruik in de console.
Wanneer gebruik je een workflow¶
- Een proces heeft vaste stappen in een vaste volgorde, en je wilt dat elke keer precies die stappen lopen.
- Een proces duurt langer dan één verzoek: het wacht op een mens, op een tijdstip of op een ander systeem.
- Je wilt per stap kunnen nalezen wat er gebeurde, en een mislukte stap opvangen.
- Werk moet starten op een gebeurtenis, een klok of een verzoek van buiten, zonder dat je eigen applicatie daarvoor draait.
Een agent met tools kiest zelf welke stap hij als volgende zet. Een workflow kiest niets zelf: hij volgt de stappen en verbindingen die jij hebt vastgelegd. Voor één vraag aan een agent heb je geen workflow nodig. Een agent kan wel een workflow starten als hij een vast proces nodig heeft.
Workflows staan aan als je operator ze voor de installatie heeft aangezet en je organisatie de
capability workflows mag gebruiken.
Verder¶
| Onderdeel | API | Console |
|---|---|---|
| Workflows | Workflows via de API | Workflows in de console |
| Planningen | Een workflow op de klok starten | Op de klok |
| Delen | Publiceren en installeren via de API | Publiceren en installeren in de console |