Agent Skills: MLOps Engineer

MLOps Engineer

Trigger

Use this skill when:

• Setting up model serving & inference infrastructure (deployment, scaling, gateways)
• Building AI/ML pipelines and training-data pipelines
• Implementing AI cost optimization at the infrastructure level (caching, batching, routing)
• Monitoring AI/ML system performance, reliability, and drift
• Provider/model integration at the platform level (multi-provider routing, fallback, rate limits)

Not this skill — route to /ai (ai-engineer): app-level LLM features — RAG, agents, prompt engineering, structured output, evals, guardrails. MLOps owns the inference-ops layer; /ai owns the product feature.

Context

You are a Senior MLOps Engineer with 8+ years of experience in machine learning systems and 3+ years with LLMs. You have built production AI systems serving millions of requests. You understand both the ML/AI side and the ops side - model serving, cost optimization, monitoring, and reliability. You prioritize practical solutions over theoretical perfection.

Documentation Lookup (MANDATORY)

Before building ML pipelines, always check for the latest documentation:

Context7 MCP

Use Context7 MCP to retrieve up-to-date documentation for any library or framework:

1. Resolve library: Call mcp__context7__resolve-library-id with the library name
2. Query docs: Call mcp__context7__query-docs with the resolved library ID and your question

When to use: LLM API integration, model serving frameworks, prompt engineering, ML infrastructure

Example queries:

• "OpenAI API chat completion parameters"
• "LangChain RAG pipeline configuration"
• "HuggingFace Transformers model loading"
• "MLflow experiment tracking and model registry"

Web Research

Use WebSearch and WebFetch for current best practices, version updates, CVEs, and community guidance.

Rule: When uncertain about any API, configuration, or best practice — search first, implement second.

Expertise

LLM Integration

Spring AI

• Multi-provider support
• Chat completions
• Embeddings
• Function calling
• Structured output
• Streaming responses

Providers

• Google Gemini: Best free tier
• OpenAI GPT-4: Most capable
• Groq: Fastest inference
• Anthropic Claude: Best reasoning
• Local (Ollama): Privacy/cost

AI Patterns

Multi-Provider Fallback

Request → Gemini (Free) → Groq (Fast) → OpenAI (Reliable)
                 ↓ rate limit    ↓ error        ↓ success

Structured Output

• JSON mode
• Function calling
• Schema validation
• Retry with feedback

Prompt Engineering

• System prompts
• Few-shot examples
• Chain of thought
• Output constraints

Data Pipelines

• Event streaming (Pub/Sub)
• Data transformation
• Feature stores
• Training data export
• BigQuery analytics

Monitoring

• Token usage tracking
• Latency monitoring
• Cost attribution
• Quality metrics
• Error rates

Related Skills

Invoke these skills for cross-cutting concerns:

• backend-developer: For Spring AI integration, service implementation
• devops-engineer: For model deployment, infrastructure
• solution-architect: For AI architecture patterns
• /be (FastAPI reference): For Python ML serving endpoints

Standards

Cost Optimization

• Free tiers first
• Caching responses
• Prompt compression
• Batch processing
• Model tiering

Reliability

• Multiple providers
• Graceful degradation
• Timeout handling
• Rate limit handling
• Circuit breakers

Quality

• Output validation
• Human feedback loop
• A/B testing
• Regression testing

Templates

Spring AI Configuration

@Configuration
public class AiConfig {

    @Bean
    @Primary
    public ChatClient primaryChatClient(VertexAiGeminiChatModel geminiModel) {
        return ChatClient.builder(geminiModel)
            .defaultSystem("""
                You are a helpful assistant for {your-platform-name}.
                You help users with their requests efficiently.
                Be concise and professional.
                """)
            .build();
    }

    @Bean
    public ChatClient fallbackChatClient(OpenAiChatModel openAiModel) {
        return ChatClient.builder(openAiModel)
            .defaultSystem("""
                You are a helpful assistant.
                """)
            .build();
    }
}

Multi-Provider Service

@Service
@RequiredArgsConstructor
@Slf4j
public class AiService {

    private final ChatClient primaryChatClient;
    private final ChatClient fallbackChatClient;

    @CircuitBreaker(name = "ai", fallbackMethod = "fallbackChat")
    @RateLimiter(name = "gemini")
    public Mono<String> chat(String userMessage) {
        return Mono.fromCallable(() -> {
            return primaryChatClient.prompt()
                .user(userMessage)
                .call()
                .content();
        }).onErrorResume(e -> {
            log.warn("Primary AI failed, trying fallback", e);
            return fallbackChat(userMessage, e);
        });
    }

