Agentic AI Onboarding: Platform Engineering for Developers, Data Scientists & AI Agents

Platform engineering started with developers. The entire discipline exists because developers were drowning in infrastructure complexity — Kubernetes, networking, secrets, monitoring — and needed a paved road from code to production.

But the users of your platform are evolving. Today your platform serves three distinct personas with increasingly different needs:

1. Developers: Build microservices, APIs, and web applications. Deploy containers. Need CI/CD, secrets, monitoring, and networking
2. Data scientists: Build models, run experiments, process datasets. Need GPUs, notebooks, experiment tracking, and a path from experiment to production
3. AI agents: Autonomous systems that need compute, data access, API credentials, and action boundaries. They "onboard" like a new team member — but they're not human

Most platforms were designed for persona #1 and force personas #2 and #3 into the same moulds. Data scientists end up writing Dockerfiles they don't understand. AI agents get shoved into generic service containers with no safety controls. The result: shadow platforms, workarounds, and risk.

The Developer Platform (What You Already Have)

If your platform engineering is even moderately mature, you've solved the developer experience:

• Git push triggers CI pipeline
• Container built, scanned, pushed to registry
• ArgoCD deploys to Kubernetes
• Monitoring, logging, and alerting are automatic
• Secrets from Vault, TLS from cert-manager
• Self-service namespace provisioning via Backstage

This is the foundation. The question is: how do you extend it for data scientists and AI agents without rebuilding?

Extending for Data Scientists

Data scientists don't think in containers, deployments, and services. They think in experiments, datasets, models, and notebooks. Your platform needs to bridge the abstraction gap.

What Changes

Capability	Developer	Data Scientist
IDE	VS Code, IntelliJ	Jupyter, VS Code with Python
Compute	CPU pods	GPU pods (T4, A100, H100)
Storage	Small PVCs (1-10GB)	Large PVCs (100GB-10TB) + object storage
Pipeline	CI/CD (build, test, deploy)	ML pipeline (data prep, train, evaluate, register)
Artefact	Container image	Model (ONNX, SafeTensors) + model card
Registry	Container registry	Model registry (MLflow)
Monitoring	Latency, errors, throughput	Accuracy, drift, bias, latency
Versioning	Git (code)	Git (code) + DVC/MLflow (data + models)

Platform Additions (Not Replacements)

You don't need a separate platform for data science. You need additional golden paths on your existing platform:

• JupyterHub on Kubernetes: Jupyter notebooks backed by your existing cluster. GPU scheduling via the NVIDIA device plugin you already have (or should have). Persistent workspaces on your existing storage classes
• GPU quota management: Extend your existing ResourceQuota to include GPU requests. Self-service GPU allocation within team budgets. Escalation workflow for additional GPU capacity
• MLflow integration: Deploy MLflow on your platform. It uses your existing PostgreSQL and object storage. Experiment tracking, model registry, and model serving — all within your platform's security and networking boundaries
• Data science Backstage template: "New ML Project" template that provisions: Jupyter workspace, MLflow experiment, GPU quota, data access permissions, and a model-to-production pipeline. Same self-service experience as your developer templates

# Backstage Template: New ML Project

Parameters:
  - project_name: string
  - team: dropdown (from team registry)
  - gpu_type: T4 | L4 | A100 | H100
  - gpu_count: 1-8
  - dataset_access: list of data catalogue entries

Creates:
  - Kubernetes namespace: ml-{team}-{project}
  - JupyterHub workspace (persists across sessions)
  - MLflow experiment
  - GPU ResourceQuota
  - Data access RBAC (read-only to requested datasets)
  - Model promotion pipeline (experiment -> staging -> production)
  - Grafana dashboard (GPU utilisation, experiment progress)
  - Cost tracking label (chargeback to team budget)

The Promotion Bridge

The biggest gap between data science and production is the "promotion" step. Data scientists create models in notebooks. Production needs containerised, versioned, monitored services. The platform must bridge this:

1. Data scientist registers model in MLflow (logs metrics, model card, lineage)
2. Data scientist clicks "Promote to Staging"
3. Platform automatically: packages model in serving container (vLLM/Triton), creates deployment manifest, generates model card metadata, runs safety validation (bias check, adversarial test), creates PR to GitOps repo
4. MLOps reviews PR, approves
5. ArgoCD deploys to staging with canary rollout
6. Safety metrics pass → auto-promote to production

