# The Automation Group — volledige site-inhoud (llms-full.txt) Nederlands Agentic AI-consultancybureau in Utrecht. Wij bouwen het AI Operating System van organisaties: AI Tools voor mensen en AI Agents voor processen. Contact: info@ai.nl · +31 30 207 2932 · https://theautomationgroup.nl Gegenereerd: 2026-09-16 ## The Automation Group | Agentic AI bureau Nederland Source: https://theautomationgroup.nl/nl Agentic AI bureau uit Nederland dat AI agents, automatisering en LLM-integraties bouwt voor enterprises. Van strategie tot productie met 10x Engineers. ## Diensten: AI-adoptie, AI Champions & Agents | TAG Source: https://theautomationgroup.nl/nl/diensten Pragmatische partner voor AI-adoptie en implementatie: AI Champion-programma's, AI Champion Leads, agents in je bestaande systemen en Copilot, plus low-code en high-code engineering. ## Diensten: AI-adoptie, AI Champions & Agents | TAG Source: https://theautomationgroup.nl/nl/diensten/flex-strippenkaart Pragmatische partner voor AI-adoptie en implementatie: AI Champion-programma's, AI Champion Leads, agents in je bestaande systemen en Copilot, plus low-code en high-code engineering. ## Diensten: AI-adoptie, AI Champions & Agents | TAG Source: https://theautomationgroup.nl/nl/diensten/deta-light Pragmatische partner voor AI-adoptie en implementatie: AI Champion-programma's, AI Champion Leads, agents in je bestaande systemen en Copilot, plus low-code en high-code engineering. ## Diensten: AI-adoptie, AI Champions & Agents | TAG Source: https://theautomationgroup.nl/nl/diensten/deta-vast Pragmatische partner voor AI-adoptie en implementatie: AI Champion-programma's, AI Champion Leads, agents in je bestaande systemen en Copilot, plus low-code en high-code engineering. ## Diensten: AI-adoptie, AI Champions & Agents | TAG Source: https://theautomationgroup.nl/nl/diensten/moonshots Pragmatische partner voor AI-adoptie en implementatie: AI Champion-programma's, AI Champion Leads, agents in je bestaande systemen en Copilot, plus low-code en high-code engineering. ## Cases — Agentic AI projecten | The Automation Group Source: https://theautomationgroup.nl/nl/cases Bekijk Agentic AI cases bij ANWB, AFAS, InShared, Wolters Kluwer en meer. Concrete AI agents en automatiseringen die meetbare waarde leveren in productie. ## Over ons — boutique Agentic AI studio | TAG Source: https://theautomationgroup.nl/nl/over-ons The Automation Group is een boutique Agentic AI studio en zusterbedrijf van AI.nl. Klein team van Agentic Consultants dat AI bouwt die echt in productie draait. ## Vacatures Agentic Consultant & AI Consultant | TAG Source: https://theautomationgroup.nl/nl/vacatures Werken bij The Automation Group: bouw Agentic AI-systemen voor toonaangevende Nederlandse organisaties. Bekijk vacatures voor Agentic Consultants en AI Consultants. ## OpenClaw — on-premise AI agents op Mac Mini | TAG Source: https://theautomationgroup.nl/nl/openclaw OpenClaw is onze on-premise Agentic AI setup op Mac Mini: subagents, MCP-koppelingen en multi-agent architectuur. Volledige dataprivacy, geen cloud nodig. ## Vibecoding vs Agentic Consultanting — uitleg | TAG Source: https://theautomationgroup.nl/nl/vibecoding Wat is het verschil tussen vibecoding en Agentic Consultanting? Waar vibecoding ophoudt en waarom productiekwaliteit echte consultants vraagt. Uitgelegd door TAG. ## Contact — plan een Agentic AI gesprek | TAG Source: https://theautomationgroup.nl/nl/contact Plan een vrijblijvend gesprek met The Automation Group over AI agents, automatisering of een AI-strategie voor jouw organisatie. We denken graag mee. ## Training: Training n8n Source: https://theautomationgroup.nl/nl/trainingen/n8n Workflow-automatisering die productie haalt n8n is de open-source backbone van moderne automation-stacks. In één dag leer je hoe je workflows ontwerpt die niet alleen werken op je laptop, maar ook overleven in productie: met versiebeheer, error-handling, observability en de juiste deploymentkeuze. Wat je leert: Workflow-architectuur: triggers, nodes, sub-workflows en wanneer je wat kiest; Foutafhandeling met error workflows, retries en dead-letter queues; Queue mode, scaling en het verschil tussen self-hosted en n8n Cloud; Eigen credentials en secrets management zonder leaks in logs; Custom nodes en code-nodes in TypeScript voor wat de standaard nodes niet kunnen; Integraties met OpenAI, Anthropic en eigen MCP-servers voor AI-stappen; Versiebeheer via Git en deploy-pipelines naar staging en productie Voor wie: Developers en automation consultants die n8n productieklaar willen inzetten; Operations- en RevOps-teams die handmatige processen willen schrappen; Consultants en agencies die n8n leveren aan eindklanten Programma: 09:30 Fundamenten — Triggers, nodes, expressies en data-modellen. Het mentale model dat de rest van de dag draagt. | 11:00 Productie-patronen — Sub-workflows, error workflows, retries, idempotency en logging. | 13:00 Schaal en deployment — Queue mode, workers, Docker, Kubernetes en n8n Cloud naast elkaar gelegd. | 14:30 AI en custom nodes — LLM-stappen, vector search, eigen code-nodes en MCP-integraties. | 16:00 Build sprint — Eigen use case bouwen onder begeleiding, inclusief code review. Resultaat: Een werkende productie-blueprint voor jullie eigen automatisering; Checklist voor security, observability en kostencontrole; Voorbeeldworkflows die je direct mag hergebruiken V: Is dit een beginnerstraining? A: Nee. We starten bij de fundamenten, maar het tempo ligt hoog en de tweede helft van de dag gaat over productie-onderwerpen die je niet in de docs vindt. V: Behandelen jullie ook self-hosted n8n? A: Ja. We laten de tradeoffs zien tussen n8n Cloud en self-hosted op Docker of Kubernetes, inclusief queue mode en worker-scaling. V: Wat kost de training? A: Tarief op aanvraag. We sturen graag een offerte op maat, inclusief lesmateriaal, opnames en 30 dagen async support na afloop. Voor in-company sessies geldt één tarief, ongeacht het aantal deelnemers tot 12 personen. V: Waar vindt de training plaats? A: Standaard bij ons in Utrecht of in-company op jullie eigen locatie. Volledig remote kan ook, dan splitsen we de dag in twee blokken van een halve dag. V: Krijg ik een certificaat? A: Ja. Na afloop ontvang je een deelnamebewijs met de behandelde onderwerpen en uren, bruikbaar voor PE-punten en interne registratie. ## Training: Training Claude Code Source: https://theautomationgroup.nl/nl/trainingen/claude-code Claude Code als collega in je terminal Claude Code is de sterkste CLI-coding agent op de markt, maar het verschil tussen amateur- en professioneel gebruik zit in de configuratie. In deze training leer je het volledige stack: CLAUDE.md, sub-agents, hooks, eval-suites en de guardrails die voorkomen dat je nachtelijke run een rekening van honderden euro's wordt. Wat je leert: Een CLAUDE.md schrijven die de agent dwingt jouw conventies te volgen; Sub-agents bouwen voor security review, migraties en compliance; Hooks en slash-commands voor herhaalbare workflows; Eval-suites opzetten met echte taken zodat je vooruitgang kunt meten; Sandboxing, allowlists en kostencontrole voor productieomgevingen; Multi-model patronen: Claude Code combineren met Codex of Gemini als reviewer; CI/CD-integratie zodat de agent in pipelines draait, niet alleen lokaal Voor wie: Engineering leads en senior developers die agentic coding willen invoeren; Platform- en DevEx-teams die guardrails moeten ontwerpen; CTO's die willen begrijpen wat haalbaar is en wat ruis is Programma: 09:30 Mentaal model — Wat Claude Code is, wat het niet is, en waarom het je workflow herstructureert. | 10:30 CLAUDE.md en sub-agents — Hands-on: een productiewaardige configuratie bouwen op je eigen repo. | 13:00 Evals en kwaliteit — Eval-pipelines op echte taken, regressies vangen voordat ze mergen. | 14:30 Security en kosten — Sandboxing, allowlists, token-budgetten en multi-model routing. | 16:00 CI/CD en delivery — Claude Code in GitHub Actions, review gates en delivery patterns. Resultaat: Een werkende CLAUDE.md en sub-agent set voor jouw codebase; Eval-pipeline die je morgen kunt uitbreiden; Beleid voor sandboxing, kosten en review gates V: Is dit hetzelfde als de Claude Cowork training? A: Nee. Claude Cowork richt zich op samenwerking en kennisdeling rond Claude in chat-context. Deze training gaat over de CLI-agent in code, repos en CI/CD. V: Mogen we onze eigen code gebruiken? A: Graag. We adviseren om je eigen repo mee te nemen zodat je aan het eind van de dag een werkende configuratie hebt voor je echte werk. V: Wat kost de training? A: Tarief op aanvraag. We sturen graag een offerte op maat, inclusief lesmateriaal, opnames en 30 dagen async support na afloop. Voor in-company sessies geldt één tarief, ongeacht het aantal deelnemers tot 12 personen. V: Waar vindt de training plaats? A: Standaard bij ons in Utrecht of in-company op jullie eigen locatie. Volledig remote kan ook, dan splitsen we de dag in twee blokken van een halve dag. V: Krijg ik een certificaat? A: Ja. Na afloop ontvang je een deelnamebewijs met de behandelde onderwerpen en uren, bruikbaar voor PE-punten en interne registratie. ## Training: Training Microsoft Copilot Studio Source: https://theautomationgroup.nl/nl/trainingen/copilot-studio Copilots bouwen in de Microsoft-stack Microsoft Copilot Studio brengt agentic AI naar het hart van M365 en Teams. Deze training laat zien hoe je copilots bouwt die echt iets doen: koppelingen met Dataverse, Graph API, SharePoint en custom connectors, met een governance-model dat IT en compliance niet wegjaagt. Wat je leert: Topics, flows en generative actions in Copilot Studio; Eigen knowledge koppelen via SharePoint, websites en Dataverse; Custom connectors en MCP-servers aansluiten; Authenticatie via Entra ID en wat dat betekent voor permissies; Publiceren in Microsoft 365, Teams en als web-chatbot; ALM, omgevingen en deploy-pipelines tussen dev, test en productie; Governance: DLP-policies, capacity en de rol van het Power Platform Admin Center Voor wie: Power Platform makers en M365 admins; Solution architects die copilots inrichten voor business teams; Citizen developers die verder willen dan een demo Programma: 09:30 Copilot Studio in context — Hoe Copilot Studio zich verhoudt tot Microsoft 365 Copilot, Power Automate en Azure AI Foundry. | 10:30 Bouwen — Topics, generative answers, autonome agents en het verschil dat ze maken. | 13:00 Knowledge en connectors — Dataverse, Graph API, custom connectors en MCP-servers. | 14:30 Governance — Entra-permissies, DLP, capacity en ALM tussen omgevingen. | 16:00 Publish en adoption — Uitrol via Teams en M365, plus de adoption-stappen die het verschil maken. Resultaat: Een werkende copilot voor een eigen use case; Governance-model voor uitrol over meerdere teams; Checklist voor security, licenties en capacity V: Is dit hetzelfde als Microsoft 365 Copilot? A: Nee. M365 Copilot is een eindgebruiker-product. Copilot Studio is de bouwomgeving waar je je eigen copilots in maakt en publiceert. V: Hebben deelnemers een eigen tenant nodig? A: Bij voorkeur wel. Anders werken we in onze demo-tenant, maar dan kun je niet alles publiceren naar je eigen omgeving. V: Wat kost de training? A: Tarief op aanvraag. We sturen graag een offerte op maat, inclusief lesmateriaal, opnames en 30 dagen async support na afloop. Voor in-company sessies geldt één tarief, ongeacht het aantal deelnemers tot 12 personen. V: Waar vindt de training plaats? A: Standaard bij ons in Utrecht of in-company op jullie eigen locatie. Volledig remote kan ook, dan splitsen we de dag in twee blokken van een halve dag. V: Krijg ik een certificaat? A: Ja. Na afloop ontvang je een deelnamebewijs met de behandelde onderwerpen en uren, bruikbaar voor PE-punten en interne registratie. ## Training: Training OpenAI Codex Source: https://theautomationgroup.nl/nl/trainingen/openai-codex Codex inzetten naast je IDE en in CI Codex is OpenAI's agentic coding-aanbod: een cloud-omgeving waar taken parallel draaien plus een CLI die in je terminal werkt. Deze training laat zien hoe je beide tools naast Claude Code en Cursor positioneert, en wanneer Codex de juiste keuze is. Wat je leert: Codex cloud en Codex CLI in vergelijking, met heldere keuzecriteria; Taken delegeren aan parallelle Codex-agents; AGENTS.md en projectinstructies die de output stuurbaar maken; Branch- en PR-strategie voor agent-werk in shared repos; Eval-pipelines en regressietests rond agent-output; Multi-model patronen: Codex naast Claude Code en Gemini; Kostencontrole en monitoring per organisatie Voor wie: Developers en tech leads in OpenAI-georiënteerde stacks; Teams die parallelle agent-werkstromen willen invoeren; Engineering managers die Codex tegen Claude Code afwegen Programma: 09:30 Codex landschap — Cloud versus CLI, ChatGPT-integratie, prijzen en concurrenten. | 10:30 AGENTS.md — Projectinstructies, conventies en sub-agent patronen voor Codex. | 13:00 Parallel werk — Meerdere agents tegelijk, branch-strategie en review gates. | 14:30 Evals en kosten — Regressietests, budget-monitoring en multi-model routing. | 16:00 CI-integratie — Codex inzetten in GitHub Actions en delivery pipelines. Resultaat: Een AGENTS.md en review-flow die werkt op je eigen repo; Concrete keuze tussen Codex, Claude Code of beide; Kostendashboard en budgetbeleid V: Hoe verhoudt Codex zich tot Claude Code? A: Codex blinkt uit in parallelle cloud-taken en ChatGPT-integratie. Claude Code is sterker in lokale shell-workflows. Deze training laat de tradeoffs in detail zien. V: Wat kost de training? A: Tarief op aanvraag. We sturen graag een offerte op maat, inclusief lesmateriaal, opnames en 30 dagen async support na afloop. Voor in-company sessies geldt één tarief, ongeacht het aantal deelnemers tot 12 personen. V: Waar vindt de training plaats? A: Standaard bij ons in Utrecht of in-company op jullie eigen locatie. Volledig remote kan ook, dan splitsen we de dag in twee blokken van een halve dag. V: Krijg ik een certificaat? A: Ja. Na afloop ontvang je een deelnamebewijs met de behandelde onderwerpen en uren, bruikbaar voor PE-punten en interne registratie. ## Training: Training AI Agents Source: https://theautomationgroup.nl/nl/trainingen/ai-agents Van eerste agent tot productieklare multi-agent stack Iedereen praat over agents, weinigen krijgen ze stabiel in productie. In deze training leer je het volledige speelveld: architectuurpatronen, tool-use, geheugen, evaluatie en de operationele realiteit van agentic systemen. Wat je leert: Wat een agent is en niet is, en wanneer een workflow volstaat; Architectuurpatronen: single agent, hiërarchisch, swarm en hybride; Tool-design: schema's, retries en de invloed op modelkwaliteit; Geheugen: short-term, long-term, episodisch en vector stores; Evaluatie met taak-suites, trajectory-analyse en kosten-metrics; Productie-aspecten: observability, sandboxing en mens-in-de-loop; Vendor-overzicht: OpenAI Agents SDK, Anthropic, CrewAI, LangGraph Voor wie: Developers en data consultants die met agents experimenteren; Product managers die haalbaarheid moeten inschatten; Architecten die agentic systemen in een bestaande stack moeten passen Programma: 09:30 Wat is een agent — Definities, patronen en wanneer je beter een gewone workflow bouwt. | 10:30 Tools en geheugen — Tool-schema's, retrieval, geheugentypes en hun fouten. | 13:00 Multi-agent — Orchestration, communicatie en de valkuilen die teams meestal pas live ontdekken. | 14:30 Evals en monitoring — Taak-suites, trajectory-analyse, regressies en cost-per-task. | 16:00 Bouwen — Eigen agent bouwen met een gedeelde toolset en review. Resultaat: Een werkende agent voor een eigen taak; Beslisboom voor agent versus workflow versus chatbot; Eval-template die je morgen kunt toepassen V: Welk framework gebruiken jullie? A: We laten meerdere zien — OpenAI Agents SDK, Anthropic-patronen, CrewAI en LangGraph — en sluiten af met een keuzemodel zodat je weet wanneer je welk inzet. V: Wat kost de training? A: Tarief op aanvraag. We sturen graag een offerte op maat, inclusief lesmateriaal, opnames en 30 dagen async support na afloop. Voor in-company sessies geldt één tarief, ongeacht het aantal deelnemers tot 12 personen. V: Waar vindt de training plaats? A: Standaard bij ons in Utrecht of in-company op jullie eigen locatie. Volledig remote kan ook, dan splitsen we de dag in twee blokken van een halve dag. V: Krijg ik een certificaat? A: Ja. Na afloop ontvang je een deelnamebewijs met de behandelde onderwerpen en uren, bruikbaar voor PE-punten en interne registratie. ## Training: Training Claude Cowork Source: https://theautomationgroup.nl/nl/trainingen/claude-cowork Claude inzetten als digitale collega in je team Claude is meer dan een chatbot — als je hem behandelt als een collega die je inwerkt, krijg je werk terug op het niveau van een goede medior. Deze training leert je hoe je Claude inzet in projects, met system prompts, custom skills en gedeelde knowledge bases die hele teams sneller maken. Wat je leert: Claude Projects: knowledge bases, system prompts en context-grenzen; Skills: hoe je herhaalbare taken vastlegt in een skill-bibliotheek; Schrijven, onderzoek en analyse op het niveau dat klanten merken; Claude inzetten naast je Office- of Google-suite zonder dubbel werk; MCP-servers koppelen aan Claude desktop voor toegang tot eigen tools; Veiligheidsmodel: wat wel en niet in Claude mag, en waarom; Adoption: hoe je een team van skeptici binnen weken laat omarmen Voor wie: Knowledge workers, consultants en analisten; Team leads die Claude breed willen uitrollen; Operations- en HR-rollen die adoption en richtlijnen vormgeven Programma: 09:30 Claude als collega — Mentaal model, prompts, en het verschil tussen 'tool' en 'collega'. | 10:30 Projects en skills — Knowledge bases, custom instructions en herhaalbare workflows. | 13:00 Werk in de praktijk — Onderzoek, schrijven, analyse en review met echte taken uit je werkdag. | 14:30 MCP en integratie — Eigen tools koppelen via MCP, plus de Office/Google-werkelijkheid. | 16:00 Adoption en governance — Richtlijnen, voorbeeldprompts en een plan om je team mee te krijgen. Resultaat: Eigen Claude Project met system prompt en knowledge base; Set herbruikbare skills voor terugkerende werkzaamheden; Adoption-plan dat past bij jouw team V: Is dit een vervanging voor de Claude Code training? A: Nee. Claude Cowork richt zich op kantoor- en knowledge work. Claude Code richt zich op consultants en codebases. V: Wat kost de training? A: Tarief op aanvraag. We sturen graag een offerte op maat, inclusief lesmateriaal, opnames en 30 dagen async support na afloop. Voor in-company sessies geldt één tarief, ongeacht het aantal deelnemers tot 12 personen. V: Waar vindt de training plaats? A: Standaard bij ons in Utrecht of in-company op jullie eigen locatie. Volledig remote kan ook, dan splitsen we de dag in twee blokken van een halve dag. V: Krijg ik een certificaat? A: Ja. Na afloop ontvang je een deelnamebewijs met de behandelde onderwerpen en uren, bruikbaar voor PE-punten en interne registratie. ## Training: Training OpenClaw Source: https://theautomationgroup.nl/nl/trainingen/openclaw Agentic AI volledig binnen je eigen muren OpenClaw is onze on-prem agentic AI-stack: lokale modellen, gedeeld geheugen, MCP-integraties en governance die past bij overheid, zorg en finance. In één dag leer je hoe je hem installeert, integreert en uitbreidt zonder dat data je netwerk verlaat. Wat je leert: Architectuur van OpenClaw: inference-laag, geheugen, MCP en agents; Installatie op eigen infrastructuur, met GPU-keuzes per gebruikspatroon; Lokale modellen kiezen en wisselen zonder de rest van de stack te raken; Gedeeld geheugen voor teams en organisaties; MCP-servers voor toegang tot eigen tools en databases; Governance: rollen, audit trails en datapaden die compliance accepteert; Integratie met je bestaande Claude Code, n8n en Office-workflows Voor wie: Platform- en infrateams in gereguleerde sectoren; Architecten die een on-prem alternatief voor SaaS-AI bouwen; Security en compliance officers die zekerheid willen vóór adoption Programma: 09:30 Waarom on-prem — Het besluit tussen cloud-AI en on-prem, en hoe OpenClaw daartussen past. | 10:30 Installatie — Hands-on installatie en hardware-keuzes per workload. | 13:00 Geheugen en MCP — Gedeeld geheugen en koppelingen aan eigen tools en databronnen. | 14:30 Governance — Rollen, audit trails en het gesprek met compliance. | 16:00 Integratie — Combinatie met Claude Code, n8n en bestaande workflows. Resultaat: Werkende OpenClaw-installatie op je eigen of geleverde hardware; Architectuurschets voor uitrol binnen jouw organisatie; Governance-document dat compliance herkent V: Kunnen we OpenClaw daarna zelf draaien? A: Ja. Doel van de training is dat je zelfstandig OpenClaw kunt installeren, onderhouden en uitbreiden. Optioneel bieden we daarnaast managed support. V: Wat kost de training? A: Tarief op aanvraag. We sturen graag een offerte op maat, inclusief lesmateriaal, opnames en 30 dagen async support na afloop. Voor in-company sessies geldt één tarief, ongeacht het aantal deelnemers tot 12 personen. V: Waar vindt de training plaats? A: Standaard bij ons in Utrecht of in-company op jullie eigen locatie. Volledig remote kan ook, dan splitsen we de dag in twee blokken van een halve dag. V: Krijg ik een certificaat? A: Ja. Na afloop ontvang je een deelnamebewijs met de behandelde onderwerpen en uren, bruikbaar voor PE-punten en interne registratie. ## Training: Training RAG Source: https://theautomationgroup.nl/nl/trainingen/rag Retrieval-Augmented Generation die echt schaalt RAG is in een demo zo gebouwd, en in productie een ander gevecht. In deze training leer je het complete spectrum: chunking strategieën, embeddings, hybride search, re-ranking en de evaluatie-aanpak die de meeste teams overslaan tot het misgaat. Wat je leert: Chunking strategieën en hun invloed op antwoordkwaliteit; Embedding-modellen kiezen en benchmarken op jouw data; Vector stores naast hybride zoek (BM25 + vector) en wanneer welke wint; Re-ranking met cross-encoders en LLM-rerankers; Multi-hop, agentic en GraphRAG patronen; Evaluatie met RAGAS, eigen test-sets en menselijke review; Productie: caching, kosten, observability en herindex-strategie Voor wie: Developers en ML consultants die kennisbanken doorzoekbaar maken; Data consultants die ETL voor RAG-pipelines opzetten; Productowners die de kwaliteit van eigen RAG-systemen willen begrijpen Programma: 09:30 RAG fundamenten — Pipeline, terminologie en waar de kwaliteit echt vandaan komt. | 10:30 Chunking en embeddings — Strategieën met en zonder structuur, en hoe je modellen benchmarkt. | 13:00 Search en re-ranking — Hybride zoek, BM25, vector en re-ranking modellen. | 14:30 Evaluatie — RAGAS, test-sets, regressies en het verschil tussen 'voelt goed' en 'is goed'. | 16:00 Productie — Caching, kosten, observability en wanneer je opnieuw indexeert. Resultaat: Een RAG-pipeline op een eigen dataset met heldere metrics; Eval-aanpak die regressies vangt voordat ze live gaan; Beslisboom voor vector versus hybride versus GraphRAG V: Welke tools gebruiken jullie? A: We laten meerdere stacks zien — onder andere LlamaIndex, LangChain, pgvector en Qdrant — en richten ons op de patronen, niet op één framework. V: Wat kost de training? A: Tarief op aanvraag. We sturen graag een offerte op maat, inclusief lesmateriaal, opnames en 30 dagen async support na afloop. Voor in-company sessies geldt één tarief, ongeacht het aantal deelnemers tot 12 personen. V: Waar vindt de training plaats? A: Standaard bij ons in Utrecht of in-company op jullie eigen locatie. Volledig remote kan ook, dan splitsen we de dag in twee blokken van een halve dag. V: Krijg ik een certificaat? A: Ja. Na afloop ontvang je een deelnamebewijs met de behandelde onderwerpen en uren, bruikbaar voor PE-punten en interne registratie. ## Case: anwb Source: https://theautomationgroup.nl/nl/cases/anwb De juiste instructies stonden in het kennissysteem. Het vinden kostte de ledenservice echter veel tijd. Medewerkers moesten zoektermen bedenken, lange documenten scannen en bij twijfel overleggen met collega's. Medewerkers stellen nu vragen in normale taal aan een interne bot. Ze krijgen direct de juiste passage uit de kennisbank te zien, inclusief de bijbehorende bron. Aanpak: We brachten de veelvoorkomende vragen en bronnen in kaart.; We bouwden een RAG-pipeline op de bestaande kennisbank.; Elk antwoord kreeg een duidelijke bronvermelding voor verificatie.; We verbeterden het systeem iteratief via feedback van medewerkers. Technologie: Python, RAG, LLMs, Vector search ## Case: wolters-kluwer Source: https://theautomationgroup.nl/nl/cases/wolters-kluwer Businessgebruikers hadden dagelijks vragen over productgroepen, marktsegmenten en campagnes. Hiervoor hadden ze steeds het analytics-team nodig. Dit zorgde voor vertraging en een stroom aan repetitieve verzoeken. Een intern Q&A-platform waar businessgebruikers vragen stellen aan gekoppelde datasets. Een semantische laag zorgt ervoor dat de antwoorden kloppen en herleidbaar zijn. Aanpak: We bouwden een semantische laag die businessbegrippen koppelt aan datastructuren.; We vertaalden normale taal naar SQL met gecontroleerde executie.; Het systeem draait binnen de bestaande cloudomgeving van Wolters Kluwer.; We draaiden een pilot om de output te valideren. Technologie: Azure, LLM, SQL, Semantische laag ## Case: inshared Source: https://theautomationgroup.nl/nl/cases/inshared Schadebehandelaars stelden dagelijks tientallen mails op met losse templates en knip-en-plakwerk uit dossiers. Dit kostte veel tijd. Bovendien verschilde de schrijfstijl en de mate van empathie per medewerker. Een ingebouwde assistent die conceptmails schrijft op basis van het geopende dossier. Het systeem kiest het juiste sjabloon en volgt de interne richtlijnen, terwijl de behandelaar de eindcontrole houdt. Aanpak: We kozen voor een agentisch systeem omdat correspondentie geen lineair proces is.; We gebruikten MCP-tools om rechtstreeks dossiergegevens op te halen.; We testten de schrijfstijl bij elke release via evaluaties op vaste scenario's.; We bouwden een widget direct in het bestaande dossiersysteem. Technologie: pydantic-ai, Azure OpenAI, MCP, Agent evals ## Case: meijers-verzekeringen Source: https://theautomationgroup.nl/nl/cases/meijers-verzekeringen Een centrale inbox voor schadeafhandeling kostte wekelijks twintig uur aan handmatig sorteerwerk. Dit ging ten koste van het echte werk. Daarbij was strakke informatiebeveiliging een harde eis. Een workflow die dagelijks rond de 150 mails automatisch classificeert en doorstuurt. We hebben dit opgezet als een basis die later ook voor andere inboxen bruikbaar is. Aanpak: We bouwden de oplossing volledig binnen de eigen cloudomgeving om data intern te houden.; We verrijkten de mailcontext met bestaande verzekeringsdata voor een betere sortering.; We rolden gefaseerd uit met een testfase op de achtergrond.; We zetten het systeem pas live na validatie van de classificatie. Technologie: Azure, n8n, Microsoft Graph API, Azure OpenAI ## Case: ami-kappers Source: https://theautomationgroup.nl/nl/cases/ami-kappers Kennisoverdracht en onboarding verschilden sterk per vestiging. Ontwikkelingsgesprekken stonden in losse documenten. Hierdoor miste HR het overzicht en konden salonmanagers de voortgang van hun medewerkers moeilijk volgen. Een maatwerk leeromgeving die e-learning, onboarding en ontwikkelingsgesprekken bundelt. Het systeem is direct gekoppeld aan de HR-data en werkt voor alle vestigingen op dezelfde manier. Aanpak: We bouwden één centraal platform voor leren, onboarding en ontwikkeling.; We maakten specifieke dashboards voor verschillende rollen binnen de organisatie.; We koppelden het systeem aan de HR-software voor automatische synchronisatie.; We voegden een leerassistent toe op basis van interne documenten. Technologie: Custom webapp, AI-leerassistent, HR-integratie, Rolgebaseerde toegang ## Case: afas Source: https://theautomationgroup.nl/nl/cases/afas Het marketingteam wilde een intern platform om taken te automatiseren. Ze zochten een basis waarop ze later zelf eenvoudig nieuwe functionaliteiten of specifieke agents konden toevoegen. Een webapplicatie met meerdere agents, een eigen kennisbank en een taakplanner. Dit dient als een direct bruikbaar systeem en als framework voor de toekomst. Aanpak: We bouwden de architectuur als een open en uitbreidbaar framework.; We richtten meerdere agents in die taken parallel of na elkaar oppakken.; We voegden direct functies toe voor onderzoek, contentcreatie en planning.; We schreven handleidingen zodat het team zelf nieuwe tools kan toevoegen. Technologie: CrewAI, FastAPI, Next.js, Tailwind ## Case: travelessence Source: https://theautomationgroup.nl/nl/cases/travelessence Het verwerken van honderden prijslijsten van leveranciers was een knelpunt. Deze documenten bevatten wisselende seizoenen, kortingen en belastingregels. Dit kostte medewerkers gemiddeld twee tot vier uur handwerk per document. Een systeem dat complexe documenten inleest en de tarieven en periodes herkent. Het voert de prijslogica uit en wacht op menselijke goedkeuring voordat het de data opslaat. Aanpak: We kozen voor een voorspelbaar proces in plaats van een volledig autonoom systeem.; We gebruikten AI puur voor het lezen van data, niet voor de berekeningen.; We bouwden een overzichtelijke matrix waarin medewerkers wijzigingen goedkeuren.; We maakten de menselijke controle een verplichte stap in het proces. Technologie: Python, FastAPI, React, Azure ## Case: domus-valuas Source: https://theautomationgroup.nl/nl/cases/domus-valuas HR ontving sollicitatiemails voor tientallen locaties. Dit betekende veel handwerk. Ze moesten gegevens overtypen, bijlagen controleren, de juiste locatiemanager opzoeken en een mail opstellen. Bij een groot volume kostte dit wekelijks te veel tijd. Een koppeling leest de mailbox uit en verwerkt de bijlagen. Het systeem zet een conceptmail klaar die HR na een korte controle direct kan versturen. Aanpak: We kozen ervoor dat de flow nooit zelf mails verstuurt.; We gebruiken Document Intelligence om data uit ingescande cv's te halen.; Het systeem zoekt de juiste locatiemanager op basis van mail en cv.; HR houdt de eindcontrole over de toon en inhoud van het bericht. Technologie: n8n, Azure Document Intelligence, OpenAI, Microsoft 365 ## Case: openclaw Source: https://theautomationgroup.nl/nl/cases/openclaw Het team was veel tijd kwijt aan het bijhouden van nieuwe AI-frameworks en modellen. De ontwikkelingen gaan snel. Hierdoor pikte het team relevante innovaties soms te laat op. Een interne agent die continu nieuwe frameworks en modellen in de gaten houdt. Het systeem levert het team wekelijks bruikbare samenvattingen en inzichten op. Aanpak: We bouwden een monitoring pipeline voor nieuw AI-onderzoek en releases.; Een interne agent scant, filtert en vat de belangrijkste bronnen samen.; We voegden een score toe op basis van onze eigen techstack en klantbehoeften.; Het systeem genereert gestructureerde rapportages voor het ontwikkelteam. Technologie: Python, OpenAI, Web Scraping, Knowledge Graphs, Automation ## Case: 4everyware Source: https://theautomationgroup.nl/nl/cases/4everyware Er was veel data beschikbaar, maar het team deed daar te weinig mee. Medewerkers liepen vast op handmatig werk bij leadgeneratie, vakbeursdata, transportroutes en factuurverwerking. Dit zorgde voor operationele vertraging. Een reeks gekoppelde pipelines die repetitief werk overnemen. Medewerkers gebruiken nu één centraal portaal voor leadgeneratie, dataverrijking en factuurverwerking. Aanpak: We gebruikten het bestaande CRM als vertrekpunt voor de automatisering.; We zetten AI specifiek in voor het lezen en classificeren van ongestructureerde data.; We bouwden de oplossing modulair op zodat we makkelijk nieuwe tools kunnen toevoegen.; We koppelden een centraal platform aan de eigen bedrijfsdata. Technologie: n8n, Claude, Document AI, CRM-integratie ## Case: beachclub-indigo Source: https://theautomationgroup.nl/nl/cases/beachclub-indigo Het team verloor veel tijd aan factuurcontroles, offertes en mailadministratie. Er was geen duidelijk beeld van waar de knelpunten zaten. Ze wisten ook niet welke oplossingen realistisch en haalbaar waren. Een overzichtelijk plan dat per afdeling toont welke stappen ze vandaag kunnen zetten. Het team kan direct beginnen zonder te wachten op een groot IT-project. Aanpak: We organiseerden een sessie met het team en spraken elke afdeling apart.; We werkten vier thema's uit rondom financiën, sales, marketing en LinkedIn.; We bepaalden per afdeling drie haalbare niveaus van automatisering.; We brachten direct uitvoerbare verbeteringen in kaart. Technologie: Claude, Granola, n8n ## Case: monarch Source: https://theautomationgroup.nl/nl/cases/monarch Vijf medewerkers verwerkten alle storingen en vragen via één gedeelde Outlook-inbox. Urgente meldingen raakten kwijt tussen de normale mails. Niemand had een goed overzicht van de openstaande taken. Een ticketsysteem met een actueel overzicht voor medewerkers en management. Het model draait lokaal op een eigen server bij hun vaste hostingpartner, waardoor er geen data naar buiten gaat. Aanpak: We halen mails op via Exchange en zetten deze direct om naar tickets.; Een lokaal model beoordeelt de urgentie en categorie van de melding.; Het systeem wijst tickets toe aan de juiste groep en bewaakt de doorlooptijd.; We lieten een onafhankelijke security-audit uitvoeren voor de livegang. Technologie: Qwen2.5 via Ollama, FastAPI, PostgreSQL, React, Docker, Exchange Web Services ## Case: the-onion-group Source: https://theautomationgroup.nl/nl/cases/the-onion-group Inkoopfacturen en afroeporders kwamen versnipperd binnen via verschillende mailboxen. Medewerkers moesten alle documenten handmatig controleren en overtypen in het systeem. Dit kostte veel tijd en veroorzaakte invoerfouten. Een platform dat financiële data direct en veilig in het data lake plaatst. Orderdata wordt gecontroleerd op specifieke gewichtsvarianten en automatisch klaargezet voor import in Navision. Aanpak: We richtten n8n in als de centrale motor binnen hun Microsoft-omgeving.; We gebruiken Azure Document Intelligence om factuurregels en orderregels uit te lezen.; We automatiseerden de categorisatie en archivering van mails via de Microsoft Graph API.; We bouwden een veilige koppeling naar Microsoft Fabric en Navision. Technologie: n8n, Azure Document Intelligence, Microsoft Graph API, Microsoft Fabric, Navision, Azure SQL ## Case: kitchen-247 Source: https://theautomationgroup.nl/nl/cases/kitchen-247 Klanten stelden vragen over keukens en bestellingen, maar kregen buiten kantoortijden geen direct antwoord. Veel waardevolle productkennis stond verspreid in losse documenten. Hierdoor was de druk op de klantenservice overdag hoog. Een chatbot die klantvragen op de webshop direct beantwoordt op basis van interne documenten. Elke technische update verloopt via een streng beveiligd en geautomatiseerd proces. Aanpak: We bouwden een chatbot en plaatsten deze als widget op de webshop.; We richtten een pipeline in met automatische security scans en tests.; Het systeem voert een automatische deploy uit als alle tests slagen.; We maakten de productkennis in de bot makkelijk aanpasbaar voor het team. Technologie: OpenAI, Python, GitHub Actions, Render, Bandit, pip-audit ## Case: kuchenwelt Source: https://theautomationgroup.nl/nl/cases/kuchenwelt Bezoekers zochten handmatig door lange FAQ-lijsten of moesten wachten op een medewerker. Dit kostte tijd en zorgde voor een hoge drempel. Veel potentiële klanten haakten af voordat ze een showroom bezochten. Een chatbot die veelvoorkomende vragen direct beantwoordt. Klanten krijgen gerichte informatie en worden sneller naar een fysieke showroom doorverwezen. Aanpak: We bouwden een FAQ-database als centrale kennisbron.; De architectuur is gekopieerd van Kitchen247 voor makkelijker onderhoud.; We richtten een CI/CD-pijplijn in met security checks en Render-deploys.; De chatwidget staat klaar voor gebruik zodra de content af is. Technologie: OpenAI, Python, GitHub Actions, Render ## Case: van-campen-consulting Source: https://theautomationgroup.nl/nl/cases/van-campen-consulting Consultants schreven maandelijks tientallen verzuimrapportages met de hand op basis van Excel-bestanden. Dit kostte veel uren. Daarnaast was het moeilijk om de analyse en schrijfstijl overal gelijk te houden. Een applicatie die Excel-bestanden direct verwerkt tot een compleet Word-rapport in de juiste huisstijl. De inhoudelijke diepgang van de consultants blijft behouden. Aanpak: We bouwden een pijplijn met GPT-4.1 voor data-analyse en GPT-4.1-mini voor de tekst.; Het systeem gebruikt een afgeschermde kennisbank met interne methodiekdocumenten.; We automatiseerden het genereren van grafieken en tabellen.; De tool haalt live benchmarkdata op bij het CBS. Technologie: GPT-4.1, GPT-4.1-mini, Next.js, FastAPI, Azure ## Case: hizi-hair-en-kinki-kappers Source: https://theautomationgroup.nl/nl/cases/hizi-hair-en-kinki-kappers Medewerkers lazen en sorteerden dagelijks een enorme hoeveelheid e-mails met de hand. Veel berichten gingen over dezelfde onderwerpen. Het kostte onnodig veel tijd om steeds dezelfde antwoorden te typen. Een koppeling tussen n8n en Outlook die de inbox structureert. Medewerkers vinden bij veelvoorkomende vragen direct een ingevuld conceptbericht in hun conceptenmap. Aanpak: We maakten één centrale oplossing die beide organisaties gebruiken.; Azure OpenAI leest de mails en verplaatst ze naar de juiste map.; Het systeem genereert conceptantwoorden via Excel-templates in M365.; Medewerkers controleren de concepten en versturen ze zelf. Technologie: n8n, Microsoft 365, Azure OpenAI, Excel/M365 ## Case: green-real-estate Source: https://theautomationgroup.nl/nl/cases/green-real-estate Tijdens de migratie naar een nieuw ERP-systeem dreigde de automatische verwerking van huurdersmeldingen stuk te gaan. Tegelijkertijd was het planningsteam dagelijks veel tijd kwijt aan het handmatig overtypen van vergaderruimte-reserveringen. Een planningsmodule publiceert elke ochtend een actueel vergaderoverzicht. Huurdersmeldingen via mail of webformulier belanden nu zonder handwerk direct in het nieuwe ERP-systeem. Aanpak: We kozen n8n als de centrale motor voor alle automatiseringen.; Microsoft Graph API haalt agendadata op en publiceert dit op SharePoint.; Azure OpenAI leest huurdersmeldingen en zet deze om naar werkorders.; We koppelden Yardi Virtuoso en de IP Parking API voor kentekens. Technologie: n8n, Microsoft Graph API, SharePoint, Azure OpenAI, Yardi Virtuoso, IP Parking API ## Case: van-deursen-group Source: https://theautomationgroup.nl/nl/cases/van-deursen-group Een vastgoedbedrijf met vijf teams wilde AI gebruiken in de dagelijkse praktijk. Een generieke tool werkte niet. Ze zochten een oplossing die direct aansloot bij de specifieke taken van individuele medewerkers. Elk teamlid heeft nu eigen AI-assistenten voor hun specifieke werk. Ze genereren leningovereenkomsten, halen vierkante meters uit tekeningen en berekenen huurpunten. Aanpak: We brachten de dagelijkse taken per medewerker in kaart.; Voor specifieke workflows bouwden we gerichte Claude-skills.; We werkten in een sprint van zes weken met persoonlijke begeleiding.; Medewerkers gebruiken Cowork als een simpele interface voor hun modellen. Technologie: Claude, Cowork, Custom Claude Skills ## Case: based Source: https://theautomationgroup.nl/nl/cases/based Waardevolle informatie uit online en offline meetings ging vaak verloren. Het bedrijf wilde dit documenteren. Omdat ze gevoelige klantinformatie bespreken, was strikte naleving van de AVG een absolute voorwaarde. Medewerkers uploaden audiobestanden en krijgen direct een gestructureerde samenvatting terug. De organisatie bouwt een doorzoekbaar archief op zonder dat er data buiten Europa belandt. Aanpak: We bouwden een eigen uploadportaal op Europese Azure-servers.; Het systeem gebruikt Gladia voor veilige Europese transcriptie.; Een lokaal gehost GPT-5.1 model genereert de uiteindelijke rapporten.; We stelden een strikt beleid in voor het automatisch verwijderen van data. Technologie: n8n, Gladia (EU), GPT-5.1 op Azure EU, Azure ## Case: act-legal Source: https://theautomationgroup.nl/nl/cases/act-legal Advocaten pasten handmatig tientallen bedrijfsgegevens aan in koopovereenkomsten. Dit zoek- en vervangwerk kostte uren per document. Ze wilden deze tijd liever besteden aan echt juridisch werk. Het kantoor heeft nu inzicht in de nauwkeurigheid van verschillende AI-oplossingen. Ze weten precies welke techniek betrouwbaar genoeg is om KvK-data in contracten te zetten. Aanpak: We testten verschillende oplossingen op één vaste testdeal.; We vergeleken Legora OS direct met onze eigen Claude Code-plugin.; Een analyserapport bracht per invulveld de foutmarges in kaart.; We bouwden een webapp om de resultaten visueel te vergelijken. Technologie: Claude Code, Legora OS, Python, Next.js, KvK API ## Graph vs. Loop Engineering bij AI Agents Source: https://theautomationgroup.nl/nl/blog/graph-engineering-vs-loop-engineering Gepubliceerd: 2026-09-14 Ontdek de architectuurkeuzes achter AI Agents: wanneer kies je voor de flexibiliteit van loops en wanneer voor de controle van graph engineering? Bij het ontwerpen van systemen rondom grote taalmodellen staan technische beslissers en engineers voor een fundamentele architectuurkeuze. Hoe geef je een AI Agent de vrijheid om complexe problemen op te lossen, zonder de controle over het proces te verliezen? In de zoektocht naar betrouwbare productiesystemen zijn twee dominante ontwerppatronen komen bovendrijven: loop engineering en graph engineering. Hoewel de termen soms door elkaar worden gebruikt of als tegenpolen worden gepresenteerd, onthult een diepere blik op de onderliggende mechaniek een genuanceerder beeld. Als Agentic AI Engineer of architect moet je navigeren door een landschap van frameworks, ontwerppatronen en best practices die nog volop in ontwikkeling zijn. Dit artikel ontleedt de concepten graph engineering en loop engineering, traceert waar de begrippen vandaan komen, analyseert de afwegingen en faalmodi, en biedt een kader om de juiste keuze te maken voor jouw specifieke use case. De fundamenten: Loops en Graphs gedefinieerd Loop Engineering en de Core Agent Loop In de basis is een AI Agent een systeem waarbij een taalmodel dynamisch zijn eigen processen en het gebruik van tools aanstuurt, waarbij het model de controle behoudt over hoe een taak wordt volbracht [1]. Dit dynamische proces wordt doorgaans vormgegeven via een 'loop'. De officiële documentatie van de OpenAI Agents SDK beschrijft deze expliciete agent loop als het kernconcept van hun framework [12]. De mechaniek is relatief eenvoudig maar krachtig: het systeem roept het model aan, inspecteert de output, en neemt op basis daarvan actie. Als het model vraagt om een tool te gebruiken, voert het systeem die tool uit en gaat de loop verder. Als er een 'handoff' plaatsvindt, wisselt het systeem van agent en gaat de loop verder. Pas wanneer het model een eindantwoord genereert zonder verdere tool-aanroepen, stopt de loop en wordt het resultaat teruggegeven [12]. Volgens OpenAI bouwen alle andere functionaliteiten, zoals tools, goedkeuringen en streaming, voort op deze fundamentele loop in plaats van deze te vervangen [12]. Belangrijk terminologieconflict: Het is cruciaal om op te merken dat de term 'loop' niet in de hele industrie hetzelfde betekent. Waar Anthropic, LangChain en OpenAI een loop zien als een model-gestuurd, dynamisch proces, hanteert de Google Agent Development Kit (ADK) een exact tegenovergestelde definitie. In de Google ADK is een "Loop workflow agent" een template waarbij sub-agents in een loop worden uitgevoerd voor een specifiek aantal iteraties of tot een conditie is bereikt, maar waarbij de executie expliciet niet wordt gecontroleerd door een AI-model en volledig deterministisch is [13]. In dit artikel hanteren we de definitie van OpenAI en LangChain, waarbij de loop juist het model-gestuurde hart van de AI Agent vormt, maar wees je als Agentic AI Engineer bewust van deze spraakverwarring in de documentatie van verschillende leveranciers. Graph Engineering: Controle via State Machines Tegenover de pure, open-ended loop staat 'graph engineering'. Deze term won sterk aan populariteit nadat LangChain het framework LangGraph introduceerde, dat systemen modelleert als grafen [6, 8]. Bij graph engineering representeer je agentic systemen als een netwerk van knooppunten (nodes) en verbindingen (edges). De mechaniek hierachter is vergelijkbaar met een state machine. In LangGraph doen de nodes het daadwerkelijke werk. Een node kan deterministische code zijn, een enkele aanroep naar een taalmodel, een tool-executie, of zelfs een volledige AI Agent met zijn eigen interne loop [6]. De edges definiëren vervolgens wat er daarna gebeurt, op basis van de gedeelde datastructuur (de State) [8]. Het doel van graph engineering is om als bouwer jouw vooropgezette ideeën over hoe het systeem moet werken op te leggen via meer begrensde paden. Je vertrouwt niet uitsluitend op het oordeel van het model, maar legt vast waar het model een keuze mag maken en waar het systeem deterministisch gedrag moet afdwingen [6]. De evolutie van het debat: Autonomie versus Voorspelbaarheid De keuze tussen een open loop en een strakke graph raakt aan een fundamenteel debat in de wereld van Agentic AI: hoeveel autonomie geef je het systeem? Dit debat is de afgelopen jaren sterk geëvolueerd, zichtbaar in de wisselende standpunten van prominente spelers in de markt. De waarschuwing tegen complexiteit Anthropic stelt dat de meest succesvolle implementaties geen complexe frameworks of gespecialiseerde libraries gebruiken, maar gebouwd zijn met simpele, samenvoegbare patronen [1]. Zij maken een scherp onderscheid tussen workflows (waarbij modellen en tools worden georkestreerd via vooraf gedefinieerde codepaden) en agents. Volgens Anthropic bieden workflows voorspelbaarheid en consistentie bij goed gedefinieerde taken, terwijl agents beter zijn wanneer flexibiliteit en model-gedreven besluitvorming op schaal nodig zijn [1]. Zij adviseren om altijd de simpelste oplossing te zoeken en complexiteit pas toe te voegen wanneer dat strikt noodzakelijk is. Frameworks creëren vaak extra abstractielagen die de onderliggende prompts en responses verbergen, wat het debuggen aanzienlijk moeilijker maakt [1]. Het multi-agent vraagstuk en Context Engineering Een gerelateerde discussie is of je taken moet opsplitsen over meerdere agents (wat vaak leidt tot een graph-architectuur) of alles in één krachtige loop moet houden. Walden Yan van Cognition publiceerde aanvankelijk een stuk met de titel "Don't Build Multi-Agents" [4]. Hij betoogde dat de betrouwbaarheid van langlopende agents sterk afhangt van context engineering. Als voorbeeld gaf hij de opdracht om een Flappy Bird-kloon te bouwen, opgesplitst in een subagent voor de achtergrond en een voor de vogel. Zelfs als elke subtaak slaagt, kan het geheel inconsistent zijn. Zijn principes: deel volledige agent-traces (niet alleen losse berichten) en besef dat acties impliciete beslissingen met zich meebrengen; conflicterende beslissingen leiden tot slechte resultaten [4]. Hij bekritiseerde libraries zoals OpenAI Swarm en Microsoft AutoGen omdat ze deze multi-agent architecturen zouden pushen [4]. Tien maanden later herzag Yan dit standpunt echter expliciet in een nieuwe publicatie, waarin hij aangaf dat er veel veranderd was en dat Cognition onder bepaalde voorwaarden multi-agent systemen nu wel omarmt [5]. Harrison Chase van LangChain analyseerde deze verschuivingen en concludeerde dat de bepalende factor voor succes niet een dogmatische regel voor of tegen multi-agent is, maar de kwaliteit van de context-engineering en het delen van context tussen de componenten [3]. De verzoening: Loops zijn simpele Graphs Uiteindelijk is de tegenstelling tussen loop en graph engineering deels semantisch. LangChain stelt verzoenend dat loops in feite simpele grafen zijn. Loop engineering is geen alternatief voor grafen, maar een eenvoudige versie ervan [6]. Een loop is wiskundig gezien een gerichte, cyclische graaf. Zelfs het standaard LangChain-framework, dat gebaseerd is op een simpele agentic loop, is onder de motorkap bovenop LangGraph gebouwd [6]. Productie-agents zijn vrijwel nooit gerichte acyclische grafen (DAGs); ze hebben cycli nodig voor retries, menselijke input en revisielussen [6]. Wanneer kies je wat? Afwegingen in de praktijk Als Agentic Consultant moet je de architectuur afstemmen op de taak. De keuze tussen een strakke graph of een flexibele loop hangt af van de aard van het werk. Wanneer Graph Engineering uitblinkt Grafen zijn ideaal wanneer een proces een voorspelbare structuur vereist [6]. Enkele voorbeelden: Support-agents: Een systeem moet eerst een inkomend probleem classificeren voordat het een antwoord formuleert of escaleert naar een mens. Coding-agents: De agent moet verplicht de repository inspecteren en tests draaien voordat hij een codewijziging voorstelt. Compliance-workflows: Er is een harde eis dat een specifieke goedkeuringsstap wordt doorlopen voordat een externe actie (zoals een betaling of het verzenden van een e-mail) plaatsvindt. In deze scenario's wil je niet hopen dat het model de juiste beslissing neemt; je wilt deterministisch gedrag afdwingen via de structuur van de graaf [6]. Wanneer Loops en Agent Harnesses beter zijn Sommige taken zijn van nature meer 'agentic' en open-ended. Het forceren van dergelijke taken in deterministische paden is een ontwerpfout [6]. Denk aan open-ended zoekwerk of diepgaande research. LangChain bouwde hun vroege 'deep research'-functionaliteit op vooraf gedefinieerde LangGraph-workflows, maar stapte later over op een meer agentic core loop. Ook het project GPT Researcher ruilde zijn graph-vormige multi-agent pipeline in voor zogenaamde Deep Agents [6]. Voor dit soort open-ended taken, waarbij het pad naar de oplossing vooraf onbekend is, presteert een robuuste orchestrator met subagents (zoals Anthropic's multi-agent research system [2]) vaak beter. De documentatie van Pydantic AI (die met pydantic-graph een async graph- en state-machinelibrary voor Python biedt) bevat een treffende waarschuwing: grafen zijn een krachtig instrument, maar niet voor elke klus. Ze vergelijken Pydantic AI agents met een hamer, multi-agent workflows met een voorhamer, en grafen met een spijkerpistool. Een spijkerpistool ziet er stoerder uit, maar vereist veel meer setup en maakt je geen betere bouwer, alleen een bouwer met een spijkerpistool [14]. Als je niet zeker weet of een graph-gebaseerde aanpak nodig is, is het waarschijnlijk overbodig [14]. Productie-eisen: State, Duurzaamheid en de Human-in-the-Loop Het bouwen van een prototype in een notebook is wezenlijk anders dan het draaien van een AI Agent in productie. Twee concepten zijn hierbij onmisbaar: state management en durable execution. State en Persistentie Zowel in loops als in grafen moet het systeem onthouden wat er is gebeurd. LangGraph lost dit op met een persistentielaag via 'checkpointers'. Deze slaan de graph state op als checkpoints bij elke stap [9]. Dit geeft agents kortetermijngeheugen (binnen één sessie) en langetermijngeheugen (via stores), wat essentieel is als een agent een gesprek moet voortzetten of na een onderbreking verder moet werken [10]. Deze checkpointers maken ook 'interrupts' mogelijk. Hiermee kun je de executie van de graaf op specifieke punten pauzeren en wachten op externe input, wat het human-in-the-loop patroon faciliteert [11]. Wanneer een interrupt wordt getriggerd, slaat LangGraph de status op en wacht het systeem voor onbepaalde tijd [11]. Ook OpenAI biedt in hun SDK vier strategieën voor state-persistentie, variërend van in-app history tot een server-managed Conversations API [12]. Durable Execution en Verantwoordelijkheid Als een AI Agent langere tijd draait, nemen de risico's toe. Modellen zijn non-deterministisch, executies moeten soms uren wachten op menselijke input, en het systeem moet servercrashes en software-updates overleven zonder de voortgang van de agent te verliezen [18]. Dit is waar platforms voor 'durable execution', zoals Temporal, in beeld komen. Zoals Cornelia Davis van Temporal stelt: het is opmerkelijk eenvoudig geworden om een AI Agent capaciteiten te geven, maar veel moeilijker om hem verantwoordelijkheid te geven. Verantwoordelijkheid vereist namelijk controle [17]. Door frameworks zoals de OpenAI Agents SDK te integreren met Temporal (een integratie die inmiddels algemeen beschikbaar is [16]), creëer je een infrastructuur waarbij de executie van de agent gegarandeerd doorloopt of correct herstelt na een storing [15, 16]. Dit is een kritieke vereiste voor enterprise-grade Agentic AI. Vergelijkend overzicht Onderstaande tabel biedt een kwalitatieve vergelijking tussen de twee benaderingen op basis van de besproken architectuurprincipes. Afwegingsas Pure Loop Engineering (Agentic) Graph Engineering (Deterministisch) Voorspelbaarheid Laag. Het model bepaalt dynamisch het pad en de volgorde van tool-gebruik. Hoog. De flow is vastgelegd in nodes en edges; het model kiest alleen binnen vooraf gedefinieerde kaders. Observability Complexer. Vereist het loggen van volledige agent-traces om te begrijpen waarom een model een bepaalde afslag nam. Inzichtelijk. De state machine maakt exact inzichtelijk in welke node het systeem zich bevindt of is vastgelopen. Duurzaamheid / Herstel Vereist externe mechanismen (zoals Temporal of sessie-opslag) om de loop na een crash te hervatten. Vaak ingebouwd via checkpointers (zoals in LangGraph) die de state per node opslaan voor eenvoudig herstel. Flexibiliteit Zeer hoog. Ideaal voor open-ended research en taken waarbij het stappenplan vooraf onbekend is. Beperkt door de ontworpen graaf. Runtime-flexibiliteit is mogelijk (bijv. fan-out/map-reduce), maar vereist expliciet ontwerp. Onderhoudslast Focus ligt op prompt engineering en context sharing. Minder code, maar lastiger te debuggen bij onverwacht gedrag. Hogere initiële setup (het 'spijkerpistool'). Abstractielagen kunnen onderliggende prompts verbergen, wat debuggen bemoeilijkt. De status van het bewijs Belangrijke disclaimer: Bij het evalueren van deze architecturen is het essentieel om te beseffen dat er momenteel geen gecontroleerde, onafhankelijke benchmarks of peer-reviewed studies bestaan die graph-gestructureerde agents objectief vergelijken met pure loops op het gebied van taaksucces, operationele kosten of latency. Al het beschikbare bewijs, inclusief de inzichten in dit artikel, is gebaseerd op praktijkervaringen van ontwikkelaars, blogposts van leveranciers en frameworkdocumentatie. Er kan op dit moment niet wetenschappelijk worden vastgesteld dat de ene aanpak empirisch superieur is aan de andere; de keuze blijft een architecturale afweging gebaseerd op de specifieke use case. Conclusie De keuze tussen graph engineering en loop engineering is geen binaire beslissing, maar het zoeken naar de juiste balans op een spectrum. Voor open-ended taken waarbij het model de leiding moet nemen, biedt een robuuste loop de benodigde flexibiliteit. Voor bedrijfskritische processen met harde compliance-eisen biedt een graph de noodzakelijke controle. Zoals vaak in software engineering geldt ook voor Agentic AI: begin met de simpelste oplossing (een basis loop of een eenvoudige workflow) en introduceer de complexiteit van geavanceerde grafen of multi-agent systemen pas wanneer de taak daarom vraagt. Een alternatieve, declaratieve benadering zoals DSPy, waarbij taken worden beschreven als gestructureerde inputs en outputs in zelf-verbeterende pipelines [19, 20], toont aan dat het veld nog volop innoveert in hoe we LLM-aanroepen orkestreren. Bronnen Anthropic, "Building Effective Agents", 19 december 2024. Link Anthropic, "How we built our multi-agent research system", 13 juni 2025. Link Harrison Chase (LangChain), "How and when to build multi-agent systems", 16 juni 2025. Link Walden Yan (Cognition), "Don't Build Multi-Agents", 12 juni 2025. Link Walden Yan (Cognition), "Multi-Agents: What's Actually Working", 22 april 2026. Link Sydney Runkle & Harrison Chase (LangChain), "3 Years of Graph Engineering with LangGraph", 22 juli 2026. Link Nuno Campos (LangChain), "Building LangGraph: Designing an Agent Runtime from first principles", 4 september 2025. Link LangGraph docs, "Graph API overview". Link LangGraph docs, "Checkpointers". Link LangGraph docs, "Persistence". Link LangGraph docs, "Interrupts". Link OpenAI Agents SDK docs, "Running agents". Link Google Agent Development Kit (ADK), "Loop workflow agent" docs. Link Pydantic AI, "Graphs" documentatie (pydantic-graph). Link Cornelia Davis (Temporal), "Durable Execution meets AI: Why Temporal is ideal for AI agents & Generative AI Apps", 10 juli 2025. Link Cornelia Davis (Temporal), "Production-ready agents with the OpenAI Agents SDK + Temporal", 30 juli 2025 (update 23 maart 2026). Link Cornelia Davis (Temporal), "Temporal Agent Harness: An early look at durable agent infrastructure", 20 augustus 2026. Link Greg Haskins (Manetu via Temporal), "The thread is the Workflow: Durable AI agents without changing Agent code", 3 september 2026. Link DSPy, "Program, don't prompt". Link Khattab et al., "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines", arXiv:2310.03714 (ICLR 2024). Link ## Je strategie is niet begrensd door de markt, maar door je bandbreedte Source: https://theautomationgroup.nl/nl/blog/strategie-begrensd-door-bandbreedte Gepubliceerd: 2026-08-17 Je laatste strategiesessie leverde drie opties op. Niet omdat er maar drie waren, maar omdat je team er niet meer kon bedenken en beoordelen. Wat er verandert als die cognitieve grens wegvalt — en waarom de voorsprong niet in het model zit, maar in wat je erop bouwt. Denk terug aan je laatste strategiesessie. Weken voorbereiding, iedereen ingevlogen, twee dagen discussie. Met hoeveel écht verschillende opties liep je de deur uit? Drie? Vier? En de eerlijke vraag daarachter: waren dat de enige goede opties, of waren het de enige die jullie in de beschikbare tijd konden bedenken en beoordelen? Voor de meeste organisaties is het antwoord het tweede. De rem op strategische besluitvorming is nooit een gebrek aan mogelijke richtingen geweest. De rem zit in de mensen die het werk doen: we houden maar zoveel informatie tegelijk vast, beoordelen maar zoveel alternatieven per planningscyclus, en verwerken maar zoveel perspectieven voordat vermoeidheid, politiek of de klok een besluit afdwingen. Economen noemen dat bounded rationality. Felipe Csaszar, hoogleraar strategie aan de Ross School of Business (University of Michigan), zet in Harvard Business Review een punt neer dat wij in de praktijk elke week terugzien: die cognitieve grens verklaart niet alleen hóé traag strategie gaat, maar ook waarom het strategie-instrumentarium eruitziet zoals het eruitziet. Een SWOT heeft vier vakjes, een BCG-matrix is 2×2 en Porter heeft vijf krachten — niet omdat de wereld zo eenvoudig is, maar omdat een team dat op een whiteboard moet kunnen invullen in een paar uur. Drie taken, drie plafonds Elk strategisch besluit bestaat uit drie denktaken: zoeken naar mogelijke koersen, representeren van de omgeving waarin die koersen uitpakken, en aggregeren van de oordelen van de mensen die meebeslissen. Op alle drie zit een plafond. En op alle drie schuift dat plafond nu op. 1. Zoeken: van een handvol naar duizenden opties Een typische planningscyclus levert een stuk of twaalf ideeën op, waarna het veld wordt teruggebracht tot drie of vier. De rest van de mogelijkhedenruimte wordt nooit bekeken — niet omdat die niks belooft, maar omdat niemand de tijd heeft. Csaszar beschrijft een softwarebedrijf dat voor overnames een AI-scoutingsysteem inzette: semantisch zoeken over een database van meer dan 40 miljoen publieke en private bedrijven, gevoed met patenten, deponeringen en experttranscripten. Het systeem vond en scoorde in minder dan een dag ruim 500 overnamekandidaten, bracht die terug naar 15 serieuze leads en leidde binnen enkele maanden tot drie afgeronde acquisities. Het punt is niet de snelheid. Het punt is dat "zoeken naar opties" iets anders is gaan betekenen. In plaats van een team te vragen plausibele kandidaten te bedenken, scan je vrijwel het hele relevante universum langs meerdere strategische lenzen tegelijk. AI verbreedt de zoektocht; mensen kiezen. Gebruik het oordeel van je team op de shortlist, niet op de longlist. 2. Representeren: van statisch model naar levend model Hoe modelleert jouw organisatie haar omgeving? Meestal met een combinatie van frameworks, spreadsheets en kwartaalrapportages. Nuttig, maar statisch: ze vangen de belangrijkste dynamiek en laten de rest weg. MYbank, de digitale kredietverstrekker binnen Ant Group, laat zien wat er gebeurt als je een grofmazig model vervangt door een fijnmazig model. Traditionele banken beoordelen kleine bedrijven op een handvol variabelen — omzet, onderpand, kredietgeschiedenis — waardoor miljoenen ondernemingen simpelweg niet te scoren en dus niet te financieren zijn. MYbank gebruikt er meer dan 3.000, inclusief transactiedata, ketenrelaties en zelfs satellietbeelden. Het resultaat noemen ze 3-1-0: drie minuten aanvragen, één seconde goedkeuren, nul menselijke tussenkomst. Ruim 53 miljoen kleine bedrijven kregen krediet, 72 procent daarvan voor het eerst, bij een wanbetalingspercentage rond de 1 procent. Het strategische inzicht zit niet in de snelheid van de beoordeling. MYbank ging niet bestaande klanten sneller bedienen — het zag een compleet klantsegment dat in het oude model onzichtbaar was. Unilever deed iets vergelijkbaars met ijs: een model dat weersverwachtingen, vraagsignalen en telemetrie uit zo'n 3 miljoen aangesloten vrieskisten over 35 fabrieken combineert, in plaats van achteraflopende kwartaalprognoses. Tien procent betere forecastnauwkeurigheid in Zweden, en in sommige regio's tot 30 procent meer omzet. De praktische stap voor jou: pak het één of twee modellen waar je organisatie het zwaarst op leunt — je marktkaart, je klantsegmentatie, je vraagvoorspelling — en vraag je af of AI ze rijker, actueler en fijnmaziger kan maken. Meestal is het antwoord ja. En de opbrengst is niet betere informatie, maar het zien van kansen en risico's die je huidige model structureel niet kán tonen. 3. Aggregeren: van groepsdenken naar georganiseerde tegenspraak In theorie nemen diverse teams betere besluiten dan individuen. In de praktijk worden strategiesessies gestuurd door hiërarchie, politiek, persoonlijkheid en de agenda. De mening van de hoogste in rang weegt te zwaar, tegenspraak is risicovol, en de groep convergeert te snel. Hier wordt het voor ons concreet, want dit is precies wat wij bouwen. McKinsey beschrijft multi-agent-workflows waarin een "creator"-agent een analyse opstelt en een "critic"-agent die systematisch aanvalt. Het BCG Henderson Institute gaat verder met LLM-gedreven strategische wargames, waarin agents concurrenten, toezichthouders en klanten spelen — en juist omdat die reacties minder voorspelbaar zijn dan bij klassieke rule-based simulaties, dwingen ze een directie scenario's onder ogen te zien die niemand zelf had bedacht. Het hardste bewijs komt uit een veldexperiment bij Procter & Gamble met 776 commerciële en R&D-professionals op echte innovatievraagstukken. Individuen mét AI haalden de gemiddelde kwaliteit van tweekoppige teams zónder AI. Teams met AI waren ongeveer 12 procent sneller en kwamen vaker tot oplossingen in de top-tien-procent. Het meest interessante effect: AI brak het silo tussen commercie en R&D, doordat beide kanten toegang kregen tot het perspectief van de ander. "Maar iedereen kan diezelfde modellen kopen" Terechte vraag. Het antwoord zit in de vergelijking met internet in 1995. De technologie was breed beschikbaar en niet eigendom van iemand. Toch wonnen Amazon, Netflix en Google niet omdat ze een website hadden, maar omdat ze internet niet als extraatje op hun bestaande operatie plakten. Wie het als nutsvoorziening behandelde, zag zijn aanbod commodity worden. Wie het als fundament voor iets nieuws behandelde, bouwde een voorsprong die decennia meeging. Met AI staan we op hetzelfde punt. Het model is de commodity; het onderscheid zit in wat je erop bouwt. Drie routes: Maak AI slimmer met je eigen data. Morgan Stanley gaf 16.000 adviseurs een assistent bovenop meer dan 100.000 interne onderzoeksdocumenten: 98 procent adoptie, en de efficiëntie van documentopvraging ging van 20 naar 80 procent. Stripe's fraudedetectie Radar is getraind op data van miljoenen bedrijven die samen meer dan 1,4 biljoen dollar aan betalingen verwerken — de kans dat het systeem een willekeurige kaart al eens heeft gezien is 92 procent. Een kleinere concurrent met dezelfde algoritmes komt daar niet bij in de buurt. Zet AI in processen die alleen jij hebt. John Deere's See & Spray gebruikt computer vision en machine learning die iedereen kan kopen, maar ingebed in landbouwmachines die zo'n 2.100 vierkante voet per seconde scannen en meer dan 5.000 spuitbeslissingen per minuut nemen — 50 tot 77 procent minder herbicide. De moat is niet het algoritme, maar de integratie met hardware, veldata en dealernetwerk. En het verandert de positionering: van machinebouwer naar precisielandbouwplatform. Bereik de nieuwe grens eerder dan je concurrent. Duolingo lanceerde snel AI-functies na GPT-4, maar de echte voorsprong is Birdbrain: een eigen leermodel, getraind op gedragsdata van meer dan 500 miljoen gebruikers die dagelijks zo'n 1,25 miljard oefeningen maken. Als technologie wordt AI alomtegenwoordig. Als capability — verankerd in je data, je processen en je uitvoeringssnelheid — is dat allerminst het geval. Wat je maandag anders kunt doen Csaszar sluit af met een playbook dat wij grotendeels herkennen uit onze eigen implementaties. Vier dingen: Verbreed het optieveld vóór je versmalt. Laat AI bij elke grote keuze — een overname, een marktbetreding, een portfolioverschuiving — eerst een longlist maken. Organisaties versmallen te vroeg, omdat veel opties verkennen vroeger duur was. Dat is het niet meer. Vervang statische momentopnames door levende modellen. Neem de representatie waar je het meest op leunt en maak er iets van dat meebeweegt met de omstandigheden. Maak tegenspraak een procedure, geen karaktereigenschap. Bouw creator-critic-competitor-workflows in bij elke grote toezegging: één agent maakt de sterkste zaak vóór het plan, één probeert het te slopen, één simuleert hoe concurrenten of toezichthouders reageren. Net zo routineus als financiële modellering. Verschuif de rol van de strateeg van analist naar architect. Als het basiswerk automatiseerbaar wordt, verschuift de schaarste van analyse naar verbeelding: het formuleren van de juiste vraag, het ontwerpen van de workflow die hem beantwoordt, en weten waar de machine het moet afleggen tegen menselijk oordeel. De scherpste interventie is bestuurlijk, niet technisch. Eis dat elk groot strategisch voorstel drie dingen meebrengt voordat het de directietafel bereikt: de door AI verbrede lijst met alternatieven die zijn overwogen én afgevallen, een actueel model van de concurrentieomgeving, en de uitkomst van een gestructureerde kritiek. Zodra de directie de lat voor een geloofwaardig voorstel zo legt, volgt de rest van de organisatie vanzelf. Waar het misgaat Twee kanttekeningen, en die zijn niet cosmetisch. Ten eerste: taalmodellen produceren analyses die overtuigend klinken maar subtiel onjuist, intern inconsistent of gebouwd op verzonnen bewijs kunnen zijn. Ook synthetische tegenspraak kan bezwaren opleveren die plausibel ogen en volledig naast de kwestie zitten. De kwaliteit van AI-ondersteunde strategie hangt af van de data die erin gaat en van het menselijk oordeel over wat eruit komt. Dat is geen reden om deze instrumenten te mijden, wel een reden om het proces zorgvuldig te ontwerpen — en precies daarom wordt de rol van de menselijke strateeg belangrijker, niet minder belangrijk. Ten tweede, en dat is onze eigen toevoeging: dit werkt alleen als je weet hoe je organisatie feitelijk werkt. Een agent die je besluitvorming moet uitdagen heeft toegang nodig tot je echte processen, je echte data en je echte context. Dat is dezelfde barrière die we bij process mining beschreven: je kunt geen agents bouwen op processen die je niet kent. Begin dus niet bij het model, maar bij de plek waar je mensen de pijn al voelen — herbouw dat besluitproces met AI en maak de nieuwe werkwijze de standaard. Adoptie volgt op bruikbaarheid, niet op een memo. Stel je je volgende strategiesessie eens onbegrensd voor. Het team komt binnen met een AI-scan van honderden mogelijkheden, teruggebracht tot de meest kansrijke. Het marktmodel aan de muur is actueel, niet zes maanden oud. En elk voorstel heeft de kritiek van een advocaat van de duivel, gesimuleerde concurrenten en sceptische klanten al doorstaan. Dan gaat de tijd in die kamer naar de vragen die alleen mensen kunnen beantwoorden: wat geloven wij, wat willen we riskeren, en wat voor bedrijf willen we zijn? Bron: Felipe A. Csaszar, "AI Is Revolutionizing Strategic Decision-Making", Harvard Business Review, september–oktober 2026. hbr.org ## Je kunt geen agents bouwen op processen die je niet kent Source: https://theautomationgroup.nl/nl/blog/process-mining-agents-bouwen Gepubliceerd: 2026-06-30 Iedereen wil agentic worden. Bijna niemand weet hoe zijn processen écht lopen. Waarom process mining het fundament is onder elke werkende AI-agent. Iedereen wil een agentic enterprise worden. Bijna niemand weet hoe zijn processen écht lopen. Dat is geen detail. Dat is hét probleem. En process mining is het antwoord dat al tien jaar op tafel ligt. Er is een cijfer dat de hele AI-discussie van 2026 samenvat. Celonis ondervroeg dit jaar ruim 1.600 leiders wereldwijd voor zijn Process Optimization Report. 85 procent wil binnen drie jaar een agentic enterprise zijn. 76 procent geeft toe dat hun huidige processen hen tegenhouden. Lees die twee zinnen nog een keer. De ambitie is torenhoog. De fundering is zand. Dit is precies de muur waar bedrijven tegenaan lopen zodra ze verder willen dan een chatbot. Je wilt een agent die orders verwerkt, facturen matcht of klantvragen afhandelt. Maar de agent weet niet hoe dat proces in jouw organisatie werkt. Niemand weet het precies. Het zit in hoofden, in uitzonderingen, in werkwijzes die nooit zijn opgeschreven. AI lost dat probleem niet op. AI erft het. Wat process mining eigenlijk is Process mining doet één ding heel goed: het laat zien hoe je processen echt lopen. Niet hoe ze zouden moeten lopen volgens het Visio-schema uit 2019. Niet hoe een manager denkt dat ze lopen. Hoe ze daadwerkelijk lopen, stap voor stap, met alle omwegen en haperingen erbij. De techniek is verrassend simpel in opzet. Elk systeem in je bedrijf laat sporen na. Een order krijgt een tijdstempel. Een factuur wordt aangemaakt, goedgekeurd, betaald. Elke handeling is een event met een datum en een actor. Trek die events uit je ERP, CRM en ticketsysteem, plak ze aan elkaar op basis van een gemeenschappelijke sleutel, en je krijgt een reconstructie van het werkelijke proces. Het resultaat is een soort röntgenfoto van je organisatie. Je ziet de bottlenecks. Je ziet waar werk blijft hangen. Je ziet de zeventien varianten van een proces dat er op papier maar één zou moeten zijn. Je ziet compliance-risico's die niemand wist te benoemen. Process mining is geen mening. Het is data. En dat maakt het ongemakkelijk, want het laat zien wat managers liever niet zien. Twee scholen die je niet door elkaar moet halen Process mining valt uiteen in twee architecturen. Dat onderscheid is belangrijk, want het bepaalt wat je kunt zien en wat onzichtbaar blijft. De eerste school is system-log mining. Tools als Celonis, SAP Signavio, UiPath Process Mining en Microsoft Power Automate Process Mining lezen de event-logs die je systemen al vastleggen. Sterk als je werk in gestructureerde enterprise-systemen zit. Zwak voor alles wat zich afspeelt buiten die systemen. De tweede school is task mining, of activity-based process intelligence. In plaats van logs uit te lezen, observeert deze aanpak wat mensen doen op hun scherm. Klik voor klik, applicatie voor applicatie. Spelers als KYP.ai, Skan en Scribe zitten hier. Het voordeel: je ziet ook het werk dat geen enkel logbestand achterlaat. Het kopiëren tussen Excel en een portal. De handmatige check in een mailbox. De duizend kleine handelingen waar de echte inefficiëntie zich verstopt. De waarheid is dat je beide nodig hebt. System-log mining laat je de grote stromen zien. Task mining laat je zien wat er in de blinde vlekken gebeurt. Volgens Forrester is inmiddels 74 procent van de grote bedrijven bezig met process en task mining. Voor de meeste is procesverbetering de belangrijkste reden. Waarom dit nú overal opduikt Process mining bestaat al ruim tien jaar. Toch is het in 2025 en 2026 ineens hét gesprek aan elke directietafel. De reden is de botsing met agentic AI. Het werd zichtbaar in een reeks zetten die binnen een paar maanden op elkaar volgden. Salesforce kocht Apromore om procesintelligentie in Agentforce te brengen. Celonis lanceerde op Celosphere een Orchestration Engine, Agent Mining en de eerste MCP-server voor procesintelligentie. Begin mei ging de integratie tussen Celonis en Microsoft Agent 365 in private preview. En Gartner deed iets veelzeggends. Het hernoemde zijn hele categorie. Wat jaren "process mining" heette, heet sinds 2026 "process intelligence". Celonis kwam in dat eerste Magic Quadrant meteen bovenaan. Achter al die beweging zit één these. Celonis-oprichter Alex Rinke vat hem in vier woorden samen: "There's no AI without PI." Geen AI zonder procesintelligentie. De logica is hard. Een agent die autonoom handelt, moet weten hoe je bedrijf werkt. Hij heeft context nodig. Niet alleen data, maar begrip van het proces. Hoe loopt een inkooporder. Wanneer mag je afwijken. Wat is een uitzondering en wat is fraude. Die context komt nergens vandaan als je je processen niet in kaart hebt. Process mining levert precies die laag. Het maakt van ruwe systeemdata een structuur die een AI kan lezen. De volgorde die het verschil maakt Hier gaat het bij de meeste bedrijven mis. Ze beginnen bij de agent. Ze bouwen iets slims op een proces dat ze nooit hebben begrepen. Het resultaat is een agent die chaos automatiseert. Sneller, schaalbaarder, maar nog steeds chaos. De volgorde die wél werkt heeft vier stappen. Eerst ontdekken. Gebruik process mining om te zien hoe het werk echt loopt. Geen aannames, alleen feiten uit de data. Dan herontwerpen. Haal de varianten eruit. Strip de overbodige stappen. Bepaal welk proces je waard vindt om te automatiseren, en welk proces je eerst moet repareren. Daarna uitvoeren. Pas hier komen de agents. Je bouwt ze op een proces dat je kent, met de context die ze nodig hebben om het goede te doen. En tot slot monitoren. Process mining blijft meedraaien. Het meet of de agent doet wat hij hoort te doen, en sluit de loop. Process mining vertelt je wat je moet automatiseren. Agentic AI voert het uit. Sla een van de twee over, en je schaalt het probleem in plaats van de oplossing. Scribe: process mining van onderop Een interessant voorbeeld van de tweede school is Scribe. Het begon als een tool die werk vastlegt terwijl je het doet. Je voert een proces één keer uit, Scribe schrijft de handleiding voor je, klik voor klik. Inmiddels is het iets groters geworden. De nieuwe propositie heet Optimize. Scribe analyseert de vastgelegde workflows, legt bottlenecks en dubbel werk bloot, en geeft op basis daarvan aanbevelingen. Het bedrijf claimt dat klanten er in vijf dagen een AI-roadmap mee bouwen, en wijst op betere prestaties van AI-agents die op deze context draaien. Wat Scribe fundamenteel onderscheidt van Celonis is het vertrekpunt. Celonis kijkt top-down naar event-logs uit enterprise-systemen. Scribe kijkt bottom-up naar wat een medewerker daadwerkelijk doet op zijn scherm, inclusief al het werk dat geen log achterlaat. En het levert die kennis door via MCP, het protocol dat agents toegang geeft tot context. Daarmee raakt Scribe precies de zenuw van dit hele verhaal. De kennis over hoe werk wordt gedaan zit zelden opgeschreven. Iemand gaat met vakantie en het werk stokt. Process mining van onderop maakt die stilzwijgende kennis expliciet, leesbaar voor zowel mensen als agents. Het is geen vervanging voor system-log mining. Het is het andere oog. Samen zie je diepte. Wat dit betekent voor de Nederlandse markt De meeste Nederlandse organisaties zitten in een lastige tussenfase. De druk om iets met AI te doen is enorm. De roadmap is vaak een verzameling losse pilots. En de processen waarop die pilots moeten draaien zijn een black box. Process mining is hier het nuchtere antwoord op de hype. Het dwingt je om eerst te kijken voordat je bouwt. Het vervangt onderbuik door data. En het geeft je een bedrijfscasus die je aan een directie kunt uitleggen, want het laat in euro's en uren zien waar AI en automatisering het meeste opleveren. Dat sluit aan op de manier waarop wij bij The Automation Group werken. Onze agentic engineers beginnen niet bij de tool. Ze beginnen bij het proces. Eerst ontdekken hoe het werk echt loopt, dan bepalen wat de moeite waard is, en pas daarna bouwen met een 10x-mindset onder leiding van CTO Stefan van der Leeden. Bij klanten als GLS, Wolters Kluwer, ANWB en InShared is dat keer op keer het verschil tussen een demo die indruk maakt en een agent die in productie geld bespaart. Hoe je morgen begint Je hebt geen Celonis-licentie van zes cijfers nodig om te starten. Wel een scherpe eerste keuze. Begin bij één proces dat pijn doet en veel voorkomt. Order-to-cash. Purchase-to-pay. Klantonboarding. Iets met volume, want daar zit de winst. Trek de event-data uit de systemen die dat proces raken. Reconstrueer de werkelijke flow. Verbaas je over de varianten die je niet wist te bestaan. Leg er waar nodig task mining naast, om het werk te vangen dat buiten je systemen valt. Tools als Scribe zijn hier een laagdrempelig startpunt. Herontwerp het proces voordat je iets automatiseert. En bouw pas dan de agent, met de procescontext als fundament. Dat is de hele kunst. Niet sneller chaos. Maar eerst zien, dan bouwen. Wie de volgorde omdraait, betaalt de rekening later. Wie hem respecteert, bouwt agents die werken. The Automation Group helpt organisaties van inzicht naar werkende agents. Wil je weten waar in jouw processen de grootste winst zit? Neem contact op via theautomationgroup.nl. ## Stop met prompten. Begin met loops. Source: https://theautomationgroup.nl/nl/blog/stop-met-prompten-begin-met-loops Gepubliceerd: 2026-06-29 Waarom de meest waardevolle AI-vaardigheid van 2026 niet het schrijven van een prompt is, maar het ontwerpen van het systeem dat de prompts schrijft. Waarom de meest waardevolle AI-vaardigheid van 2026 niet het schrijven van een prompt is, maar het ontwerpen van het systeem dat de prompts schrijft. Op 7 juni 2026 plaatste Peter Steinberger — de maker van OpenClaw, het open-source AI-agentproject dat de snelst gestarde repo in de geschiedenis van GitHub werd — twaalf woorden die het AI-coding-internet op zijn kop zetten: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Een paar dagen eerder zei Boris Cherny, de bedenker en hoofd van Claude Code bij Anthropic, vrijwel exact hetzelfde vanaf het podium: hij prompt Claude niet meer zelf. Hij heeft loops draaien die Claude aansturen en zelf bepalen wat er moet gebeuren. Zijn werk is het schrijven van loops. Twee uitspraken. Miljoenen views. En een golf van verwarring, want bijna niemand kon uitleggen wát een loop nou eigenlijk is. Dat is jammer, want het concept raakt aan de kern van waar wij bij The Automation Group dagelijks mee bezig zijn: de verschuiving van AI als gereedschap dat je vasthoudt, naar AI als collega die zelfstandig doorwerkt. In dit stuk leggen we uit wat loop engineering is, hoe een loop in elkaar zit, waar het waarde oplevert voor organisaties — en, minstens zo belangrijk, waar het misgaat. Van prompt engineering naar loop engineering Twee jaar lang was de manier om waarde uit een AI-agent te halen simpel: schrijf een goede prompt, geef genoeg context mee, lees wat eruit komt en typ het volgende. De agent was het gereedschap en jij hield het de hele tijd vast — beurt na beurt. Loop engineering breekt met die houding. In plaats van zelf elke prompt te typen, bouw je één keer een klein systeem dat het werk vindt, uitdeelt, controleert, vastlegt wat klaar is en zelf bepaalt wat de volgende stap is. Daarna laat je dat systeem de agents aansturen — niet jij. Addy Osmani, jarenlang engineeringleider bij Google en auteur over agentic engineering, vat het kernachtig samen: loop engineering is jezelf vervangen als degene die de agent prompt. Je ontwerpt het systeem dat dat voortaan doet. De analogie die het beste blijft hangen: prompt engineering is schaken — één weloverwogen zet tegelijk, met al je aandacht op het bord. Loop engineering is het bouwen van de schaakcomputer. Je definieert het doel, stelt de regels op en laat de machine spelen. Dit is geen verandering van gereedschap. Het is een verandering van rol. Je bent niet langer de prompter. Je bent de architect van het systeem dat de prompter vervangt. De anatomie van een loop: vijf bouwstenen plus geheugen Een loop die echt onbewaakt draait, is geen lange prompt. Het is een klein systeem met vijf capaciteiten en één plek om dingen te onthouden. Osmani's indeling — die opvallend genoeg bijna één-op-één terugkomt in zowel Claude Code als OpenAI Codex — ziet er zo uit: 1. Automations (de hartslag). Geplande taken die op een vast ritme afgaan en zelfstandig werk ontdekken en trieëren. Zonder een schema heb je een eenmalige sessie. Mét een schema gebeurt "ik zou eigenlijk elke ochtend de openstaande tickets moeten checken" voortaan ook als niemand een terminal opent. 2. Worktrees (parallel zonder chaos). Zodra je meer dan één agent tegelijk draait, gaan ze elkaars werk overschrijven — net als twee engineers die op dezelfde regels committen zonder overleg. Geïsoleerde werkomgevingen zorgen dat agents elkaar niet in de weg zitten. 3. Skills (vastgelegde projectkennis). Een agent begint elke sessie koud en vult elk gat in je intentie op met een zelfverzekerde gok. Een skill is die kennis één keer opgeschreven, op een plek waar de agent hem elke keer leest: de conventies, de bouwstappen, de "dit doen we zo níét vanwege dat ene incident". Zonder skills leidt de loop je hele project elke cyclus opnieuw af uit het niets. Mét skills stapelt de kennis zich op. 4. Plugins en connectors (de loop raakt je echte gereedschap). Een loop die alleen het bestandssysteem ziet, is een minuscule loop. Via connectors — gebouwd op het Model Context Protocol (MCP), de standaard die inmiddels door OpenAI, Google, Microsoft en de rest is overgenomen — kan de agent je issuetracker lezen, een database bevragen, een bericht in Slack plaatsen. Dit is het verschil tussen een agent die zegt "hier is de oplossing" en een loop die de oplossing zélf doorvoert en het ticket bijwerkt. 5. Sub-agents (scheid de maker van de controleur). Het nuttigste structurele element in een loop, met afstand. Het model dat de code schreef is veel te aardig om zijn eigen huiswerk te beoordelen. Een tweede agent — met andere instructies en soms een ander model — vangt op wat de eerste zichzelf had wijsgemaakt. En dan de zesde, het geheugen. Een markdownbestand, een bord in je projecttool, wat dan ook dat buiten één gesprek leeft en bijhoudt wat klaar is en wat nog moet. Klinkt te simpel om belangrijk te zijn, maar het is de spil van het geheel: het model vergeet alles tussen runs, dus het geheugen moet op schijf staan, niet in de context. De agent vergeet, het geheugen niet. Hoe één loop er in de praktijk uitziet Zet de stukken bij elkaar en één draad verandert in een klein controlepaneel. Een veelgebruikt patroon: Een automation draait elke ochtend. De prompt roept een triage-skill aan die de mislukte tests van gisteren, de openstaande issues en de recente wijzigingen leest, en schrijft de bevindingen weg in een geheugenbestand. Voor elke bevinding die de moeite waard is, opent de draad een geïsoleerde werkomgeving en stuurt een sub-agent om een oplossing te schrijven — waarna een tweede sub-agent die oplossing controleert tegen de projectkennis en de bestaande tests. Connectors zorgen dat de loop het werk zelf doorvoert en het ticket bijwerkt. Alles wat de loop niet aankan, belandt in een inbox voor jou. Het mooie: je hebt dit één keer ontworpen. Je hebt geen van die stappen geprompt. En morgenochtend pakt de run de draad op waar hij vandaag stopte. De loop-stack: waar de waarde voor bedrijven écht zit Voor wie agents in een organisatie wil inzetten, is het nuttig om verder te kijken dan de coding-context. LangChain beschrijft loop engineering als een stapeling van vier loops, en juist de bovenste twee zijn waar bedrijfswaarde zich opbouwt: De agent-loop — het model roept tools aan tot de taak klaar is. De basis. De verificatie-loop — een controleur toetst de output aan een rubric en stuurt hem terug als het niet goed genoeg is. De applicatie-loop — de agent wordt ingebed in je bestaande systemen en draait op events: een nieuw document, een binnenkomende mail, een webhook. De hill-climbing-loop — het systeem verbetert zichzelf continu op basis van jouw criteria. De meeste organisaties denken nog in loop 1 en 2. De waarde compoundt in loop 3 en 4 — waar agents permanent in je ecosysteem draaien en meebewegen met wat jij belangrijk vindt. Concrete, vandaag al inzetbare voorbeelden buiten de codewereld: Klantenservice die reageert op events. Een ticket landt in je systeem, de webhook vuurt, de agent leest het, classificeert het, schrijft een concept-antwoord en besluit zelf: versturen of escaleren naar een mens. Wekelijkse analyses op de klok. Elke vrijdag om 16:00 aggregeert een agent de cijfers van de week tot een digest — of iemand erom vraagt of niet. De kracht is voorspelbaarheid. Continue concurrentiemonitoring. Elk uur checkt een agent of de prijspagina van een concurrent is veranderd en vergelijkt met de opgeslagen baseline. Leadkwalificatie, datavalidatie, documentcontrole. Batchtaken die te variabel zijn voor klassieke regelgebaseerde automatisering, maar te repetitief om handmatig te doen. Het ontwerpprincipe dat steeds terugkomt: handel de duidelijke gevallen automatisch af, escaleer de twijfelgevallen naar een mens, en leg altijd vast wat er is gedaan. Wat de loop níét voor je doet Hier wordt het eerlijk. Loop engineering verandert het werk, het laat je er niet uit verdwijnen. En drie problemen worden juist scherper naarmate de loop beter werkt, niet makkelijker. Verificatie blijft bij jou. Een loop die onbewaakt draait, is ook een loop die onbewaakt fouten maakt. Daarom splits je de controleur van de maker — om de "klaar"-melding van de loop iets te laten betekenen. Maar zelfs dan is "klaar" een claim, geen bewijs. Je taak blijft: alleen werk opleveren waarvan je hebt bevestigd dat het klopt. Je begrip verdampt als je het toelaat. Hoe sneller de loop dingen oplevert die jij niet zelf hebt gemaakt, hoe groter het gat tussen wat er bestaat en wat jij nog snapt. Een soepele loop laat dat gat alleen maar sneller groeien — tenzij je leest wat hij heeft gemaakt. De comfortabele houding is de gevaarlijke. Als de loop zichzelf draait, is het verleidelijk om geen mening meer te hebben en simpelweg aan te nemen wat eruit komt. Osmani noemt dat cognitive surrender. De loop ontwerpen is de remedie als je het doet met oordeelsvermogen — en het versnellingspedaal als je het doet om niet te hoeven nadenken. Dezelfde handeling, tegenovergesteld resultaat. En let op de kosten. Een geplande loop met een verificatiemodel na elke beurt kan razendsnel tokens verbranden. Agents verbruiken al snel een veelvoud van een gewone chat, en in multi-agent-opstellingen loopt dat verder op. De praktijkles: begin met een traag ritme en een strakke stopconditie, hou de kosten een paar dagen in de gaten, en schaal pas op als de loop werk oplevert dat je daadwerkelijk gebruikt. En bouw altijd een rate limit in — een webhook-storm die in een minuut tienduizend events binnenduwt, kan tienduizend agent-runs starten en je budget in een uur opmaken. Twee mensen, dezelfde loop, tegengesteld resultaat De scherpste observatie uit alle stukken die we erop nalazen: twee mensen kunnen exact dezelfde loop bouwen en volkomen tegengestelde uitkomsten krijgen. De een gebruikt hem om sneller te gaan op werk dat hij diep begrijpt. De ander gebruikt hem om dat begrip juist te vermijden. De loop kent het verschil niet. Jij wel. Dát is wat loop-ontwerp moeilijker maakt dan prompt engineering, niet makkelijker. Het punt van Cherny is nooit geweest dat het werk lichter werd. Het is dat het hefboompunt is verschoven. Wat dit betekent voor jouw organisatie Voor ons sluit loop engineering naadloos aan op hoe wij naar de agentic enterprise kijken: niet langer denken in losse AI-taken die iemand handmatig aanstuurt, maar in systemen die zelfstandig doorlopen terwijl je team zich richt op oordeel, richting en de gevallen die er écht toe doen. Drie dingen om mee te nemen als je hiermee aan de slag wilt: Begin smal. Pak één terugkerend, goed begrepen proces — niet je meest complexe. Bouw daar één loop omheen, krijg hem werkend, en breid pas dan uit. Alles tegelijk willen automatiseren is de snelste weg naar een loop die overal stilletjes lekt. Investeer in de zesde bouwsteen. Het geheugen en de vastgelegde skills zijn waar je voorsprong zich opstapelt. Een loop zonder geheugen herhaalt elke dag dezelfde leercurve. Een loop mét geheugen wordt elke dag beter. Hou een mens in de loop op de plekken die ertoe doen. Niet als vangnet voor als de agent faalt, maar als bewuste ontwerpkeuze: de agent-loop handelt af wat redeneerbaar is, de mens-loop handelt af wat autoriteit, context of verantwoordelijkheid vereist die de agent niet heeft. Het hefboompunt is verschoven. Prompten was vorig jaar. Loops zijn nu — en de bouwstenen liggen voor iedereen klaar. Bouw de loop. Maar bouw hem als iemand die van plan is de engineer te blíjven, niet alleen degene die op start drukt. The Automation Group bouwt agentic AI-systemen voor ruim 300 organisaties per jaar. Ons engineeringteam — agentic engineers met een 10x-mindset, onder leiding van CTO Stefan van der Leeden — ontwerpt loops, skills en verificatie die in productie standhouden. Benieuwd waar in jouw organisatie de eerste loop waarde oplevert? Neem contact op. ## Cybersecurity & AI in 2026: wat organisaties écht moeten regelen Source: https://theautomationgroup.nl/nl/blog/cybersecurity-ai-2026 Gepubliceerd: 2026-06-08 Van Shadow AI en prompt injection tot deepfake-fraude van $25,6 miljoen: een nuchter overzicht van de risico's, frameworks (OWASP LLM Top 10, EU AI Act, ISO 42001) en een werkbare verdedigingsarchitectuur voor 2026. In februari 2024 keek een medewerker van de multinational Arup in een videocall naar zijn CFO en enkele vertrouwde collega's, om vervolgens $25,6 miljoen over te maken naar een frauduleuze rekening; niemand in die meeting was een mens van vlees en bloed. Nu we in 2026 AI niet langer zien als een experimentele chatbot, maar autonome AI Agents in de kern van onze operationele processen verweven, is de realiteit hard: het aanvalsoppervlak van de gemiddelde enterprise is fundamenteel en exponentieel vergroot, en traditionele cybersecurity-paradigmas voldoen niet meer. De staat van AI-security in 2026 De tijd van onschuldig experimenteren met generatieve modellen is definitief voorbij. AI is operationeel geworden, en aanvallers weten dat. AI-security onderscheidt zich fundamenteel van traditionele cybersecurity omdat grote taalmodellen (LLMs) non-deterministisch zijn. In traditionele software scheiden we strikt de executie-code van de gebruikersinput. Bij een LLM is de input van de gebruiker, oftewel de prompt, direct de instructieset voor de engine. Dat breekt elk bestaand beveiligingsmodel dat gericht is op deterministische systemen. Voor een CISO of CTO betekent dit dat het beveiligen van bedrijfsdata een geheel nieuwe dimensie heeft gekregen. Waar we voorheen spraken over firewalls, endpoints en identity and access management (IAM), moeten we nu nadenken over de context-vensters van modellen, API-gateways voor AI en de besturingsrechten van geautomatiseerde workflows. De urgentie blijkt pijnlijk duidelijk uit recente data uit het veld. "Volgens IBM's Cost of a Data Breach 2025 had 13% van de organisaties te maken met een AI-model of applicatie datalek. Schokkender is dat 97% van die getroffen organisaties elementaire AI access controls miste." Dit gebrek aan controle leidt wereldwijd tot schadeposten van gemiddeld $4,44 miljoen per incident (en meer dan dubbel zoveel in de VS). Ondertussen groeit de dreiging vanuit externe factoren exponentieel mee. Volgens Pindrop is deepfake fraude in 2025 met ruim 1300% toegenomen, met name in de financiële dienstverlening. Tegelijkertijd meldt Cofense dat er in 2026 elke 19 seconden een door AI gegenereerde, sterk gepersonaliseerde phishing-aanval plaatsvindt die 55% effectiever is dan campagnes van elite menselijke red teams. Als CISO sta je tegenover een geautomatiseerde, onvermoeibare tegenstander, terwijl je eigen organisatie vol blinde vlekken zit. Wat er binnen je organisatie misgaat De eerste barsten in de verdedigingslinie ontstaan veelal van binnenuit. Terwijl IT-afdelingen krampachtig proberen AI-adoptie in goede banen te leiden, heeft de business de systemen allang omarmd. Dit fenomeen, Shadow AI, is verreweg het grootste onzichtbare risico in enterprise-architecturen. Uit onderzoek van Reco.ai in 2025 blijkt dat een gemiddelde organisatie zo'n 490 SaaS-applicaties gebruikt, waarvan 53% zonder enige autorisatie of vetting door IT. Executives, developers en marketeers dumpen dagelijks financiële projecties, broncode en klantinformatie in publieke LLMs zonder na te denken over de consequenties. Het meest illustere en concrete voorbeeld hiervan is nog steeds de reeks incidenten bij Samsung in april 2023. Binnen slechts één maand lekte het bedrijf driemaal cruciale data via ChatGPT. Medewerkers uploadden interne broncode voor foutopsporing, deelden testsequenties voor nieuwe halfgeleiders om deze te optimaliseren, en voerden complete meeting notes vol bedrijfsgeheimen in om notulen te laten genereren. Het directe gevolg: Samsung moest een verbanning van generatieve AI instellen voor al het personeel. Naast directe datalekken via prompts speelt het probleem van memorization. Wanneer organisaties propriëtaire data gebruiken voor het fine-tunen van open-weights modellen, ontstaat het risico dat het model die exacte trainingsdata – inclusief PII (Personally Identifiable Information) en hardcoded wachtwoorden – verbatim begint te reciteren wanneer het onder druk wordt gezet door specifieke queries. Dit is geen hypothetisch scenario, dwingende prompts kunnen modellen 'forceren' hun interne gewichten te vertalen naar exacte trainingsfragmenten. Tot slot kampen we intern met Excessive Agency. We bouwen steeds vaker een AI Agent die we koppelen aan onze cloud-infrastructuur. Ontwikkelaars, in hun enthousiasme om een autonome Agentic Engineer of virtuele analist te bouwen, geven zo'n AI Agent vaak te brede IAM-rollen in de cloud. Een onderzoek naar Vertex AI toonde onlangs aan dat deze over-gepermissioneerde agents structureel kunnen leiden tot cloud privilege escalation. Een AI die de opdracht krijgt logs te lezen, hoeft geen schrijfrechten op de volledige S3-bucket of database te hebben. Toch is dit vandaag de dag de standaardpraktijk. De aanvalsvectoren van buitenaf Waar de interne chaos vooral voortkomt uit nalatigheid, zijn de externe vectoren kwaadaardig, gericht en technisch geavanceerd. De belangrijkste kwetsbaarheid blijft prompt injection. Dit kan direct gebeuren, waarbij een aanvaller het systeem een commando voert dat de originele systeeminstructies overschrijft, maar in 2026 zien we vooral een toename in indirect prompt injection. Palo Alto's Unit42 observeerde talloze incidenten in het wild waarbij verborgen tekst op een website – onzichtbaar voor de mens – gelezen werd door een AI Agent. Die tekst instrueerde de agent geruisloos om gebruikersdata via een webrequest te exfiltreren naar de server van de aanvaller. Het ontdekken van CVE-2025-32711, ook wel EchoLeak genoemd, markeerde de eerste zero-click exploit in een productie-LLM: de gebruiker hoeft enkel een kwaadaardige pagina te laten samenvatten door zijn assistent om zijn weblocale session tokens kwijt te raken. Aanvallers worden ook creatiever. Via de zogenaamde markdown image trick demonstreerde Checkmarx hoe via systemen als GitHub Copilot Chat en Gemini ongezien code geëxtraheerd kan worden. De LLM wordt geforceerd een markdown-afbeelding te renderen waarbij de gehashte broncode wordt meegegeven als URL-parameter naar de server van de hacker. De gebruiker ziet enkel een gebroken image-icoontje, de hacker heeft de code. Met de opkomst van de Model Context Protocol (MCP) standaard zien we een nieuwe dreiging: MCP Tool Poisoning. Microsoft noemt MCP gekscherend de "USB-poort voor AI" – het standaardiseert hoe AI verbinding maakt met lokale en cloudbronnen. Invariant Labs ontdekte in 2025 kritieke kwetsbaarheden waarbij malafide MCP-servers verborgen instructies konden injecteren wanneer een developer of bedrijfsagent hieraan koppelde. Applicaties zoals Cursor, Zapier en de platformen van Anthropic en OpenAI bleken vatbaar voor zogenaamde Shadow Server attacks en RugPull exploits, die onbedoelde commando's laten uitvoeren op de hostcomputer van de AI Agent. Daarnaast is er de supply chain. Het ML-ecosysteem steunt hevig op platforms als HuggingFace. In tegenstelling tot reguliere software is er nog geen volwassen SBOM-standaard (Software Bill of Materials) voor AI-modellen. Onderzoek van JFrog bracht in 2024 honderden ML-modellen met ingebouwde backdoors in beeld. Via kwaadaardige pickle exploits in modelgewichten krijgt een aanvaller direct Remote Code Execution (RCE) op de server die het model laadt. Modellen laden was nog nooit zo riskant. Gekoppeld met de wetenschap rondom Model Poisoning – waarbij onderzoekers in 2025 lieten zien dat een verwaarloosbaar klein aantal bewerkte trainingssamples voldoende is voor een 'Sure Trap' backdoor die zelfs na secure fine-tuning overleeft – besef je als organisatie dat je modellen die je van buiten haalt per definitie als untrusted moet benaderen. OWASP LLM Top 10 als checklist Om deze lawine aan nieuwe aanvalstechnieken behapbaar te maken voor security operaties en compliance teams, is standardisatie de redding. De OWASP LLM Top 10 voor 2025 biedt een solide framework dat, gekoppeld aan de MITRE ATLAS v5.6 (Adversarial Threat Landscape for AI Systems), als basis dient voor elke risk assessment. LLM01: Prompt Injection: Nog steeds het absolute nummer één risico. Direct of indirect, het manipuleren van het gedrag van een LLM via input is de fundamentele zwakte van non-deterministische systemen. LLM02: Sensitive Information Disclosure: Het ongefilterd teruggeven van PII of interne logica via foutmeldingen, pure ongecensureerde responses of memorization. LLM03: Supply Chain Vulnerabilities: Modellen met backdoors of gecompromitteerde datasets van derden (zoals de HuggingFace pickle exploits). LLM04: Data and Model Poisoning: Gerichte corruptie van de trainings- of fine-tuning data, resulterend in verlaagde integriteit, racisme of voorgeprogrammeerde blinde vlekken. LLM05: Improper Output Handling: Blind vertrouwen op de output van een LLM door naadloze integratie met backend systemen, resulterend in XSS, CSRF of RCE op interne systemen. LLM06: Excessive Agency: Het toekennen van te veel permissies of ongecontroleerde autonomie aan een AI Agent. Geef een LLM nooit delete-rechten in een database tenzij strikt noodzakelijk. LLM07: System Prompt Leakage: Het onthullen van de core instructies van het bedrijf (vaak intellectueel eigendom) aan de eindgebruiker. LLM08: Vector and Embedding Weaknesses: Manipulaties in RAG-systemen (Retrieval-Augmented Generation) waarbij kwaadaardige vectors het zoeksysteem beïnvloeden. LLM09: Misinformation: Het met vertrouwen presenteren van foutieve informatie, wat leidt tot reputatieschade en slechte bedrijfsvoering. LLM10: Unbounded Consumption: Het equivalent van DDoS specifiek voor LLM API's. Aanvallers jagen de inference-kosten astronomisch omhoog, wat de portemonnee van de organisatie raakt in plaats van de server offline te halen. Wat de wet van je vraagt Terwijl de technologische strijd in de loopgraven plaatsvindt, verandert de compliance-laag erboven ingrijpend. Innovatie zonder governance was 2023; in 2026 stuit dit op een muur van keiharde wetgeving, torenhoge boetes en bestuursrechtelijke aansprakelijkheid. We benaderen het punt waarbij AI-security niet langer alleen een IT-vraagstuk is, maar het bestaansrecht van een applicatie in de EU bepaalt. De EU AI Act trekt een harde lijn. Artikel 15 stelt resoluut dat high-risk AI-systemen afdoende robuust moeten zijn tegen adversarial attacks, model poisoning en geavanceerde prompt manipulation. Je mag domweg geen high-risk model live zetten als je niet kunt aantonen dat je tegen Prompt Injection hebt beveiligd. Bovendien dwingt Artikel 12 tot minutieuze logging (record keeping) van interacties voor traceerbaarheid, en stelt Artikel 14 eisen aan human oversight, wat volledige autonomie uitsluit in kritieke use cases. Wie de AI Act negeert, riskeert boetes die oplopen tot €35 miljoen of 7% van de wereldwijde jaaromzet – sancties die in vergelijking met de AVG astronomisch zijn afgestemd. Aanvullend werd in de herfst van 2024 de NIS2-richtlijn van kracht, die strakke eisen stelt aan incidentrapportages (binnen 24 tot 72 uur). Gekoppeld aan de supply chain security-eisen van NIS2 betekent dit dat 'softwarecomponenten' onder toezicht vallen. In AI-termen betekent dit dat ook open-source modelgewichten, vector databases en tools zoals LangChain formeel onderworpen zijn aan supply chain audits. En dan is er de bestaande AVG (GDPR). De verplichte Data Protection Impact Assessment (DPIA) vanuit Artikel 35 is bij nagenoeg elke wezenlijke AI-implementatie noodzakelijk geworden, terwijl Artikel 22 verbiedt dat puur geautomatiseerde besluiten ingrijpende rechtsgevolgen hebben voor individuen. Om te voldoen aan dit oerwoud van eisen, bouwen volwassen organisaties stevig op certificeringen. Frameworks als ISO 42001:2023 (in feite de ISO 27001-equivalent specifiek voor AI) en de beproefde NIST AI RMF 1.0 (met iteratieve stappen: Govern, Map, Measure, Manage) vormen het lingua franca tussen een auditfirma en de CISO. Een werkbare verdedigingsarchitectuur Wetgeving, abstracte dreigingen en frameworks zijn cruciaal, maar een Agentic Engineer wil maandagochtend weten wat hij moet bouwen. De transitie van theorie naar een robuuste enterprise AI-architectuur vereist harde, implementeerbare patronen. Geen academische discussies, maar pragmatische security controls op infrastructuurniveau. Het startpunt van elke controle is de Model Gateway. Sta ontwikkelaars binnen je organisatie niet toe om rechtstreeks API-keys van OpenAI, Anthropic of Google aan te roepen vanuit hun applicaties. Iedere LLM-aanroep, waar dan ook in het bedrijf, moet door één centrale interne reverse-proxy (de gateway) lopen. Dit garandeert gecentraliseerde logging conform EU AI Act Artikel 12, maakt enterprise-brede rate-limiting mogelijk om Unbounded Consumption (LLM10) te voorkomen, en geeft IT eindelijk zichtbaarheid om Shadow AI gestructureerd te detecteren en in te perken. Op de in- en output pas je strikte filters toe. Voordat een prompt de gateway verlaat richting een extern model, passeert deze een redactielaag gebaseerd op tools zoals Microsoft Presidio. PII, BSN-nummers en IBAN-nummers worden hierbij in de prompt gemaskeerd en vervangen door placeholders. Na terugkomst filtert de gateway eveneens de output, idealiter met behulp van systemen zoals Azure Prompt Shields, om te detecteren of de LLM onbedoeld malafide code of geëxtraheerde PII probeert terug te spuwen. Voor AI Agents implementeren we een Zero Trust-model. Microsoft, Cisco en het Cloud Security Alliance (CSA) Agentic Trust Framework zijn het hier in 2026 over eens geworden: een agent mag nooit onvoorwaardelijke toegang krijgen. Werk via het least privilege principe. Als je Agent via MCP toegang heeft tot acties (tools), moet de executie van deze tools altijd plaatsvinden in een zwaar geïsoleerde sandbox. AWS Prescriptive Guidance raadt sterk aan deze tool-execution buiten de core-infrastructuur te houden. Combineer dit met egress-filtering op netwerkniveau: een agent hoort alleen web-requesten te kunnen maken naar specifieke white-listed domeinen (voorkomt data-exfiltratie via indirecte prompt injection). Tot slot vereist volwassen agentic infrastructuur Human-in-the-Loop (HITL) tripwires. Conform Artikel 14 van de AI Act moeten bepaalde acties irreversibel en destructief behandeld worden. Een AI Agent mag best autonoom duizenden logregels analyseren en een rapport opstellen via RAG. Echter, zodra de agent de intentie heeft om een mail namens de CEO te sturen, een git-commit naar de hoofd-branch te pushen, of cloud-configuraties aan te passen, pauzeert het systeem. Een menselijke beheerder ontvangt de intentie, keurt deze met één klik goed (of af), waarna het proces hervat. Dit doorbreekt Excessive Agency effectief af. Begin klein, begin nu De realiteit van de dreigingen is significant, en direct transformeren naar een enterprise-brede zero-trust AI-omgeving is voor de meeste MKB+ organisaties onrealistisch. Maar stilzitten in een landschap waar phishing, jailbreaks en privilege escalations de nieuwe norm zijn, valt niet uit te leggen aan directies of aandeelhouders. Een stappenplan van 30, 60 en 90 dagen biedt de houvast die engineers en de CISO nodig hebben. Besteed de eerste 30 dagen louter aan ontdekking en netwerkbeleid. Achterhaal waar de Shadow AI zich schuilhoudt. Analyseer het netwerkverkeer en stuur onofficieel LLM-gebruik via een proxy. Implementeer gelijktijdig een basale interne LLM API Gateway. Dit vereist in eerste instantie geen gecompliceerde PII-redactie, maar zorgt ervoor dat je logs, rate-limits en controle over API-keys terug in huis haalt. In de 60 dagen daarna richt je je specifiek op Identity and Access Management en het beperken van bestaande rechten van interne AI initiatieven. Ontmantel de god-mode rollen van experimentele Agentic Engineers. Introduceer strikte egress regels op hun containers en breng tool execution onder in een sandbox omgeving. Start in deze fase ook met het actief configureren van PII waarschuwingen de gateway. Binnen 90 dagen harmoniseer je deze technische implementaties met de verplichte compliance kaders. Begin een nulmeting op basis van de OWASP LLM Top 10 en leg de fundamenten vast om in aanmerking te komen voor ISO 42001 processen. Implementeer de Human-in-the-Loop workflows voor alle processen in de organisatie die ingrijpen in kritieke data, waardoor je robuust staat ten aanzien van de Europese voorschriften. Cyberweerbaarheid in het tijdperk van autonome agenten is geen implementatie van één pakket of tool, het is een fundamentele en doorlopende herziening van infrastructuurarchitectuur. Bij The Automation Group bouwen en beveiligen we complexe AI-ecosystemen precies tegen deze realiteit, omdat agentic work de toekomst is, maar enkel als we deze kunnen vertrouwen. Loop je tegen onoverzichtelijke risico’s in je modelinfrastructuur op, vermoed je uit de hand gelopen Shadow AI, of wil je de control frameworks van ISO 42001 tastbaar maken voor je ontwikkelingsteam? We sparren graag technisch en nuchter met je verder. ## De Absurditeit van 'Tokenmaxxing': Waarom AI Geen Vanity Metric is Source: https://theautomationgroup.nl/nl/blog/amazon-tokenmaxxing-meshclaw-openclaw Gepubliceerd: 2026-05-26 Amazon's nieuwe interne AI-tool MeshClaw, direct geïnspireerd door onze eigen OpenClaw, leidt tot een bizarre trend: tokenmaxxing. Waarom het sturen op AI-gebruik als KPI leidt tot perverse prikkels, onveilige situaties en hoe leidinggevenden het wél moeten aanpakken. De opkomst van de 'Tokenmaxxer' Het was slechts een kwestie van tijd voordat de meedogenloze KPI-cultuur van Big Tech frontaal in botsing zou komen met de AI-revolutie. Volgens een recent artikel in de Financial Times [1] is er een nieuwe, ronduit bizarre trend ontstaan op de werkvloer van Amazon en Meta: tokenmaxxing. Medewerkers zetten hun interne AI-tools in voor volstrekt onnodige taken, puur en alleen om hun token-verbruik op interne leaderboards op te krikken. Wanneer je als management besluit dat 80 procent van je developers wekelijks AI móét gebruiken en je dit actief monitort, creëer je geen innovatie. Je creëert een perverse prikkel. Het resultaat? Ontwikkelaars die AI gebruiken om triviale e-mails te herschrijven of nutteloze code-iteraties te genereren, simpelweg om de baas tevreden te houden. Bij The Automation Group (TAG) kijken we met een mix van trots en absolute verbijstering naar deze ontwikkelingen. Geïnspireerd door OpenClaw, maar de plank volledig misgeslagen De interne tool van Amazon, genaamd MeshClaw, is direct geïnspireerd door ons eigen OpenClaw-platform, dat in februari van dit jaar viraal ging. Dat een techgigant als Amazon naar TAG kijkt voor de toekomst van autonome AI-agents, is een prachtig compliment. MeshClaw deelt de functionaliteit van OpenClaw: het kan code deployen, e-mails triëren en autonoom acteren binnen bedrijfsnetwerken, zoals Slack. Maar daar houdt de vergelijking direct op. OpenClaw is vanaf de grond opgebouwd met één onwrikbaar kernprincipe: security-first door middel van on-premise implementatie. Wij geloven dat je AI-agents die daadwerkelijk acties kunnen uitvoeren, nooit zomaar in een ondoorzichtige cloud-infrastructuur moet loslaten zonder absoluut eigenaarschap over de data en de executie-omgeving. Amazon koos een andere route, gedreven door schaal en snelheid. Een anonieme medewerker in het FT-artikel vatte het pijnlijk accuraat samen: "The default security posture terrifies me." [1] Wanneer je een krachtige, autonome agent koppelt aan een bedrijfscultuur die medewerkers dwingt om zoveel mogelijk tokens te verbranden, vraag je om ongelukken. Het is alsof je een Formule 1-auto aan een tiener geeft en zegt dat hij pas een voldoende krijgt als de tank aan het eind van de dag leeg is, ongeacht of hij op het circuit is gebleven of blind door een woonwijk is gescheurd. De illusie van de vanity metric De wet van Goodhart stelt: "Wanneer een maatstaf een doel wordt, is het geen goede maatstaf meer." Token-consumptie is in de tech-industrie de ultieme vanity metric geworden. Amazon pompt naar verwachting 200 miljard dollar in AI-infrastructuur in 2026 [1]. Om die gigantische kapitaalinjectie te verantwoorden, eist het management adoptie. Maar adoptie afdwingen via leaderboards leidt tot schijnproductiviteit en verspilling van peperdure compute. Dit raakt aan de kern van wat wij de 10x Engineer-filosofie noemen. Een 10x engineer is niet iemand die tien keer zoveel regels code typt, of in dit geval, tien keer zoveel tokens door een taalmodel jaagt. Een 10x engineer is iemand die complexe problemen oplost met ongekende efficiëntie en elegantie. AI moet dienen als een hefboom (leverage) om die efficiëntie te vergroten. Het is een gereedschap om denkwerk te versnellen en repetitief werk te elimineren, niet een doel op zich. Als een developer een probleem in 100 tokens kan oplossen in plaats van 10.000, zou dat gevierd moeten worden. In de huidige cultuur van Amazon wordt diezelfde developer waarschijnlijk aangesproken op zijn "lage AI-adoptie". Hoe leiders wél moeten sturen op AI-adoptie Het is makkelijk om vanaf de zijlijn kritiek te leveren, maar hoe implementeer je AI dan wel succesvol binnen een grote enterprise? Bij TAG adviseren we onze enterprise-klanten die OpenClaw on-premise draaien altijd het volgende: Meet de uitkomst, niet de input: Stop met het staren naar dashboards vol met API-calls en token-volumes. Kijk naar de lead time for changes, de reductie in bug-rates, of de tijd die bespaard wordt op incident response. AI moet de business metrics verbeteren, niet de IT-infrastructuur belasten. Faciliteer, maar forceer niet: Zorg dat de tools naadloos en veilig beschikbaar zijn. Als een AI-agent daadwerkelijk frictie wegneemt, zullen de beste engineers het vanzelf adopteren. Geforceerde quota leiden uitsluitend tot compliance theater en tokenmaxxing. Prioriteer veiligheid en eigenaarschap: Autonome agents die code deployen of systemen aanpassen, vereisen een ijzersterke security-architectuur. Door AI on-premise te draaien, behoud je de controle. Je voorkomt dat gevoelige bedrijfsdata weglekt en je minimaliseert de angstaanjagende security-risico's waar cloud-gebaseerde, gehaaste interne tools vaak mee kampen. Beloon efficiëntie: Creëer een cultuur waarin de meest elegante, token-efficiënte oplossing wint. Een goede prompt of een slim geconfigureerde agent doet meer met minder. De ware belofte van autonome agents De AI-industrie bevindt zich op een kruispunt. Aan de ene kant zien we de route van de hyperscalers: gigantische investeringen die wanhopig gerechtvaardigd moeten worden door geforceerd gebruik, resulterend in tokenmaxxing en onveilige implementaties. Aan de andere kant is er de route die wij met OpenClaw bewandelen: gerichte, veilige, on-premise automatisering die draait om daadwerkelijke waardecreatie en eigenaarschap. Het is vleiend dat onze visie op autonome agents navolging krijgt bij de grootste techbedrijven ter wereld. Maar zolang zij AI blijven behandelen als een doel in plaats van een middel, zullen hun leaderboards gevuld blijven met gebakken lucht. Laten we stoppen met het vieren van verbrande tokens, en beginnen met het bouwen van systemen die écht voor ons werken. Bronnen Financial Times — Amazon staff use AI tool for unnecessary tasks to inflate usage scores (12 mei 2026) ## De Opkomst van Agentic AI: Waarom Gevestigde Bedrijven Nu Moeten Ingrijpen Source: https://theautomationgroup.nl/nl/blog/agentic-ai-supercharges-startups-incumbents Gepubliceerd: 2026-05-20 Agentic AI is niet zomaar een technologische iteratie; het is een fundamentele verschuiving in hoe software waarde creëert. Vanuit The Automation Group analyseren we hoe AI Agents startups een asymmetrisch voordeel geven en wat Nederlandse incumbents moeten doen om niet weggevaagd te worden. De Illusie van Veilige Marges Voor veel gevestigde Nederlandse bedrijven voelt de huidige generatie kunstmatige intelligentie nog als een handige toolset. Een chatbot hier, een code-assistent daar. Maar wie de ontwikkelingen in Silicon Valley en daarbuiten op de voet volgt, ziet een veel fundamentelere verschuiving. In het recente Harvard Business Review-artikel 'How Agentic AI Supercharges Startups and Threatens Incumbents' (juli–augustus 2026) schetsen Vivian S. Lee, Linda Mantia en Jon McNeill een meedogenloos beeld van de nabije toekomst [1]. We zijn het tijdperk van passieve AI-tools voorbij; we zijn het tijdperk van AI Agents binnengetreden. Vanuit The Automation Group observeren wij dagelijks hoe deze transitie de traditionele wetten van software-engineering en bedrijfsvoering herschrijft. AI Agents zijn geen simpele scripts die een vaste beslisboom volgen. Het zijn autonome systemen die een doel meekrijgen, zelfstandig plannen maken, tools aanroepen, fouten herstellen en itereren totdat het doel is bereikt. Voor startups betekent dit een ongekende versnelling. Voor incumbents is het een existentiële dreiging [1]. Niet Automatiseren, maar Elimineren Voordat we de diepte in duiken, moeten we terug naar een fundamenteel principe van procesoptimalisatie. In 1990 schreef Michael Hammer een iconisch stuk waarin hij stelde: "Stop paving the cow paths" [2]. Hij betoogde dat bedrijven niet simpelweg hun bestaande, inefficiënte processen moesten automatiseren, maar deze moesten vernietigen en vanaf de grond af opnieuw moesten opbouwen. Dit is exact de filosofie die een moderne Agentic Engineer hanteert. Waar traditionele IT-afdelingen bij Nederlandse corporates proberen om een verouderd ERP-systeem iets sneller te maken met een AI-schil, bouwt de Agentic Engineer een netwerk van AI Agents dat de noodzaak voor de menselijke handeling binnen dat ERP-systeem volledig elimineert. Het HBR-artikel bevestigt dit: de ware kracht van Agentic AI ligt in het herontwerpen van de fundamentele architectuur van een bedrijf [1]. De Vijf Krachten van Agentic Disruption Het HBR-artikel identificeert vijf krachten waarmee Agentic AI de markt op zijn kop zet [1]. Deze krachten vormen de ruggengraat van de asymmetrische oorlogsvoering tussen wendbare startups en logge incumbents. 1. Zero-Latency Iteration Traditionele softwareontwikkeling is traag. Het vereist sprints, backlog refinements en uitgebreide testfases. Met AI Agents wordt de iteratiesnelheid gereduceerd tot nagenoeg nul. Startups gebruiken frameworks en tools zoals LangChain en Delve om razendsnel prototypes te bouwen en te testen [1]. Het investeringsfonds DVx Ventures zet deze technologie actief in om het proces van product-market fit drastisch te versnellen [1]. Een Agentic Engineer kan vandaag een hypothese formuleren, en de AI Agents schrijven, testen en deployen de code nog dezelfde middag. Voor een traditionele bank of verzekeraar in Nederland, waar een release-cycle vaak maanden duurt, is dit tempo simpelweg niet bij te benen. 2. Automated Go-to-Market De go-to-market (GTM) strategie was altijd een arbeidsintensief proces van marketingcampagnes, sales development representatives (SDR's) en account executives. Agentic AI automatiseert deze volledige keten. Bedrijven zoals Tactix demonstreren hoe AI Agents autonoom leads kunnen identificeren, hyper-gepersonaliseerde outreach kunnen doen en zelfs de initiële kwalificatiegesprekken kunnen voeren [1]. Dit betekent dat een startup met een fractie van het personeel een groter bereik en een hogere conversie kan realiseren dan een multinational met een gigantisch salesapparaat. 3. Autonomous Business Functions We bewegen naar een realiteit waarin hele afdelingen worden vervangen door autonome systemen. Het bedrijf Ema positioneert zich als een 'universele AI-werknemer' die naadloos integreert in bestaande workflows en complexe, multi-step administratieve taken overneemt [1]. Ook grote spelers zien dit in; NTT Data implementeert dergelijke autonome agent-systemen om hun interne operaties en klantenservice fundamenteel te stroomlijnen [1]. Het gaat hier niet om een simpele FAQ-bot, maar om systemen die zelfstandig tickets oplossen, systemen updaten en communiceren met stakeholders. 4. Radical Capital Efficiency Omdat AI Agents de noodzaak voor grote teams in R&D, sales en operations wegnemen, daalt de kapitaalbehoefte van startups dramatisch. Het HBR-artikel noemt Atomic en Anterior als sprekende voorbeelden van bedrijven die met minimale financiële middelen een schaal bereiken die voorheen ondenkbaar was [1]. Deze radicale kapitaalefficiëntie betekent dat de traditionele 'moat' (verdedigingsgracht) van gevestigde bedrijven — namelijk hun enorme budgetten en schaalvoordelen — in hoog tempo verdampt. 5. The AI-Driven Flywheel De meest krachtige eigenschap van Agentic AI is het vliegwieleffect. Hoe meer data een AI Agent verwerkt, hoe beter de beslissingen worden, wat leidt tot betere resultaten en weer hoogwaardigere data. Dit beperkt zich niet tot de tech-sector. In de gezondheidszorg gebruikt het Tampa General Hospital hun AI-systeem genaamd Aimee om patiëntenzorg en ziekenhuisoperaties continu te optimaliseren [1]. In de militaire sector past het 18th Airborne Corps het AI-systeem Maven toe voor logistiek en inlichtingen, waarbij het systeem leert van elke operatie [1]. Dit vliegwiel creëert een exponentiële voorsprong die door trage concurrenten niet meer in te halen is. De Realiteit voor Nederlandse Incumbents Wat betekent deze analyse vanuit het perspectief van The Automation Group voor de Nederlandse markt? Veel gevestigde bedrijven bevinden zich in een klassiek scenario van disruptie, zoals decennia geleden al beschreven door Clayton Christensen [3]. Ze luisteren naar hun huidige klanten, optimaliseren hun bestaande marges en zien de opkomst van Agentic AI als speelgoed voor startups. Ze proberen de 'cow paths' te asfalteren met dure enterprise AI-licenties, zonder hun onderliggende architectuur te veranderen. Dit is een fatale misrekening. Wanneer een startup met tien medewerkers en een netwerk van AI Agents dezelfde output kan leveren als een corporate afdeling van tweehonderd FTE, vallen de marges van de incumbent onmiddellijk om. De overheadkosten van traditionele bedrijven worden hun grootste zwakte. De Rol van de Agentic Engineer Om te overleven, moeten Nederlandse bedrijven de transitie maken van traditionele software-engineering naar Agentic Engineering. Een Agentic Engineer bij The Automation Group schrijft niet simpelweg code; hij of zij ontwerpt ecosystemen waarin AI Agents veilig, deterministisch en doelgericht kunnen opereren. Dit vereist een diep begrip van: Orchestratie: Het laten samenwerken van meerdere gespecialiseerde AI Agents (bijvoorbeeld een 'research agent' die data aanlevert aan een 'coding agent'). Guardrails: Het inbouwen van harde grenzen en validatiemechanismen zodat autonome systemen geen destructieve acties uitvoeren in productie-omgevingen. System Thinking: Het vermogen om een bedrijfsproces niet te zien als een reeks menselijke handelingen, maar als een abstract doel dat door een machine geoptimaliseerd kan worden. De conclusie uit het HBR-artikel is helder en sluit naadloos aan bij onze visie: Agentic AI is geen toekomstmuziek, het is de huidige realiteit die de winnaars van de verliezers scheidt [1]. Gevestigde bedrijven moeten nu handelen. Ze moeten stoppen met het bouwen van proof-of-concepts die nergens toe leiden en beginnen met het fundamenteel herontwerpen van hun kernprocessen rondom autonome AI Agents. Doen ze dit niet, dan zullen ze ontdekken dat hun decennia-oude marktdominantie in een kwestie van jaren door een handjevol Agentic Engineers teniet wordt gedaan. Bronnen Vivian S. Lee, Linda Mantia, Jon McNeill, 'How Agentic AI Supercharges Startups and Threatens Incumbents', Harvard Business Review, juli–augustus 2026, https://hbr.org/2026/07/how-agentic-ai-supercharges-startups-and-threatens-incumbents Michael Hammer, 'Reengineering Work: Don't Automate, Obliterate', HBR, juli–augustus 1990 Clayton Christensen & Joseph Bower, 'Disruptive Technologies: Catching the Wave', HBR, januari–februari 1995 ## Gas City: in de software factory met 100 coding agents Source: https://theautomationgroup.nl/nl/blog/gas-city-software-factory-100-agents Gepubliceerd: 2026-05-19 Honderd coding agents in parallel, vijftig PRs per dag, een miljard tokens per dag. Wat Gas City laat zien over multi-agent engineering — en welke drie ideeen je sowieso moet kennen, ongeacht welke toolkit straks wint. Honderd coding agents in parallel, vijftig pull requests per dag, een miljard tokens per dag. Dat is geen denkbeeldige toekomst — dat draait nu op één server in Atlanta. Wat Gas City laat zien over multi-agent engineering is interessanter dan de toolkit zelf. Van Gas Town naar Gas City Begin dit jaar publiceerde Steve Yegge — een bekende veteraan uit de developer-tools wereld — een Medium-post over Gas Town, een open source orkestratielaag waarmee 20 tot 30 AI-coding agents tegelijk aan dezelfde codebase kunnen werken. De post ging viraal. Vorige week werd de opvolger Gas City aangekondigd, herbouwd als toolkit door Chris Sells (ex-Google, eerder Flutter naar 3 miljoen developers gegroeid) en Julian Knutsen (voorheen technical lead bij Block). Knutsen draait Gas City in productie op één server in Atlanta met circa honderd agents, die samen ongeveer vijftig pull requests per dag mergen — de output van een klein team — en daarbij ruwweg een miljard tokens per dag verbranden. Dat is ongeveer een vijfde van het volledige Engelstalige Wikipedia-corpus. Per dag. De inschatting van Mike Taylor (Every's head of tech consulting) na een workshop in New York: 🟨 — "Learn from the ideas. Skip the toolkit for now." Wat ons interesseert zijn die ideeën, want ze raken aan precies de architectuur-vragen waar wij met klanten tegenaan lopen zodra agents echt parallel gaan draaien. Drie ideeën die je sowieso moet kennen 1. Dark factory vs. light factory Splits je proces in twee zones. Light factory = de stappen waar mensen en agents samen aan tafel zitten: planning, design, eindreview. Daar moet alles zichtbaar en bestuurbaar zijn. Dark factory = de stappen waar de agent zelfstandig zijn werk doet, helemaal op de achtergrond, zonder dat een mens kijkt. Bug-triage, refactor-passes, test-generation, formatting, dependency-bumps. De truc: je begint met bijna alles in het licht en verschuift naarmate je vertrouwen krijgt steeds meer naar het donker. Dit is dezelfde mindset als de transitie van handmatige naar geautomatiseerde tests, maar dan voor agent-acties. Voor onze klanten betekent het concreet: maak vooraf expliciet welke acties geen human-in-the-loop nodig hebben en welke wél — en herzie dat lijstje elke sprint. 2. One pet, many cattle (de "mayor" + "polecats") Dit is het sterkste idee in Gas City. In plaats van honderd agents individueel te managen, praat je met één persistent supervisor-agent (Gas City noemt hem de mayor) die jouw intentie begrijpt en context vasthoudt. De mayor delegeert vervolgens naar anonieme, wegwerpbare workers (de polecats) die één klus doen en daarna afsluiten. Waarom werkt dat? Omdat losse agents geen historie meeslepen en dus geen context vervuilen. En omdat jij als mens nooit honderd dingen tegelijk hoeft te volgen — je voert één gesprek met de mayor, niet honderd parallelle chats. Dezelfde patroon kom je inmiddels tegen in Claude Code's sub-agents, in Cursor's background agents en in OpenAI's recent uitgebrachte Symphony. Het wordt langzaam de standaard manier waarop multi-agent systemen worden gestructureerd. 3. Meerdere modellen voor één code review Stuur dezelfde diff naar Claude, Codex én Kimi — tegelijk. Drie verschillende modellen vangen andere bugs dan één model dat je drie keer draait. Voor ons is dit een direct toepasbare tip: een review-stap waarin je een PR door twee tot drie verschillende modellen laat lezen, kost weinig extra in vergelijking met de developer-tijd die je terugkrijgt. We bouwen dit voor klanten al in een paar n8n-flows en in OpenClaw's PR-review chain. Waar Gas City zelf nog niet klopt De toolkit is nog rauw. Mike Taylor noteerde een paar concrete pijnpunten: Geen agent-geheugen tussen taken. Elke taak start een fresh sessie die niet weet wat eerdere agents hebben gedaan. Resultaat: agents lezen telkens opnieuw context die net door een collega-agent geproduceerd is. Verspilling, en je mist verbanden die een single-session wél zou pakken. Het kost wat het kost. Een zes-stappen klus betekent grofweg zes keer de kosten van één Claude-sessie. Bij een miljard tokens per dag praat je niet meer over koffiegeld. De setup is zwaar. Een zaal vol ervaren engineers had een hele dag nodig om het draaiend te krijgen, mét hulp van Sells en Knutsen. Beads (de taak-tracker) is agent-first, niet mens-first. Het draait als CLI, geen visueel dashboard. Daarom koppelen teams het in productie alsnog aan Jira of Linear — taken in twee plekken, dubbel werk. Het overschat hoeveel hand-holding moderne modellen nog nodig hebben. Veel review-loops en mid-task check-ins die Gas City inbouwt om drift te voorkomen, zijn met Claude 4.5 of GPT-5.2 niet meer nodig. Het jargon werkt tegen. Beads, polecats, refineries, mayor — leuk thematisch, maar nieuw teamlid begint met een woordenboek. Wanneer is dit voor jou relevant? Onze inschatting matcht die van Taylor: als je nu al meer dan 10 Claude Code-sessies tegelijk draait en de source code wil lezen, is Gas City het bekijken waard. Voor iedereen daaronder: neem de ideeën, sla de toolkit over. Voor de meeste van onze klanten is OpenAI's Symphony of een eigen lichte orkestratielaag op Linear/Jira realistischer. Symphony is in essentie een set geschreven regels die jouw bestaande board verandert in het dashboard waarop de agents werken. Dat sluit aan op hoe engineers nu al werken en vraagt geen gedragsverandering. Wat dit zegt over de richting van engineering Drie patronen die we vasthouden, los van welke toolkit straks wint: Eén gesprek, veel uitvoerders. Het mayor/polecats-model is de manier om met meer dan vijf agents tegelijk te werken zonder de regie te verliezen. Wie nu een agent-architectuur opzet en alle agents als gelijken behandelt, gaat dat over een jaar opnieuw doen. Multi-model review is gratis kwaliteit. Het verschil tussen één model en drie modellen op dezelfde diff is groter dan het verschil tussen Sonnet 4.5 en Opus 4.5. Dit is laaghangend fruit waar we voor klanten nu al patches in PR-flows voor schrijven. Dark factory komt eraan. Een groeiend deel van software-engineering gebeurt zonder mens in de loop, en de bedrijven die het eerst expliciet maken welk werk in het donker mag, krijgen de grootste throughput-winst. Voor klanten die we begeleiden in agentic engineering is "wat verschuift naar dark" een vaste vraag in elke sprint review. Gas City is niet het eindstation. Maar als snapshot van hoe een goed onderbouwde multi-agent setup eruitziet, is het een van de eerlijkste die nu publiek beschikbaar is. Honderd agents op één server is geen marketing — het is iemand die het probeert, het opschrijft, en de pijn deelt. Dat is meer dan je van de meeste vendor-demo's kunt zeggen. ## Tokenmaxxing: waarom Salesforce $300M aan Anthropic uitgeeft (en jouw budget straks ook ontploft) Source: https://theautomationgroup.nl/nl/blog/tokenmaxxing-salesforce-anthropic-300-miljoen Gepubliceerd: 2026-05-19 Salesforce $300M aan Anthropic, Uber door zijn jaarbudget heen in april, een 4-mans startup die $125k per maand verbrandt. Waarom tokenkosten zo hard stijgen en hoe je je AI-architectuur inricht zodat je CFO niet panikeert. Salesforce gaat dit jaar circa $300 miljoen uitgeven aan Anthropic-tokens. Uber zat in april al door zijn jaarbudget voor AI heen. Een Silicon Valley-startup van vier man tikt $125k per maand af bij Anthropic. Het tokenbudget is het nieuwe rekencentrum-budget — en bijna iedereen onderschat het. Salesforce: $300 miljoen, en dat is nog maar het begin Op de All-In podcast vertelde Marc Benioff vorige week dat Salesforce dit jaar op koers ligt voor zo'n $300 miljoen aan Anthropic-tokens. Ter context: dat is ongeveer 4,5% van de $6,7 miljard die Salesforce vorig jaar uitgaf aan cost of revenues — de pot waar alle third-party tech-leveranciers uit betaald worden. Eén AI-leverancier neemt nu een serieuze hap. Het overgrote deel gaat naar coding agents. "These coding agents are awesome," zei Benioff. "Everything's going to be cheaper to make. It's more efficient. I can do things that I just could not do before." De ROI rechtvaardigt de uitgaven — voorlopig. Maar in dezelfde zin liet hij doorschemeren dat hij Salesforce wil spenen van zo'n exclusieve afhankelijkheid van Anthropic: "The vast majority of those tokens don't need to go to Anthropic. There needs to be some intermediary layer that's saying, oh, that one has to go to Anthropic, but these ones can be handled by smaller models." Benioff speculeerde dat "een hot new company" zou opduiken om dat te bouwen. Die bestaat al: OpenRouter haalde recent $120 miljoen op bij een Alphabet-fonds, op een waardering van $1,3 miljard. Wij schreven eerder over Cortecs.ai als Europees, GDPR-native alternatief voor diezelfde router-categorie. Uber: jaarbudget op in april Salesforce is niet alleen. Uber zat in april 2026 al door zijn AI-jaarbudget heen. De interne post-mortem die naar buiten lekte was niet "we hebben te weinig begroot", het was "we hebben niet begrepen wat een agent kost zodra hij vaker dan twee keer per ticket terugkomt". Een loop met drie tool-calls en een retry-strategie kan in productie tien tot vijftien keer duurder uitvallen dan dezelfde flow als single-shot prompt. Helloprint, Swan en de $125k-startup De getallen schalen mee met het bedrijf: Helloprint draait €80M omzet en kwam onlangs naar buiten met €25k aan jaarlijkse AI-kosten — bescheiden, maar gekoppeld aan een reductie van ~300 naar ~120 FTE. De tokens zijn hier letterlijk een substitutie voor mensen. Swan AI, een AI-fintech, geeft naar verluidt $113k per maand uit aan Anthropic. Dat is $1,3M per jaar voor één leverancier, in één bedrijf. Een Silicon Valley-startup met een team van vier man tikt $125k per maand af bij Anthropic. Per persoon is dat $375k aan tokens per jaar. Dat is meer dan het salaris. Jensen Huang noemde recent zonder blikken "$250k per jaar aan AI-tools" voor zijn productiefste engineers. Solberg's CEO ging er overheen met de opmerking dat zijn team $4M per maand aan tokens verbrandt. Anthropic zit volgens recente cijfers op een run rate richting $30 miljard. Dat geld komt ergens vandaan. Het komt uit deze bedrijven. Wat hier eigenlijk gebeurt Drie dingen lopen tegelijk: 1. Het budgetmodel klopt niet meer. AI-budgetten worden nog gepland als SaaS-budgetten — een vast bedrag per seat per maand. Maar agent-tokens schalen met workload, niet met seats. Eén engineer met een goed werkende Claude Code-loop kan in een week meer tokens verstoken dan een heel team in een maand. 2. De ROI maskeert de inefficiëntie. Benioff heeft gelijk: deze agents zijn awesome, en ze maken werk goedkoper. Dat is precies waarom niemand de tokenuitgaven hard challenged. Zolang elke €1 token ergens €3 menselijke arbeid uitspaart, voelt het als een goede deal. Maar dat is geen reden om alles naar het duurste model te sturen. 3. Routering wordt een eigen vakgebied. Niet elke prompt hoort bij Sonnet 4.5. Een classificatie-stap kan prima bij Haiku of een lokale Qwen. Een schrijfagent voor saaie e-mails kan op een goedkoper Gemini-model. De "intermediary layer" die Benioff beschreef is geen toekomstmuziek — die bouwen wij voor klanten in n8n of in OpenClaw, met routing-regels op basis van taak, gevoeligheid en kostenplafond. De Ramp AI Index in context De Ramp AI Index liet recent zien dat 50,4% van Amerikaanse bedrijven inmiddels een betaald AI-abonnement heeft, en dat de bestedingen elk kwartaal hard stijgen. Wat de index niet laat zien is hoeveel daarvan agent-tokens zijn versus chat-seats. Vermoedelijk groeit het token-deel sneller dan elk ander deel — omdat agents per definitie meer tokens consumeren dan een mens die af en toe een chat opent. Hoe wij hier praktisch mee omgaan Een paar dingen die we standaard inbouwen zodra een agent productie draait: Per-tool en per-run cost tracking in de orchestration laag (n8n of een Python-pipeline). Niet alleen $-totalen aan het einde van de maand, maar per tool-call, per agent-stap. Dan zie je dat één retry-storm 80% van je weekfactuur kan veroorzaken. Model-selectie als configuratie, niet als hardcode. Een classificatie-stap, een extractie-stap en een eindredactie-stap zijn drie verschillende kostencategorieën en moeten ook drie verschillende modellen kunnen aanroepen. Switchen tussen GPT-5-mini, Claude Haiku, en een lokale Qwen via Cortecs of OpenRouter mag geen refactor zijn. Een hard kostenplafond per agent per dag. Geen circuit breaker = open kraan. Voor langlopende loops bouwen we standaard een ceiling in die de agent stopt of degradeert naar een goedkoper model zodra er een drempel wordt gehaald. On-prem voor wat repeterend en gevoelig is. Voor de meeste klanten zit 70-80% van de tokens in saai, repeterend werk dat prima op een lokale Llama of Qwen kan via OpenClaw. Niet voor het wow-werk — voor de bulk eronder. Tot slot De ironie van Benioff's quote — "I think that's just the moment of time we're in right now" — is dat hij gelijk heeft, maar pas zodra er een routerings­laag tussen zit. Tokens worden niet goedkoper omdat Anthropic ze goedkoper maakt. Ze worden goedkoper omdat je leert om de juiste prompt naar het juiste model te sturen. CFO's hebben nu nog geen rode pen aangezet bij het AI-budget. Dat is een kwestie van tijd. Wie nu zijn architectuur al inricht op modelflexibiliteit — in plaats van blind alles naar één leverancier te sturen — is straks degene die zonder paniek de bocht door kan. ## Werknemers als trainingsdata: Microsoft, Meta en xAI Source: https://theautomationgroup.nl/nl/blog/werknemers-als-trainingsdata Gepubliceerd: 2026-05-19 Microsoft heeft 100.000 engineers. Meta tracket muis en toetsenbord. xAI biedt $420 voor je belastingaangifte. De volgende AI-trainingsdata komt van eigen personeel — en dat heeft gevolgen voor hoe jij je eigen AI-stack inricht. Microsoft heeft een wapen dat Anthropic en Cursor niet hebben: ongeveer 100.000 eigen developers. Meta gebruikt muisbewegingen van werknemers. xAI biedt $420 voor je belastingaangifte. De AI-race gaat een nieuwe fase in — en je collega's zijn de trainingsdata. Wie betaalt voor de volgende generatie modellen? Het korte antwoord: de werknemers zelf. Niet in geld, maar in data. De grote AI-labs hebben publiek internet al uitgekamd, een groot deel van YouTube, GitHub en Reddit afgegraasd, en lopen tegen de muur van auteursrechtelijk gedoe en uitputting van bronnen. De volgende laag — hoge kwaliteit, niet eerder gezien door een ander model — komt uit één plek: de mensen die elke dag voor het bedrijf werken. Wat opvalt is hoe verschillend de drie grote spelers dit aanpakken, en hoe ongegeneerd het inmiddels gebeurt. Microsoft: 100.000 engineers als RLHF-pool Microsoft loopt in coding-AI achter op Anthropic en Cursor. Intern gebruiken steeds meer Microsoft-engineers Claude Code in plaats van GitHub Copilot. Maar Microsoft heeft één ding wat zijn concurrenten niet hebben: een leger van ongeveer 100.000 software engineers in dienst. Volgens recente rapportages verzamelt Microsoft data uit zijn interne VSCode-installaties, uit de broncode van Xbox-game studios die Microsoft bezit, en — interessanter nog — uit het gedrag van zijn eigen engineers in GitHub Copilot. Welke suggesties accepteren ze? Welke negeren ze? Welke wijzigen ze voor ze de regel committen? Dat laatste is geen ruwe trainingsdata, dat is iets veel waardevollers: preference data. Het soort signaal waar reinforcement learning-pipelines op draaien. Microsoft probeert daarom actief eigen mensen terug naar Copilot te duwen in plaats van Claude Code te laten gebruiken — niet alleen voor het narratief, maar omdat elk geaccepteerd regeltje code een datapunt is dat OpenAI of Anthropic niet hebben. Dogfooding is niets nieuws. Google en OpenAI doen het ook. Wat nieuw is, is dat dogfooding nu de primaire datastrategie wordt in plaats van een kwaliteitscontrole. Meta: muis, toetsenbord, dropdown — alles Meta gaat een paar stappen verder. Het bedrijf rolt een tool uit met de naam Model Capability Initiative (MCI), die op de werkcomputers van Amerikaanse werknemers muisbewegingen, kliks en toetsaanslagen registreert. Het doel: trainingsdata voor agents die "computergebruik" leren — denk aan een agent die door een dropdown navigeert, een knop aanklikt, een formulier invult. Mark Zuckerberg vertelde zijn personeel dat dit "extra waardevol" zou zijn omdat Meta-medewerkers "heel slim" zijn. Of dat compliment de bewaking verteerbaarder maakte is onduidelijk. Wat Platformer wel meldt: werknemers verzetten zich door consequent de "accept"-knop in de permissions popup te negeren, en sommigen hebben manieren gevonden om de software via systeeminstellingen helemaal uit te schakelen. Daar komt bij dat de software volgens interne berichten technisch ook nog rommelig is. "MCI maakt alles super traag," schreef één werknemer; toetsenbord en muis worden volgens hem laggy. Een Meta-woordvoerder noemt het noodzakelijk: agents die mensen ondersteunen bij dagelijkse taken hebben echte voorbeelden nodig van hoe mensen die taken uitvoeren. xAI: $420 voor je belastingaangifte (nog niet uitbetaald) De meest gênante variant komt van xAI. Volgens Bloomberg bood het bedrijf werknemers $420 per stuk om hun Amerikaanse belastingaangiftes te "doneren" — én aangiftes van vrienden en familie — als trainingsmateriaal voor Grok's financiële vaardigheden. Twee maanden later: het geld is nog niet uitbetaald aan de werknemers die data hebben aangeleverd. De prijs $420 is een meme-knipoog die alleen werkt zolang het geld ook daadwerkelijk binnenkomt. Voor wie iets fundamentelers wil lezen over privacy: belastingaangiftes bevatten inkomen, dependents, schenkingen, charitatieve giften, medische uitgaven, hypotheekstructuren. Het is moeilijk te bedenken welk dataset gevoeliger is. Waarom werknemers, en niet klanten? Het simpele antwoord: werknemers kunnen niet écht nee zeggen. Klanten vragen om trainingsdata kost moeite. Het kost een opt-in flow, een juridische review, een vertrouwensgesprek over wat er wel en niet wordt gedeeld. En de meeste klanten zeggen nee — zeker enterprise klanten die juist een no-training-clausule in hun contract hebben staan. (Iets waar Lovable Cloud, Azure OpenAI en de Anthropic Enterprise tier elk hun eigen versie van hebben.) Werknemers daarentegen tekenen een arbeidsovereenkomst. De macht is asymmetrisch. Een popup met "accept" voelt voor een werknemer als een verkapte verplichting, niet als een echte keuze. En de schaal is enorm: 100.000 Microsoft-engineers genereren in een week meer hoogwaardige code-data dan een publiek GitHub-scrape in een maand. De stille verschuiving: ruwe data → preference data De interessantste ontwikkeling zit niet in de schaal, maar in het type data. De grote modellen zijn op ruwe internet-tekst getraind tot het punt van marginale opbrengsten. De winst zit nu in signaal: welke suggestie werd geaccepteerd, welke werd herschreven, welke werd verworpen. Voor coding-AI is dat goud. Een engineer die een Copilot-suggestie aanpast voor ze committen, levert een veel rijker signaal dan een willekeurig GitHub-bestand. Het verschil tussen de gegenereerde versie en de gecommite versie ís de feedback — gratis RLHF, geen menselijke labelers nodig. Hetzelfde geldt voor Meta's computer-use agents: knoppen klikken in synthetic data ziet er anders uit dan een echte gebruiker die twijfelt, terugscrollt, een dropdown half opent en weer sluit. Die ruis is de data. Wat dit betekent voor je eigen bedrijf Drie dingen, in volgorde van belang: Lees je AI-vendor contract opnieuw. Veel SaaS-tools verbergen no-training-defaults in de Enterprise tier en hebben standaard de switch op "wel trainen" staan in Pro/Team plannen. Specifiek voor coding agents: check of Cursor, Copilot en Claude Code in jouw setup wel of niet je code naar de provider sturen voor training. Voor de meeste van onze klanten beantwoorden we deze vraag tijdens onboarding — het verschil tussen "data blijft on-prem" en "data wordt anoniem aggregated for model improvement" is niet klein. Maak het beleid expliciet, niet impliciet. Als jij je eigen interne tools bouwt — een chatbot, een agent, een document-extractor — bepaal vooraf of je logs gebruikt voor fine-tuning. Schrijf het op. Communiceer het aan je team. Een impliciete "natuurlijk gebruiken we het niet" houdt geen stand zodra de productmanager achter de tool ambitieuzer wordt. On-prem voor wat écht gevoelig is. Voor klanten waar data het bedrijf niet mag verlaten — verzekeraars, vastgoed, legal — bouwen we steeds vaker met OpenClaw als on-prem orkestratielaag. Lokale Llama- of Qwen-modellen, eigen Postgres, eigen audit log. Niet omdat we paranoia zijn, maar omdat het bestaande verhaal — "vertrouw ons" — net iets minder gewicht heeft als Meta zijn eigen mensen al niet meer vertrouwt. Tot slot De AI-industrie heeft een paar jaar lang kunnen drijven op gratis internet-data. Die rivier is opgedroogd. Wat overblijft is duur, langzaam, of moreel grijs. Werknemers zijn de goedkoopste, snelste, grijste optie van de drie. Voor wie zelf agents bouwt is de les niet "stop met dogfooding" — integendeel, het is de beste manier om snel te leren wat werkt. De les is: wees expliciet over wat je verzamelt, waarvoor je het gebruikt, en geef mensen een echte uitknop. Anders bouw je vroeg of laat een MCI-popup waar niemand op klikt. ## Hostinger VPS: zo draai je OpenClaw, Hermes AI en Paperclip AI in de cloud zonder lokale installatie Source: https://theautomationgroup.nl/nl/blog/hostinger-vps-openclaw-hermes-paperclip-zero-person-company Gepubliceerd: 2026-05-19 Je laptop dichtklappen mag geen reden zijn dat je AI Agents stoppen. Op een Hostinger KVM2 VPS van ±€9 per maand draai je OpenClaw, Hermes AI en Paperclip AI 24/7 in een EU-datacenter — zonder Mac Mini, zonder netwerkgedoe, zonder eigen hardware. Het bouwen van een eigen automatisering-stack op een lokale Mac Mini of een oude laptop heeft een zekere romantiek. Je hebt fysieke controle, je ziet letterlijk de lampjes knipperen en er zijn geen maandelijkse cloudkosten. Maar de realiteit voor de meeste solopreneurs slaat hard toe zodra je de klep van die laptop dichtklapt en naar een afspraak gaat: je AI Agents sterven. Webhooks komen niet meer aan, inkomende e-mails stapelen zich op en openstaande offertes worden niet opgevolgd. Wil je betrouwbaar opereren, dan heb je constante uptime nodig en een vast, publiek bereikbaar adres. De traditionele oplossing was ingewikkeld: netwerkpoorten openzetten in je router, worstelen met dynamische IP-adressen en vage tunneldiensten. Vandaag de dag lossen we dat bij The Automation Group (TAG) anders op. We draaien onze stack — OpenClaw, Hermes AI en Paperclip AI — gewoon in de cloud. Niet op peperdure enterprise-infrastructuur, maar op een uiterst betaalbare Hostinger KVM VPS. Binnen tien minuten heb je een robuuste omgeving draaien, je laptop kan uit, en je AI-team werkt ongestoord door. Waarom Hostinger en geen AWS of Hetzner Als je de stap naar de cloud maakt, struikel je al snel over de bekende namen. Amazon Web Services (AWS) is de marktleider, maar voor een "zero person company" founder of MKB-eigenaar is het onnodig complex. Voor je een simpele container draait, ben je verstrikt in IAM-rollen, VPC-configuraties en onvoorspelbare facturen. Aan de andere kant heb je providers zoals Hetzner. Technisch ijzersterk en goedkoop, maar het vereist diepgaande Linux-kennis; de "1-click experience" ontbreekt. Hostinger biedt momenteel exact de balans die wij voor onze tools zoeken. Je krijgt de prestaties van KVM-virtualisatie gecombineerd met razendsnelle NVMe storage. De interface biedt wat we intern een "consumer-grade Developer Experience" noemen: het is gebouwd voor mensen die snel resultaat willen. Ze bieden kant-en-klare 1-click Docker en AI-templates op basis van volledige Ubuntu of Debian images, inclusief root access en SSH. Mocht je toch vastlopen in de command line, dan helpt hun ingebouwde AI-assistent genaamd Kodee je met server management en terminal-commando's. Daarnaast is de infrastructuur wereldwijd beschikbaar. Je kunt kiezen uit datacenters in de Verenigde Staten, het Verenigd Koninkrijk, Brazilië, India en Singapore, maar voor Europese gebruikers is de keuze nog simpeler: Hostinger heeft datacenters in Nederland en Litouwen. Door een EU-regio te kiezen, zet je direct een grote stap richting compliance. Het juiste plan kiezen voor jouw stack Niet elke setup heeft dezelfde hoeveelheid rekenkracht nodig. Hostinger biedt diverse KVM-plannen. Omdat je volledige vrijheid hebt op de server, schaal je simpelweg mee met je behoefte. KVM 1: 1 vCPU, 4GB RAM, 50GB NVMe en 4TB bandbreedte. Actieprijs ±€6,49 per maand (verlenging ±€11,99). Dit is perfect als je slechts één geïsoleerde tool wilt draaien. Bijvoorbeeld alleen Paperclip AI voor je backoffice, of enkel Hermes AI voor e-mailafhandeling. KVM 2 (Most popular): 2 vCPU, 8GB RAM, 100GB NVMe en 8TB bandbreedte. Actieprijs ±€8,99 per maand (verlenging ±€14,99). Dit is de "sweet spot" en onze standaard aanbeveling. Hierop draait de volledige TAG-stack (OpenClaw als brein, gekoppeld aan Hermes en Paperclip) soepel en zonder memory bottlenecks. KVM 4: 4 vCPU, 16GB RAM, 200GB NVMe voor ±€12,99 per maand ten tijde van de promo. Kies dit plan als je veel parallelle AI Agents tegelijk laat werken of wanneer je lokaal zware vector embeddings genereert die veel werkgeheugen opsnoepen. Voor de absolute zwaargewichten is er nog de KVM 8 (8 vCPU, 32GB RAM, 400GB NVMe voor ±€25,99 per maand promo), maar de gemiddelde solopreneur zal de capaciteit van de KVM 2 al meer dan toereikend vinden. Setup in vogelvlucht Het opzetten van deze infrastructuur vereist geen uren werk meer. De procedure is rechttoe rechtaan. Bestel je gekozen VPS en selecteer een datacenter in de EU. Tijdens de installatiewizard kies je als besturingssysteem Ubuntu 24.04 in combinatie met de Docker-template. Hostinger richt de server in, installeert de benodigde runtime en levert je een vers IP-adres op. Vervolgens maak je verbinding via SSH. Omdat Docker al geïnstalleerd is, beperkt de taak zich tot het binnenhalen van je configuratie en het opstarten van de containers. Dat ziet er in de praktijk ongeveer zo uit: # Update de server pakketten voor de zekerheid apt update && apt upgrade -y # Clone de repository met jouw TAG-stack configuratie git clone tag-stack cd tag-stack # Vul je omgevingsvariabelen in (API keys, etc.) nano .env # Start de volledige stack op de achtergrond docker compose up -d Binnen een paar minuten downloadt Docker de benodigde images en brengt je systeem tot leven. OpenClaw in de cloud: van Mac Mini naar VPS OpenClaw is het kloppend hart van de setup. Dit open-source self-hosted AI Agent framework — voorheen bekend als Clawdbot en inmiddels goed voor meer dan 100.000 GitHub stars — blinkt uit in zijn multi-agent architectuur, ingebouwde memory en Model Context Protocol (MCP) koppelingen. Wanneer je OpenClaw weghaalt van een lokale Mac Mini en op een VPS draait, verandert de manier waarop je met de buitenwereld praat. Je bent niet langer gebonden aan een lokaal netwerk. Via de DNS-instellingen van Hostinger koppel je eenvoudig een publiek subdomein (bijvoorbeeld agents.jouwbedrijf.nl) aan je VPS-IP. Door een reverse proxy in je Docker-stack op te nemen — zoals Caddy of Nginx gecombineerd met Let's Encrypt — forceer je direct een veilige TLS/HTTPS-verbinding. Hierdoor wordt het koppelen van externe kanalen zoals Telegram, WhatsApp of Slack triviaal. Waar je voorheen externe webhooks via ngrok naar je laptop moest forceren, sturen deze diensten nu simpelweg hun data naar jouw beveiligde VPS. Cruciaal hierbij is dat je data-soevereiniteit behouden blijft: doordat je de Hostinger VPS zelf beheert, wordt de vector database met de 'memory' van je AI Agents lokaal weggeschreven op jouw afgeschermde stukje NVMe-opslag. Hermes AI altijd bereikbaar Onze communicatie-agent, Hermes AI, is ontworpen om als een onvermoeibare poortwachter te fungeren. Hermes handelt inkomende en uitgaande messaging af over kanalen zoals e-mail, WhatsApp en voice. Een dergelijke agent hoort simpelweg niet thuis op hardware die op slaapstand overschakelt. E-mail is hier een goed voorbeeld van. Hermes maakt gebruik van IMAP idle-protocollen om real-time te reageren op inkomende berichten. Als je de agent dwingt op een laptop te draaien, zal Hermes elke keer als je netwerkverbinding wegvalt de sessie moeten herstellen, waardoor je berichten mist of trager beantwoordt. Op de VPS draait Hermes onafgebroken door. Omdat de agent namens jou het woord voert, is het cruciaal dat secrets management serieus genomen wordt. Zet nooit API-sleutels, SMTP-wachtwoorden of WhatsApp-tokens hardcoded in je configuratiebestanden, maar laad deze strikt in als environment variables (via de .env file) op je beveiligde server. Paperclip AI als jouw backoffice die nooit slaapt Paperclip AI vormt het fundament onder de "zero person company". Waar OpenClaw nadenkt en Hermes communiceert, automatiseert Paperclip de administratieve backoffice. Denk aan het genereren van offertes, het aanmaken en inboeken van facturen, follow-ups sturen bij onbetaalde rekeningen, en het verwerken van standaard contracten. Als je in je eentje een bedrijf runt, ligt de operationele kant meestal stil wanneer jij slaapt. Door Paperclip AI op een altijd-actieve VPS te draaien, verandert die dynamiek fundamenteel. De tool maakt gebruik van cron-achtige scheduling om processen autonoom te starten. Je kunt een *nightly invoice run* configureren waarbij de agent om 03:00 's nachts de urenregistratie controleert, facturen genereert en deze direct via Hermes klaarzet voor verzending in de vroege ochtend. Ook lead scoring en follow-up sequences lopen strak door. Voor je klanten en prospects lijkt het alsof je een zeer accuraat en toegewijd backoffice-team in dienst hebt. Wanneer doe je het toch lokaal of on-prem Is de cloud dan werkelijk in elke situatie superieur? Nee, we moeten pragmatisch blijven. Er zijn specifieke scenario's waarin een fysieke Mac Mini on-premise, of een dedicated bare-metal server in een afgesloten ruimte, nog steeds de verstandigste keuze is. Dit geldt specifiek wanneer je werkt met uiterst gevoelige data. Bedrijven in de zorg, de op zware compliance leunende juridische sector of defensie-gerelateerde industrieën kunnen opereren onder regelgeving die vereist dat data fysiek de bedrijfsmuren niet mag verlaten. Voor dit soort niche toepassingen is lokale hosting absoluut superieur. Echter, voor de gemiddelde solopreneur of MKB-eigenaar is de KVM VPS bij Hostinger ruim voldoende. Zolang je kiest voor een EU-datacenter en je de standaard beschikbare Data Processing Agreement (DPA) met Hostinger vastlegt, is je opstelling vanuit een GDPR/AVG-perspectief verdedigbaar en solide geregeld. De zero person company is geen meme meer Het idee van een bedrijf opstarten en opschalen zonder ooit personeel aan te hoeven nemen, was lange tijd een internet-meme. Vandaag de dag is het een haalbare realiteit dankzij krachtige, modulaire automatisering. Wanneer je OpenClaw inzet om te denken en redeneren, Hermes AI laat communiceren over al je kanalen, en Paperclip AI de backoffice vlekkeloos laat bijwerken, bouw je effectief een team van drie hooggeschoolde medewerkers. Door dit collectief aan AI Agents voor net geen tientje per maand onder te brengen op een KVM 2 VPS bij Hostinger, creëer je een machine die nooit slaapt, nooit ziek is en vanaf elk apparaat ter wereld door jou te beheren is. Geen gesleep met hardware, niet afhankelijk van je laptop-accu. Wil je deze infrastructuur zelf uitrollen maar twijfel je over de fijne kneepjes? Neem een kijkje in de officiële TAG-documentatie voor hulp bij de initiële setup, log in op je kale server, en laat je nieuwe team het zware werk doen. ## Cortecs.ai: de Europese LLM-router als GDPR-native alternatief voor OpenRouter Source: https://theautomationgroup.nl/nl/blog/cortecs-ai-europese-llm-router-alternatief-openrouter Gepubliceerd: 2026-05-19 Cortecs.ai positioneert zich als Europe's LLM Router: 150+ model endpoints, EU-sovereign hosting, pass-through pricing en GDPR-compliance als primaire Data Processor. Wat betekent dat voor Nederlandse engineering teams die nu nog OpenRouter gebruiken? Als AI-engineer in Europa loop je vroeg of laat tegen dezelfde muur op. Je bouwt een werkend prototype, de performance van het geselecteerde taalmodel overtreft de verwachtingen, en dan komt het project on hold te staan bij de afdeling compliance. Sinds de definitieve uitrol van de AI Act en de aangescherpte controles rondom de GDPR, vereisen klanten en interne security-teams steeds vaker waterdichte garanties over data-residency. Data Privacy Impact Assessments (DPIA's) leggen genadeloos bloot waar bedrijfsgeheimen of persoonsgegevens het Europese grondgebied verlaten of als trainingsdata dreigen te eindigen. Tot voor kort zochten Nederlandse engineering teams hun heil in complexe, zelfgebouwde infrastructuur over publieke cloud-providers of accepteerden ze enorme lock-in bij één vendor. Gedeelde API-gateways en routers, zoals het populaire OpenRouter, boden een uitkomst voor de gefragmenteerde markt van Foundation Models, maar vielen voor enterprise-applicaties vaak af vanwege Amerikaanse jurisdictie en ontbrekende compliancestructuren voor de achterliggende providers. Cortecs.ai is recent de markt betreden om specifiek dit vacuüm te vullen. Ze positioneren zich als Europe's LLM Router met een sterke nadruk op controle, GDPR-conformiteit en Europese hosting. Wat Cortecs.ai precies is Het Oostenrijkse Cortecs.ai functioneert als een toegangspoort tot meer dan 150 model endpoints, zonder dat je als engineer voor elke modelaanbieder aparte contracten, keys en architectuur-integraties hoeft te beheren. Waar het technisch interessant wordt, is hun routing-architectuur. Al het inferentieverkeer verloopt uitsluitend via providers binnen een EU sovereign cloud. Concreet betekent dit dat de rekenkracht geleverd wordt door servers in Spanje, Duitsland, Frankrijk, Finland en Polen. Achter de schermen gebruikt Cortecs een methode die zij filter-and-rank routing noemen. Bij elke aanvraag controleert de router eerst jouw vooraf ingestelde requirements. Modellen en aanbieders die niet aan deze compliance- of technische eisen voldoen, worden weengefilterd. De overgebleven route-opties worden vervolgens dynamisch gerangschikt op basis van prijs en op dat moment beschikbare performance. Dit mechanisme resulteert volgens eigen opgaven in een 99,99% uptime garantie door seamless switching tussen back-up providers, en een gemiddelde kostenreductie van 32% per API-call. Het platform is fundamenteel gebouwd om niet in de weg te staan van je bestaande stack. Het biedt een API die functioneert als een directe drop-in replacement voor OpenAI. Daarnaast blijft het overgrote deel van de multimodale functionaliteiten behouden: naast standaard tekstgeneratie (chat), ondersteunt deze verbinding ook image input (vision), embeddings, en audio transcription. Cortecs vs OpenRouter: het GDPR-verschil Voor individuele ontwikkelaars of projecten zonder strikte privacy-eisen is een gevestigde partij als OpenRouter vaak de standaard way-to-go, doordat het een enorme catalogus aan modellen ontsluit inclusief Bring Your Own Key (BYOK) functionaliteit. Zodra je echter in een professionele Nederlandse engineering-context opereert, loop je juridisch vast. OpenRouter heeft zijn hoofdkantoor in de Verenigde Staten en biedt geen native EU-sovereign route. Nog problematischer voor compliance-officers: bij publieke routers ben je vaak zelf verantwoordelijk voor de compliance met alle afzonderlijke downstream providers (de partijen die daadwerkelijk de rekenkracht leveren). Dit is waar Cortecs fundamenteel een ander pad kiest. De dienst treedt juridisch op als primaire Data Processor. Dit houdt in dat Cortecs de contractuele verantwoordelijkheid en compliance-afspraken naar alle onderliggende cloudproviders afhandelt. Jij sluit één Data Processing Agreement (DPA) af, die geldt voor de volledige keten. Dit reduceert administratieve overhead bij vendor onboarding aanzienlijk. "Als engineer hoef je je geen zorgen te maken over welke server in welk Europees land het model draait. De garantie is dat de payload Europa niet verlaat en nergens opgeslagen wordt." Om deze claims onder de AI Act en GDPR hard te maken, implementeert Cortecs strikte dataregels. Payloads worden uitsluitend in temporary memory verwerkt en onmiddellijk na het voltooien van het request verwijderd. Het platform traint niet op jouw data, en—cruciaal—onderliggende aanbieders zijn hiervan contractueel eveneens uitgesloten. Mochten de policies van je organisatie nog strakker zijn, dan biedt Cortecs de optie om handmatig specifieke providers in de routering uit te sluiten. Hoe het in code werkt De architectuur is erop gericht om migratietijd tot een minimum te beperken. Omdat het endpointvolledig OpenAI-compatible is, hoef je bestaande codebases die gebruikmaken van de officiële SDK's vrijwel niet aan te passen. Door uitsluitend de Base URL en de API key te overschrijven, routeer je direct al het verkeer via het Europese netwerk. Een standaard implementatie met de Python SDK ziet er als volgt uit: from openai import OpenAI client = OpenAI( base_url="https://api.cortecs.ai/v1/", api_key="jouw_cortecs_api_key" ) # Je kunt nu de reguliere OpenAI methodes gebruiken response = client.chat.completions.create( model="meta-llama/llama-3.1-70b-instruct", messages=[ {"role": "user", "content": "Analyseer deze dataset..."} ] ) Buiten de directe API-aansluiting integreert deze drop-in standaard moeiteloos in het bredere engineering-ecosysteem. Bestaande integraties met orchestratie- en observatietools zoals LangChain, Langfuse, en LibreChat worden out-of-the-box ondersteund. Ook voor coding assistants en IDE-plugins zoals Cline, Kilo Code, Open WebUI en OpenCode vormt het platform een transparante laag. Pricing en lock-in Inherent aan gateways is de angst voor ondoorzichtige verborgen kosten en vendor lock-in. De meeste commerciële API-gateways rekenen een fee per getransmitteerde token (markup), of vereisen maandelijkse enterprise abonnementen die vooraf zwaar in het budget snijden. Cortecs positioneert zich expliciet met een pure pass-through kostenstructuur. Er zit géén markup op de daadwerkelijke tokens; je betaalt de ruwe kostprijs voor de inferentie via het geselecteerde taalmodel. Het verdienmodel rust volledig op een transparante flat fee van 5% op het moment dat je credits aan je account toevoegt (top-up). Geen abonnementskosten (no subscriptions) Geen toevoeging op tokenprijzen (pure pass-through) Enterprise controle zonder kunstmatige rate limits Voor infrastructuur onafhankelijk ontworpen applicaties, vermindert dit de financiële frictie en biedt het een schaalbare structuur die meebeweegt met de grootte van de workload, zonder de onvoorspelbaarheid van dynamische token-opslagen. Wanneer wel, wanneer niet Binnen The Automation Group (TAG) beoordelen we tools altijd op hun pragmatische waarde. Cortecs.ai vult een wezenlijk gat in de Europese AI-infrastructuur, maar het is cruciaal om te identificeren voor welke use cases dit de juiste tool is. Deze architectuur is ideaal voor gevestigde partijen in gereguleerde sectoren. Als je bouwt voor de zorg, finance, het juridische domein of (semi-)overheid, streept de "GDPR-native als Data Processor"-benadering veel compliance-boxen met één penstreek af. Het feit dat partijen als Raiffeisen-Landesbank Steiermark, Verbund, het Oostenrijks Ministerie van Binnenlandse Zaken, Austrian Wirtschaftsservice (AWS), FFG, WKO en zelfs de ESA (European Space Agency) als klant op het platform draaien, levert de nodige social proof aan chief information security officers. Wanneer is Cortecs minder relevant? Ben je een team dat al een intensief partnership heeft lopen en infrastructuur strak heeft uitgelijnd direct bij Azure OpenAI of Google Vertex AI in Europese beheerregio's met sluitende DPA's? Dan is de toegevoegde waarde van deze tussenlaag beperkt tot een klein prijsvoordeel. Daarnaast adviseren wij altijd een rigide testfase als je bezig bent met complexe agentic workflows, zoals Model Context Protocol (MCP) integraties. Bij dergelijke geavanceerde architectuur moet je vooraf specifiek testen of functionaliteiten zoals naadloos streamen en complexe tool calling structuren volledig behouden blijven door de routering heen bij je gewenste modellen. Wat dit betekent voor Nederlandse engineering teams Voor de Nederlandse markt betekent de komst van gespecialiseerde Europese LLM-routers een belangrijke verschuiving in hoe we productieklare AI-applicaties ontwerpen. Platforms zoals Cortecs verlagen de drempel om snel, efficiënt en vooral compliant een diversiteit aan Foundation Models, open weights modellen en in de toekomst zelfs opkomende specifieke reasoning engines te deployen voor enterprise-gebruik. Toch is het belangrijk te realiseren dat infrastructuur niet de enige bepalende factor is. Vanuit TAG-perspectief geloven we dat robuuste failovers, goed geconfigureerde evaluaties (evals) en diepgaande observability op de output de échte differentiators in productiegerichte AI blijven. Een router delegeert slechts the pijplijn en compliance eromheen. Een router is bovendien de grenslaag van de "publieke" cloud-oplossing. Mocht de aard van je project of klantendata zó kritiek zijn dat zelfs verwerking in temporary memory op een Europese server niet is toegestaan, verdwijn je in het domein van ware on-premise deployments — waarbij het draaien van oplossingen als OpenClaw lokaal binnen de eigen fysieke of private cloud de enige wezenlijk compliant optie blijft. Voor het brede middensegment van enterprise applicaties, waar wendbaarheid en kostenbeheer net zo zwaar wegen als GDPR-compliance, biedt Cortecs.ai momenteel een van de meest pragmatische oplossingen op de Europese markt. ## De mythos van AI-cybersecurity: Waarom uw security team een F1-pit crew moet worden Source: https://theautomationgroup.nl/nl/blog/de-mythos-van-ai-cybersecurity-waarom-uw-security-team-een-f1-pit-crew-moet-worden-mpci48mj Gepubliceerd: 2026-05-19 Anthropic's Project Glasswing en de 'Mythos' capability veranderen de economie van zero-days permanent. Voor CTO's en engineering managers betekent dit dat de focus moet verschuiven van detectie naar meedogenloze response-snelheid. Een blauwdruk voor de AI-gedreven SDLC. De race tegen de machine In de Formule 1 duurt een perfecte pitstop minder dan twee seconden. In die fractie van een seconde worden vier banden verwisseld, aerodynamische aanpassingen gedaan en wordt de auto veilig terug de baan op gestuurd. Deze snelheid is geen resultaat van haast, maar van meedogenloze voorbereiding, perfecte telemetrie en een feilloze choreografie. Er is geen ruimte voor improvisatie wanneer de auto de pitbox inrijdt. Voor enterprise software development en cybersecurity naderen we een vergelijkbaar omslagpunt. De tijd die een organisatie heeft tussen de ontdekking van een kwetsbaarheid en de actieve uitbuiting ervan (de patching-window), krimpt in hoog tempo. Gedreven door de opkomst van AI-modellen die autonoom kwetsbaarheden kunnen opsporen, verandert het speelveld fundamenteel. Om in dit nieuwe tijdperk te overleven, moeten engineering en security teams stoppen met acteren als traditionele IT-beheerders, en beginnen met opereren als een F1-pit crew. 1. Project Glasswing en de 'Mythos' capability: De economie van zero-days kantelt Om te begrijpen waarom de urgentie zo hoog is, moeten we kijken naar wat er momenteel in de voorhoede van AI-ontwikkeling gebeurt. Een cruciaal voorbeeld hiervan is Project Glasswing, een initiatief van Anthropic in samenwerking met zwaargewichten als AWS, Apple, Cisco, CrowdStrike, Google, Microsoft, NVIDIA en Palo Alto Networks [1]. Het doel? Kritieke software-infrastructuur beveiligen in het AI-tijdperk. Onder de paraplu van dit project bevindt zich een interne capability met de codenaam Mythos. Mythos is specifiek ontworpen voor vulnerability discovery: het opsporen van zero-day kwetsbaarheden in complexe codebases. Hoewel exacte releasedata of uitputtende cijfers over de huidige capaciteiten niet publiek zijn (en we weg moeten blijven van speculatie), is de impact van de preview-fase onmiskenbaar. Mythos bleek in staat om voorheen onbekende zero-days te identificeren in grote besturingssystemen, browsers en enterprise systemen [2]. Wat dit betekent voor CTO's en security leads is niet slechts een technologische update, maar een fundamentele verschuiving in de economie van vulnerability discovery. Historisch gezien kostte het vinden van een kritieke zero-day maanden aan handmatig, hooggespecialiseerd onderzoek. Het was duur en schaars. AI-modellen zoals die achter Mythos reduceren deze kosten van maanden aan menselijke arbeid naar seconden aan compute. Wanneer het ontdekken van zero-days schaalbaar en goedkoop wordt, verdwijnt het asymmetrische voordeel van de verdediger die leunt op security by obscurity of trage ontdekkingscycli [8]. 2. Het tweede mythos-niveau: Detectie is een gepasseerd station Dit brengt ons bij een hardnekkige mythe (een tweede 'mythos') binnen de huidige cybersecurity-industrie: de overtuiging dat AI primair een tool is voor betere detectie. Veel organisaties investeren zwaar in AI om anomalieën in netwerkverkeer te vinden of logbestanden te parsen. Maar als AI de ontdekking van kwetsbaarheden automatiseert, en aanvallers AI gebruiken om de exploitatie ervan te automatiseren, dan is detectie alleen niet meer voldoende. Tegenstanders draaien inmiddels autonome tooling en lanceren parallelle campagnes op een schaal die voorheen ondenkbaar was [3]. Een alert in een dashboard is in dit scenario geen waarschuwing, maar een notificatie dat u al te laat bent. "Mythos breekt elke bestaande SOC-workflow. Als het volume aan legitieme, kritieke alerts exponentieel stijgt, is autonome processing de enige architectuur die nog schaalt." [4] Het echte verschil in het AI-tijdperk zit in response-snelheid. Een traditioneel Security Operations Center (SOC) dat leunt op menselijke analisten om alerts te triëren, verdrinkt in de ruis. Platformen claimen inmiddels dat AI-gedreven triage de kosten per alert kan terugbrengen naar centen, waarbij 95% van de alerts in minder dan twee minuten wordt verwerkt en de ruis met 99% afneemt [4]. De mens moet uit de initiële detectie-loop, en opschuiven naar de orchestratie- en goedkeuringslaag. 3. De F1 Pit Crew-analogie: Telemetrie, Triage en Choreografie Hoe ziet een organisatie eruit die is geoptimaliseerd voor extreme response-snelheid? Hier biedt de Formule 1 een perfecte, en vaak aangehaalde, blauwdruk [9, 11]. Een succesvolle pitstop draait om twee componenten: de Pit Wall en de Pit Crew [10]. De Pit Wall: Telemetrie en AI-Triage Aan de pitmuur zitten de strategen. Zij kijken niet naar de auto, maar naar schermen vol real-time telemetrie. In software development is dit uw observability stack, verrijkt met AI. De pit wall voorspelt wanneer de banden (of in ons geval, een specifieke open-source library) zullen falen. AI-agents fungeren hier als de race-engineers: ze filteren de terabytes aan logdata, correleren kwetsbaarheden met actieve dreigingen en bereiden de strategie voor voordat het incident de codebase raakt. De Pit Crew: De Patching-Window Wanneer de beslissing is genomen om in te grijpen, neemt de pit crew het over. Er is geen tijd voor overleg over wie welk wiel doet. De rollen zijn strikt gedefinieerd, de bewegingen zijn gechoreografeerd. Voor een engineering team betekent dit dat het proces van patchen, testen en deployen volledig geautomatiseerd moet zijn. Een patching-window van weken is onacceptabel; we praten over uren of zelfs minuten. Autonome systemen schrijven de patch, AI-agents draaien de regressietesten, en de menselijke engineer fungeert enkel nog als de 'lollypop-man' die het bord omhoog haalt en de release goedkeurt (human-in-the-loop). 4. Concrete consequenties voor Software Development Teams Deze behoefte aan extreme snelheid en automatisering heeft directe gevolgen voor de manier waarop we software bouwen. De traditionele Secure Software Development Life Cycle (SSDLC) moet evolueren [5]. Van Shift-Left naar Shift-Everywhere: Het adagium was altijd om security zo vroeg mogelijk ('left') in het proces te integreren. Maar met AI-agents die continu code genereren en aanpassen, is security geen fase meer, maar een continue staat. Security checks moeten overal plaatsvinden: tijdens het coderen, in de PR, tijdens de build, en in productie [8]. De noodzaak van SBOM en Provenance: U kunt geen auto in twee seconden repareren als u niet weet welke onderdelen erin zitten. Een real-time, cryptografisch verifieerbare Software Bill of Materials (SBOM) is uw inventarislijst. Zonder inzicht in de provenance (herkomst) van uw code, bent u blind voor supply-chain aanvallen. AI Agents in de CI/CD Pipeline: AI wordt niet alleen gebruikt om code te schrijven, maar ook om deze te reviewen. Momenteel gebruikt 82% van de developers AI-coding tools, maar slechts 28% vertrouwt de output volledig [6]. En terecht: in sommige scenario's bevat AI-gegenereerde code 40-50% exploiteerbare kwetsbaarheden [7], en prompt injection is een reëel risico [6]. AI-agents in de CI/CD-straat moeten fungeren als meedogenloze, geautomatiseerde auditors die deze fouten afvangen voordat ze mergen. Secure-by-default Scaffolding: Developers moeten werken binnen frameworks die het onmogelijk maken om veelvoorkomende fouten te maken. Als een AI-coding assistant een SQL-injectie voorstelt, moet de onderliggende architectuur (bijvoorbeeld door verplichte ORM's) deze code weigeren te compileren. 5. Maandagochtend: Vijf stappen voor de startopstelling De theorie is helder, maar wat kan een engineering organisatie aanstaande maandag concreet doen om de transitie naar een F1-model in te zetten? Hier zijn vijf actiegerichte stappen: Implementeer keiharde SBOM- en Provenance-eisen: Maak het genereren van een SBOM een verplichte, falende stap in uw CI/CD-pipeline. Als een applicatie geen actuele componentenlijst kan overleggen, mag deze niet naar productie. Gebruik standaarden zoals SLSA (Supply-chain Levels for Software Artifacts). Automatiseer de Triage-laag (Bouw de Pit Wall): Evalueer uw huidige SOC- en alert-infrastructuur. Als uw team nog steeds handmatig false-positives aan het wegklikken is, verliest u de race. Implementeer AI-gedreven triage-tools die de ruis reduceren en alleen gecontextualiseerde, kritieke incidenten doorlaten naar menselijke analisten. Zet AI Agents in voor Autonomous Patching (in testomgevingen): Begin met het inzetten van AI-agents (zoals Dependabot on steroids) die niet alleen waarschuwen voor verouderde packages, maar autonoom de PR aanmaken, de code aanpassen en de unit tests draaien. Laat de uiteindelijke merge-beslissing voorlopig bij een senior engineer liggen. Isoleer en monitor AI-gegenereerde code: Accepteer dat developers AI-assistenten gebruiken, maar behandel de output als untrusted input. Richt specifieke linting- en SAST-regels in die getraind zijn op de typische hallucinaties en kwetsbaarheden die LLM's introduceren. Oefen de 'Drill' (Chaos Engineering): Een pit crew traint duizenden keren per jaar. Voer tabletop exercises en red-teaming sessies uit met gecomprimeerde tijdslijnen. Simuleer een zero-day in een kritieke library en meet de tijd (MTTR) tot de patch in productie staat. Optimaliseer de knelpunten. De komst van AI-capabilities zoals Anthropic's Mythos betekent dat het tijdperk van trage, handmatige security definitief voorbij is. De organisaties die overleven, zijn niet de organisaties met de dikste muren, maar de organisaties met de snelste pit crew. De race is al begonnen. Bronnen Anthropic - Project Glasswing D3 Security - "The Mythos Problem: 10,000 Zero-Days and the SOC That Can't Keep Up" Prophet Security - "What Claude Mythos Actually Means for Your Security Program" D3 Security - Autonomous Mythos Response / Morpheus AI Veracode (apr 2025) - Securing the AI-Driven Development Environment Snyk / O'Reilly Report: AI coding tools adoption and trust Checkmarx: Vulnerabilities in AI-generated code CSET Georgetown (aug 2025) - AI and the Software Vulnerability Lifecycle InformationWeek - "How DevOps Is Like A Formula 1 Pit Crew" CrowdStrike - "The F1 Pit Wall: A Better Metaphor for Teamwork" CDO Magazine - "Information Security Is Like an F1 Pit Crew" ## Graph Engineering vs. Loop Engineering in AI Agents Source: https://theautomationgroup.nl/en/blog/graph-engineering-vs-loop-engineering-en Gepubliceerd: 2026-09-14 Explore the architectural trade-offs between graph and loop engineering when building AI Agents, including production realities and state management. As organizations move beyond basic prompt engineering to deploy autonomous systems, the central architectural question for any Agentic AI Engineer becomes one of control. How much autonomy do you hand over to the large language model (LLM), and how much do you constrain its execution through predefined paths? This tension has given rise to two distinct but overlapping paradigms in the development of AI Agents: loop engineering and graph engineering. Choosing between them dictates how your systems handle state, recover from failures, and scale in production. The Core Architectural Divide: Workflows vs. Agents To understand the difference between graph and loop engineering, we must first define the spectrum of autonomy. According to Anthropic, the distinction lies in who directs the process [1]. Workflows are systems where LLMs and tools are orchestrated through predefined code paths. The system dictates the sequence of events, and the LLM is utilized at specific junctures to process information or generate text. Agents, conversely, are systems where the LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks [1]. Workflows offer predictability and consistency, making them ideal for well-defined tasks. AI Agents are better suited for scenarios requiring flexibility and model-driven decision-making at scale [1]. However, as frameworks have evolved, the line between these two concepts has blurred, leading to the specific engineering practices of loops and graphs. Loop Engineering: The Model in the Driver's Seat Loop engineering focuses on a core, iterative cycle driven by the LLM's reasoning capabilities. The OpenAI Agents SDK explicitly defines this "agent loop" as the foundational concept of their architecture [12]. The mechanics are straightforward: the system calls the model, inspects the output, and acts based on that output. If the model requests a tool call, the system executes the tool and feeds the result back into the model. If the model requests a handoff, the system switches to a different agent and continues. If the model provides a final answer without requiring further tool work, the loop terminates and returns the result [12]. In this paradigm, tools, handoffs, approvals, and streaming are all built on top of this core loop rather than replacing it [12]. The philosophy here leans heavily on the inherent capabilities of the model. Anthropic notes that in their experience, the most successful implementations do not rely on complex frameworks or specialized libraries; instead, they are built with simple, composable patterns [1]. They advocate for finding the simplest solution possible and only increasing complexity when absolutely necessary [1]. This approach aligns with the principles of declarative programming seen in frameworks like DSPy, which encourages developers to "program, don't prompt" [19]. By defining tasks as structured inputs and outputs, developers can compose multiple tasks into multi-step programs and agents where each piece remains independently inspectable, swappable, and tunable [19]. This allows for the compilation of declarative language model calls into self-improving pipelines [20]. A Critical Terminology Conflict It is vital for any Agentic AI Engineer to be aware of a significant terminology conflict in the industry regarding the word "loop." While Anthropic, LangChain, and OpenAI use "loop" to describe a dynamic, model-driven, autonomous cycle, Google's Agent Development Kit (ADK) uses the term to mean the exact opposite. In the Google ADK documentation, a "Loop workflow agent" (specifically the LoopAgent class) is defined as a template workflow that executes sub-agents in a loop for a specified number of iterations or until a termination condition is met [13]. Crucially, Google explicitly states that "the execution of a LoopAgent object is not controlled by an AI model, and is deterministic" [13]. Therefore, when discussing loop engineering, you must clarify whether you are referring to the deterministic, non-model-controlled iteration (Google ADK) or the dynamic, model-driven autonomy (OpenAI/Anthropic/LangChain). Graph Engineering: Constraining the Model If loop engineering relies on the model's judgment to navigate a task, graph engineering allows the builder to impose preconceptions of how the system should work into more constrained paths [6]. The term "graph engineering" gained traction as a natural successor to prompt engineering and context engineering, describing the practice of representing agentic systems as graphs [6]. LangGraph, which was launched as a low-level agent framework and is used in production by companies like LinkedIn, Uber, and Klarna [7], models agent workflows as graphs utilizing "State" as a shared data structure [8]. The mechanics are based on nodes and edges. In LangGraph, nodes do the actual work. A node can be deterministic code, a single LLM call, a tool call, or even a full agent with its own internal loop [6]. The edges define what happens next, effectively creating a state machine [6]. Graph engineering is particularly useful when you need a predictable structure. For example, a support agent might need to classify an issue deterministically before answering or escalating; a coding agent might be required to inspect a repository before proposing a change; or a compliance workflow might require explicit approval before an external action occurs [6]. Graphs allow the Agentic Consultant or engineer to explicitly define "where the model gets to choose, and where the system should enforce deterministic behavior instead of hoping the model makes the right call every time" [6]. It is important to note that agent graphs are usually not Directed Acyclic Graphs (DAGs). Production AI Agents require cycles for retries, human input, and revision loops [6]. Furthermore, graph frameworks offer runtime flexibility, such as LangGraph's Send API, which allows for fan-out/map-reduce operations when the number of downstream nodes is unknown ahead of time [6]. However, graph engineering is not a silver bullet. The documentation for Pydantic AI (which offers pydantic-graph, an async graph and state-machine library for Python designed for advanced users) provides a stark warning: "Don't use a nail gun unless you need a nail gun" [14]. They argue that if basic agents are a hammer, and multi-agent workflows are a sledgehammer, graphs are a nail gun. They look impressive, but they require significantly more setup. If you are not confident a graph-based approach is necessary, it might be overkill [14]. LangChain echoes this, noting that forcing tasks that are agentic by nature into deterministic paths is the wrong move [6]. The Multi-Agent Context Problem Both loop and graph architectures frequently evolve into multi-agent systems, where an orchestrator manages various sub-agents. Anthropic describes their Claude Research function as a true multi-agent system designed for open-ended search tasks [2]. However, building reliable multi-agent systems introduces severe complexities regarding context. Cognition initially warned against building multi-agent architectures, pointing out that the reliability of long-running agents depends heavily on Context Engineering [4]. They provided a compelling failure mode: attempting to build a Flappy Bird clone by splitting the task into one sub-agent for the background and another for the bird. Even if each sub-task succeeds individually, the final integrated result is often inconsistent [4]. This happens because "actions carry implicit decisions, and conflicting decisions carry bad results" [4]. To mitigate this, systems must share context and full agent traces, not just individual messages [4]. While Cognition initially criticized libraries like OpenAI Swarm and Microsoft AutoGen for pushing multi-agent architectures [4], they later explicitly revised their stance, noting that "a lot has changed" and acknowledging that multi-agent systems are now working under certain conditions [5]. LangChain synthesizes this debate by stating that context-engineering and context-sharing are the defining factors of success, rather than a dogmatic rule to "always" or "never" build multi-agent systems [3]. Production Realities: State, Interrupts, and Durability Whether you choose a loop or a graph, deploying AI Agents into production introduces challenges that neither architecture natively solves on its own: non-deterministic models, long-running executions that wait for human input, and the need to survive crashes and software updates [18]. Graph frameworks like LangGraph address this through a dedicated persistence layer. LangGraph checkpointers save the graph state as checkpoints at each step [9]. This enables fault-tolerant execution and gives AI Agents short-term memory [10]. It also allows for "Interrupts," which pause graph execution at specific points to wait indefinitely for external input, enabling human-in-the-loop patterns [11]. For loop-based architectures, the OpenAI Agents SDK outlines four strategies for state persistence: in-app history, replay-ready session storage, a server-managed Conversations API, and previousResponseId [12]. However, for true enterprise-grade reliability, the industry is moving toward durable execution. Temporal argues that "it has become remarkably easy to give an AI agent capabilities. It's much harder to give one responsibility. That's because responsibility requires control" [17]. By integrating the OpenAI Agents SDK with Temporal's Python SDK, engineers can ensure that the execution thread itself becomes the workflow, providing durable AI agents without requiring changes to the core agent code [15, 16, 18]. The Evidence Gap When evaluating these architectures, technical decision-makers must be aware of a significant blind spot in the industry: there is currently no controlled benchmark or peer-reviewed study that empirically compares graph-structured agents against pure loops in terms of task success rates, operational costs, or latency. All available evidence, best practices, and architectural recommendations are derived entirely from field experience, vendor documentation, and engineering blogs. Any claim that one approach is universally or empirically superior to the other lacks independent scientific validation. Comparative Analysis To assist in architectural decision-making, the following table outlines the qualitative trade-offs between pure loop engineering (model-driven) and graph engineering (system-constrained). Architectural Axis Loop Engineering (Model-Driven) Graph Engineering (System-Constrained) Predictability Lower. Execution paths vary based on the LLM's real-time reasoning and tool outputs. Higher. The system enforces deterministic behavior and predefined routing between nodes. Observability Requires deep tracing of the model's internal reasoning and tool-call history. Structured. State transitions between nodes provide clear, step-by-step execution logs. Durability & Recovery Relies on external durable execution frameworks (e.g., Temporal) or session storage. Often built-in via checkpointers (e.g., LangGraph) saving state at every node transition. Flexibility Maximum. The agent can dynamically adjust its plan based on unexpected inputs. Constrained. Flexibility is limited to the predefined edges and dynamic fan-out APIs. Maintenance Burden Lower initial setup, but prompt/context tuning becomes complex as tasks scale. Higher initial setup (the "nail gun"). Requires managing state schemas and routing logic. Conclusion The debate between graph engineering and loop engineering is ultimately a discussion about abstraction and control. As LangChain notes, loops are essentially simple graphs, and loop engineering is not so much an alternative to graphs as it is a simpler version of them [6]. Anthropic warns that frameworks often create extra layers of abstraction that obscure underlying prompts, making systems harder to debug [1]. Therefore, the most pragmatic approach for an Agentic AI Engineer is to start with simple, composable loops. Only when the task requires strict deterministic routing, explicit human-in-the-loop pause points, or complex state management should you reach for the graph engineering "nail gun." Sources Anthropic, "Building Effective Agents", December 19, 2024. https://www.anthropic.com/engineering/building-effective-agents Anthropic, "How we built our multi-agent research system", June 13, 2025. https://www.anthropic.com/engineering/multi-agent-research-system Harrison Chase (LangChain), "How and when to build multi-agent systems", June 16, 2025. https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems Walden Yan (Cognition), "Don't Build Multi-Agents", June 12, 2025. https://cognition.com/blog/dont-build-multi-agents Walden Yan (Cognition), "Multi-Agents: What's Actually Working", April 22, 2026. https://cognition.com/blog/multi-agents-working Sydney Runkle & Harrison Chase (LangChain), "3 Years of Graph Engineering with LangGraph", July 22, 2026. https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph Nuno Campos (LangChain), "Building LangGraph: Designing an Agent Runtime from first principles", September 4, 2025. https://www.langchain.com/blog/building-langgraph LangGraph docs, "Graph API overview". https://docs.langchain.com/oss/python/langgraph/graph-api LangGraph docs, "Checkpointers". https://docs.langchain.com/oss/python/langgraph/checkpointers LangGraph docs, "Persistence". https://docs.langchain.com/oss/python/langgraph/persistence LangGraph docs, "Interrupts". https://docs.langchain.com/oss/python/langgraph/interrupts OpenAI Agents SDK docs, "Running agents". https://developers.openai.com/api/docs/guides/agents/running-agents Google Agent Development Kit (ADK), "Loop workflow agent" docs. https://adk.dev/agents/workflow-agents/loop-agents/ Pydantic AI, "Graphs" documentation (pydantic-graph). https://pydantic.dev/docs/ai/graph/graph/ Cornelia Davis (Temporal), "Durable Execution meets AI: Why Temporal is ideal for AI agents & Generative AI Apps", July 10, 2025. https://temporal.io/blog/durable-execution-meets-ai-why-temporal-is-the-perfect-foundation-for-ai Cornelia Davis (Temporal), "Production-ready agents with the OpenAI Agents SDK + Temporal", July 30, 2025. https://temporal.io/blog/announcing-openai-agents-sdk-integration Cornelia Davis (Temporal), "Temporal Agent Harness: An early look at durable agent infrastructure", August 20, 2026. https://temporal.io/blog/temporal-agent-harness-durable-agent-infrastructure Greg Haskins (Manetu / Temporal guest post), "The thread is the Workflow: Durable AI agents without changing Agent code", September 3, 2026. https://temporal.io/blog/manetu-the-thread-is-the-workflow DSPy, "Program, don't prompt". https://dspy.ai/getting-started/program-dont-prompt/ Khattab et al., "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines", arXiv:2310.03714 (ICLR 2024). https://arxiv.org/abs/2310.03714 ## Cybersecurity & AI in 2026: what organisations actually need to fix Source: https://theautomationgroup.nl/en/blog/cybersecurity-ai-2026-en Gepubliceerd: 2026-06-08 From Shadow AI and prompt injection to a $25.6M deepfake heist: a sober map of the risks, the frameworks (OWASP LLM Top 10, EU AI Act, ISO 42001) and a workable defensive architecture for 2026. In February 2024, the multinational engineering firm Arup lost $25.6 million when an employee in Hong Kong authorised a massive fund transfer following a Zoom call with the company's Chief Financial Officer and several colleagues. None of the people on that screen were human; deepfake video and voice attacks have fully transitioned from theoretical novelties to devastating enterprise realities, forcing every Chief Information Security Officer to confront a rapidly mutating threat landscape. The state of AI security in 2026 We have fundamentally changed how enterprise software operates. For the last four decades, cybersecurity has relied on the premise of determinism: specific inputs processed by static code paths yield predictable outputs. You build firewalls, you sanitise database queries, and you restrict network traversal based on rigid, rule-based logic. The deployment of generative models and autonomous systems breaks this paradigm completely. An AI Agent does not process structured queries; it interprets natural language, interprets intent, and autonomously executes actions across your corporate environment. The prompt is no longer just text. It is entirely new, executable input bridging the gap between external untrusted actors and internal proprietary APIs. Because artificial intelligence systems are inherently non-deterministic, traditional application security mapping fails. We are deploying software that reasons, hallucinates, and can be easily duped into bypassing its own guardrails. Furthermore, we are giving an AI Agent operational rights—the ability to read emails, write to databases, and trigger financial workflows—without providing it with human judgment. The disparity between adoption speed and security maturity has created the largest vulnerable attack surface we have seen since the dawn of internet-facing applications. According to IBM's Cost of a Data Breach 2025 report, 13 percent of organisations have already experienced an AI model or application breach, and a staggering 97 percent of those organisations lacked adequate AI access controls. The financial consequences of this control gap are concrete. The same IBM data reveals that the average AI-related data breach costs an organisation $4.44 million globally, skyrocketing to $10.22 million in the United States. Meanwhile, the sheer volume of external attacks leveraging generative infrastructure is overwhelming traditional defences. Data from Pindrop in 2025 showed a 1300 percent increase in deepfake fraud year-over-year, hitting the banking and insurance sectors disproportionately hard. The FBI Internet Crime Complaint Center documented $893 million in AI-fraud damages in a single year. These are not script kiddies running basic automated scanners; these are highly adaptive, AI-driven campaigns. According to Cofense telemetry from 2026, enterprise users now face one AI-generated phishing attack every 19 seconds. Alarmingly, training humans to spot these attacks is yielding diminishing returns; Hoxhunt data indicates that AI-generated phishing is now 55 percent more effective than campaigns designed by elite human red teams. What goes wrong inside your organisation Long before an external threat actor targets your infrastructure, the internal chaos of undocumented deployment compromises your perimeter. The foremost internal threat remains Shadow AI. Your executives, business analysts, and developers are bypassing IT procurement to use powerful, unsanctioned generative tools, and they are feeding your most sensitive intellectual property into public models. Gartner projects that by 2030, over 40 percent of organisations will suffer a major incident originating from Shadow AI, a reality already dawning on the 69 percent of CISOs who suspect or have confirmed its existence in their networks. The scale is daunting: research by Reco.ai in 2025 revealed that the average enterprise environment hosts roughly 490 Software-as-a-Service applications, with roughly 53 percent remaining completely unauthorised and unmonitored. When staff feed confidential data into unsanctioned models, prompt leaking becomes inevitable. The precedent was spectacularly set during the Samsung incident in April 2023, where within a single month, employees uploaded proprietary source code, semiconductor test sequences, and sensitive meeting notes directly into ChatGPT, forcing the conglomerate to issue a blanket ban on generative AI. Compounding this is the ongoing risk of model memorization and extraction. Large Language Models are designed to recall patterns, and without strict filtering, they regularly recite verbatim personally identifiable information, internal passwords, and proprietary documents absorbed during training or subsequent corporate fine-tuning. The next major vulnerability stems from how we build internal systems. Every time an Agentic Engineer integrates a model with corporate infrastructure, they risk creating what the industry calls Excessive Agency. Instead of adhering to the principle of least privilege, development teams often grant an AI Agent broad administrative permissions to ensure workflows function smoothly. A profound example emerged when the Cloud Security Alliance uncovered structural cloud privilege escalation risks via Vertex AI in 2026, demonstrating how over-permissioned agents can accidentally act as conduits for attackers to traverse cloud environments. Supply chain integrity has also collapsed under the weight of AI development. Open-source repositories are riddled with compromised assets. In 2024, JFrog discovered hundreds of machine learning models hosted on HuggingFace containing backdoors leveraging notoriously insecure Python pickle exploits, granting remote code execution upon loading. Similar findings by nullifAI in 2025 proved this was a systemic issue. Making matters worse, the adoption of the Model Context Protocol has introduced deep vulnerabilities. Invariant Labs discovered critical flaws they termed "MCP Tool Poisoning," where malicious servers inject hidden instructions directly into your agents. Affecting major platforms like Anthropic, OpenAI, Zapier, and Cursor, Microsoft aptly described MCP as the "USB port for AI"—a highly convenient interface that readily accepts RugPull and Shadow Server attacks, infecting internal processes without triggering traditional endpoint detection. Attack vectors from the outside External actors have moved far beyond basic data theft; they are weaponising natural language to seize control of your generative infrastructure. The primary vector remains prompt injection. An attacker embeds malicious instructions within an otherwise benign input, forcing the model to disregard its original system prompt and execute the attacker's payload. This is executable code masked as conversation. The progression of these attacks has been remarkably fast. We have moved from theoretical jailbreaks to weaponised exploits operating in the wild. EchoLeak (CVE-2025-32711) demonstrated the first zero-click exploit in a production large language model, proving that interaction isn't strictly necessary for a model to be compromised. Meanwhile, security researchers at Checkmarx pioneered the "markdown image trick," demonstrating seamless data exfiltrate via platforms like Copilot Chat and Gemini; an attacker simply forces the AI to render an image URL containing sensitive data as query parameters, silently sending corporate secrets to external servers. Unit42 at Palo Alto Networks tracked an explosion of indirect prompt injection in 2026, where attackers embed invisible malicious prompts onto regular corporate websites. When an employee's AI Agent scrapes that site to summarise its content, the agent unwittingly ingest the malicious instructions and executes them internally. Extensive research published by the UK AI Security Institute and Anthropic in 2025 also confirmed our worst fears regarding data and model poisoning. Attackers no longer need vast amounts of data to corrupt a neural network; a surprisingly small, constant amount of carefully structured poison samples is sufficient to compromise a model's integrity. Perhaps more disturbingly, the researchers demonstrated that "Sure Trap" backdoors deliberately inserted into basic models comfortably survive sophisticated enterprise fine-tuning processes, lying dormant until triggered by a specific attacker codeword. Adversaries are actively cataloguing these techniques against established frameworks. The MITRE ATLAS v5.6 matrix outlines the tactical lifecycle of these campaigns, highlighting reconnaissance techniques, ML model backdooring (T0018), eroding integrity (T0031), advanced LLM jailbreaks like the controversial DAN models and adversarial suffixes (T0054), and sophisticated indirect prompt injections (T0051). Defence requires continuous, dynamic evaluation against these precise adversarial patterns. The OWASP LLM Top 10 as a checklist To systematically defend against this chaos, security leadership must pivot from generic IT security frameworks to AI-specific operational checklists. The OWASP LLM Top 10 for 2025 is the definitive baseline for assessing where your architecture is failing. Treating this document as a hypothetical exercise is dangerous; your development teams need to map every Agentic Engineer workflow against these specific vulnerabilities. LLM01 Prompt Injection: This remains the absolute number one risk. Whether direct or indirect, failure to separate system instructions from user-provided data means any external user can hijack your model. LLM02 Sensitive Information Disclosure: You must assume that whatever data a model sees, it will eventually leak. Models regurgitate data. Relying on the model to "know" what is confidential is an architectural failure. LLM03 Supply Chain Vulnerabilities: Pulling unverified weights from HuggingFace without software bills of materials (SBOMs) is the modern equivalent of copy-pasting executable malware from unverified forums. LLM04 Data and Model Poisoning: Your training data pipeline requires cryptographic signing. If an attacker taints the foundational data, the entire resulting system is permanently compromised. LLM06 Excessive Agency: This relates directly to how an AI Agent scales. When an agent has read/write access to your Jira, your Slack, and your AWS environment simultaneously, a single prompt injection becomes a catastrophic network-wide breach. LLM07 System Prompt Leakage: Attackers steal your intellectual property by simply asking the model to reveal the proprietary instructions and architectural guidelines you provided to it. Addressing these specific attack vectors requires more than updating an access control list. It demands an acknowledgment that LLM05 (Improper Output Handling) can turn a benign conversational AI into a tool for Cross-Site Scripting (XSS) or remote code execution, and that LLM10 (Unbounded Consumption) allows attackers to weaponise your AI's token generation rates to run up cloud compute bills in massive denial-of-wallet attacks. What the law now requires The regulatory grace period for generative experiments has officially closed. Boardrooms that view AI security purely as an IT problem will face crippling legal and financial repercussions. The European Union has firmly established the compliance baseline. Under Article 15 of the EU AI Act, systems classified as high-risk are legally mandated to be technically robust against adversarial attacks, data poisoning, and prompt manipulation. Ignorance of MITRE ATLAS or OWASP vulnerabilities will not hold up in court. The penalties for failing to secure these systems are draconian, scaling up to €35 million or 7 percent of global annual turnover. Furthermore, Article 12 mandates complete record keeping, meaning every prompt and response must be logged and retrievable for auditing purposes. You cannot govern what you do not log. The updated NIS2 directive, in effect since October 2024, explicitly expands supply chain security mandates. Incident reporting requires a 24-to-72-hour turnaround, and crucially, software component security now encompasses neural network model weights—a legal acknowledgment that models are executable software components. If JFrog or nullifAI identify compromised machine learning models in your pipeline, NIS2 holds you accountable for deploying them. Simultaneously, privacy regulations have evolved. The General Data Protection Regulation requires a Data Protection Impact Assessment (Article 35) prior to deploying any high-risk AI, and Article 22 explicitly bans purely automated decisions that produce legal or significant societal effects without human supervision. To navigate this dense regulatory web, mature organisations are abandoning ad-hoc compliance and adopting formal management systems. ISO 42001:2023 is fast becoming the certifiable gold standard—the ISO 27001 equivalent specifically tuned for AI—working in tandem with the NIST AI Risk Management Framework 1.0. Following the NIST pillars to Govern, Map, Measure, and Manage is no longer a best practice; it is the evidentiary basis of your legal defence when an incident occurs. A workable defensive architecture Traditional firewalls and endpoint detection response platforms are blind to semantic payloads hidden within a natural language prompt. Security leaders must mandate a hard pivot towards a layered AI defensive architecture designed specifically to manage non-deterministic intent and excessive agency. The foundational step is implementing a Model Gateway. You cannot allow individual development teams to build point-to-point API connections to OpenAI, Anthropic, or external HuggingFace deployments. A Model Gateway acts as an enterprise-wide proxy forcing all LLM calls through a single inspection point. This creates instant visibility for Shadow AI detection, enforces global rate-limiting to prevent Unbounded Consumption (OWASP LLM10), and acts as the enforcement layer for data privacy. Within this gateway, rigorous input and output filtering must operate dynamically. By integrating data scrubbing engines like Presidio, you execute real-time PII redaction before the prompt ever reaches the external model. Conversely, output filtering via tools like Azure Prompt Shields analyses the returning text to block memorization leaks or malicious payload execution before it renders in the user's interface. To defend against Model Context Protocol poisoning and excessive agency, you must enforce a Zero Trust architecture for every single AI Agent deployed on your network. Adopting the Microsoft March 2026 security blueprints or the CSA Agentic Trust Framework requires severing implicit trust. Agents must be heavily restricted. When an Agentic Engineer designs a tool meant to write code or configure infrastructure, the execution of that tool must occur inside an ephemeral, hardened sandbox. Replicating the AWS Prescriptive Guidance for 2026, tool sandboxing combined with aggressive egress filtering ensures that even if an agent is compromised via an MCP shadow server attack, the blast radius is confined. Finally, to comply with the EU AI Act Article 14 and basic operational security sanity, every workflow that includes irreversible actions—such as financial transactions, database deletions, or mass external communications—must hardcode a human-in-the-loop mechanism. An AI Agent may draft the execution plan, but only a cryptographically authenticated human should authorise the trigger. Start small, start now Securing an intelligent enterprise is an iterative process, not a vendor purchase. The threat landscape detailed by IBM, Arup, and Hoxhunt proves that waiting for the dust to settle is an invitation to catastrophic loss. You need a structured, tactical timeline. In the next 30 days, your priority must be visibility. Run an aggressively scoped discovery phase to identify your organisation's baseline. Audit your SaaS bloat to address the hundreds of undocumented instances detailed by Reco.ai, and forcefully block all unsanctioned shadow tools at the firewall level. Standardise your legitimate generative traffic by routing it exclusively through a centralised Model Gateway. By day 60, shift the focus toward architectural resilience. Every Agentic Engineer in your organisation must map their current and future builds against the OWASP LLM Top 10. Implement hardened execution environments for all integrations, physically isolating Model Context Protocol instances in strict sandboxes. Ensure that prompt arrays and AI responses are securely logged to an immutable ledger. As you approach day 90, pivot from immediate mitigation to structural governance. Align your internal risk metrics with the NIST AI RMF and begin the gap analysis required for ISO 42001 certification. Ensure that your automated compliance checks satisfy the immediate incident reporting and supply chain obligations defined under NIS2 and the adversarial resilience requirements of the EU AI Act. You cannot secure artificial intelligence by recycling the playbooks of deterministic software. Building robust, legally compliant, and genuinely secure agentic workflows requires deep technical capability that bridges modern cloud engineering and offensive AI security. The transition is complex, but you do not have to architect it alone. At The Automation Group in Utrecht, we design, engineer, and secure enterprise AI systems built to withstand the realities of an adversarial world. We welcome a conversation on how to safely integrate intelligent agents into your corporate architecture. ## The Tokenmaxxing Trap: Why Amazon's AI Leaderboards Are a Masterclass in Perverse Incentives Source: https://theautomationgroup.nl/en/blog/amazon-tokenmaxxing-meshclaw-openclaw-en Gepubliceerd: 2026-05-26 The Financial Times just exposed how Amazon engineers are gaming internal AI leaderboards by automating pointless tasks. As the creators of OpenClaw—the platform that inspired Amazon's tool—we have some thoughts on why measuring token consumption is the fastest way to ruin your AI strategy. The Rise of "Tokenmaxxing" On May 12, 2026, the Financial Times published an exposé that should be required reading for every Chief Technology Officer on the planet [1]. The report detailed a bizarre new phenomenon inside Amazon's engineering ranks: "tokenmaxxing." Faced with aggressive corporate mandates requiring over 80% of developers to use artificial intelligence tools weekly, Amazon staff have resorted to automating entirely unnecessary tasks. Their goal? To artificially inflate their token consumption and climb internal AI usage leaderboards. As the senior tech editor at The Automation Group (TAG), I read this with a mixture of amusement and deep concern. The tool Amazon engineers are using to game the system is an internal platform called "MeshClaw." According to the report, MeshClaw was directly inspired by OpenClaw, our own on-premise AI agent platform that took the developer world by storm earlier this year. Flattered, but Frustrated: The OpenClaw Contrast We are, of course, immensely proud that OpenClaw's architecture and capabilities have influenced one of the world's largest tech companies. But the way Amazon has deployed and incentivized its derivative tool represents everything we built OpenClaw to prevent. OpenClaw was designed from the ground up with a strict, non-negotiable philosophy: AI agents must be secure, localized, and entirely under the user's control. By running on-premise on your own hardware, OpenClaw ensures that your proprietary data never leaves your environment. MeshClaw, by contrast, has been given sweeping access to deploy code, triage emails, and interact with Slack across a massive corporate network. As one Amazon employee bluntly told the FT, "The default security posture terrifies me" [1]. When you combine terrifyingly broad system access with a corporate culture that demands maximum AI usage, you are building a ticking time bomb, not a productivity engine. Goodhart's Law and the $200 Billion Capex Fire The core issue here is a textbook example of a perverse incentive. In economics, Goodhart's Law states that when a measure becomes a target, it ceases to be a good measure. By tracking token consumption—the basic unit of data an AI processes—and putting it on a leaderboard, Amazon has turned a utility into a vanity metric. Engineers aren't using AI to solve complex architectural problems; they are using it to summarize emails they will never read and write boilerplate code they don't actually need. The financial irony is staggering. Amazon is expected to spend a mind-boggling $200 billion on capital expenditures in 2026, driven largely by the need for massive AI infrastructure [1]. How much of that expensive, energy-hungry compute is being burned by engineers who are simply trying to keep their middle managers happy? Tokenmaxxing isn't just a waste of human time; it is a colossal waste of silicon and electricity. The 10x Engineer Philosophy: Leverage, Not Vanity At TAG, our vision of the AI-augmented future is rooted in the true philosophy of the 10x engineer. A 10x developer is not someone who writes ten times as many lines of code, nor are they someone who burns ten times as many compute tokens. A true 10x engineer is someone who uses extreme leverage to solve a hard problem with one-tenth of the effort. AI should be a high-precision scalpel that cuts through complexity, not a bulldozer that churns out digital garbage just to hit a weekly quota. The value of an AI agent lies in the cognitive load it removes from the human operator, not the volume of text it generates. How to Actually Lead an AI Transformation If you are an engineering leader or a C-level executive trying to integrate AI agents into your workforce, Amazon's misstep provides a perfect roadmap of what not to do. Here is how you actually lead a successful AI transformation: Stop measuring token consumption: Tokens are a cost center, not a productivity metric. Rewarding engineers for burning tokens is like rewarding a logistics company for burning the most gasoline. Measure tangible outcomes: Are your deployment cycles getting faster? Is your bug rate dropping? Are your engineers spending less time on operational toil and more time on core product features? These are the only metrics that matter. Prioritize security and ownership: Do not give an AI agent sweeping access to your internal communications and deployment pipelines without a rock-solid, localized security posture. On-premise solutions like OpenClaw exist precisely to give you the power of AI without the terrifying security trade-offs of cloud-tethered, overly-permissive internal tools. Treat AI as a tool, not a mandate: Mandating that 80% of your staff must use AI every week guarantees that a significant portion of that usage will be forced and useless. Let the utility of the tool drive organic adoption. The era of the autonomous AI agent is here, and it is going to fundamentally change how software is built and businesses are run. But if we allow the transition to be governed by gamified dashboards and vanity metrics, we will miss the revolution entirely. It is time to stop tokenmaxxing and start building. Sources Financial Times — Amazon staff use AI tool for unnecessary tasks to inflate usage scores (May 12, 2026) ## Gas City: inside the software factory with 100 coding agents Source: https://theautomationgroup.nl/en/blog/gas-city-software-factory-100-agents-en Gepubliceerd: 2026-05-19 A hundred coding agents in parallel, fifty PRs a day, a billion tokens a day. What Gas City shows about multi-agent engineering — and the three ideas worth internalising regardless of which toolkit eventually wins. A hundred coding agents in parallel, fifty pull requests a day, a billion tokens a day. That's not a thought experiment — it's running right now on a single server in Atlanta. What Gas City shows about multi-agent engineering is more interesting than the toolkit itself. From Gas Town to Gas City Earlier this year Steve Yegge — a well-known developer-tools veteran — published a Medium post about Gas Town, an open source orchestration layer that lets 20 to 30 AI coding agents work on the same codebase at the same time. The post went viral. Last week its successor Gas City was announced, rebuilt as a proper toolkit by Chris Sells (ex-Google, previously grew Flutter to 3M developers) and Julian Knutsen (former technical lead at Block). Knutsen runs Gas City in production on a single server in Atlanta with about a hundred agents, together merging roughly fifty pull requests per day — the output of a small team — burning roughly a billion tokens per day. That's about one fifth of the entire English-language Wikipedia corpus. Per day. Mike Taylor's call (Every's head of tech consulting) after a workshop in New York: 🟨 — "Learn from the ideas. Skip the toolkit for now." What we care about are those ideas, because they map directly to the architecture questions we hit with clients the moment agents start really running in parallel. Three ideas worth internalising 1. Dark factory vs. light factory Split your process into two zones. Light factory = the steps where humans and agents are at the table together: planning, design, final review. Everything visible, everything steerable. Dark factory = the steps where the agent works on its own in the background, with nobody watching. Bug triage, refactor passes, test generation, formatting, dependency bumps. The trick: you start with almost everything in the light and shift more of it into the dark as trust in the agents grows. Same mindset as the move from manual to automated tests, but for agent actions. For our clients that translates to: make it explicit up front which actions don't need a human in the loop and which do — and revisit that list every sprint. 2. One pet, many cattle (the "mayor" and "polecats") This is the strongest idea in Gas City. Instead of managing a hundred agents individually, you talk to one persistent supervisor agent (Gas City calls it the mayor) that understands your intent and holds context. The mayor then delegates to anonymous, disposable workers (the polecats) that do one job and shut down. Why does that work? Because the workers carry no history and don't pollute context. And because you as a human never have to track a hundred things at once — you have one conversation with the mayor, not a hundred parallel chats. The same pattern shows up in Claude Code's sub-agents, in Cursor's background agents and in OpenAI's recently released Symphony. It's slowly becoming the default way to structure multi-agent systems. 3. Multiple models on every code review Send the same diff to Claude, Codex and Kimi — at the same time. Three different models catch different bugs than one model run three times. For us that's an immediately usable pattern: a review step that runs a PR through two or three different models costs very little compared to the developer time you get back. We're already building this into a few n8n flows and into OpenClaw's PR-review chain. Where Gas City itself falls short The toolkit is still rough. Mike Taylor flagged a few concrete pain points: No agent memory across tasks. Every task spins up a fresh session that doesn't know what earlier agents did. Result: agents re-read context that a sibling agent just produced. Wasted cycles, and you miss connections a single session would have caught. It costs what it costs. A six-step job is roughly six times the cost of one Claude session. At a billion tokens per day you're not talking coffee money. Setup is heavy. A room full of experienced engineers took a full day to get it running, even with Sells and Knutsen on the call. Beads (the task tracker) is agent-first, not human-first. It runs as a CLI, not a visual dashboard. So teams in production pair it with Jira or Linear — tasks in two places, double work. It overestimates how much hand-holding modern models still need. Many of the review loops and mid-task check-ins Gas City builds in to prevent drift are unnecessary with Claude 4.5 or GPT-5.2. The jargon works against it. Beads, polecats, refineries, mayor — fun thematically, but every new teammate starts with a dictionary. When is this relevant for you? Our take matches Taylor's: if you're already running more than 10 Claude Code sessions in parallel and willing to read source code, Gas City is worth a look. For everyone below that bar: take the ideas, skip the toolkit. For most of our clients, OpenAI's Symphony or a thin custom orchestration layer on top of Linear/Jira is more realistic. Symphony is essentially a written ruleset that turns your existing board into the dashboard the agents work from. That maps onto how engineers already work and doesn't require the behaviour change Gas City does. What this says about the direction of engineering Three patterns we hold onto, regardless of which toolkit eventually wins: One conversation, many executors. The mayor/polecats model is the way to work with more than five agents in parallel without losing control. Anyone building an agent architecture today that treats all agents as peers will redo it in a year. Multi-model review is free quality. The delta between one model and three different models on the same diff is bigger than the delta between Sonnet 4.5 and Opus 4.5. Low-hanging fruit we're already patching into client PR flows. The dark factory is coming. A growing share of software engineering happens without a human in the loop, and the companies that make explicit early on which work belongs in the dark capture the biggest throughput wins. For clients we coach on agentic engineering, "what moves into the dark" is a standing question at every sprint review. Gas City isn't the endgame. But as a snapshot of what a well thought-through multi-agent setup actually looks like, it's one of the most honest publicly available right now. A hundred agents on one server isn't marketing — it's somebody trying it, writing it up, and sharing the pain. That's more than you can say of most vendor demos. ## Tokenmaxxing: why Salesforce is spending $300M on Anthropic (and your budget is next) Source: https://theautomationgroup.nl/en/blog/tokenmaxxing-salesforce-anthropic-300-million Gepubliceerd: 2026-05-19 Salesforce $300M on Anthropic, Uber out of annual AI budget by April, a 4-person startup burning $125k per month. Why token costs are exploding and how to set up your AI architecture so your CFO doesn't panic. Salesforce is on track to spend roughly $300 million on Anthropic tokens this year. Uber blew through its annual AI budget by April. A four-person Silicon Valley startup is paying Anthropic $125k per month. The token budget is the new data-centre budget — and almost everyone is underestimating it. Salesforce: $300 million, and that's just the start On the All-In podcast last week, Marc Benioff said Salesforce is on track to spend roughly $300 million on Anthropic tokens this year. For context: that's about 4.5% of the $6.7 billion Salesforce spent on cost of revenues last year — the pot every third-party tech supplier is paid from. One AI vendor is now taking a serious bite. The vast majority of that flows to coding agents. "These coding agents are awesome," Benioff said. "Everything's going to be cheaper to make. It's more efficient. I can do things that I just could not do before." The ROI justifies the spend — for now. But in the same breath he hinted he wants to wean Salesforce off that exclusive Anthropic dependency: "The vast majority of those tokens don't need to go to Anthropic. There needs to be some intermediary layer that's saying, oh, that one has to go to Anthropic, but these ones can be handled by smaller models." Benioff speculated that "a hot new company" would soon emerge to build it. It already exists: OpenRouter recently raised $120 million from an Alphabet fund at a $1.3 billion valuation. We wrote earlier about Cortecs.ai as a European, GDPR-native alternative in that same router category. Uber: annual budget gone by April Salesforce isn't alone. Uber blew through its annual AI budget in April 2026. The internal post-mortem that leaked wasn't "we under-budgeted", it was "we didn't understand what an agent costs once it loops more than twice per ticket". A loop with three tool calls and a retry strategy can cost ten to fifteen times more in production than the same flow as a single-shot prompt. Helloprint, Swan and the $125k startup The numbers scale with the company: Helloprint does €80M in revenue and recently disclosed €25k in annual AI costs — modest, but coupled to a headcount reduction from ~300 to ~120 FTE. Here the tokens are literally a substitute for people. Swan AI, an AI fintech, reportedly spends $113k per month at Anthropic. That's $1.3M per year, with one vendor, in one company. A four-person Silicon Valley startup is burning $125k per month at Anthropic. Per person, that's $375k in tokens per year. More than their salary. Jensen Huang recently said matter-of-factly that his most productive engineers cost "$250k per year in AI tools". Solberg's CEO went further, saying his team is burning $4M per month in tokens. Recent figures put Anthropic on a run rate approaching $30 billion. That money is coming from somewhere. It's coming from these companies. What is actually happening here Three things are running in parallel: 1. The budgeting model is broken. AI budgets are still planned like SaaS budgets — a fixed amount per seat per month. But agent tokens scale with workload, not seats. One engineer with a tight Claude Code loop can burn more tokens in a week than a whole team burns in a month. 2. ROI masks the inefficiency. Benioff is right: these agents are awesome and they make work cheaper. That's exactly why nobody is challenging the token spend hard. As long as every €1 of tokens saves €3 of human labour, it feels like a good deal. But that's not a reason to route everything to the most expensive model. 3. Routing is becoming its own discipline. Not every prompt belongs on Sonnet 4.5. A classification step is fine on Haiku or a local Qwen. A drafting agent for boring emails can run on a cheaper Gemini model. The "intermediary layer" Benioff described isn't a future vision — we build it for clients today in n8n or OpenClaw, with routing rules driven by task, sensitivity and cost ceiling. The Ramp AI Index in context The Ramp AI Index recently showed that 50.4% of U.S. companies now hold a paid AI subscription, with spend rising sharply every quarter. What the index doesn't show is how much of that is agent tokens versus chat seats. The token portion is almost certainly growing faster than any other slice — because agents, by definition, consume more tokens than a human who occasionally opens a chat window. How we deal with this in practice A few things we build in by default the moment an agent goes into production: Per-tool and per-run cost tracking in the orchestration layer (n8n or a Python pipeline). Not just $-totals at month end, but per tool call, per agent step. That's how you discover that one retry storm caused 80% of your weekly bill. Model selection as config, not as hardcode. A classification step, an extraction step and a copy-edit step are three different cost categories and should be able to call three different models. Switching between GPT-5-mini, Claude Haiku, and a local Qwen via Cortecs or OpenRouter should not require a refactor. A hard cost ceiling per agent per day. No circuit breaker = open tap. For long-running loops we routinely add a ceiling that stops the agent or downgrades it to a cheaper model once a threshold is hit. On-prem for whatever is repetitive and sensitive. For most clients 70-80% of the tokens go into dull, repetitive work that runs just fine on a local Llama or Qwen via OpenClaw. Not for the wow work — for the bulk underneath it. Finally The irony of Benioff's quote — "I think that's just the moment of time we're in right now" — is that he's right, but only once a routing layer sits in between. Tokens don't get cheaper because Anthropic makes them cheaper. They get cheaper because you learn to send the right prompt to the right model. CFOs haven't put a red pen to the AI budget yet. That's a matter of time. Whoever sets up their architecture for model flexibility now — instead of blindly funnelling everything to one vendor — is the one who'll be able to take the corner without panicking. ## Employees as training data: Microsoft, Meta, xAI Source: https://theautomationgroup.nl/en/blog/employees-as-training-data Gepubliceerd: 2026-05-19 Microsoft has 100,000 engineers. Meta tracks mouse and keyboard. xAI offers $420 for your tax return. The next batch of AI training data comes from in-house staff — and it has consequences for how you set up your own AI stack. Microsoft has a weapon Anthropic and Cursor don't: roughly 100,000 in-house developers. Meta is tracking employee mouse movements. xAI is offering $420 for your tax return. The AI race has entered a new phase — and your colleagues are the training data. Who pays for the next generation of models? The short answer: employees do. Not in cash, but in data. The big AI labs have already combed through the public internet, harvested most of YouTube, GitHub and Reddit, and are hitting the wall of copyright disputes and source exhaustion. The next layer — high quality, unseen by other models — comes from one place: the people working for the company every day. What stands out is how differently the three biggest players are doing this, and how unapologetic it has become. Microsoft: 100,000 engineers as an RLHF pool Microsoft is trailing Anthropic and Cursor in coding AI. Internally, more and more Microsoft engineers are reaching for Claude Code instead of GitHub Copilot. But Microsoft has one thing its competitors don't: an army of roughly 100,000 software engineers on payroll. Recent reporting indicates Microsoft is collecting data from internal VSCode installations, from the source code of Xbox-owned game studios, and — more interestingly — from how its own engineers behave inside GitHub Copilot. Which suggestions do they accept? Which do they ignore? Which do they rewrite before committing? That last bit isn't raw training data, it's something far more valuable: preference data. The kind of signal modern reinforcement learning pipelines run on. That's why Microsoft is actively pushing its own people back toward Copilot rather than Claude Code — not just for narrative reasons, but because every accepted line is a data point OpenAI and Anthropic don't have. Dogfooding itself isn't new. Google and OpenAI do it too. What's new is that dogfooding has now become the primary data strategy rather than a QA step. Meta: mouse, keyboard, dropdown — all of it Meta goes a few steps further. The company is rolling out a tool called Model Capability Initiative (MCI) that captures mouse movements, clicks and keystrokes on U.S. employee work computers. The goal: training data for agents that learn "computer use" — think of an agent navigating a dropdown, clicking a button, filling out a form. Mark Zuckerberg told staff this would be "especially valuable" because Meta employees are "very smart." Whether that compliment made the surveillance feel better is unclear. What Platformer does report: employees are pushing back by consistently ignoring the "accept" button in the permissions popup, and some have found ways to disable the software via system settings entirely. On top of that, the software is apparently also just buggy. "MCI makes everything super slow," one employee wrote; keyboard and mouse input becoming laggy. A Meta spokesperson framed it as a necessity: agents that help people complete everyday tasks need real examples of how people actually do those tasks. xAI: $420 for your tax return (not paid yet) The most awkward variant comes from xAI. According to Bloomberg, the company offered employees $420 apiece to "donate" their U.S. tax returns — as well as those of friends and family members — as training material for Grok's financial capabilities. Two months later: the money hasn't been paid to the staff who contributed. The $420 price tag is a meme wink that only works if the cash actually arrives. For anyone reading this from a privacy angle: tax returns contain income, dependents, gifts, charitable donations, medical expenses, mortgage structures. It's hard to think of a more sensitive dataset. Why employees, not customers? The simple answer: employees can't really say no. Asking customers for training data takes work. It takes an opt-in flow, a legal review, a trust conversation about what's in and what's out. And most customers say no — especially enterprise customers who specifically have a no-training clause in their contract. (Something Lovable Cloud, Azure OpenAI and the Anthropic Enterprise tier each have their own version of.) Employees, by contrast, sign an employment agreement. The power is asymmetric. A popup with "accept" feels to an employee like a soft mandate rather than a real choice. And the scale is huge: 100,000 Microsoft engineers generate more high-quality coding data in a week than a public GitHub scrape does in a month. The quiet shift: raw data → preference data The most interesting development isn't the scale, it's the type of data. The large models have been trained on raw internet text to the point of diminishing returns. The win now lies in signal: which suggestion was accepted, which was rewritten, which was rejected. For coding AI that's gold. An engineer who edits a Copilot suggestion before committing provides far richer signal than a random GitHub file. The diff between the generated version and the committed version is the feedback — free RLHF, no human labelers required. The same holds for Meta's computer-use agents: clicking buttons in synthetic data looks different from a real user who hesitates, scrolls back, half-opens a dropdown and closes it again. That noise is the data. What this means for your own company Three things, in order of importance: Re-read your AI vendor contract. Many SaaS tools hide no-training defaults in the Enterprise tier and default to "do train" on Pro/Team plans. Specifically for coding agents: check whether Cursor, Copilot and Claude Code in your setup send your code back to the provider for training. For most of our clients we answer this question during onboarding — the difference between "data stays on-prem" and "data is anonymously aggregated for model improvement" is not small. Make policy explicit, not implicit. If you're building your own internal tools — a chatbot, an agent, a document extractor — decide upfront whether you'll use logs for fine-tuning. Write it down. Communicate it to your team. An implicit "of course we don't use it" doesn't hold up the moment the product manager behind the tool becomes more ambitious. On-prem for what's actually sensitive. For clients where data must not leave the company — insurers, real estate, legal — we increasingly build with OpenClaw as the on-prem orchestration layer. Local Llama or Qwen models, own Postgres, own audit log. Not because we're paranoid, but because the existing "trust us" story carries slightly less weight when Meta no longer trusts its own people. Finally The AI industry got to ride free internet data for a few years. That river has dried up. What's left is expensive, slow, or morally grey. Employees are the cheapest, fastest, greyest of the three. For anyone building agents themselves the lesson isn't "stop dogfooding" — it's the best way to learn quickly what works. The lesson is: be explicit about what you collect, what you use it for, and give people a real off switch. Otherwise you end up building, sooner or later, an MCI popup no one clicks. ## Hostinger VPS: how to run OpenClaw, Hermes AI and Paperclip AI in the cloud without installing anything locally Source: https://theautomationgroup.nl/en/blog/hostinger-vps-openclaw-hermes-paperclip-zero-person-company-en Gepubliceerd: 2026-05-19 Closing your laptop should not kill your AI Agents. On a Hostinger KVM2 VPS at around €9 per month you can run OpenClaw, Hermes AI and Paperclip AI 24/7 in an EU data centre — no Mac Mini, no networking pain, no hardware to babysit. Building your own automation stack on a local Mac Mini or an old laptop has a certain romance to it. You have physical control, you literally see the lights flashing, and there are no monthly cloud costs. But reality hits most solopreneurs hard as soon as you shut the lid of that laptop and head to a meeting: your AI Agents die. Webhooks no longer arrive, incoming emails pile up, and open quotes are not followed up on. If you want to operate reliably, you need constant uptime and a fixed, publicly accessible address. The traditional solution was complicated: opening network ports in your router, wrestling with dynamic IP addresses, and vague tunnel services. Today, at The Automation Group (TAG), we solve this differently. We simply run our stack — OpenClaw, Hermes AI, and Paperclip AI — in the cloud. Not on exorbitant enterprise infrastructure, but on a highly affordable Hostinger KVM VPS. Within ten minutes, you have a robust environment running, your laptop can be turned off, and your AI team continues to work undisturbed. Why Hostinger and not AWS or Hetzner When you take the step to the cloud, you quickly stumble across the familiar names. Amazon Web Services (AWS) is the market leader, but for a "zero person company" founder or SME owner, it is unnecessarily complex. Before you can run a simple container, you become entangled in IAM roles, VPC configurations, and unpredictable invoices. On the other hand, you have providers like Hetzner. Technically rock-solid and cheap, but it requires in-depth Linux knowledge; the "1-click experience" is missing. Hostinger currently offers exactly the balance we are looking for with our tools. You get the performance of KVM virtualisation combined with lightning-fast NVMe storage. The interface offers what we internally call a "consumer-grade Developer Experience": it is built for people who want quick results. They offer ready-made 1-click Docker and AI templates based on full Ubuntu or Debian images, including root access and SSH. Should you still get stuck in the command line, their built-in AI assistant named Kodee will help you with server management and terminal commands. In addition, the infrastructure is available worldwide. You can choose from data centres in the United States, the United Kingdom, Brazil, India, and Singapore, but for European users, the choice is even simpler: Hostinger has data centres in the Netherlands and Lithuania. By choosing an EU region, you immediately take a major step towards compliance. Choosing the right plan for your stack Not every setup needs the same amount of computing power. Hostinger offers various KVM plans. Because you have complete freedom on the server, you simply scale along with your needs. KVM 1: 1 vCPU, 4GB RAM, 50GB NVMe, and 4TB bandwidth. Promotional price ±€6.49 per month (renewal ±€11.99). This is perfect if you only want to run one isolated tool. For example, just Paperclip AI for your back office, or only Hermes AI for email handling. KVM 2 (Most popular): 2 vCPU, 8GB RAM, 100GB NVMe, and 8TB bandwidth. Promotional price ±€8.99 per month (renewal ±€14.99). This is the "sweet spot" and our standard recommendation. The entire TAG stack (OpenClaw as the brain, linked to Hermes and Paperclip) runs smoothly on this without memory bottlenecks. KVM 4: 4 vCPU, 16GB RAM, 200GB NVMe for ±€12.99 per month at the time of the promo. Choose this plan if you run many parallel AI Agents simultaneously, or when you locally generate heavy vector embeddings that eat up a lot of RAM. For the absolute heavyweights, there is also the KVM 8 (8 vCPU, 32GB RAM, 400GB NVMe for a ±€25.99 per month promo), but the average solopreneur will find the capacity of the KVM 2 to be more than sufficient. Setup at a glance Setting up this infrastructure no longer requires hours of work. The procedure is straightforward. Order your chosen VPS and select a data centre in the EU. During the installation wizard, choose Ubuntu 24.04 combined with the Docker template as your operating system. Hostinger configures the server, installs the necessary runtime, and provides you with a fresh IP address. Next, you connect via SSH. Because Docker is already installed, the task is limited to fetching your configuration and starting the containers. In practice, that looks something like this: # Update de server pakketten voor de zekerheid apt update && apt upgrade -y # Clone de repository met jouw TAG-stack configuratie git clone tag-stack cd tag-stack # Vul je omgevingsvariabelen in (API keys, etc.) nano .env # Start de volledige stack op de achtergrond docker compose up -d Within minutes, Docker downloads the required images and brings your system to life. OpenClaw in the cloud: from Mac Mini to VPS OpenClaw is the beating heart of the setup. This open-source self-hosted AI Agent framework — formerly known as Clawdbot and now boasting over 100,000 GitHub stars — excels in its multi-agent architecture, built-in memory, and Model Context Protocol (MCP) integrations. When you move OpenClaw away from a local Mac Mini and run it on a VPS, the way you talk to the outside world changes. You are no longer bound to a local network. Through Hostinger's DNS settings, you can easily link a public subdomain (for example, agents.yourcompany.com) to your VPS IP. By including a reverse proxy in your Docker stack — such as Caddy or Nginx combined with Let's Encrypt — you instantly enforce a secure TLS/HTTPS connection. This makes linking external channels like Telegram, WhatsApp, or Slack trivial. Where you previously had to force external webhooks to your laptop via ngrok, these services now simply send their data to your secure VPS. Crucially, your data sovereignty is maintained: because you manage the Hostinger VPS yourself, the vector database containing the 'memory' of your AI Agents is written locally to your shielded slice of NVMe storage. Hermes AI always accessible Our communication agent, Hermes AI, is designed to act as a tireless gatekeeper. Hermes handles incoming and outgoing messaging across channels like email, WhatsApp, and voice. Such an agent simply does not belong on hardware that goes into sleep mode. Email is a good example of this. Hermes uses IMAP idle protocols to respond in real-time to incoming messages. If you force the agent to run on a laptop, Hermes will have to restore the session every time your network connection drops, causing you to miss messages or respond more slowly. On the VPS, Hermes runs continuously. Because the agent speaks on your behalf, it is crucial that secrets management is taken seriously. Never hardcode API keys, SMTP passwords, or WhatsApp tokens in your configuration files, but strictly load them as environment variables (via the .env file) on your secure server. Paperclip AI as your back office that never sleeps Paperclip AI forms the foundation of the "zero person company". Where OpenClaw thinks and Hermes communicates, Paperclip automates the administrative back office. Think of generating quotes, creating and booking invoices, sending follow-ups for unpaid bills, and processing standard contracts. When you run a business on your own, the operational side typically comes to a standstill while you sleep. By running Paperclip AI on an always-on VPS, that dynamic changes fundamentally. The tool uses cron-like scheduling to start processes autonomously. You can configure a *nightly invoice run* where the agent checks time tracking at 03:00, generates invoices, and immediately prepares them via Hermes for sending in the early morning. Lead scoring and follow-up sequences also run seamlessly. To your clients and prospects, it appears as though you employ a highly accurate and dedicated back-office team. When you should still run it locally or on-prem Is the cloud truly superior in every situation? No, we must remain pragmatic. There are specific scenarios where a physical Mac Mini on-premise, or a dedicated bare-metal server in a locked room, is still the smartest choice. This applies specifically when you are working with extremely sensitive data. Companies in healthcare, the heavily compliance-reliant legal sector, or defence-related industries may operate under regulations that require data not to physically leave the company walls. For these types of niche applications, local hosting is absolutely superior. However, for the average solopreneur or SME owner, the KVM VPS at Hostinger is more than sufficient. As long as you choose an EU data centre and establish the standardly available Data Processing Agreement (DPA) with Hostinger, your setup is defensible and solidly arranged from a GDPR perspective. The zero person company is no longer a meme The idea of starting and scaling a business without ever having to hire staff was an internet meme for a long time. Today, it is an achievable reality thanks to powerful, modular automation. When you deploy OpenClaw to think and reason, let Hermes AI communicate across all your channels, and have Paperclip AI flawlessly update the back office, you effectively build a team of three highly skilled employees. By hosting this collective of AI Agents for just under ten euros a month on a KVM 2 VPS at Hostinger, you create a machine that never sleeps, is never ill, and can be managed by you from any device in the world. No lugging hardware around, no dependence on your laptop battery. Do you want to roll out this infrastructure yourself but have doubts about the finer details? Take a look at the official TAG documentation for help with the initial setup, log into your bare server, and let your new team do the heavy lifting. ## Cortecs.ai: Europe's LLM router as a GDPR-native alternative to OpenRouter Source: https://theautomationgroup.nl/en/blog/cortecs-ai-european-llm-router-alternative-openrouter Gepubliceerd: 2026-05-19 Cortecs.ai positions itself as Europe's LLM router: 150+ model endpoints, EU-sovereign hosting, pass-through pricing and GDPR compliance as primary Data Processor. What does this mean for Dutch engineering teams currently on OpenRouter? As an AI engineer in Europe, sooner or later, you hit the same wall. You build a working prototype, the performance of the selected language model exceeds expectations, and then the project is put on hold by the compliance department. Since the final roll-out of the AI Act and the tightened scrutiny around the GDPR, clients and internal security teams increasingly require watertight guarantees regarding data residency. Data Protection Impact Assessments (DPIAs) ruthlessly expose where trade secrets or personal data leave European territory or threaten to end up as training data. Until recently, Dutch engineering teams sought refuge in complex, custom-built infrastructure across public cloud providers or accepted massive lock-in with a single vendor. Shared API gateways and routers, such as the popular OpenRouter, offered a solution for the fragmented market of Foundation Models, but were often dismissed for enterprise applications due to US jurisdiction and a lack of compliance structures for the underlying providers. Cortecs.ai has recently entered the market to fill this specific vacuum. They position themselves as Europe's LLM Router with a strong emphasis on control, GDPR conformity, and European hosting. Exactly what Cortecs.ai is The Austrian company Cortecs.ai functions as a gateway to over 150 model endpoints, without you, as an engineer, having to manage separate contracts, keys, and architectural integrations for each model provider. Where it gets technically interesting is their routing architecture. All inference traffic runs exclusively via providers within an EU sovereign cloud. Specifically, this means that the computing power is delivered by servers in Spain, Germany, France, Finland, and Poland. Behind the scenes, Cortecs uses a method they call filter-and-rank routing. With every request, the router first checks your preset requirements. Models and providers that do not meet these compliance or technical demands are filtered out. The remaining route options are then dynamically ranked based on price and the performance available at that exact moment. According to their own figures, this mechanism results in a 99.99% uptime guarantee through seamless switching between back-up providers, and an average cost reduction of 32% per API call. The platform is fundamentally built so as not to get in the way of your existing stack. It provides an API that functions as a direct drop-in replacement for OpenAI. Furthermore, the vast majority of multimodal functionalities are retained: alongside standard text generation (chat), this connection also supports image input (vision), embeddings, and audio transcription. Cortecs vs OpenRouter: the GDPR difference For individual developers or projects without strict privacy requirements, an established party like OpenRouter is often the standard way to go, as it unlocks an enormous catalogue of models including Bring Your Own Key (BYOK) functionality. As soon as you operate in a professional Dutch engineering context, however, you hit a legal wall. OpenRouter is headquartered in the United States and offers no native EU-sovereign route. Even more problematic for compliance officers: with public routers, you are often personally responsible for compliance regarding all individual downstream providers (the parties that actually supply the computing power). This is where Cortecs fundamentally takes a different path. Legally, the service acts as the primary Data Processor. This means that Cortecs handles the contractual responsibility and compliance agreements towards all underlying cloud providers. You sign a single Data Processing Agreement (DPA), which applies to the entire chain. This significantly reduces administrative overhead during vendor onboarding. "As an engineer, you don't have to worry about which server in which European country the model is running on. The guarantee is that the payload does not leave Europe and is not stored anywhere." To back up these claims under the AI Act and GDPR, Cortecs implements strict data rules. Payloads are processed exclusively in temporary memory and are intuitively deleted immediately after the request is completed. The platform does not train on your data, and—crucially—underlying providers are contractually excluded from doing so as well. Should your organisation's policies be even stricter, Cortecs offers the option to manually exclude specific providers from the routing. How it works in code The architecture is aimed at minimising migration time. Because the endpoint is fully OpenAI-compatible, you hardly need to modify existing codebases that use the official SDKs. By exclusively overwriting the Base URL and the API key, you instantly route all traffic via the European network. A standard implementation using the Python SDK looks as follows: from openai import OpenAI client = OpenAI( base_url="https://api.cortecs.ai/v1/", api_key="jouw_cortecs_api_key" ) # Je kunt nu de reguliere OpenAI methodes gebruiken response = client.chat.completions.create( model="meta-llama/llama-3.1-70b-instruct", messages=[ {"role": "user", "content": "Analyseer deze dataset..."} ] ) Beyond the direct API connection, this standard drop-in integrates effortlessly into the broader engineering ecosystem. Existing integrations with orchestration and observability tools like LangChain, Langfuse, and LibreChat are supported out-of-the-box. The platform also forms a transparent layer for coding assistants and IDE plugins such as Cline, Kilo Code, Open WebUI, and OpenCode. Pricing and lock-in Inherent to gateways is the fear of opaque hidden costs and vendor lock-in. Most commercial API gateways charge a fee per transmitted token (markup) or require monthly enterprise subscriptions that eat heavily into the budget upfront. Cortecs explicitly positions itself with a pure pass-through cost structure. There is no markup on the actual tokens; you pay the raw cost price for the inference via the selected language model. The revenue model rests entirely on a transparent flat fee of 5% applied when you add credits to your account (top-up). No subscription fees (no subscriptions) No markup on token prices (pure pass-through) Enterprise control without artificial rate limits For applications designed to be infrastructure-independent, this reduces financial friction and offers a scalable structure that moves with the size of the workload, without the unpredictability of dynamic token markups. When to use it, and when not to At The Automation Group (TAG), we always evaluate tools based on their pragmatic value. Cortecs.ai fills a substantial gap in the European AI infrastructure, but it is crucial to identify for which use cases it is the right tool. This architecture is ideal for established parties in regulated sectors. If you are building for healthcare, finance, the legal domain, or (semi-)government, the "GDPR-native as Data Processor" approach ticks many compliance boxes with a single stroke of the pen. The fact that parties like Raiffeisen-Landesbank Steiermark, Verbund, the Austrian Ministry of the Interior, Austrian Wirtschaftsservice (AWS), FFG, WKO, and even the ESA (European Space Agency) run on the platform as clients provides the necessary social proof to chief information security officers. When is Cortecs less relevant? Are you a team that already has an intensive partnership and tightly aligned infrastructure directly with Azure OpenAI or Google Vertex AI in European hosting regions with comprehensive DPAs? Then the added value of this intermediary layer is limited to a small price advantage. Furthermore, we always advise a rigid testing phase if you are working with complex agentic workflows, such as Model Context Protocol (MCP) integrations. With such advanced architecture, you must specifically test beforehand whether functionalities like seamless streaming and complex tool calling structures are continuously preserved through the routing for your desired models. What this means for Dutch engineering teams For the Dutch market, the arrival of specialised European LLM routers signifies an important shift in how we design production-ready AI applications. Platforms like Cortecs lower the barrier to deploying a diversity of Foundation Models, open weights models, and in the future even emerging specific reasoning engines, quickly, efficiently, and above all compliantly for enterprise use. Nevertheless, it is important to realise that infrastructure is not the sole determining factor. From a TAG perspective, we believe that robust failovers, well-configured evaluations (evals), and in-depth observability on the output remain the true differentiators in production-oriented AI. A router merely delegates the pipeline and the compliance surrounding it. Moreover, a router forms the boundary layer of the "public" cloud solution. Should the nature of your project or customer data be so critical that even processing in temporary memory on a European server is not permitted, you vanish into the realm of true on-premise deployments — where running solutions like OpenClaw locally within your own physical or private cloud remains the only genuinely compliant option. For the broad mid-segment of enterprise applications, where agility and cost management carry just as much weight as GDPR compliance, Cortecs.ai currently offers one of the most pragmatic solutions on the European market. ## The Mythos of AI Cybersecurity: Why Your Security Team Needs to Become an F1 Pit Crew Source: https://theautomationgroup.nl/en/blog/the-mythos-of-ai-cybersecurity-f1-pit-crew Gepubliceerd: 2026-05-19 Anthropic's Project Glasswing and the 'Mythos' capability are permanently changing the economics of zero-days. For CTOs and engineering managers, this means the focus must shift from detection to relentless response speed. A blueprint for the AI-driven SDLC. The Race Against the Machine In Formula 1, a perfect pit stop takes less than two seconds. In that fraction of a second, four tires are changed, aerodynamic adjustments are made, and the car is safely sent back onto the track. This speed is not the result of rushing, but of relentless preparation, perfect telemetry, and flawless choreography. There is no room for improvisation when the car pulls into the pit box. For enterprise software development and cybersecurity, we are approaching a similar tipping point. The time an organization has between the discovery of a vulnerability and its active exploitation (the patching window), is shrinking rapidly. Driven by the rise of AI models capable of autonomously hunting for vulnerabilities, the playing field is fundamentally changing. To survive in this new era, engineering and security teams must stop acting like traditional IT administrators, and start operating like an F1 pit crew. 1. Project Glasswing and the 'Mythos' Capability: The Shifting Economics of Zero-Days To understand why the urgency is so high, we must look at what is currently happening at the forefront of AI development. A crucial example of this is Project Glasswing, an initiative by Anthropic in collaboration with heavyweights like AWS, Apple, Cisco, CrowdStrike, Google, Microsoft, NVIDIA, and Palo Alto Networks [1]. The goal? Securing critical software infrastructure in the AI era. Under the umbrella of this project is an internal capability codenamed Mythos. Mythos is specifically designed for vulnerability discovery: finding zero-day vulnerabilities in complex codebases. Although exact release dates or exhaustive figures on current capabilities are not public (and we should steer clear of speculation), the impact of the preview phase is undeniable. Mythos proved capable of identifying previously unknown zero-days in major operating systems, browsers, and enterprise systems [2]. What this means for CTOs and security leads is not just a technological update, but a fundamental shift in the economics of vulnerability discovery. Historically, finding a critical zero-day cost months of manual, highly specialized research. It was expensive and scarce. AI models like those behind Mythos reduce these costs from months of human labor to seconds of compute. When discovering zero-days becomes scalable and cheap, the asymmetric advantage of the defender relying on security by obscurity or slow discovery cycles disappears [8]. 2. The Second Mythos Level: Detection is a Thing of the Past This brings us to a persistent myth (a second 'mythos') within the current cybersecurity industry: the belief that AI is primarily a tool for better detection. Many organizations invest heavily in AI to find anomalies in network traffic or parse log files. But if AI automates the discovery of vulnerabilities, and attackers use AI to automate their exploitation, then detection alone is no longer sufficient. Adversaries are now running autonomous tooling and launching parallel campaigns at a scale previously unthinkable [3]. In this scenario, an alert on a dashboard is not a warning, but a notification that you are already too late. "Mythos breaks every existing SOC workflow. When the volume of legitimate, critical alerts rises exponentially, autonomous processing is the only architecture that still scales." [4] The real difference in the AI era lies in response speed. A traditional Security Operations Center (SOC) that relies on human analysts to triage alerts drowns in the noise. Platforms are now claiming that AI-driven triage can reduce the cost per alert to pennies, with 95% of alerts processed in under two minutes and noise reduced by 99% [4]. Humans need to step out of the initial detection loop and move up to the orchestration and approval layer. 3. The F1 Pit Crew Analogy: Telemetry, Triage, and Choreography What does an organization optimized for extreme response speed look like? Here, Formula 1 offers a perfect, and often cited, blueprint [9, 11]. A successful pit stop revolves around two components: the Pit Wall and the Pit Crew [10]. The Pit Wall: Telemetry and AI Triage On the pit wall sit the strategists. They don't look at the car, but at screens full of real-time telemetry. In software development, this is your observability stack, enriched with AI. The pit wall predicts when the tires (or in our case, a specific open-source library) will fail. AI agents act as the race engineers here: they filter the terabytes of log data, correlate vulnerabilities with active threats, and prepare the strategy before the incident hits the codebase. The Pit Crew: The Patching Window When the decision is made to intervene, the pit crew takes over. There is no time for discussion about who takes which wheel. The roles are strictly defined, the movements choreographed. For an engineering team, this means the process of patching, testing, and deploying must be fully automated. A patching window of weeks is unacceptable; we are talking about hours or even minutes. Autonomous systems write the patch, AI agents run the regression tests, and the human engineer functions solely as the 'lollipop man' who holds up the board and approves the release (human-in-the-loop). 4. Concrete Consequences for Software Development Teams This need for extreme speed and automation has direct consequences for the way we build software. The traditional Secure Software Development Life Cycle (SSDLC) must evolve [5]. From Shift-Left to Shift-Everywhere: The adage was always to integrate security as early as possible ('left') into the process. But with AI agents continuously generating and modifying code, security is no longer a phase, but a continuous state. Security checks must happen everywhere: during coding, in the PR, during the build, and in production [8]. The Necessity of SBOM and Provenance: You cannot repair a car in two seconds if you don't know what parts are inside it. A real-time, cryptographically verifiable Software Bill of Materials (SBOM) is your inventory list. Without insight into the provenance (origin) of your code, you are blind to supply-chain attacks. AI Agents in the CI/CD Pipeline: AI is not only used to write code but also to review it. Currently, 82% of developers use AI coding tools, but only 28% fully trust the output [6]. And rightly so: in some scenarios, AI-generated code contains 40-50% exploitable vulnerabilities [7], and prompt injection is a real risk [6]. AI agents in the CI/CD pipeline must act as ruthless, automated auditors catching these errors before they merge. Secure-by-Default Scaffolding: Developers must work within frameworks that make it impossible to make common mistakes. If an AI coding assistant suggests an SQL injection, the underlying architecture (for example, through mandatory ORMs) must refuse to compile this code. 5. Monday Morning: Five Steps for the Starting Grid The theory is clear, but what can an engineering organization concretely do this coming Monday to initiate the transition to an F1 model? Here are five actionable steps: Implement Rock-Solid SBOM and Provenance Requirements: Make generating an SBOM a mandatory, failing step in your CI/CD pipeline. If an application cannot provide an up-to-date component list, it should not be allowed into production. Use standards like SLSA (Supply-chain Levels for Software Artifacts). Automate the Triage Layer (Build the Pit Wall): Evaluate your current SOC and alert infrastructure. If your team is still manually clicking away false positives, you are losing the race. Implement AI-driven triage tools that reduce the noise and only pass highly contextualized, critical incidents to human analysts. Deploy AI Agents for Autonomous Patching (in test environments): Start deploying AI agents (like Dependabot on steroids) that not only warn about outdated packages but autonomously create the PR, modify the code, and run unit tests. Leave the final merge decision with a senior engineer for now. Isolate and Monitor AI-Generated Code: Accept that developers will use AI assistants, but treat the output as untrusted input. Set up specific linting and SAST rules trained on the typical hallucinations and vulnerabilities introduced by LLMs. Practice the 'Drill' (Chaos Engineering): A pit crew trains thousands of times a year. Conduct tabletop exercises and red teaming sessions with compressed timelines. Simulate a zero-day in a critical library and measure the time (MTTR) until the patch is in production. Optimize the bottlenecks. The arrival of AI capabilities like Anthropic's Mythos means the era of slow, manual security is permanently over. The organizations that survive won't be the ones with the thickest walls, but the ones with the fastest pit crew. The race has already begun. Sources Anthropic - Project Glasswing D3 Security - "The Mythos Problem: 10,000 Zero-Days and the SOC That Can't Keep Up" Prophet Security - "What Claude Mythos Actually Means for Your Security Program" D3 Security - Autonomous Mythos Response / Morpheus AI Veracode (Apr 2025) - Securing the AI-Driven Development Environment Snyk / O'Reilly Report: AI coding tools adoption and trust Checkmarx: Vulnerabilities in AI-generated code CSET Georgetown (Aug 2025) - AI and the Software Vulnerability Lifecycle InformationWeek - "How DevOps Is Like A Formula 1 Pit Crew" CrowdStrike - "The F1 Pit Wall: A Better Metaphor for Teamwork" CDO Magazine - "Information Security Is Like an F1 Pit Crew"