Ingestion to Insight: AI-Orchestrated Data Platform

Introduction

This captures the vision for Future of Data Platforms as well as a quick design reference, using AI as the mechanism to build up and power the platform and automate the mundane processes of creation of new metrics, doing RCAs for the failures and fixing them or to even search/build for any metric at a specific grain, taking sprints to actually serving the new analysis.

Pre-Requisites

  • A Data Cataloging layer, powered with MCP Server, so that AI Agents can communicate and polished and vetted metadata.
  • Standardised Config Driven Ingestion System.
  • Standardised Config Driven ETL/Reverse ETL System which can help in creating Processing Workflows.
  • Common semantic layer centralising the definition of metrics.
  • Out of Scope Things : Storage/Data Lakes and Governance.

High Level Design

Press enter or click to view image in full size

AI Driven Data Platform

Pre-Requisites

  • A single Data Cataloging layer, powered with MCP Server, so that AI Agents can communicate and fetch polished and vetted metadata.
  • Automated Config Driven Ingestion Facilitation System.
  • Automated Config Driven ETL/Reverse ETL System which can help in creating Processing Workflows.

Flow-Diagrams

1. Find out RCA for the failure of the Job

A lot of productive time of developers is actually spent on keeping the systems alive as of now and finding out the reasons of failures of the system. If we automate the RCA for Jobs Failures/Data Quality Issues, the same time can actually be spent on more innovative things.

Press enter or click to view image in full size

Flow for RCA of Failures

2. To serve X metric on Y Grain

Serving a new metric either for taking business decisions or for training models or for populating feature stores, with current development cycles easily take weeks, what if some part of the development cycle is taken by AI Agents, from identifying the sources for a metric to writing logic, which is eventually vetted by humans having more business context and better knowledge of the existing metrics, again leading to more productive work at the end.

Press enter or click to view image in full size

Flow for new Metric Creation

3. Create an Ingestion Pipeline

Ingestion Pipelines are usually standardised, since we have to onboard data from other operational systems to Platform, and the possible sources are finite, so standardising this framework itself would save a lot of time, rest if we can train an AI Agent to configure this system as well, it would mean reducing the development time of Ingestion pipeline to minutes.

Press enter or click to view image in full size

Flow for new Ingestion Pipeline Creation

4. Create an ETL Pipeline

ETL Pipelines is the most tricky part, since transformations will depend on business use case and should be correct and efficient, else in this Big Data world it might cost a lot for fixing the problems in the code and reprocessing the data or for processing the data at the first time with inefficient code you might end up paying a very good amount. This layer is mostly going to be dependent on the Human Developers, but AI Agents can still help out in bringing the first draft of the ETL Pipeline and then eventually developers can build over/fix the generated code, which will again save good amount of time.

Press enter or click to view image in full size

Flow for new ETL Pipeline Creation

Summary

Data teams today spend more time maintaining systems than building value. Failed pipelines, manual metric definitions, and reactive data quality fixes consume engineering capacity that should be focused on innovation.

The next generation of data platforms changes this by embedding AI agents at the core — not as an add-on, but as active participants in how data is managed and served. Pipelines that fail diagnose themselves. Metrics are created through conversation, not code sprints. Data quality issues are detected, root-caused, and resolved automatically before the business feels the impact.

The most fascinating part is, the technology needed to build this exists today, and we have also started taking a dig at it but in parts and fragments. Good way to look at it would be to make sure we remove fragments and silos and start moving towards a One-Stop Shop Data Platforms.

Vitthal Mirji profile photo

Vitthal Mirji

Staff Data Engineer @ Walmart

Mumbai, India

Staff Data Engineer & Architect from Mumbai, India. Sharing insights on Data Engineering, Functional programming, Scala, Open source, and life.

Expertise
  • Data Engineering
  • Scala
  • Apache Spark
  • Functional Programming
  • Cloud Architecture
  • GCP
  • Big Data
Next time, we'll talk about "Immutability: The Art of Never Changing Your Mind (Unlike Management)"