Philip

Laatste bericht

Hi Philip,

Mooi dat je doorpakt, direct de juiste vragen. Hieronder mijn antwoorden per punt.

1. Concrete ervaring Dify/Flowise

Eerlijk: ik heb geen publiek live productie-agent in Dify of Flowise draaien. Wel prototypes in beide om hun sterke punten te leren — Dify voor RAG + workflows + multi-tenant, Flowise voor LangChain visual chains. Mijn productie-werk met agentic AI zit tot nu toe vooral in native implementaties: direct met de Anthropic en OpenAI SDK's, tool use, function calling, MCP-servers, en RAG-pipelines in Python en Next.js. De onderliggende concepten (memory, tool use, retrieval, prompt-chaining) zijn hetzelfde; Dify en Flowise zijn de visuele lagen eroverheen. Ik werk er graag mee juist omdat ze het tempo van iteratie vergroten — wat past bij wat jullie willen (POC + per klant fine-tunen).

2. Concrete agents die ik gemaakt heb

- WhatsApp reserveringsagent voor een restaurant: ontvangt natuurlijke taal ("kunnen we zaterdag rond 8 met 4 personen?"), checkt beschikbaarheid, bevestigt of stelt alternatief voor.
- Email-naar-menu automatisering: leest binnenkomende mails met dagaanbiedingen, extraheert producten en prijzen, update de site.
- Acquisitie-pipeline voor mijn eigen bureau: classificeert binnenkomende freelance-opdrachten, scoort op fit, genereert concept-reacties in mijn stijl. Daardoor kon ik, (of mijn agent) ook zo snel en uitgebreid reageren ;).
- Review-aggregator: orkestreert calls naar Google Places, Airbnb en Booking, geeft één gestructureerde JSON-output terug.

3. Publieke URL

Geen van deze is een publiek aan te roepen agent — het zijn interne workflows of klantsystemen. Wat ik wel kan doen: een korte POC voor jullie use case bouwen in Dify, publiek toegankelijk, en exact de case hieronder correct laten oplossen. Dan hebben jullie iets concreets om te beoordelen.

4. De case — volgens mij de kernvraag

Het foute "antwoord C" komt door drie dingen die los vaak goed gaan maar samen falen:

a) Geen conversation state. De agent "vergeet" dat de gebruiker al cursus X heeft gekozen. Wat eerder is vastgesteld (X = 2 dagen, geen examen) moet als gestructureerde sessievariabele bewaard blijven, niet alleen als chat-history-blob. In Dify doe je dat met conversation variables, in Flowise met buffer/state memory.

b) Geen parametrische retrieval. De agent haalt het complete annuleringsbeleid op als één tekstblok en dumpt dat. Beter: een tool get_cancellation_policy(course_id) die alleen relevante regels teruggeeft. Dan bestáát regel C niet eens in het antwoord omdat de cursus geen examen heeft.

c) Geen metadata-filtering op RAG-chunks. Als je het beleid via RAG ophaalt, moeten de chunks tags hebben (geldt_voor: "heeft_examen", geldt_voor: "alle") en filter je op cursus-attributen vóór retrieval — niet erna in de prompt.

De robuuste oplossing combineert die drie: chosen_course als conversation variable, tool call met die parameters, tool retourneert alleen wat van toepassing is, agent formuleert antwoord. Daar hoort ook een eval-set bij: een set scripted gesprekken (waaronder precies deze case) die bij elke wijziging automatisch draait, zodat regressies vóór deploy worden gevonden. Dit laatste is precies waar de meeste Dify/Flowise-builds tekortschieten — mensen bouwen demo's, niet eval-harnessen.

Voor de POC: dit is exact het soort case waar ik het verschil tussen "demo werkt" en "productie werkt" wil laten zien. Ik bouw graag een korte POC met dummy cursus-data (of jullie eigen data) waarin ik deze flow correct afhandel, inclusief de eval-set. Op uurbasis of vaste prijs voor de POC, wat jullie het prettigst vindt.

Fijne avond,
Wesley