Track-and-trace agent stack: hoe een Nederlandse 3PL kiest

Het is vrijdag 16:47 in Veghel. Het klantenserviceteam van een Nederlandse 3PL met minder dan €20M omzet heeft 312 onbeantwoorde e-mails openstaan, de meeste van drie woorden: waar is mijn pakket. De planner neemt de telefoon niet meer op, want elk gesprek gaat over dezelfde vraag. De operations lead heeft een Slack-DM van de CEO die in zijn geheel zegt: "kunnen we hier niet gewoon een bot op zetten." Maandag willen ze weten op welke stack ze het bouwen. Niet welke in theorie het beste is. Welke voor hen het beste is.

Dit is de methode waarmee wij ze in één middag een antwoord geven. Hij scoort op drie punten: per-zending-kosten bij hun echte volume, AVG-verdedigbare logging, en wie wie belt om 03:00 als DHL Parcel een SOAP-endpoint roteert.

De drie stacks die op tafel liggen

Voor een Nederlandse logistieke mkb'er onder €20M met 12.000 tot 25.000 wekelijkse statusvragen zijn er drie realistische opties. We zetten ze neer zoals ze meestal gepitcht worden, niet zoals ze presteren.

Vercel AI SDK op Postgres

Eén Next.js-app, de Vercel AI SDK voor de modelcalls, één Postgres-rij per zending, een webhook vanuit het FMS. Gehost op Vercel, deploy bij elke git push. De default voor elk team dat de afgelopen drie jaar een website heeft opgeleverd.

Self-hosted Dify met Qdrant

Dify orkestreert de agent, Qdrant slaat embeddings van de standaardantwoorden op, alles draait in een docker compose op een Hetzner-bak in Falkenstein. Geen vendor lock-in. Twee senior engineers, een onderhoudsbudget en af en toe een zondagavond aan die bak.

Custom Claude Agent SDK gekoppeld aan Transics

Een speciaal gebouwde agent op de Claude Agent SDK, die direct praat met het Transics FMS, met een dunne SOAP-bridge naar DHL Parcel en PostNL voor de overdracht naar de vervoerders. Draait op de bestaande infra van de klant. Leest het FMS bijna realtime uit. Twee weken bouwen, daarna een doorlopend retainer.

De drie dingen die het werkelijk beslissen

Elke stack werkt technisch. Het is technisch ook niet de vraag. We scoren in plaats daarvan op drie meetbare regels.

Per-zending-kosten bij 18.000 wekelijkse statusvragen

De vendorpitch is per bericht of per seat. De realiteit is per zending: hoeveel euro kosten de klantvragen rond één zending je, opgeteld over modelcalls, hosting, retrieval en de engineertijd om het draaiend te houden. Een statusvraag triggert meestal twee tot vier modelturns, zodra je vervolgvragen en vervoerderlookups meerekent. Bij 18.000 wekelijkse statusvragen zit je tussen de 60.000 en 75.000 modelturns per week. Cijfers in de miljoenen per kwartaal klinken kleiner dan ze zijn. De gepubliceerde API-tarieven van Anthropic geven je een concreet plafond. De echte kosten landen op twee tot drie keer de pure modelspend zodra retrieval, logs en menselijke review erbij komen.

AVG-verdedigbare logging

De Autoriteit Persoonsgegevens heeft geen mening over je stack. Wel over de vraag of je op verzoek kunt aantonen wie welke adresgegevens hoe lang gezien heeft, en of de modelprovider op dat moment een verwerkersovereenkomst had. De richtlijn van de AP over verwerking in de cloud is het document waar elke 3PL-FG je naar terug zal verwijzen. De vraag die je scoort is niet "is deze stack veilig". Het is of je operations lead binnen vijf werkdagen, zonder hulp van een leverancier, de volledige gespreksgeschiedenis van een klant kan ophalen, met namen van iedereen die geantwoord heeft en een lijst van welke data de EU verlaten heeft.

Wie patcht de SOAP-bridge om 03:00

Dit punt beslist meer deployments dan welke benchmark dan ook. DHL Parcel roteert zijn tracking-endpoint ongeveer twee keer per jaar, meestal 's nachts op zondag, met de deprecation-melding ergens diep in een portaal waar niemand in jouw team een login voor heeft. PostNL doet hetzelfde op zijn eigen ritme. De vraag is niet of je stack SOAP ondersteunt. De vraag is wiens telefoon gaat als de bridge om 03:14 op maandagochtend 503's begint terug te geven en de operations lead wakker wordt met 800 boze tracking-mails.

