Chakraview Data & AI A Chakraview Technologies LLC Company
← All Articles

I Built a Data Mesh for Humans. Then I Put an Agent in Front of It.

The four principles of data mesh still hold. Two of them were quietly assuming a person on the other end.

By Narendra Loganathan • 13 min read • Updated 2026-10-23

Here is an ordinary request in a data mesh I designed.

A fraud analyst wants the fraud scores owned by the Risk and Compliance domain, the risk_compliance.fraud_scores table. She finds the product in the discovery portal, reads its contract (schema, freshness SLA, column classifications, approval rules, retention), and submits an access request with a sentence of justification. Policy evaluates the request and, because her role needs the owner’s sign-off for sensitive data, routes it to the owning domain with a two-hour approval SLA. Every governed read then goes through a masking step that asks policy, column by column, how to mask for her role, and writes an audit record before any rows come back. The table itself falls under ten-year AML retention.

Now look at what the policy engine actually received. A user ID. A role, fraud_analyst, from the same short list as analyst and risk_analyst. An action. The classification of the data. The justification went to a human approver as free text; the policy never read it.

Every one of those inputs describes a person.

sequenceDiagram
    actor Analyst as Fraud analyst
    participant Portal as Discovery portal
    participant OPA as OPA policy
    participant Owner as Risk and Compliance owner
    participant Query as Query engine (Iceberg)

    Analyst->>Portal: read the fraud_scores contract
    Note right of Portal: Agent: the contract has schema and SLAs, not meaning
    Analyst->>Portal: access request (user_id, role, free-text justification)
    Portal->>OPA: evaluate (user_id, user_role, action, classification)
    Note right of OPA: Agent: which user_role? whose identity?
    OPA-->>Portal: sensitive for this role: needs owner approval
    Portal->>Owner: route request (2-hour SLA)
    Note right of Owner: Agent: hundreds of queries a minute, not one request a day
    Owner-->>Analyst: approved
    Analyst->>Query: query fraud scores
    Query->>OPA: masking for this role?
    OPA-->>Query: masking strategy per column
    Query-->>Analyst: masked rows, audit record written
    Note over Analyst,Query: Every input to every decision describes a person

The access request as designed. Each note marks the assumption an agent consumer breaks.

Now run the same request from an AI agent acting for that analyst, at three in the morning, issuing a few hundred queries a minute across three domains because it decided that was the fastest way to answer her question. Which value goes in user_role? Who reads the justification? What happens to the two-hour SLA?

That question is where this series starts: five articles, plus a short practical coda, that take the data mesh from human consumers to AI agents. The full lineup is below. I build and govern distributed data platforms for a living, and I have published a reference implementation of the mesh above. This piece is an audit of my own design against a consumer it was not built for. It is not a report from running production LLM agents on it. The point is architectural, and the evidence is the design itself.

What the mesh got right

Data mesh got the hard part right, and it is worth saying so before taking it apart. Its four principles are domain ownership, data as a product, a self-serve platform, and federated computational governance. Together they solved a real organizational failure: a central data team that becomes the bottleneck for every question the business asks.

My fintech mesh follows them closely. Five domains (Transactions, Accounts, Risk and Compliance, Counterparties, Market Data) each own their data end to end, on an Apache Iceberg lakehouse fed by Kafka. Every data product ships a contract. Governance is policy as code in OPA, and the decision record for that choice explicitly rejected plain role-based access because roles multiply out of control at scale. Attributes were supposed to fix that.

Underneath all four principles sits an assumption the original formulation never had to state, because it was always true: the consumer is a person. A person reads the documentation. A person resolves ambiguity in their head. A person carries a role, a manager and accountability. A person works at human speed, so an approval queue measured in hours is a reasonable control.

The consumer that is arriving now breaks that assumption in three specific ways:

  • It is autonomous. No human approves each query; the agent decides what to read next.
  • It is non-deterministic. The same question can produce a different plan, a different query, a different join, and its behavior can be steered by whatever lands in its context.
  • It runs at machine speed. Hundreds of queries, fanned out across domains, in the time a person would take to read one contract.

Put that consumer in front of the four principles and they do not all fail. Two of them hold, and two break.

Principle by principle

