Building a resource optimization agent with Kubex: Patterns

The rise of large-language models (LLMs) that can understand and create text, and reason about problems has opened the door for software agents that use the reasoning power of LLMs to interact with the wider world and solve problems. At Kubex, our bread and butter is compute and GPU resource optimization, so it’s natural for us to ask how agents could help our customers more effectively optimize their resources.

Of course, the other group of people asking that question are our customers themselves. For more than a year now Kubex has provided an MCP server that allows LLMs to connect to Kubex data and recommendations, and some of our customers have been eager to take those MCP tools and use them as a foundation for their own agentic resource optimization solutions. Here are some of the patterns we’re seeing our customers use in their production systems.

Patterns

The quesiton answerer

An easy place to start is to connect Kubex MCP to your LLM of choice, such as Claude or ChatGPT. This isn’t so different from using the Kubex built-in agent, but we’re talking to more and more users who are using LLMs as a primary interface to the tools they use and the systems they manage. Have Kubex there with you! Not only can you answer questions about your resource usage and optimization potential, but you’re able to pull data from other MCP servers and wherever your data lives. Cross reference stability alerts with Kubex resource risks using an MCP server for your real-time monitoring solution. Open tickets based on Kubex optimization opportunities using an MCP server for your ticketing system. In the past, integrations like these would have required custom software development to “glue” the systems together. With an LLM, the LLM itself acts as the glue, routing appropriate requests to different MCP servers and synthesizing the results for you.

Behind the scenes, this is implemented as an “agentic loop”: the user’s prompt is submitted to the LLM, which may respond with an answer or may request the output of one or more calls to MCP tools. The client loops as long as the LLM keeps requesting tool calls, until it finally produces an answer for the user.

Bring it to your developers

Here’s a puzzle: what if the people who most need advice on resource optimization are the ones who aren’t likely to ask Kubex for help? Developers make small but impactful decisions all the time, often without enough context to know whether their choices are optimal or even good. Some organizations address this challenge by enabling the Kubex automation engine, dynamically optimizing resource usage without developer involvement. This isn’t the right choice for every situation, though: many organizations use GitOps processes that require Kubernetes resources to live in git repositories. In such an environment it often falls on developers  to update the resources in the repository.

We’re working with a customer right now who is addressing this situation by connecting Kubex to their coding agent (Cursor). This allows the agent to consult Kubex directly when defining or altering resources, and gives a way for developers to get insight without breaking their flow by forcing them to switch to a different tool. Another approach is to incorporate an agent into a continuous integration pipeline, auditing proposed changes to ensure that they are compliant with organizational policies. For instance, a pipeline can compare machine instance types in terraform resources against Kubex recommendations and reject those that are outside of organizational tolerances.

Architecturally these use the same agentic loop described previously, they just operate in more specialized contexts, as opposed to the very general approach of the question answerer. This can allow the prompt text and tool selection to be tailored to the use case which may allow for increased efficiency and reliability. Rather than rely on an off-the-shelf agentic harness, a specialized agent might be built on top of an agentic framework like LangGraph or Pydantic AI.

The whole agentic enchilada

The paradigm of a single agentic loop works for so many use cases because the flexibility of the LLM when combined with the depth of the Kubex MCP interface allows a huge variety of problems to be solved. If you can solve your problem with a simple architecture you should! However, you’re not restricted to a single agent. Using the Agent2Agent (A2A) protocol it’s possible to set up a set of cooperating agent processes, each running independent agentic loops. The agents participate in the A2A protocol by exposing “agent cards” detailing the kinds of requests they can handle, and they can communicate among themselves to solve large-scale problems. One of our customers uses agents that are specialized to different purposes (e.g., getting instance data from Kubex or from AWS) coordinated by a top-level agent that can then instruct yet another agent to propose updated terraform plans that a human can approve to realize right-sizing of cloud machine instances. Why decompose agents in this way? Isolation, primarily. Separate agents operate with their own context, their own set of tools, and their own authorizations. Encapsulating responsibilities as distinct agents allows each of those agents to specialize in a particular business problem and reduces the potential for a single agent to become confused due to lengthening context or an over-abundance of available tools.

What’s next

We want to see our customers succeed at building their own agentic systems using Kubex because we see the use and importance of agents only increasing from here. That means we’re constantly improving the ability of agents to get the information they need from our product (our “agentic experience” or AX), making our data cleaner and easier to use and introducing new kinds of data so that agents have even more relevant context. It also means helping our customers overcome the technical obstacles that can make it harder than it should be to bootstrap agentic systems.

Not only that, but we’re building out our agentic platform with a focus on more ways for our users to move from advice to action. Agents have a huge potential to take a wide variety of inputs and use them to autonomously identify unique optimization opportunities that are customized to apply to very specific customer situations. However, it’s simply not realistic to give agents the unrestricted capability to reconfigure sensitive systems, even if that’s where the biggest optimization potential is. We’re creating a framework that allows agents to surface proposed optimizations, allows humans to refine and approve the proposals, and deterministically automates the approved actions to achieve results. We’ll have a lot more to say about this framework and the thinking behind it in the near future.