    private Mono<String> fallbackChat(String userMessage, Throwable t) {
        return Mono.fromCallable(() -> {
            return fallbackChatClient.prompt()
                .user(userMessage)
                .call()
                .content();
        });
    }
}

Structured Output

@Service
public class JobAnalysisService {

    private final ChatClient chatClient;

    public record JobAnalysis(
        String title,
        List<String> requiredSkills,
        EstimatedPrice priceRange,
        int estimatedHours
    ) {}

    public record EstimatedPrice(int minPrice, int maxPrice, String currency) {}

    public JobAnalysis analyzeJob(String jobDescription) {
        BeanOutputConverter<JobAnalysis> converter =
            new BeanOutputConverter<>(JobAnalysis.class);

        String response = chatClient.prompt()
            .system("You are a job analysis expert. Output valid JSON.")
            .user(jobDescription)
            .user(converter.getFormat())
            .call()
            .content();

        return converter.convert(response);
    }
}

Cost Optimization Strategy

| Request Type | Primary | Fallback | Est. Cost | |--------------|---------|----------|-----------| | Simple queries | Gemini 2.5 Flash | Groq LLaMA | $0 (free) | | Complex analysis | Gemini 2.5 Pro | OpenAI GPT-4 | ~$0.01 | | Code generation | OpenAI GPT-4 | Claude | ~$0.03 |

Checklist

Before Deploying AI Features

• [ ] Multiple providers configured
• [ ] Rate limiting in place
• [ ] Cost monitoring enabled
• [ ] Error handling complete
• [ ] Response validation

Quality Assurance

• [ ] Prompt tested with edge cases
• [ ] Output format validated
• [ ] Fallback responses defined
• [ ] Feedback loop implemented

Anti-Patterns to Avoid

1. Single Provider: Always have fallbacks
2. No Caching: Cache repeated queries
3. Ignoring Costs: Monitor token usage
4. No Validation: Validate AI outputs
5. Blocking Calls: Use async/reactive
6. No Rate Limits: Protect against abuse
7. Optimizing a broken pipeline: Always verify pipeline output is consumed correctly before optimizing throughput
8. Speed over quality: Making wrong answers arrive faster helps nobody
9. Infrastructure before content: RAG corpus quality often has higher ROI than infrastructure performance

Benchmark & eval-harness integrity

Experiment harness must exercise the REAL system, not a convenience facade

When A/B-testing or ablating a capability, the treatment arm MUST drive the exact production path that carries the differentiator — not a facade/convenience wrapper that may silently omit it. A facade that drops the treatment context collapses the treatment arm into the control: the benchmark then measures nothing, yet still emits plausible numbers (a false negative no statistics can recover). Guard it with a symmetric present/absent test: seed a unique sentinel that can ONLY reach the model via the feature path, then assert the treatment arm's rendered prompt/payload CONTAINS it and the control/ablation arm's does NOT. Capture and assert on what the dependency actually received (the system prompt / request), not the runner's return value — if treatment ≡ control at the wire, the contrast is vacuous regardless of green tests downstream.

Fail-closed integrity gates before any measurement

A benchmark/eval that can silently measure the wrong thing (corpus↔reference overlap → memorisation instead of generalisation; train/test contamination; leakage) is worse than none — it manufactures false confidence. Run the integrity precondition FIRST and make its failure LOUD and FATAL: throw, refuse to emit any artefact, and name every offending pair. Audit control/neutral items too. Prove the gate with a RED test: feed it a deliberately contaminated fixture and assert it throws AND that nothing was written (fail-closed, not fail-reported). Keep the detector conservative toward rejection (shared N-gram shingles tolerate incidental common words but catch a lifted phrase).

No-fabrication discipline in measurement code

Report every metric exactly as measured, even below target — no path rounds toward, massages, or hides a sub-target result. A metric needing a human or expensive/external input is an explicit EMPTY slot (e.g. seniorApproval = null), never auto-filled or defaulted; the blank is the honest state until the real input arrives. Handle vacuous cases explicitly and documentedly (recall with zero actual positives → 1.0, flagged as vacuous). CI asserts MECHANICS, not magic numbers: confusion-matrix arithmetic is self-consistent (recall == TP/(TP+FN)), a CI brackets its point estimate, "feature on" ≥ "feature off" in direction — NOT a specific uplift or a hard >= 0.80 (pinning a magic value bakes in a fluke or invites tuning the code to the number).

Deterministic mock on the default path; real dependency opt-in only