Domain ownership holds. Nothing about an agent consumer changes who should own the transactions data or who gets paged when it goes stale. If anything, clear ownership matters more, because an agent needs someone accountable for the meaning it is relying on.

The self-serve platform holds, and matters more. Agents are the most demanding self-serve users there are. A platform that already exposes discovery, contracts and health through APIs is in a much better position than one that runs on tickets and tribal knowledge.

Data as a product breaks at “understandable.” A data product is supposed to be discoverable, addressable, trustworthy and understandable. My contracts carry the schema, SLAs, quality rules, masking and retention. What they do not carry is meaning. Meaning lived in the reader.

Take “customer,” which means something slightly different in Accounts, Transactions and Risk. My mesh links them through RDF with a deterministic identifier. Each domain mints the same customer IRI from the same two fields, so a federated query can join accounts, transactions and risk scores without a central lookup. It works, and I would build it again. But my own documentation shows the failure mode: if one domain computes the identifier from the email alone while another uses the email plus the KYC ID, the IRIs never match. The federated join does not fail. It returns nothing, quietly.

A human analyst looking at a churn report with zero high-risk customers in it senses something is off and goes to ask. An agent reports the empty result as the answer. The difference between those two outcomes is not intelligence. It is that the human was carrying the meaning in her head, and the agent can only carry what the product actually declares.

Federated computational governance breaks at “who.” The computational part is real: my policies are versioned, tested in CI, and evaluated on every access request and every governed read. But everything they compute over is an attribute of a person. There is no workload identity in the input. There is no notion of acting on behalf of someone. There is no machine-readable purpose; the justification is a sentence for a human approver.

So when an agent shows up, a team has three options, and all three are bad:

  1. Lend it the analyst’s identity. Now the audit log says she ran four hundred queries at 3 a.m. It is accurate about whose authority was used and silent about what actually acted.
  2. Give it a service account with a broad role. The approval queue disappears, and so does least privilege. The agent can now read whatever that role can read, for whichever user it happens to be serving.
  3. Put it in the approval queue. Two hours per new product, for a consumer that wanted the answer in two seconds. Nobody keeps this option for long, which is how teams end up at option 2.

This is not hypothetical. A recent academic prototype that connects LLM agents to an enterprise data product marketplace through MCP authenticated the agent with role-linked API keys. When the authors showed it to practitioners, the experts asked for exactly what the mesh lacks: separate identities for humans and AI, tighter limits on what the AI may do, and no security decisions delegated to the model.

The part the mesh has no word for

There is a third problem, and it is the one most writing on this topic skips. Agents do not only read.

They summarize, derive features, flag records and write results back. In my mesh, a producer is a domain team: it has an on-call rotation, a contract, a retention policy and a name in the ownership column. An agent that writes a derived risk summary has none of those. Who owns that output? What lineage does it carry? Which retention rule applies to a summary derived from a table that AML rules require us to keep for ten years? If the summary is wrong, who gets paged?

The original mesh has two kinds of participant: domains that produce and people who consume. The agent is a third kind, and it needs to be governed as a participant, not just tolerated as a client.

flowchart LR
    subgraph Human["Consumer the mesh was built for"]
        direction TB
        H1["Analyst<br/>role, manager, accountability"]
        H2["Reads the contract<br/>resolves ambiguity herself"]
        H3["Access request<br/>approved in hours"]
        H1 --> H2 --> H3
    end

    DP["<b>Data product</b><br/>risk_compliance.fraud_scores<br/>contract + OPA policy + Iceberg table"]

    subgraph Agent["Consumer that is arriving"]
        direction TB
        A1["AI agent acting for the analyst<br/>autonomous, non-deterministic, machine-speed"]
        G1["Gap 1: meaning<br/>only what the product declares"]
        G2["Gap 2: identity<br/>no workload identity, no on-behalf-of"]
        G3["Gap 3: participation<br/>writes outputs no one owns"]
        A1 --> G1
        A1 --> G2
        A1 --> G3
    end

    H3 -->|query as a person| DP
    G1 -.->|meaning?| DP
    G2 -.->|which user_role?| DP
    G3 -.->|derived data, no lineage| DP

    classDef gap fill:#fef3c7,stroke:#f59e0b,color:#92400e
    class G1,G2,G3 gap

