A Strong Suite in Agentic Strategy: Data Apps
Root drivers of compounding AI Strategies are usually three layers below the AI model
About Our Contributing Expert
Parth Khatke | Full Stack Developer
Parth Khatke is a full-stack developer who combines the curiosity of a builder with the discipline of an engineer. Currently at The Modern Data Company, he works across modern web technologies including React, Next.js, Java, Node.js, TypeScript, REST APIs, SQL, Docker, and AWS, contributing to customer-facing applications and platform capabilities.
What distinguishes Parth is his approach to new-age data problems. His writing and professional reflections reveal an engineer who values first-principles thinking, ownership, and continuous learning as much as technical execution. His work spans frontend engineering, API design, authentication systems, and AI-powered applications, including projects leveraging large language models and cloud-native deployment architectures.
Parth represents a new generation of developers who are equally comfortable working across the application stack while maintaining a strong focus on understanding systems, diagnosing problems methodically, and developing the habits that make engineers dependable collaborators. We’re thrilled to feature his insights on Modern Data 101.
We actively collaborate with data experts to bring the best resources to a 20,000+ strong community of data leaders and practitioners. If you have something to share, reach out!
🫴🏻 Share your ideas and work: community@moderndata101.com
*Note: Opinions expressed in contributions are not our own and are only curated by us for broader access and discussion. All submissions are vetted for quality & relevance. We keep it information-first and do not support any promotions, paid or otherwise!
Over to Parth 💬
I build data applications for a living. And the pattern I keep seeing across organisations investing heavily in AI agents, semantic layers, and decision automation is that while the ambition is right, the surface through which humans and AI systems actually touch data hasn’t been designed with that same ambition in mind.
A data application, built correctly, is not a dashboard with better charts. It is the governed, queryable, role-aware interface layer that makes both human decision-making and AI autonomy possible at the same time. And until your organisation understands that distinction, your agentic and semantic layer investments in terms of effort, resources, or time are building on sand.
This write-up is a shot at explaining why, from the ground up.
A Dev’s POV on the Infamous Struggle of Data Leaders: Why AI Agents Flop in the Enterprise
Start with the simplest possible question: what does an AI agent actually need to be useful?
It needs to answer questions accurately. To do that, it needs access to the right data. To have the right access, there must be a layer that understands who, or what, is asking, what they’re permitted to see, and how the data should be represented in context.
That layer doesn’t come built into an AI’s context or understanding. In fact, your AI has NO IDEA. This has to be built.
Most organisations approaching agentic AI today assume the agent itself is the hard part. The challenging aspect is everything underneath it: the governed data access, enforced policies, and the semantically consistent representation of business concepts.
The agent is only as capable as the infrastructure it queries. A data application is that infrastructure, made accessible.
Not just for AI, but for every human decision-maker in the organisation as well. When you build it right, you build it once, and both audiences benefit.
What a Data App Is, and Why It Isn’t a Dashboard
A regular digital application is built around an action. Book a flight. Send a message. Approve a request. Data serves the action.
A data application inverts this. The data is the product. Every design decision, like the UI, workflows, access controls, or the rendering logic, exists in service of surfacing data accurately, securely, and in context.
This distinction sounds subtle, but it changes the entire architecture.
Consider a commercial team managing performance across hundreds of distributors, regions, and product lines. The data exists in warehouses, in CRMs, in field systems.
A dashboard shows some of it, statically, for whoever designed it months ago. While a data application makes all of it accessible, governed, and queryable for the sales manager who needs to spot blocked inventory, the regional head who needs to compare territory performance, and increasingly, the AI agent tasked with surfacing anomalies before anyone thought to look.
The baseline promise of a data application is a single, governed surface through which decisions get made, human or automated.
Enterprise Scale Is Where Naive Architectures Break
Here is where senior leaders need to pay close attention, because this is where most implementations suffer. Unfortunately, flushing down months of development and maintenance effort.
The moment you operate at enterprise scale, identity becomes infrastructure. Single Sign-On (SSO) is non-negotiable because the organisation owns the identity layer instead of the application owning it.
Your data app, AI agent, and semantic layer- none of them own identity at this scale. They consume it from what the organisation has standardised.
But identity is just the beginning. The harder problem is what you do with it once you have it.
Who is this person? What is their role? Which region do they own? What data classification levels are they cleared for? The answers to these questions must travel all the way down to the data layer instead of stopping at the UI.
This is the difference between access control that governs what a user sees and access control that governs what a user gets. The former is cosmetic while the latter is architectural.
For AI agents operating on behalf of users, this distinction becomes even more critical. An agent must inherit and respect the access entitlements of the principal it represents, or your governance model collapses entirely.
The Semantic Layer Needs a Governed Access Layer to Mean Anything
Semantic layer, the abstraction that translates raw data into consistent business concepts like “revenue,” “active customer,” or “at-risk account,” has become a central investment for data organisations.
And rightly so. Without semantic consistency, every team is computing metrics differently, every AI is reasoning from a different definition, and the organisation cannot trust its own numbers.
But a semantic layer without a governed access layer is incomplete.
A semantic layer defines what the data means, while the governed access layer defines who can see it, in what form, and under what conditions. You need both.
A senior finance leader querying “revenue by region” through a semantic layer should see the same definition as a junior analyst, but not necessarily the same granularity, or the same underlying transaction records, or the same customer identifiers.
The data application is where these two layers meet and are enforced together.
It is the surface that takes a semantic definition, applies an access policy, and returns governed data to whoever, or whatever, asked for it.
Investing in semantic layers without simultaneously investing in governed data application surfaces will eventually result in semantic consistency breaking down at the point of access, and therefore, added engineering effort to bring it back to baseline performance.
PII and Compliance are the Architecture’s Responsibility
Let’s talk about sensitive data, because this is where AI initiatives frequently create new risk while trying to create new value.
PII is subject to regulation in virtually every market: GDPR in Europe, DPDP in India, and an expanding set of equivalents everywhere else. These regulations govern how data is stored, accessed, displayed, and processed.
The naive implementation: hide the column if the user isn’t permitted to see it.
The correct implementation: show the column, masked or hashed, so the user understands the shape of the data that the field exists and that it has a value, without seeing the value itself.
This is a meaningful operational distinction, and it matters enormously for AI agents that are reasoning about data structure and completeness.
More importantly, this logic should not exist in application code. It should be in the platform layer that governs all data access, so that the masking is enforced regardless of which application or which agent is querying the data.
Systems that implement this correctly ensure that governance travels with the data.
A new application built on top of the same dataset inherits the same policies automatically.
To build agentic systems, this is the recommended model: Governance at the platform layer, not the application layer. Otherwise, every new agent you deploy is a new governance surface you have to audit.
Visualisation Is the Product Output
Most people think of data applications primarily as visualisation tools. Charts, graphs, drill-downs, filters. And yes, good visualisation is essential. A well-designed spatial view communicates a pattern that no table of numbers ever could.
But visualisation is the output layer. It is not the product.
The product is the governed, queryable, access-controlled data infrastructure underneath it.
The visualisation is simply how one class of user (the human decision-maker) consumes that infrastructure. An AI agent consuming the same infrastructure does not need a chart. It needs a well-formed, semantically consistent, governed query response.
This is the frame shift that counts for decision makers. When you evaluate a data application, don’t evaluate the charts. Evaluate the infrastructure. Ask questions like:
How is identity handled?
How are access policies enforced?
How does the semantic layer integrate?
How does it expose itself to AI interfaces?
The visualisation can always be improved. If the infrastructure is wrong, you rebuild from the ground up.
Conversational AI Is the Inevitable Direction
The most capable data applications being built right now share one characteristic: they are designed to be queried in natural language, not just navigated through fixed views.
This matters for a specific reason. A dashboard answers the questions someone thought to ask when they built it. A conversational interface answers the question the user has right now. The difference in decision quality and decision speed is significant.
For AI managers or project owners, this is more than a UX improvement. Conversational interfaces are the natural entry point for agentic systems.
When your data application is designed to respond to natural language queries with governed, semantically consistent data, you have the foundation for autonomous agents that can surface insights, flag anomalies, and recommend actions without human prompting.
The architecture decisions you make today determine whether this is easy or painful later. Specifically, is your data access layer queryable? Can it accept a natural language input, translate it to a governed query, and return structured data?
If the answer is no, your conversational AI and agentic ambitions have a hard dependency on infrastructure work you haven’t done yet.
Where You Host Is a Strategic Decision
Infrastructure conversations often get delegated too far down in the organisation. Which they shouldn’t.
The standard deployment options (Vercel, Render, Netlify) are fine for frontend applications. They are not the right answer when your data application is backed by governed pipelines, semantic layers, and policy engines that exist in a specific data environment.
Every network hop between your application and your data platform is a point of latency, a point of failure, and a point where governance can break down. The cleanest architecture co-locates the application with the data: same network, same security perimeter, same operational environment.
For organisations running on a data developer platform like DataOS, this means the application is deployed within the platform itself. The governance, semantic layer, and access policies are not remote dependencies the application calls out to, but part of the same fabric.
It is an architectural principle that determines how reliably your governance model holds under load, under scale, and under the access patterns that AI agents generate.
The Builder’s Advantage
The tooling available for building governed data applications has improved dramatically. AI-assisted development tools like Cursor, Claude Code, and others have meaningfully reduced the time it takes to go from architecture to a working application.
But tooling does not substitute for architectural clarity. A few principles that matter in practice:
Never develop against production data.
Use synthetic schemas: representative structures, anonymised values, accurate shapes, that let you build and test without exposing sensitive information. This forces clarity on the data model before a line of UI code is written.
Prefer JSON over CSV for data structure.
JSON carries schema natively. Relationships, types, and hierarchies are explicit. AI development tools reason from JSON schemas accurately and immediately. CSV requires inference, which introduces ambiguity exactly where you need precision.
Adopt integration patterns early.
Most serious data platforms ship with opinionated integration patterns for common frameworks. These encode best practices about how applications should connect to the governed data layer. Ignoring them in favour of custom wiring creates architectural debt that compounds quickly.
What You’re Actually Building Toward
A data application, built with the right architectural principles, is an enterprise-grade system that:
Authenticates every user and agent through the organisation’s identity layer.
Enforces access at the data level (by role, location, and attribute) not just at the UI level.
Handles sensitive data through platform-level governance that travels with the data regardless of which surface consumes it.
Exposes semantically consistent data that means the same thing to every human and every AI that queries it.
Supports both fixed visualisation for human decision-makers and queryable interfaces for AI agents.
Is deployed within the same infrastructure that governs its data, so governance holds at scale.
The gap between a Power BI report and this kind of system is not a gap in chart quality but true architectural maturity.
Treat data applications as governed, decision-ready infrastructure rather than visualisation tools to compound the outcomes and performance of AI consumers.
Every agent deployed inherits a sound foundation, every semantic layer investment lands on governed access, and every conversational interface queries data we can trust.
Without closing this gap, one will keep discovering that their AI ambitions have a dependency they didn’t plan for.
MD101 Support ☎️
If you have any queries about the piece, feel free to connect with the author(s). Or connect with the MD101 team directly at community@moderndata101.com 🧡
Author Connect 💬
Got questions or want to share your own experiments? Find Parth on LinkedIn or drop a comment below. 💬
From MD101 team 🧡
🌎 State of Data Products, Q1 2026
Don’t place your 2026 data bets in the dark. Discover how the best minds are leaning toward architectural resilience and trust: Read the Q1 Edition of the State of Data Products, The Catalyst.
 | A guest post by
|
Three layers below the model is the right place to look. It's also the place strategy decks never zoom into. What decides whether the suite compounds or collapses is the metric semantics sitting directly under each app. Two apps on the same warehouse will disagree on active customer unless that definition is written once and inherited. Serve it once, consume it everywhere. Is the suite sharing one semantic contract, or just a data source?