Week 10: A Reference Architecture for Modern AI Platforms

A tension is emerging in many engineering organizations. The world of platform engineering, which we’ve spent years refining, is built on principles of stability and repeatability. Yet the world of AI development is inherently experimental, data-intensive, and iterative. When we try to force the exploratory work of machine learning into the rigid guardrails of a traditional Internal Developer Platform, the result is often friction, not flow.

This friction suggests that the two workflows may be fundamentally different. It led us to use a reference architecture for AI platforms that acknowledges this difference by separating concerns into three distinct planes.

A Model for Clarity: The Three Planes

The model organizes the system into three specialized areas:

• The Control Plane: This is the familiar world of platform engineering: CI/CD pipelines, GitOps, Kubernetes, and application deployment. Its job is to manage the lifecycle of the software that uses AI, providing a stable, scalable environment.

• The Data Plane: This is where all data-centric work happens, from ETL pipelines and data warehousing to the management of feature stores and vector databases. This plane is responsible for transforming raw information into clean, reliable, model-ready data.

• The Model Plane: This is the native environment for data scientists and ML engineers—a space designed for experimentation. It contains the tools for model training, evaluation, and versioning, from Jupyter notebooks to full MLOps pipelines.

Why This Separation Matters

By defining these boundaries, you allow each team to use the right tools for their specific job without compromising the needs of others. The platform team can focus on uptime and developer experience in the Control Plane. Data engineers can manage complex data workflows in the Data Plane. And data scientists can experiment freely in the Model Plane, knowing they have access to reliable data without being constrained by application deployment standards.

It recognizes that the lifecycle of a model is not the same as the lifecycle of a microservice.

Where This Might Lead

Perhaps this pattern hints at where our platforms are heading. An effective AI platform may not be a single, unified system, but rather a federation of specialized planes, each with clear responsibilities. It suggests that a mature AI Native organization requires distinct engineering disciplines—Platform, Data, and ML—that are loosely coupled and enabled by well-defined interfaces. The goal is no longer a single pane of glass, but a set of purpose-built environments that work in concert.

The reference architecture is detailed further in a recent blog post: https://re-cinq.com/blog/ai-platform-reference-arch

When we stop trying to force every workflow into a single, standardized process, what new efficiencies become possible?