The engineering problem
Uber describes a pre-platform environment with fragmented tools, bespoke production paths, limited reproducibility, and no uniform lifecycle for training and prediction data. The scaling problem was organizational as much as computational: each successful model required scarce integration work.
The approach
Michelangelo standardizes six stages—data management, training, evaluation, deployment, prediction, and monitoring—and integrates them with Uber's data and compute infrastructure. A shared feature store and common serving paths turn repeated project work into platform capability. The useful abstraction is the workflow around the model.
Tradeoffs
An end-to-end platform creates consistency and leverage, but it also centralizes roadmap pressure and can constrain specialized teams. Build-versus-buy decisions vary by layer: commodity compute may be reused while internal interfaces encode company-specific data, deployment, and governance needs.
What generalizes
Production AI needs versioned data inputs, reproducible transformations, controlled promotion, observable serving, and ownership across the full lifecycle. These requirements apply to LLM and agent systems even when the artifacts are prompts, retrieval configurations, tools, and evaluation sets rather than conventional models.
What is context-dependent
Uber's topology, throughput, feature reuse, and internal infrastructure reflect Uber's scale. Smaller organizations should copy the lifecycle contract before copying the platform footprint. A managed service and a few strong conventions may provide more leverage than a dedicated platform.
Architecture review questions
- Where does a prototype become a supported production artifact?
- How are training and serving transformations kept consistent?
- Which layer needs a platform and which only needs a convention?
- What operational signal causes rollback or retraining?
System details are paraphrased from Uber's article; the transferability analysis is my synthesis.