The data scientist never writes a Dockerfile. The MLOps engineer never manually packages a model. The platform handles the translation. For the full multi-stakeholder platform architecture, see our detailed breakdown.

Extending for AI Agents

This is the frontier. AI agents are a new type of platform consumer that doesn't fit neatly into either the developer or data scientist model.

What Makes Agents Different

• Autonomous execution: Developers and data scientists interact with the platform manually. Agents interact programmatically and autonomously. They make decisions, call APIs, and take actions without human approval (within boundaries)
• Unpredictable resource patterns: A developer's service has relatively stable resource usage. An agent's resource usage depends on what tasks it receives — it might be idle for hours, then suddenly need 8 GPUs to process a complex request
• Action boundaries: Developers are trusted with broad access because they're humans exercising judgment. Agents need explicit, technical boundaries on what actions they can take, what data they can access, and what rate they can operate at
• Identity and attribution: When a developer deploys a bad config, you check the Git log. When an agent takes a harmful action, you need attribution, reasoning trace, and rollback — all automated

Agent Onboarding as Platform Capability

Onboarding an AI agent should be as structured as onboarding a new team member — because the risks are similar:

# Agent Onboarding Golden Path

1. Team requests "New AI Agent" via Backstage
2. Parameters:
   - Agent name and purpose
   - Risk classification (low / medium / high / critical)
   - Required capabilities (API access, data access, compute)
   - Action scope (read-only / read-write / external API calls)
   - Human oversight level (async review / sync approval / autonomous)

3. Platform creates:
   - Service account with RBAC scoped to declared capabilities
   - Namespace (shared with team or isolated, based on risk level)
   - NetworkPolicy (only declared external APIs, deny-all else)
   - Action rate limiter (max API calls/minute, configurable)
   - Output validation webhook (PII filter, toxicity check)
   - Audit log pipeline (every action, every decision, reasoning trace)
   - Cost budget with automatic shutdown on breach
   - Monitoring dashboard (actions/min, error rate, cost, safety metrics)

4. Agent operates within boundaries
5. Weekly automated safety review generates compliance report
6. Quarterly human review of agent scope and permissions

The Agent Scaling Paradox

Here's the insight that most platform teams miss: AI agent requirements are more similar to scaling a human team than scaling a technical system.

When you hire a new engineer, you:

• Define their role and scope (job description → agent purpose and capability declaration)
• Grant appropriate access (onboarding checklist → RBAC + NetworkPolicy)
• Set expectations and boundaries (company policies → action rate limits + output validation)
• Monitor their work initially (probation period → enhanced audit logging for new agents)
• Expand their scope as they prove reliable (promotion → scope expansion after safety review)
• Budget for their cost (salary → compute budget with alerts)

The platform should support this lifecycle: provision → constrain → monitor → expand → review. It's HR for AI — and it should be as self-service as creating a new microservice.

The Unified Platform Stack

Three personas, one platform

Go Fast, Iterate Safely

The temptation is to design the perfect unified platform before shipping anything. Don't. Instead:

1. Week 1-2: Ship the data science golden path on your existing platform (JupyterHub + MLflow + GPU quota). It won't be perfect. Ship it
2. Week 3-4: Ship the agent onboarding template with conservative defaults (strict boundaries, enhanced monitoring). Get one agent running on the platform
3. Month 2: Gather feedback from data scientists and agent operators. What's missing? What's frustrating? What's unused?
4. Month 3: Iterate. Expand golden paths based on actual usage patterns, not theoretical requirements
5. Ongoing: Every two weeks, ship one improvement. A new template, a better dashboard, a streamlined workflow. Visible progress builds trust and adoption

For the full platform acceleration playbook, see our dedicated guide on consistent DevEx at scale.

What Open Empower Delivers

• Platform extension design: Assess your existing developer platform and design extensions for data science and AI agent workloads
• Data science golden path: JupyterHub, MLflow, GPU scheduling, and model promotion pipeline on your existing Kubernetes platform
• Agent onboarding framework: Backstage templates, RBAC, NetworkPolicy, rate limiting, output validation, and audit logging for AI agents
• Unified observability: Grafana dashboards covering developer services, ML models, and AI agents in a single pane
• Safety and compliance: Policy-as-code for all three personas. Admission control, data classification, and automated compliance evidence

Your platform started with developers. It's time to serve everyone who builds. Let's extend yours.