Skip to content
Bizzi AI Governance Framework
Pillar IV: Data, AIOps, Infrastructure · § 05

Agentic Development Lifecycle (ADLC), overview

Classical MLOps was built for predictive ML. Train a model, deploy a binary, watch for drift. Agentic AI does not fit this shape. The base model is prompted rather than trained. Iteration happens in prompts and graphs rather than weights. A single user query touches a dozen LLM calls. ADLC is what we put in front of this reality.

Context

Section titled “Context”

We considered keeping the MLOps label and stretching it. We decided against it because three things genuinely changed. Evaluation moved from a single accuracy number to a multi-dimensional judgment (Accuracy, Groundedness, Safety). Deployment moved from “publish model artifact” to “route through a gateway with fallbacks.” Monitoring added a runtime cost dimension with no equivalent in batch ML. ADLC is the name for the discipline addressing all three.

  1. 1
    Design
    Prompt and model classification
  2. 2
    Evaluation
    LLM-as-a-Judge
  3. 3
    Testing
    A/B and shadow mode
  4. 4
    Deployment
    AI Gateway and fallback
  5. 5
    Monitoring
    Drift detection
Stage 5 drift Stage 1 retrain
ADLC, five stages

The five stages

Section titled “The five stages”
  1. Design (§6). Choose the right model for the task complexity. Write a portable and bounded prompt. Version it in the observability layer.
  2. Evaluation (§7). Run LLM-as-a-Judge against three criteria, Accuracy, Groundedness, Safety, on every prompt version.
  3. Testing (§8). Shadow mode first, then phased A/B rollout against real traffic with explicit kill criteria.
  4. Deployment (§9). Promotion through the AI Gateway, with the previous version retained as fallback for at least 30 days.
  5. Monitoring (§10). Continuous drift detection on inputs, outputs, and business KPIs. Drift over threshold triggers a retrain back into Stage 1.

ADLC versus the six-step risk framework

Section titled “ADLC versus the six-step risk framework”

ADLC is the technical lifecycle. The six-step risk framework in Pillar I §8 is the governance lifecycle. They run in parallel, and a feature must pass both.

  • The six-step framework answers should we build this, and what guardrails does it need?
  • ADLC answers given we decided to build it, how do we ship it safely?

A feature clearing the six-step framework but failing Stage 2 evaluation does not ship. A feature with a perfect evaluation score but no six-step approval does not ship either.

Ownership

Section titled “Ownership”
  • The Centre of Excellence (CoE) owns the ADLC standard. Only the CoE changes what a stage requires.
  • The squad executes ADLC for its own features. The Data/AI Steward signs off each stage gate.
  • DevSecOps integrates ADLC into CI/CD and provides the observability stack.

Tooling

Section titled “Tooling”

ADLC runs on a fixed stack. An observability layer for prompt versioning and trace capture. An AI Gateway for model routing and fallback. An A/B framework for shadow and phased traffic. A drift monitoring pipeline computing PSI on a daily cadence. The specific products are documented in Appendix B and are swappable without changing this framework.

Standards mapping

Section titled “Standards mapping”