The Data Mesh is Dead. Long Live the Agentic Mesh.
In 2019, Zhamak Dehghani published a blog post that changed how enterprises think about data. The core idea of data mesh was elegant: stop dumping everything into a central lake. Let domain teams own their own data. Treat data as a product. Federate governance.
Five years later, the track record is mixed. Zalando, Netflix, PayPal adopted data mesh. Many more tried and failed. The recurring complaints are predictable: federated governance turns into governance-by-committee, domain teams resent the new responsibility because it's rarely compensated, and employees report severe lack of comprehension of what data mesh even means (that last one is from actual academic research, not my opinion).
I think data mesh was the right diagnosis applied to the wrong patient. The problem was real: centralised data teams become bottlenecks. The solution assumed that data wants to sit in one place and be queried. What if data doesn't want to sit anywhere? What if data wants to move?
The Dutch healthcare data problem, specifically
The Netherlands has a healthcare data landscape that makes the data mesh failures look quaint.
There are roughly 12,000 GP practices. About 90 hospital organisations. Eight academic medical centres. Hundreds of mental health, rehabilitation, and home care providers. Every one of them has an EHR (electronic health record). The GP systems mostly run HIS (Huisartsinformatiesysteem) software from a handful of vendors. Hospitals run their own systems. Pharmacies have their own. The national EHR from 2012 is a "virtual EHR" - a reference server that knows which local EHR stores what kind of patient record. It doesn't actually store data. It points to data.
Most data exchange still happens via EDIFACT - a messaging standard from the 1980s that was originally designed for shipping container logistics. In 2024, only about 11% of Dutch health data was interoperable between providers.
The IZA (Integraal Zorgakkoord) wants that at 66% by 2030. They're spending €2.8 billion on transformation plans to get there. Over 270 plans submitted before the postbus closed in July 2025.
The Wegiz (Wet elektronische gegevensuitwisseling in de zorg) - the law mandating electronic data exchange in healthcare - came into effect to force the issue. But mandating exchange and achieving it are different things. The law says you must exchange. It doesn't say how. And "how" is where every integration project in Dutch healthcare goes to die.
Why data mesh won't save healthcare
A data mesh advocate would look at this and say: give each domain (GPs, hospitals, pharmacies) ownership of their data products. Let them publish standardised data contracts. Build a self-serve data platform. Federate the governance.
It sounds reasonable. It doesn't survive contact with the Dutch healthcare system.
The three problems with data mesh in healthcare
Problem 1: Domain ownership presupposes willing domain owners.
In data mesh, domain teams are supposed to take end-to-end responsibility for their data products. In Dutch healthcare, a GP practice with 2 GPs and a practice nurse is not a "domain team" in the Thoughtworks sense. They're three people drowning in 30% administrative overhead trying to see patients. Asking them to also maintain a data product with quality metrics, documentation, and access controls is asking them to become a software team. They are not a software team. They are doctors.
The same applies to most hospitals. The IT departments are running EHR systems, not building data products. They have vendor contracts with Chipsoft or Epic or Nexus. The data sits inside those systems, behind vendor-specific APIs. The hospital doesn't own the data product in any meaningful engineering sense. The vendor does.
Data mesh works when you have autonomous engineering teams that can iterate on data quality. Healthcare has autonomous clinical teams that want the computer to stop breaking.
Problem 2: Data contracts assume stable schemas.
In retail or fintech, a data contract between "orders" and "payments" domains can be versioned and maintained because the schema is well-understood and relatively stable. In healthcare, the clinical data model is vast, evolving, and clinically nuanced. FHIR R4 defines over 150 resource types. A single patient encounter might generate Condition, Observation, Encounter, Procedure, MedicationRequest, DiagnosticReport, and ServiceRequest resources, each with dozens of fields and extensions.
The Dutch healthcare standards body Nictiz publishes "Zibs" (Zorginformatiebouwstenen - care information building blocks) that try to standardise clinical concepts across systems. There are over 150 Zibs. They're good. They're also insufficient, because the clinical reality is messier than any schema can capture.
A data mesh data contract between "GP practice" and "hospital" would need to cover every possible clinical exchange scenario. That's not a contract. That's a standards body. We already have several of those. They've been working on it for decades.
Problem 3: Federated governance in healthcare is called "regulation" and it already exists and it already doesn't work well enough.
Healthcare is the most regulated data domain in existence. GDPR, the Wgbo (Wet geneeskundige behandelingsovereenkomst), NEN 7510 (information security), NEN 7512 (trust infrastructure), NEN 7513 (logging). The governance is not missing. There is too much governance and not enough interoperability.
Data mesh's federated governance model assumes that governance is the thing you need to create. In healthcare, governance is the thing that's preventing data from moving. Adding another governance layer on top of existing regulation is not a solution. It's another committee.
What an agentic mesh does differently
The difference is agency. In a data mesh, data is passive. It sits in a domain, behind a contract, waiting for someone to pull it. In an agentic mesh, data is carried by agents that can discover each other, negotiate, and act.
In Cammelot, my healthcare simulation, I built this. Every GP and specialist is an autonomous agent. Each publishes an Agent Card - a machine-readable description of capabilities, wait times, and capacity - at a well-known URL. This follows the A2A (Agent-to-Agent) protocol, which Google published as an open standard in 2025.
When Dr. de Jong needs to refer a patient with heart disease, she doesn't query a data lake. She doesn't look up a data product. Her agent reads the cardiology agent card, checks the wait time, and sends a referral. The referral has a lifecycle (submitted → working → completed). Both sides track it. The data moves with the action.
The patient's medical history is stored as FHIR R4 resources, the international healthcare data standard. But it's not stored in a data product that someone queries. It's the agent's memory. The agent carries its own context. When the agent interacts with another agent, relevant context flows with the interaction, through communication rather than a data pipeline.
This is not theoretical. The A2A protocol (version 1.0.0, released under the Linux Foundation) already specifies discovery, negotiation, task lifecycle, streaming, and push notifications. FHIR R4 has been a published standard since 2019. SMART-on-FHIR provides OAuth-based authorization scoping. The pieces exist. They've never been assembled into a mesh.
The four properties that matter
1. Discovery, not integration.
In the current Dutch landscape, adding a new specialist to a hospital's referral network requires integration work that takes, by most estimates I've heard, 3 to 18 months. In an agentic mesh, the specialist publishes an Agent Card and other agents discover it. The network grows by publication, not by connection. This is the same architectural pattern that made the web scale: HTTP didn't require every browser to negotiate with every server. Both sides spoke the same protocol.
2. Context travels with action.
In a data mesh, if a GP needs a patient's hospital records, they query the hospital's data product. In an agentic mesh, when the hospital agent sends a discharge summary, the relevant FHIR resources travel with the message. The receiving GP agent has the context it needs to act. No query. No pipeline. No ETL.
This isn't just more convenient. It changes the security model. In a data mesh, you need to secure every data product's access point. In an agentic mesh, you need to secure the communication channel and scope the data per interaction. SMART-on-FHIR already defines this: OAuth tokens scoped to specific patients and resource types per interaction.
3. Agents can reason about their own data.
A data product doesn't know when it's stale, incomplete, or contradictory. An agent can. In Cammelot, each GP agent runs a reflection cycle: it notices when its queue is growing, when burnout is climbing, when patients in the waiting list are deteriorating. These reflections drive action - referrals, escalations, alerts.
Extend this to a real-world agentic mesh. A GP agent notices that a patient's blood pressure Observations have been trending upward over three consecutive encounters. It doesn't wait for the GP to notice. It flags the trend, suggests a medication review, and - if authorised - sends a status query to the cardiology agent to check current wait times. The data is the same as in a data mesh. The difference is that something acts on it without being asked.
4. Governance is embedded, not federated.
This matters most in the Dutch context. Data mesh says: create a federated governance group that agrees on policies. An agentic mesh says: encode the policies in the agent behaviour and enforce them at the protocol level.
If a GP agent tries to refer a patient to a specialist without meeting the triage threshold, the specialist agent rejects the referral automatically, with a machine-readable reason. If a patient's data is requested without proper SMART-on-FHIR scoping, the request is denied at the protocol level. If an agent card claims a wait time that's inconsistent with its processing rate, anomaly detection flags it (this is the Mordred attack from my security red-teaming post).
You don't need a governance committee to enforce these rules. You need them encoded in the protocol. The governance meeting is replaced by a test suite.
What this looks like in practice
Imagine a 72-year-old patient in Amersfoort with COPD and type 2 diabetes. Today's data flow:
- GP sees patient. Dictates notes into HIS. Sends EDIFACT referral to hospital. Maybe.
- Hospital receives referral. Manually enters it into their system. Waits 4-12 weeks.
- Specialist sees patient. Writes a letter back to the GP. On paper. Or maybe a PDF in a portal.
- GP receives letter. Types key findings into their own HIS. The two records are now inconsistent.
- Pharmacist has a third, independent record. The home care nurse has a fourth.
Five providers. Five records. Zero automated interoperability. The data mesh version would give each provider a data product. The GP queries the hospital's data product. Better than nothing. But still pull-based, still requires integration per data product pair, still assumes someone is asking the right question.
The agentic mesh version:
- GP agent sees patient. FHIR resources (Encounter, Observation, Condition) are created automatically from the consultation. The agent's reflection cycle notices the COPD Markov trajectory is trending toward severe.
- GP agent reads the pulmonology agent card. Wait time: 6 weeks. Below Treeknorm. Sends A2A referral with embedded FHIR context (relevant Conditions, recent Observations, medication list).
- Pulmonology agent receives the referral. Validates the triage threshold. Accepts. The patient enters the queue with priority calculated from clinical severity and comorbidity risk.
- During the wait, the patient's Digital Twin agent monitors the FHIR Observation stream. COPD exacerbation risk rises. The agent sends a proactive alert to the GP agent and the pulmonology agent.
- Pulmonology agent bumps the patient's priority. The GP agent initiates ketenzorg (chronic care management) while the patient waits.
- After treatment, the pulmonology agent sends a structured discharge message with FHIR resources. The GP agent's memory is updated. The pharmacy agent receives the MedicationRequest directly.
Same five providers. One shared protocol. Data moves with action. No one queries anything. No one types anything twice. Governance is enforced by the agents' behaviour, not by a committee.
The bigger picture: research and benchmarks
Everything above - the referral mesh, the Agent Cards, the FHIR memory - is what I built first. After writing the initial version of this post, I went back and added two new agent types to the simulation: a Research Agent that runs federated population health queries across GP practices, and a Benchmark Agent that collects quality metrics from providers. Both run only in SOLL mode. The Research Agent checks consent flags, enforces k-anonymity (cohort ≥ 10), and logs results as FHIR resources. In a 100-run validation, it completed 30 queries per run, encountered ~52 consent refusals (~5% opt-out rate), and had its diabetes-specific cohort suppressed ~29 times because the town is too small for condition-specific anonymity.
I then ran five targeted experiments (20 runs each, 3000 cycles) to stress-test the claims in this post:
- Opt-out sensitivity. Varying opt-out rate from 5% to 50%. At 50%, the research agent encounters 544 consent refusals per run (up from 63 at 5%), but patient outcomes (deaths, wait times, burnout) are statistically unchanged. The research agent is read-only infrastructure - it doesn't affect care delivery.
- K-anonymity threshold. Lowering k from 10 to 3 increased successful research queries from 30 to 42 per run (the diabetes cohort passes more often). At k=20, only population-health queries succeed. This is the privacy-utility tradeoff in practice: stricter thresholds mean less granular science.
- Research frequency. Querying every 50, 100, 200, or 500 cycles - no measurable impact on GP burnout or mortality at any frequency.
- Benchmark frequency. Same result: continuous benchmarking (every 50 cycles) vs. rare benchmarking (every 500) has no mortality impact, but faster benchmarking catches quality problems sooner.
- Mordred v2 (see T2). Both forged-card and replay attacks were blocked by signature verification. System metrics were indistinguishable from unattacked baseline.
The referral scenario is one interaction type. But the same architecture applies to research and quality benchmarks — two things the current system handles poorly.
Deep dive: Personal Health Train, vantage6, and the evolution to agents
The concept of sending computation to where data lives, instead of centralising data, is not new. In fact, the Netherlands is one of the pioneers. The Personal Health Train (PHT), developed by Health-RI (the Dutch national health research infrastructure) and DTL (Dutch Techcentre for Life Sciences), explicitly uses this metaphor: data stays at the "station" (the hospital, the GP practice), and the "train" (the analysis) travels to it.
The technical implementation is vantage6, an open-source Privacy Enhancing Technology (PET) platform built by IKNL (Integraal Kankercentrum Nederland). It works: a researcher defines an algorithm, the vantage6 server distributes it to participating nodes, each node runs the computation locally on its own data, and only aggregated results return to the researcher. Federated learning, federated statistics, multi-party computation - vantage6 supports all of them. It has been used in oncology research across multiple hospitals.
So the idea of "questions traveling to data" already exists in the Dutch healthcare ecosystem. The agentic mesh is not that idea. Or rather, it's an evolution of it.
The difference is in what travels. In vantage6, what travels is a containerised algorithm. It runs on data, produces a result, and stops. It has no state, no memory, no ability to discover what other data exists, and no ability to negotiate access on the fly. It's batch computation that happens to be federated.
In an agentic mesh, what travels is an agent. It can discover other agents (via Agent Cards). It can negotiate (present credentials, request specific FHIR scopes). It can reason about what it finds (is this cohort large enough? does the aggregate make sense given what I already know from three other nodes?). And it maintains state across interactions.
Consider a concrete research scenario. A university epidemiologist wants to know the average HbA1c trajectory of type 2 diabetes patients who also have COPD in the eastern Netherlands. Today's process: write a research protocol, obtain METC approval (medical ethics committee), negotiate data sharing agreements with each participating hospital and GP practice, wait for each institution's data manager to extract and de-identify the data, assemble it centrally, and finally run the analysis. Nivel, the Netherlands Institute for Health Services Research, has built an impressive infrastructure for this - their Primary Care Database receives data from hundreds of GP practices. But even Nivel's process requires each practice to participate in the registration, and researchers must formally request access through a governance protocol with steering committees.
With vantage6, this is faster: the algorithm goes to the data. But the researcher still needs to know in advance which nodes have relevant data. The discovery is manual. The consent verification is separate from the computation. The algorithm can't adapt based on what it finds at the first node.
In an agentic mesh, the research agent carries a signed protocol (METC-approved), a SMART-on-FHIR scope definition, and a consent verification requirement. It discovers GP agents on the mesh via their Agent Cards - which advertise, among other things, whether the practice participates in research protocols and what disease populations they serve. The agent visits each relevant node. At each GP agent, it presents credentials. The GP agent checks: does this patient have an active research consent for this study type? If yes, the agent runs the FHIR query locally and returns the aggregate. If the cohort at this node is too small for anonymity (say, fewer than 10 patients), the agent flags it and moves on without returning data.
The difference: discovery is automated, consent is verified per-interaction, and the agent can reason about statistical sufficiency as it goes. The raw data never leaves the practice. The agent is stateful - it knows what it has already collected and what it still needs.
Deep dive: DICA quality benchmarks and the EHDS
Quality benchmarks: the DICA problem.
DICA (Dutch Institute for Clinical Auditing) runs 26 quality registries for hospital care. Their tagline is "life saving data," and it's accurate - systematic quality measurement has measurably improved surgical outcomes in the Netherlands. They collect data from hospitals into registries like DSCA (colorectal cancer), DUCA (upper GI cancer), DHFA (hip fracture), and 23 others. Hospitals submit data, DICA analyses it, and the results go back as "mirror sessions" (spiegelsessies) where clinicians compare their outcomes with national benchmarks.
The problem is the data pipeline. Hospitals must extract, format, and submit data to DICA. This is manual work. DICA recently announced that batch costs for PROMs (Patient-Reported Outcome Measures) data submission were fully abolished as of January 2026 - which tells you that the cost of submitting data to quality registries was a real barrier. The benchmarks are retrospective: by the time you learn that your hospital's complication rate is above the national average, the patients have already been treated.
In an agentic mesh, a benchmark agent carries a standardised measurement definition (say: "30-day mortality after colorectal surgery, adjusted for ASA score and tumor stage"). It visits each hospital agent. Each hospital agent runs the calculation against its own FHIR store and returns one number. The benchmark agent aggregates. No data extraction. No manual formatting. No batch submission costs. The benchmark updates continuously instead of annually.
The EHDS changes the legal landscape - and creates new problems.
The European Health Data Space (EHDS, Regulation EU 2025/327) entered into force on March 26, 2025. It is the most significant piece of European health data legislation since GDPR. For secondary data use (research, benchmarks, policy), the EHDS mandates that each EU member state establish at least one Health Data Access Body (HDAB). Researchers apply to the HDAB, the HDAB processes the request, data holders are obligated to share, and analysis must happen in "secure processing environments" under HDAB control. Patients can opt out.
An agentic mesh is not a replacement for the EHDS - the regulation is law, and compliance isn't optional. But it could be the infrastructure layer that HDABs use to fulfil their mandate. Instead of manually coordinating data extraction from every hospital, an HDAB could dispatch a certified research agent into the mesh.
Deep dive: Security (vantage6 breach) and data ownership
The security question is not theoretical.
If you think "sending computation to data nodes" is inherently safe, consider what happened to vantage6 in March 2026. An attacker gained admin access to vantage6's Harbor container registry and injected malware into infrastructure Docker images - including node images, VPN clients, and algorithm base images. The malware was a downloader that, once executed, would fetch additional payloads from the internet. Several infrastructure images that had internet access (VPN clients, SSH tunnels, proxy containers) were compromised. The vantage6 team published an advisory on April 2, 2026, and the investigation is still ongoing.
This is exactly the attack vector that matters for federated computation: the "train" that visits your hospital's data can be tampered with before it arrives. In an agentic mesh, every agent presents an Agent Card with verifiable credentials. If the card doesn't validate against a trust anchor, the receiving agent refuses the interaction. The defence is protocol-level validation, not perimeter security.
The open question: who owns derived conclusions?
This is the thing I genuinely do not have a good answer for. Under GDPR, the data controller is whoever determines the purposes and means of processing personal data. When a researcher sends a federated query and 200 GP agents each return an aggregate, the individual aggregates may not constitute personal data - they're statistics. But the researcher's combined analysis might be re-identifiable in small cohorts. Who is the data controller of the combined result?
In a data mesh, ownership is at least theoretically clear: the domain owns its data product. In an agentic mesh, the data never leaves the domain. But conclusions do. And ownership of conclusions derived from federated computation across hundreds of independent data controllers is an unsolved legal question. I'm flagging this as an open research problem.
Honest limitations and what I'm not claiming
The agentic mesh does not exist as a production system today. What exists is a simulation (Cammelot) that demonstrates the architectural pattern - including signed agent cards, scoped FHIR access, referral rate limiting, a research agent with consent verification and k-anonymity, and a benchmark agent that collects quality metrics. These are working code, validated across 100 simulation runs. But they operate on 45 synthetic agents, not 12,000 GP practices. The gap between simulation and production is measured in decades of technical debt, vendor lock-in, and regulatory complexity.
Agents don't replace humans. The agents I'm describing are infrastructure, not clinical decision-makers. They move data, flag risks, enforce protocols, and manage queues. The GP still decides. The specialist still treats. The agent handles the plumbing that currently consumes 30% of their time.
And data mesh wasn't wrong. The four principles - domain ownership, data as a product, self-serve platform, federated governance - are genuinely good ideas. They just assumed a world where data is the thing you optimise. In healthcare, the thing you optimise is the workflow. And workflows are what agents do.
The uncomfortable question
The IZA is spending €2.8 billion on transformation plans. Most of those plans are building integrations between existing systems. What if, instead, every provider published an agent card and every interaction followed a shared protocol?
I don't think anyone is going to rebuild Dutch healthcare IT around an agentic mesh in the next five years. But I do think the plans that will still be working in ten years are the ones that bet on protocol-level interoperability rather than integration-level connectivity. HTTP beat proprietary networks. FHIR is beating HL7v2. A2A might beat the connector model.
References and sources
"Data stays where it is. Agents come to the data."