Skip to main content
Hello and welcome back. In this lesson we recap the full flow we built from the start of the session and show how each piece maps to the overall system so you can maintain, extend, or adapt it for your environment. Where did we start?
A flow diagram of a Kubernetes-based system with service boxes (booking-api, payment, search, kube-system) and a Kubernetes logo on the left. On the right it shows an agent workflow connecting an LLM and MCP/Docker to a Python "Agent (Prompt/Langchain)" that uses tagging rules, system prompts, and an issue ticket creator to send output to an issue tracker.
A quick reminder of the starting point: we observed an operational problem inside a Kubernetes cluster. Our SRE, Alina, wanted findings to become actionable instead of remaining noisy, unstructured logs. From that need we built an automated pipeline that turns cluster findings into prioritized, actionable tickets. Core capabilities we explored
  • Surface findings from Kubernetes using an MCP-based endpoint for programmatic access (see MCP For Beginners).
  • Use an LLM to analyze, classify, and enrich findings so they contain meaningful remediation and context.
  • Orchestrate the end-to-end flow in a Python agent (LangChain) to translate raw data into tracker issues.
Agent architecture — logical building blocks
  1. Rules definition
    • Tagging rules, patterns, and heuristics that classify findings (e.g., severity, component, owner).
  2. System prompt and instruction set
    • A stable, structured system prompt that shapes the LLM’s behavior for issue creation and remediation suggestions.
  3. Orchestration (LangChain)
    • LangChain acts as the orchestration layer: it sequences LLM calls, runs validation/parsing steps, and routes outputs to enrichment and posting components.
  4. Enrichment and structured output
    • Convert noisy logs into structured objects with fields such as title, description, severity, remediation steps, and links to evidence.
  5. Issue creation
    • Post the enriched findings to an issue tracker via MCP or your chosen ticketing API.
Component responsibilities (at-a-glance) How the end-to-end flow runs
  1. Findings are emitted from Kubernetes (via MCP or another collector).
  2. The findings endpoint returns raw findings to the Python agent.
  3. The agent applies tagging rules to classify and prioritize each finding.
  4. The agent invokes the LLM using a stable system prompt to enrich the finding and produce structured output (title, description, severity, remediation).
  5. The structured output is validated, optionally routed through a human review step, then posted to the configured issue tracker.
This mapping means when something breaks you know exactly which component to inspect:
  • If classifications look wrong, update the tagging rules.
  • If LLM output drifts, refine the system prompt or change the model.
  • If issues fail to post, check the issue poster integration and API credentials.
Model configuration (important)
We used the Claude Haiku model during this lesson. To switch models, update your model name in your environment configuration and restart the agent so the new model value is picked up by the running service.
Example .env entry (adjust the variable name to match your project):
Remember to restart or redeploy the service after changing environment variables. Operational tips and next steps
  • Swap the model: Test with alternative LLMs to compare cost, latency, and output quality. Update the .env and run end-to-end tests.
  • Tune rules: Add or refine tagging rules to reduce false positives and to route issues to the right teams.
  • Add observability: Log LLM prompts/responses (redact sensitive data), track ticket creation success/failure metrics.
  • Human-in-the-loop: For high-severity issues, add an approval step before ticket creation.
  • Integration choices: Connect to Jira, GitHub Issues, or other trackers via the issue poster component—ensure you store API tokens securely.
Links and references That is it for this lesson — with this architecture you can trace where findings originate, how they are enriched, and where actionable tickets are created so your SREs can focus on resolution instead of sifting through noise.

Watch Video