Agentic AI Workflow Automation: Streamlining Enterprise Operations In The Netherlands
14 Aug 2026
by Guido van Beek, CTO & Co-founder
Editor, Nadiy, Senior Content Writer
14 Aug 2026
by Guido van Beek, CTO & Co-founder
Editor, Nadiy, Senior Content Writer
Agentic AI Workflow Automation: Streamlining Enterprise Operations In The Netherlands
Table of contents
Contact us
We will get back to you in the next 48 hours.
The #4 installment of Lizard Global's CTO Corner, written by Guido van Beek, this blog details how our company transitioned from passive AI implementation to active agentic workflow automation, initially testing the architecture on internal operations before scaling to enterprise clients in the Netherlands. By detailing real-world applications such as a comprehensive CRM audit, unified cross-platform financial dashboards, live call-center decision support in Rotterdam, and multi-agent B2B lead generation pipelines, the post outlines the technical design principles required for enterprise execution. It covers single-responsibility agent design, structured schema handoffs, Model Context Protocol (MCP) integrations, robust audit logging, and hard human-in-the-loop checkpoints. Crucially, it highlights how strict GDPR compliance and ISO 27001 data governance must be natively architected into agent systems to ensure enterprise-grade security and operational efficiency.
key takeaways
I wrote before about how AI became part of our business through compliance, not through an AI mandate. This is the piece that follows from that: what happened once we started letting agents take multi-step action across our own systems, not just answer questions from them.
There is a real difference between the two. An agent that answers a scoping question from documentation is informing a decision a person still makes. An agent that pulls data from one system, cross-references it against rules, and hands back a structured set of recommendations for a person to act on is doing something closer to work. That second category is what I mean by agentic workflow automation, and it is where we have learned the most, on our own operations first.
Where we actually started: our own delivery process
Before we touched a client-facing workflow, we changed how we run delivery internally, moving to a more structured, agent-driven way of building software ourselves. It was a genuine adjustment, not a switch we flipped. But it is what gave us the confidence, and the internal proof, to offer this to clients rather than pitch it from theory.
The clearest example of what that actually looks like in practice was not glamorous. It was our own CRM.
The Pipedrive audit: a real multi-step agentic workflow, on our own mess
We had let our Pipedrive pipeline drift for years: 423 open deals, 87 percent of value parked in a stage with no exit criteria, probabilities set by gut feel. Cleaning that up manually would have meant someone spending days cross-referencing deal age, activity logs, stage, and probability by hand, deal by deal.
Instead, an agent pulled the full export, applied a consistent set of rules across every deal, and produced a structured report: 360 of 423 deals flagged stale, 43 deals with probabilities inflated relative to their actual stage and activity, and 50 deals meeting a clear "dead" threshold, representing roughly €1.68 million in pipeline value that had no realistic chance of closing. It took a fraction of the time a manual audit would have, and it did not miss anything a manual pass would have caught.
The agent did the multi-step, cross-referencing work by utilizing business process automation. A person still decided what to do with each flagged deal. Nothing got marked Lost automatically.
That last point matters more than the speed. The moment an agent is taking multi-step action across your systems, the question is not just "does this save time," it is "who is accountable for what it changes." Keeping the recommendation and the decision in separate hands is not a limitation we are working around. It is the design.
The bigger picture: one operational view, not four disconnected tools
The Pipedrive audit was the first piece, not the whole picture. We connected Xero, Harvest, and ClickUp into the same view, so that financial data, time tracking, delivery status, and pipeline health stopped living in four separate tools that nobody cross-referenced by hand.
The clearest sign it changed something real: our MT meetings now start with it, not with someone reconstructing the state of the business from memory and four open tabs. Cash position, hours logged against active delivery, deal movement, and account health, in one view, before the conversation even starts. Decisions that used to wait for someone to pull the numbers together now happen in the room, because the numbers are already there.
It also surfaces things earlier that used to show up late: a project running over its logged hours before the invoice reflects it, a deal marked "closing soon" that has not actually moved in months, committed cash sitting against payables nobody had flagged yet.
None of these are dramatic individually. Caught consistently, weeks earlier than they would have surfaced otherwise, they add up to a business that runs on what is actually happening, not on what someone remembers happening.
Bringing it to clients
The reason this belongs in a blog post rather than an internal memo is that we are now building the same category of system for clients, not just for ourselves, expanding our work across our portfolio of client projects.
For a long-term client based in Rotterdam, we designed an agentic workflow built directly into their call centre. It hooks into their VoIP software, pulls the caller's record the moment the number is identified, and listens in on the conversation as it happens, keeping the relevant account and case history on screen for the whole call instead of leaving the agent to search for it mid-conversation.
It helps draft replies in real time, suggests the right SOP to follow based on the company's own templates and that caller's case history, and logs the entire interaction automatically once the call ends. Work that used to depend on one person's memory of the right template and a scramble through old tickets now sits in front of them before they have to ask for it, showcasing the impact of AI integration in software systems.
For another Rotterdam-based client, still mid-implementation, we built lead generation as a chain of agents rather than one tool. One agent pulls prospect data from multiple sources. A second enriches and verifies it. A third researches recent news on each lead, so outreach is grounded in something current rather than a generic template. A sequencer then suggests the outreach message, over InMail or email, reads the responses that come back, makes a judgment call on what kind of reply it is, and suggests the next message accordingly.
What used to be a person doing several separate lookups before writing one message is now a chain of agents doing the lookups, with a person still approving what actually goes out.
Both are live engagements, not case studies with a tidy before-and-after yet. I would rather describe them honestly, as work in progress, than attach numbers to them before we have real ones to report.
How these agents are actually put together
Everything above describes what these systems do. For whoever on your side has to sign off on how, it is worth being specific about the architecture, because "we added AI" and "we built an agentic workflow" are not the same claim.
One agent per job, not one agent doing everything.
The lead generation pipeline is four separate agents, not one large prompt trying to source, verify, research, and write outreach in a single pass. Sourcing, enrichment, news research, and message drafting each run as a distinct agent with a narrow, well-defined job and its own tool access.
A single agent asked to do all four tends to degrade at the seams, quietly skipping steps or blending them. A chain of narrow agents, each handing off a structured result to the next, is slower per step and considerably more reliable end to end, and it is far easier to debug when one link produces a bad result.
Structured handoffs, not prose passed between steps.
Each agent in the chain returns data against a defined schema, not a paragraph the next agent has to interpret. The enrichment agent does not receive "here's some stuff about this lead" from the sourcing agent, it receives a fixed set of fields it knows how to validate.
This is what makes a multi-agent pipeline different from stringing together a few chatbot prompts: every handoff is a contract, and a malformed one fails loudly instead of quietly corrupting the next step.
Integration through a standard protocol, not bespoke code per tool.
The call centre workflow needs to reach the VoIP system, the CRM, and the client's document store. We connect agents to these through MCP servers rather than writing a one-off integration for every system on every project using scalable API and microservices architecture.
It means the same connector pattern that reads a case history today can read a different CRM on the next client without a rebuild, and it is a large part of why we can stand these up in weeks rather than months.
A defined point where the agent stops and a person starts.
This is architectural, not a UI checkbox. In the call centre workflow, the agent surfaces context and drafts a reply; a person sends it. In the lead generation pipeline, the agent reads a response and classifies it, then proposes the next message; a person approves it before it goes out over InMail or email.
The pipeline is built so that any action with an external consequence, a message sent, a record changed, a deal marked Lost, requires a human step in between. Autonomy up to that point, a hard stop at it, aligned with modern principles of enterprise AI governance.
Every step logged, not just the outcome.
Each agent's input, the tools it called, and the output it produced are recorded individually, not just the final result. That is what makes a pipeline debuggable when something goes wrong three steps in, and it is the same discipline that makes this defensible to a client's compliance or security team asking what the system actually did and why.
Compliance is not a separate conversation from the agent's design
Every example in this piece touches personal data somewhere: a caller's voice and account history, a lead's name and inbox, an employee's activity log. None of that is optional to think about once. It has to be designed before the first agent runs, not reviewed after the fact, embedding security and ISO compliance from day one.
A few things that actually change once you take that seriously:
Access is scoped per agent, not per project.
Because each agent in a pipeline has one job, it only needs the data that job requires. The enrichment agent in the lead generation pipeline does not need access to the call centre's account records, and the call centre agent does not need access to the CRM's financial fields.
Narrow agents make this the natural outcome of the architecture, rather than a policy someone has to enforce separately on top of it.
Legal basis gets decided before the agent is built, not argued about after a complaint.
A call centre agent listening in on a live conversation is processing personal data in real time, which in the Netherlands means the caller needs to be informed, consistently, before the call starts. A lead generation agent enriching a prospect's contact details is relying on legitimate interest for B2B outreach, which has its own limits on what it can justify.
Deciding this after the pipeline is already live is how agencies end up retrofitting consent flows into a system that was never designed to support them.
The audit log from the architecture is also the compliance evidence.
The per-step logging described above, what data an agent touched, what tool it called, what it produced, is the same record a client's DPO or an auditor asks for when they want to know what happened to a specific piece of personal data. We do not maintain two systems, one for engineering and one for compliance.
It is one discipline serving both.
The human checkpoint is also the accountability boundary.
GDPR does not have a clean answer for "the agent decided this." A person approving the message that goes out, or the record that gets changed, is also the person who can be identified as having made that decision, which matters the moment anyone asks who is responsible for a specific action.
We have written separately about how ISO 27001 and GDPR shaped our service model. What is different with agentic systems specifically is that compliance is not a layer added around the system afterwards. It has to be a property of how the pipeline is built, agent by agent, from the start.
What "streamlining enterprise operations" actually means
It does not mean removing the person from the loop. In every example here, ours and our clients', a person still owns the decision the agent's output feeds into. What changes is how much groundwork a person has to do before they can make that decision well. That is the same argument I made about capacity in the last post, applied now to operations rather than documentation: the same team handling more, not a smaller team doing the same amount.
For a business in the Netherlands looking at where to start, my honest advice is the same as it was for compliance: start with the operational mess you already have, not the flashiest use case you can imagine. We started with our own CRM because it was the thing closest to us that was clearly broken. That is usually where the real leverage is.
Streamline Your Enterprise Operations
Transform operational chaos into structured, compliant, multi-agent workflows built specifically for your enterprise stack. Whether you need to connect your fragmented software ecosystem or automate high-volume business operations with human-in-the-loop accountability, our engineering team designs solutions tailored to Dutch compliance and European data governance standards.
Schedule an Architecture Discovery Call with Our Engineering Team
The #4 installment of Lizard Global's CTO Corner, written by Guido van Beek, this blog details how our company transitioned from passive AI implementation to active agentic workflow automation, initially testing the architecture on internal operations before scaling to enterprise clients in the Netherlands. By detailing real-world applications such as a comprehensive CRM audit, unified cross-platform financial dashboards, live call-center decision support in Rotterdam, and multi-agent B2B lead generation pipelines, the post outlines the technical design principles required for enterprise execution. It covers single-responsibility agent design, structured schema handoffs, Model Context Protocol (MCP) integrations, robust audit logging, and hard human-in-the-loop checkpoints. Crucially, it highlights how strict GDPR compliance and ISO 27001 data governance must be natively architected into agent systems to ensure enterprise-grade security and operational efficiency.
I wrote before about how AI became part of our business through compliance, not through an AI mandate. This is the piece that follows from that: what happened once we started letting agents take multi-step action across our own systems, not just answer questions from them.
There is a real difference between the two. An agent that answers a scoping question from documentation is informing a decision a person still makes. An agent that pulls data from one system, cross-references it against rules, and hands back a structured set of recommendations for a person to act on is doing something closer to work. That second category is what I mean by agentic workflow automation, and it is where we have learned the most, on our own operations first.
Where we actually started: our own delivery process
Before we touched a client-facing workflow, we changed how we run delivery internally, moving to a more structured, agent-driven way of building software ourselves. It was a genuine adjustment, not a switch we flipped. But it is what gave us the confidence, and the internal proof, to offer this to clients rather than pitch it from theory.
The clearest example of what that actually looks like in practice was not glamorous. It was our own CRM.
The Pipedrive audit: a real multi-step agentic workflow, on our own mess
We had let our Pipedrive pipeline drift for years: 423 open deals, 87 percent of value parked in a stage with no exit criteria, probabilities set by gut feel. Cleaning that up manually would have meant someone spending days cross-referencing deal age, activity logs, stage, and probability by hand, deal by deal.
Instead, an agent pulled the full export, applied a consistent set of rules across every deal, and produced a structured report: 360 of 423 deals flagged stale, 43 deals with probabilities inflated relative to their actual stage and activity, and 50 deals meeting a clear "dead" threshold, representing roughly €1.68 million in pipeline value that had no realistic chance of closing. It took a fraction of the time a manual audit would have, and it did not miss anything a manual pass would have caught.
The agent did the multi-step, cross-referencing work by utilizing business process automation. A person still decided what to do with each flagged deal. Nothing got marked Lost automatically.
That last point matters more than the speed. The moment an agent is taking multi-step action across your systems, the question is not just "does this save time," it is "who is accountable for what it changes." Keeping the recommendation and the decision in separate hands is not a limitation we are working around. It is the design.
The bigger picture: one operational view, not four disconnected tools
The Pipedrive audit was the first piece, not the whole picture. We connected Xero, Harvest, and ClickUp into the same view, so that financial data, time tracking, delivery status, and pipeline health stopped living in four separate tools that nobody cross-referenced by hand.
The clearest sign it changed something real: our MT meetings now start with it, not with someone reconstructing the state of the business from memory and four open tabs. Cash position, hours logged against active delivery, deal movement, and account health, in one view, before the conversation even starts. Decisions that used to wait for someone to pull the numbers together now happen in the room, because the numbers are already there.
It also surfaces things earlier that used to show up late: a project running over its logged hours before the invoice reflects it, a deal marked "closing soon" that has not actually moved in months, committed cash sitting against payables nobody had flagged yet.
None of these are dramatic individually. Caught consistently, weeks earlier than they would have surfaced otherwise, they add up to a business that runs on what is actually happening, not on what someone remembers happening.
Bringing it to clients
The reason this belongs in a blog post rather than an internal memo is that we are now building the same category of system for clients, not just for ourselves, expanding our work across our portfolio of client projects.
For a long-term client based in Rotterdam, we designed an agentic workflow built directly into their call centre. It hooks into their VoIP software, pulls the caller's record the moment the number is identified, and listens in on the conversation as it happens, keeping the relevant account and case history on screen for the whole call instead of leaving the agent to search for it mid-conversation.
It helps draft replies in real time, suggests the right SOP to follow based on the company's own templates and that caller's case history, and logs the entire interaction automatically once the call ends. Work that used to depend on one person's memory of the right template and a scramble through old tickets now sits in front of them before they have to ask for it, showcasing the impact of AI integration in software systems.
For another Rotterdam-based client, still mid-implementation, we built lead generation as a chain of agents rather than one tool. One agent pulls prospect data from multiple sources. A second enriches and verifies it. A third researches recent news on each lead, so outreach is grounded in something current rather than a generic template. A sequencer then suggests the outreach message, over InMail or email, reads the responses that come back, makes a judgment call on what kind of reply it is, and suggests the next message accordingly.
What used to be a person doing several separate lookups before writing one message is now a chain of agents doing the lookups, with a person still approving what actually goes out.
Both are live engagements, not case studies with a tidy before-and-after yet. I would rather describe them honestly, as work in progress, than attach numbers to them before we have real ones to report.
How these agents are actually put together
Everything above describes what these systems do. For whoever on your side has to sign off on how, it is worth being specific about the architecture, because "we added AI" and "we built an agentic workflow" are not the same claim.
One agent per job, not one agent doing everything.
The lead generation pipeline is four separate agents, not one large prompt trying to source, verify, research, and write outreach in a single pass. Sourcing, enrichment, news research, and message drafting each run as a distinct agent with a narrow, well-defined job and its own tool access.
A single agent asked to do all four tends to degrade at the seams, quietly skipping steps or blending them. A chain of narrow agents, each handing off a structured result to the next, is slower per step and considerably more reliable end to end, and it is far easier to debug when one link produces a bad result.
Structured handoffs, not prose passed between steps.
Each agent in the chain returns data against a defined schema, not a paragraph the next agent has to interpret. The enrichment agent does not receive "here's some stuff about this lead" from the sourcing agent, it receives a fixed set of fields it knows how to validate.
This is what makes a multi-agent pipeline different from stringing together a few chatbot prompts: every handoff is a contract, and a malformed one fails loudly instead of quietly corrupting the next step.
Integration through a standard protocol, not bespoke code per tool.
The call centre workflow needs to reach the VoIP system, the CRM, and the client's document store. We connect agents to these through MCP servers rather than writing a one-off integration for every system on every project using scalable API and microservices architecture.
It means the same connector pattern that reads a case history today can read a different CRM on the next client without a rebuild, and it is a large part of why we can stand these up in weeks rather than months.
A defined point where the agent stops and a person starts.
This is architectural, not a UI checkbox. In the call centre workflow, the agent surfaces context and drafts a reply; a person sends it. In the lead generation pipeline, the agent reads a response and classifies it, then proposes the next message; a person approves it before it goes out over InMail or email.
The pipeline is built so that any action with an external consequence, a message sent, a record changed, a deal marked Lost, requires a human step in between. Autonomy up to that point, a hard stop at it, aligned with modern principles of enterprise AI governance.
Every step logged, not just the outcome.
Each agent's input, the tools it called, and the output it produced are recorded individually, not just the final result. That is what makes a pipeline debuggable when something goes wrong three steps in, and it is the same discipline that makes this defensible to a client's compliance or security team asking what the system actually did and why.
Compliance is not a separate conversation from the agent's design
Every example in this piece touches personal data somewhere: a caller's voice and account history, a lead's name and inbox, an employee's activity log. None of that is optional to think about once. It has to be designed before the first agent runs, not reviewed after the fact, embedding security and ISO compliance from day one.
A few things that actually change once you take that seriously:
Access is scoped per agent, not per project.
Because each agent in a pipeline has one job, it only needs the data that job requires. The enrichment agent in the lead generation pipeline does not need access to the call centre's account records, and the call centre agent does not need access to the CRM's financial fields.
Narrow agents make this the natural outcome of the architecture, rather than a policy someone has to enforce separately on top of it.
Legal basis gets decided before the agent is built, not argued about after a complaint.
A call centre agent listening in on a live conversation is processing personal data in real time, which in the Netherlands means the caller needs to be informed, consistently, before the call starts. A lead generation agent enriching a prospect's contact details is relying on legitimate interest for B2B outreach, which has its own limits on what it can justify.
Deciding this after the pipeline is already live is how agencies end up retrofitting consent flows into a system that was never designed to support them.
The audit log from the architecture is also the compliance evidence.
The per-step logging described above, what data an agent touched, what tool it called, what it produced, is the same record a client's DPO or an auditor asks for when they want to know what happened to a specific piece of personal data. We do not maintain two systems, one for engineering and one for compliance.
It is one discipline serving both.
The human checkpoint is also the accountability boundary.
GDPR does not have a clean answer for "the agent decided this." A person approving the message that goes out, or the record that gets changed, is also the person who can be identified as having made that decision, which matters the moment anyone asks who is responsible for a specific action.
We have written separately about how ISO 27001 and GDPR shaped our service model. What is different with agentic systems specifically is that compliance is not a layer added around the system afterwards. It has to be a property of how the pipeline is built, agent by agent, from the start.
What "streamlining enterprise operations" actually means
It does not mean removing the person from the loop. In every example here, ours and our clients', a person still owns the decision the agent's output feeds into. What changes is how much groundwork a person has to do before they can make that decision well. That is the same argument I made about capacity in the last post, applied now to operations rather than documentation: the same team handling more, not a smaller team doing the same amount.
For a business in the Netherlands looking at where to start, my honest advice is the same as it was for compliance: start with the operational mess you already have, not the flashiest use case you can imagine. We started with our own CRM because it was the thing closest to us that was clearly broken. That is usually where the real leverage is.
Streamline Your Enterprise Operations
Transform operational chaos into structured, compliant, multi-agent workflows built specifically for your enterprise stack. Whether you need to connect your fragmented software ecosystem or automate high-volume business operations with human-in-the-loop accountability, our engineering team designs solutions tailored to Dutch compliance and European data governance standards.
Schedule an Architecture Discovery Call with Our Engineering Team
FAQs
How does agentic AI workflow automation differ from standard chat-based AI?
Why use multiple single-purpose AI agents instead of a single prompt?
How do agentic AI workflows maintain GDPR compliance in the Netherlands?
What is the Model Context Protocol (MCP) and why is it used in enterprise automation?
How do human-in-the-loop controls work within autonomous agent workflows?
Can agentic workflows integrate across legacy systems like CRMs, ERPs, and VoIP platforms?
How do Dutch enterprises scale AI adoption without introducing operational risks?
similar reads
AI & Machine Learning
Enterprise Digital Transformation Services Powered by AI Integration
15 June 2026
AI & Machine Learning
How Malaysian Enterprises Can Recover Failing Software Projects with AI-Led Delivery
18 June 2026
AI & Machine Learning
Malaysia’s Top 5 Leading AI Integration Agencies for Enterprise-Scale Systems
24 June 2026
Stuck between a great idea and the right team to build it?Let's talk.
We work with corporate innovation teams and ambitious scale-ups across the Netherlands, Singapore, and Australia, and wherever great software needs to be built. Drop us a message and we'll get back to you within one business day.
Markus Monnikendam
Global Commercial Director
hello@lizard.global