Demo Whiteboarding tagging rules Integration

Hello and welcome back. In this lesson we’ll take the next step: making the agent produce structured, schema-compliant output so it’s predictable and machine-parseable. Instead of a vague, one-off prompt that asks the model to “try to see if there is an owner” or to “let us know”, we’ll integrate the organization’s tagging rules and enforce a strict output format. That lets automation pipelines and downstream tools consume results reliably across teams. Why enforce structured output?

Vague prompts yield inconsistent, noisy outputs that are hard to validate or automate.
A canonical tagging-rules.yaml captures the authoritative schema for tags, types, patterns, and allowed values.
Combining that rules file with a locked-down system prompt forces the agent to return only schema-compliant results, enabling automated validation, auditing, and remediation.

Two central concepts

Tagging rules file (tagging-rules.yaml): your organization’s canonical schema and policy for tags. This file varies across orgs and defines required tags, allowed values, and validation patterns.
System prompt: an authoritative, version-controlled instruction set provided to the LLM that end users cannot override. It defines the required output format (for example, a JSON object matching the tagging schema) and how to behave when fields are unknown or ambiguous.

In the diagram below I zoom into the agent block and surrounding components to show where the tagging rules and system prompt fit.

Screenshot of a diagrams.net (draw.io) canvas showing a flowchart of a Kubernetes FinOps agent architecture with boxes labeled Agent, LLM - KodeKloud, MCP - K8 Docker, kube-system, Tagging Rule yaml, System Prompt, and Output format as logs. The editor UI with the shapes palette on the left and style/options panel on the right is also visible.

How to link tagging-rules.yaml to the agent and guarantee structured output

Supply the rules as model context
- Inject either a concise representation or the relevant subset of tagging-rules.yaml into the system prompt or as a separate tool input.
- If the rules file is large, only surface the applicable subset to keep within token/context limits.
- Prefer a normalized representation (key names, types, enums, regex patterns) that the model can apply directly.
Enforce compliance with a strict system prompt
- The system prompt must require a single structured output (e.g., JSON) and forbid any free-text outside that structure.
- Keep the system prompt short, authoritative, version-controlled, and editable only by a small, trusted team (SRE/DevOps/Platform).
- Use the system prompt to define behavior when data is missing: set required fields to null and include an errors array describing missing/ambiguous fields.

Tip: Surface only the subset of the tagging rules relevant to the resource being analyzed. This reduces token usage and keeps the model focused on what’s important.

Require and validate a strict output format
- Ask the model to return JSON that maps exactly to the tagging schema.
- Implement an automatic validation step against your schema and:
  - Accept and process valid outputs.
  - On validation failures, either return a deterministic fallback, re-run the agent with clarifying context, or flag for manual review.
- Log both the raw model output and validation results for auditing and continuous improvement.
Use model-assisted enforcement tools (optional)
- Use function-calling, output-parsers, or typed response features if your LLM provider supports them.
- Consider a small parser/validator microservice that receives model output, runs schema validation, and returns clean, sanitized results to downstream consumers.

Example minimal tagging-rules.yaml (illustrative)

# tagging-rules.yaml
tags:
  owner:
    type: string
    pattern: "^[a-z0-9._-]+@[a-z.-]+$"
    required: true
  environment:
    type: string
    enum: ["prod", "staging", "dev"]
    required: true
  cost_center:
    type: string
    pattern: "^[A-Z]{3}-[0-9]{4}$"
    required: false

Concise, enforceable system prompt (example)

You are an assistant that MUST produce a single JSON object that conforms to the organization's tagging schema described below.
- Do NOT include any text outside the JSON object.
- Always enforce types, enums, and regex patterns.
- If a required field cannot be determined, set it to null and include an "errors" array with validation messages.

Tagging schema (abbreviated): see `tagging-rules.yaml`.
Output keys: "owner", "environment", "cost_center", "errors".

User instruction prompt (example)

Analyze the following Kubernetes resource metadata and return tags according to the schema in `tagging-rules.yaml`. Return only a JSON object conforming to the system prompt.

Resource metadata:
<resource metadata or YAML here>

Expected structured output (example)

{
  "owner": "alice@example.com",
  "environment": "prod",
  "cost_center": "FIN-0123",
  "errors": []
}

Best practices and checklist

Area	Recommendation
System prompt management	Keep it short, authoritative, versioned, and editable only by a small trusted team.
Context size	Surface only the relevant subset of `tagging-rules.yaml` to reduce token usage.
Validation	Validate automatically against the schema and implement deterministic fallbacks (e.g., request human review).
Observability	Log model inputs, outputs, and validation results for auditing and improvement.
Testing	Write unit/integration tests that exercise edge cases from your tagging rules.

Warning: Never allow end users to modify or override the system prompt or the canonical tagging rules. This can introduce policy drift and enable outputs that break automation or compliance requirements.

Operational tips

Version the tagging rules file and the system prompt together so changes are auditable.
If you use regex patterns in tagging-rules.yaml, include unit tests for edge-case inputs (e.g., unusual email formats, utf-8 characters).
Consider exposing a schema introspection API for the model wrapper; the wrapper can fetch only the relevant tag definitions for a given resource type.
If your LLM supports function-calling or typed return values, prefer those mechanisms for strong enforcement of types and shapes.

References and further reading

JSON Schema overview: https://json-schema.org/
Designing effective system prompts for LLMs: https://platform.openai.com/docs/guides/system-roles
Using function calling and typed outputs (LLM provider docs): check your provider’s “function calling” or “response schema” documentation.

From this point on you are working as a prompt engineer and architect: craft system-level prompts, feed the right subset of tagging rules, and build validation logic so the agent consistently produces machine-readable, schema-compliant tags for your automation pipelines. Well, that’s it for this lesson. See you in the next one.

Introduction

The Problem Statement

Introduction to FinOps

Setting Up SkyLine Air Kubernetes Services

MCP Gateway for Kubernetes

LangChain MCP Agents

LLM Policy-Aware Label Audit

From Findings to Actionable Tickets

Demo Whiteboarding tagging rules Integration

Watch Video