Skip to main content
Welcome back to the whiteboarding session. This article updates an earlier architecture: we’ve removed unused pieces and redesigned the flow to reflect recent decisions. The goal is to centralize tool interactions through an MCP server and run agent orchestration with LangChain. What changed
  • Removed: cURL and the Supergateway layer.
  • Added/kept:
    • MCP as the tool endpoint for Kubernetes.
    • An LLM provider (diagram shows KodeKloud; you can use ChatGPT, Claude, or another provider).
    • A Python agent implemented with LangChain to host the prompt and runtime.
    • Outputs surfaced as logs (for now).
Core components and references
A screenshot of a diagrams.net (draw.io) workspace showing a system architecture diagram. It depicts Kubernetes components (payment, search, kube-system) on the left and connected boxes on the right labeled MCP - K8 Docker, LLM - KodeKloud, Agent (Python - Prompt Langchain) and "Output format as logs" with arrows indicating data/tool calls.
How the redesign works — step-by-step flow
  1. The agent runtime (Python + LangChain) formats a prompt and sends it to the LLM.
  2. The LLM returns a decision that includes a tool choice (for example, “call MCP to list pods”).
  3. The agent runtime interprets that decision and issues the corresponding tool call to the MCP (the runtime performs the actual request).
  4. MCP forwards the request to the Kubernetes cluster and later returns the callback/result to MCP.
  5. MCP returns the result back to the agent runtime.
  6. The agent runtime either:
    • passes the result back to the LLM in the next prompt/turn for further reasoning, or
    • uses the result locally to continue orchestration, then prints the outcome as logs.
Note the iterative, conversational pattern: the LLM suggests actions and the runtime executes tools and manages returned data. This centralizes external access through MCP and keeps the orchestration logic inside the LangChain-based agent runtime. Component responsibilities (quick reference)
  • The agent runtime is implemented with LangChain and contains both the prompt and the orchestration logic.
  • MCP serves as the tool endpoint for interacting with Kubernetes and is shown running via Docker.
  • For now outputs are surfaced as logs; the output format can be extended later (e.g., to dashboards, databases, or monitoring systems).
Next steps
  • In a follow-up article we’ll focus on extracting accurate labels and metadata from the Kubernetes cluster and how to surface that information into the agent’s observations and prompts.
  • Consider which LLM provider best fits your operational constraints and cost model; the runtime design keeps the LLM provider pluggable.
See you in the next lesson.

Watch Video