Hoe de drie stacks scoren

Haal dezelfde klantbriefing door alle drie de lenzen en het beeld wordt scherp.

Vercel AI SDK op Postgres wint op dag-één-kosten. Eén engineer levert de MVP op binnen een week. De hostingrekening is verwaarloosbaar bij dit volume. Hij valt om op de AVG-regel als het team niet apart een verwerkersovereenkomst met elke modelprovider heeft getekend, en dat hebben de meeste teams niet. Hij valt om op de SOAP-regel, want het telefoontje van 03:00 gaat naar de freelancer die hem gebouwd heeft, die misschien al niet meer voor je werkt.

Dify op Qdrant wint op datacontrole. Alles blijft op je Hetzner-bak. De AVG-regel is goed te verdedigen. De per-zending-kosten liggen hoger dan ze lijken, want twee senior engineers kosten op jaarbasis meer dan de hele Vercel-stack. De SOAP-regel komt bij diezelfde twee engineers terecht, die nu elke dependency in de compose-file op hun bordje hebben.

Een custom Claude Agent SDK-build die gekoppeld is aan het FMS wint op de SOAP-regel, want de on-call-rotatie is een regel in het retainer en de bridge staat op een bekende plek met een bekende eigenaar. De per-zending-kosten landen tussen de andere twee in. De AVG-regel is verdedigbaar als de build EU-modelrouting gebruikt en het loggingschema vanaf het begin is opgezet voor verwerkersovereenkomst-vragen, wat het hoort te zijn.

Het scoreblad dat we daadwerkelijk versturen

De versie die we de operations lead geven is één pagina. Drie rijen, drie kolommen, met een echt getal in elke cel. Geen sterrenrating. Een getal met een eenheid en een voetnoot die zegt waar het vandaan komt.

                     Vercel AI SDK   Dify + Qdrant   Custom Agent SDK
Per-zending (€)      0,04 tot 0,07   0,11 tot 0,18   0,06 tot 0,09
AVG-verdediging (d)  5 tot 10        1 tot 2         2 tot 3
SOAP on-call         eigen eng       eigen eng       retainer-regel

De getallen verschuiven per klant. De methode niet. Veranker elke cel in iets dat de operations lead voor de lunch kan verifiëren.

De HN-thread die je waarschijnlijk al gelezen hebt

De Hacker News-frontpage had deze week een Ask HN van 1.000 comments over het vervangen van Claude of GPT door een lokaal model voor dagelijks coderen. Nuttig om te lezen en tegelijk misleidend voor deze beslissing. Het eerlijke antwoord in de thread is dat lokale modellen dichtbij genoeg komen voor een IDE-assistent. Het eerlijke antwoord voor een klantgerichte logistieke chat agent is dat een statusvraag een veel kleiner foutenbudget heeft dan jouw editor, en dat de SOAP-rotaties aan de vervoerderkant niets te maken hebben met welk model je gekozen hebt. Voer de modeldiscussie als laatste. Kies eerst de on-call en het AVG-schema.

Wat dit je oplevert op maandagochtend

De reden dat we de scoring op één pagina doen, is dat de operations lead ermee een maandag-standup in moet, waar de CEO één vraag stelt: "kunnen we het gewoon doen." Met die pagina kan hij antwoorden: "ja, op deze stack, om deze reden, en hier is wie om 03:00 de telefoon opneemt." Alles wat langer is, gaat opnieuw ter discussie.

Toen wij vorige winter de track-and-trace-agent bouwden voor een Brabantse 3PL was de modelkeuze het makkelijke stuk: de bestaande SOAP-bridge naar DHL Parcel had drie verschillende timeoutwaarden verspreid over drie services en geen duidelijke eigenaar, dus de eerste endpoint-rotatie haalde de agent zes uur uit de lucht. We hebben de bridge herbouwd als één service met één timeout en één on-call engineer. Dat is het soort werk dat we leveren als we AI-agents bouwen voor Nederlandse operations-teams.

Het kleinste wat je vandaag kunt doen: open een gedeeld document, schrijf de drie scoringregels van hierboven op en probeer de derde kolom in te vullen voor je eigen volume. Als je voor de lunch geen echt eurobedrag in de per-zending-cel kunt zetten, weet je nog niet genoeg over je eigen verkeer om een stack te kiezen.