One data product, two consumers. The three gaps map to the three threads of this series.

Three threads

Pull those failures apart and three threads come out. Each one is something the original formulation left soft, because a human consumer used to absorb it.

  1. Meaning has to be machine-interpretable. If the consumer cannot carry meaning in its head, the product has to carry it, in a form a machine can check. That means domain-owned semantics, which in my work means RDF and shared ontologies rather than column descriptions. That is the next article.
  2. Trust has to be computed from identity, not inferred from a role. Every consumer needs an attested identity, every delegation needs to be explicit, and policy has to evaluate both at the data product’s boundary. I made the case for those primitives, in a security context, in Zero Trust for the Workloads You Don’t Control. The third article applies them to the mesh.
  3. The agent has to be a governed participant. It consumes and produces, so it needs an identity, bounded capabilities and an owner, like any other participant. That is the fourth article.

The series

Each article stands on its own, but they build in order, and each one is anchored in an architecture I have already published.

  1. Data mesh was built for human consumers. AI changed the consumer. This article: where an autonomous, machine-speed consumer breaks the mesh, and the three threads that follow from it.
  2. Data products need meaning, not just schemas. Why data as a product falls apart across domains without shared semantics, and why RDF, knowledge graphs and SPARQL are the federated semantic layer the mesh always needed but rarely specified. Domain-owned ontologies, shift-left semantic integration, and the identifier-drift failure above, worked through from my fintech mesh’s semantic integration case study.
  3. Federated governance is a trust problem, not a policy document. Making the mesh’s softest principle concrete with zero-trust primitives: attested identity for data products and their consumers, policy at the data product’s boundary, least-privilege access, and lineage treated as attestation.
  4. When the data consumer is an autonomous agent. The convergence: agents that read and write data products, interpreted through RDF semantics and bounded by on-behalf-of delegation and capability policy at the product boundary. Includes what the agent owns when it produces data.
  5. The AI-era data mesh. The three threads assembled into one reference architecture, with the full diagram set: domains, semantics, trust and agents as one design.
  6. Adopting it without boiling the ocean (coda). Where to start, what it costs, and what to skip, for teams that cannot rebuild their mesh at once.

Where this sits in the conversation

I am not the first to notice that agents change the consumer. Zhamak Dehghani, who defined data mesh, has been building toward “autonomous data products” at Nextdata: products that carry embedded semantics, enforce policy at runtime and support discovery by agents. Thoughtworks’ review of the state of data mesh this year describes “dual-use” products that serve analytics and AI from the same contract. I agree with both diagnoses.

Where I differ is on mechanism, and on what I think is still missing. Most of the current writing says agents need semantics and governance. Very little says what identity an agent carries when it reaches a data product, or what the semantic layer actually is in standards terms. My bet is on open standards I have already shipped: RDF and SPARQL for meaning, SPIFFE workload identity and OPA policy for trust. These are not a new platform. They are pieces most enterprises can already run.

What it costs

Taking this seriously is not free, and the costs are worth naming up front.

Shared semantics is slow and political. Getting domains to agree on what “customer” means is usually slower than building the pipelines, and the negotiation repeats with every new domain. Workload identity is real plumbing: certificate issuance, rotation, and a policy engine that now evaluates delegation as well as roles. Every query pays for an extra policy decision, and every team has to learn to write policies about machines, not just people.

And it is not always worth it. If your only consumers are dashboards and analysts, the human assumption still holds, and the original mesh is still the right design. The case for this series rests on one condition: autonomous agents are reading, and soon writing, your data products. For a growing number of organizations, that condition is already true or about to be.

The four principles still hold. They just need a fifth assumption made explicit: the consumer may not be a person, and the mesh has to know the difference.

I would value pushback, especially from anyone running agents against governed data today. Did you lend them a person’s identity, give them a service account, or find a fourth option?

References and further reading

Data mesh, from the source

The current conversation about agents and data mesh

Standards this series builds on

My reference architectures

I am a software engineer at heart. With 25 years building distributed systems, I treat every part of software development, whether microservices, data engineering, agentic workloads or security, with the intense rigor of a complete engineer. No layer is someone else’s problem, and no detail is beneath attention. I have published open reference architectures at naren-chakraview.github.io.