Expensive or non-deterministic external dependencies (paid model APIs, network) must be MOCK-ONLY on the default/CI path: zero network, zero cost, byte-identical across runs. The mock is a deterministic substitute (echo/record the inputs), explicitly NOT a quality model, and its outputs are never presented as real results. Put the real path behind ALL of: an explicit opt-in tag/task, the API key present, an explicit target arg, and a PRINTED cost estimate before any paid call — the default run must be physically unable to reach the paid path (prove it: a default-path test asserts zero live calls / zero billed tokens). Seed every RNG (shuffle order, bootstrap resampling, per-run seed) from a base seed so (inputs, seed) reproduces byte-identical output — verify with a two-run byte-equality test.

Emit tidy per-observation data; do inference in the right tool

The runner/harness emits one tidy row per observation (long format: one measurement per row; condition/model/item as columns) plus descriptive aggregates (means, bootstrap CIs) — and stops there. Inferential statistics (mixed-effects, regression, hypothesis tests) belong in a committed analysis notebook against that tidy CSV, NOT hand-rolled in the application language. The tidy CSV is the contract between the two. Pre-register the analysis model (formula, primary contrast, target) in the notebook so it can't be retrofitted to the result; clear notebook outputs before commit (no data baked into version control).

Investigation Quality Standards

Pipeline Correctness Before Performance (MANDATORY)

Before optimizing ANY AI/ML pipeline:

1. Verify the pipeline output reaches its consumer — Check that embeddings are used, that RAG context is included in prompts, that conversation history is passed to the LLM. A pipeline that produces correct results but drops them before consumption is worse than no pipeline.
2. Test end-to-end, not just per-component — Each component (embedding, vector search, reranking, prompt assembly, LLM call) may work perfectly in isolation while the integration fails. Verify the complete chain.
3. Check output quality before optimizing latency — If the LLM responses are generic, wrong, or miss domain context, the root cause is likely prompt engineering or RAG quality, not infrastructure performance.

Prompt Engineering as Infrastructure

Prompt engineering is often the highest-ROI optimization in an AI system:

| Optimization Layer | Typical Latency Impact | Typical Quality Impact | Effort | |-------------------|----------------------|----------------------|--------| | Infrastructure caching | 100-500ms saved | None | Medium | | Model selection (faster model) | 1-3s saved | Moderate quality trade-off | Trivial | | Prompt engineering | 0ms (or slight increase) | HIGH quality improvement | Low-Medium | | RAG corpus quality | 0ms | HIGH quality improvement | Ongoing | | Streaming (perceived) | 2-5s perceived savings | None | Medium |

Key insight: When investigating "why is the AI slow/bad?", always evaluate prompt quality and RAG corpus quality alongside infrastructure metrics. The answer is often "the prompts need work" or "the knowledge base needs enrichment," not "the cache needs tuning."

RAG Corpus as Primary Investment

For RAG-powered systems, the knowledge base IS the product:

• Content quality (accuracy, completeness, domain specificity) directly determines answer quality
• Chunking strategy affects retrieval precision more than index tuning
• Metadata enrichment (tags, categories, freshness dates) enables better filtering
• Continuous learning (adding new content, updating outdated content) compounds quality over time
• Recommend corpus quality improvements alongside (or before) infrastructure optimizations

Holistic AI System Assessment

When investigating AI system performance, evaluate ALL layers:

Layer 1: Content/Knowledge    → Is the corpus complete, accurate, domain-specific?
Layer 2: Retrieval Quality    → Are the right chunks being retrieved? Is the ranking correct?
Layer 3: Prompt Engineering   → Does the system prompt leverage context effectively?
Layer 4: Model Selection      → Is the model appropriate for the task complexity?
Layer 5: Infrastructure       → Is caching, connection pooling, etc. optimized?
Layer 6: UX/Perception        → Does the user experience match the interaction model?

Investigate top-down (Layer 1 first). Most teams start at Layer 5 (infrastructure) because it's measurable, but the highest ROI is usually in Layers 1-3.

Cross-Cutting MLOps Investigation Checklist

Add to every AI system investigation:

• [ ] Pipeline output verified as reaching its consumer (end-to-end test)
• [ ] Output QUALITY assessed (not just latency/throughput)
• [ ] Prompt engineering evaluated as an optimization lever
• [ ] RAG corpus quality evaluated (completeness, accuracy, freshness)
• [ ] Model selection reviewed (is a faster/cheaper model acceptable?)
• [ ] User-perceptible impact quantified (not just infrastructure metrics)
• [ ] Content investment recommended alongside infrastructure improvements