# Fuzzball 4.2: AI Agents Can Now Run HPC Jobs via MCP > Source: > Published: 2026-09-07 23:08:35+00:00 CIQ shipped Fuzzball 4.2 on September 3 with a native MCP server, and the implication is straightforward: any AI agent that speaks Model Context Protocol can now inspect, submit, and monitor HPC jobs directly. No ticket queue. No ops handoff. Your agent submits the fine-tuning run, Fuzzball runs it, and the agent monitors it to completion. That is what agentic infrastructure looks like when the plumbing is actually finished. ## What Fuzzball Is Fuzzball is CIQ’s sovereign AI and HPC orchestration platform — the layer that sits between your GPU cluster and your workloads. It is container-first, multi-cloud, and designed for organizations that need to run serious compute on infrastructure they control. CIQ, the founding commercial sponsor of Rocky Linux, built Fuzzball for the same audience that runs supercomputing centers and regulated AI training: enterprises and research institutions that cannot simply route everything through a hyperscaler API. ## The MCP Server: Protocol-Level Access, Not a UI Feature The key addition in 4.2 is not an AI button in a dashboard. It is an MCP server, which means agents built on Claude, Cursor, or any MCP-compatible tool now have direct programmatic access to Fuzzball’s compute layer. An agent can inspect what is running, draft a workflow definition, submit it, and monitor execution — all through standard MCP tool calls. The permission model is tiered by design. Read access is open to agents. Write and execution access require explicit operator permission. Destructive actions are locked behind a separate permission level entirely. Every agent operates within boundaries an operator configures in advance. This is worth noting because most “AI-enabled” infrastructure tools bolt an AI assistant on top and call it agentic. Shipping an MCP server is different: it slots Fuzzball into the same protocol graph as your databases, APIs, and developer tools — places agents already operate. ## Self-Service Workflow API: Jobs That Spawn Jobs The second major change is less obvious but arguably more consequential. In Fuzzball 4.2, running workflows can call the Fuzzball API themselves. Every job and service container receives a workflow-scoped API credential and the cluster API address at startup — auto-injected, no configuration required. A running training job can submit its own evaluation suite when it finishes. An inference server can spin up preprocessing jobs it needs. A workflow becomes an orchestrator. The practical effect is that agentic compute pipelines are now possible entirely within the HPC environment. No shared secrets. No long-lived tokens. No external orchestration layer needed for dynamic job graphs. The workflow credential is scoped to that workflow and expires with it. ## AMD ROCm and Multi-Tenant Controls Fuzzball 4.2 adds AMD ROCm support, making the platform hardware-agnostic across both Nvidia and AMD GPU pools. Organizations running mixed GPU environments — increasingly common given Nvidia supply constraints and AMD’s MI300X momentum — can now schedule workloads across both without separate orchestration setups. Per-workflow accounting tracks compute, storage, and network egress, and node health scoring moves jobs off degraded hardware automatically. The multi-tenant controls fill a practical gap for enterprises. Multiple teams can share one large GPU environment with enforced storage isolation, per-team placement rights, and separate access controls. One cluster. Many teams. No shared state between them. ## Why This Matters Now MCP has moved fast. As of July 2026, [78% of enterprise AI teams have MCP-backed agents in production](https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol), and the official registry lists over 6,400 servers. The protocol has become the connective tissue of the agentic stack. What Fuzzball 4.2 signals is that HPC compute — historically inaccessible without specialized knowledge of Slurm, modules, and job schedulers — is joining that stack as a first-class participant. The trajectory is clear: infrastructure vendors are not adding AI features. They are becoming MCP endpoints. Fuzzball is one of the first HPC platforms to make that move at the protocol level. If your agent can already read from your database, write to your project management tool, and query your observability stack, there is no reason it should not be able to submit a fine-tuning job or a batch inference run to your compute cluster. [Fuzzball 4.2](https://ciq.com/blog/fuzzball-4-2-ai-agents-that-drive-fuzzball-and-workflows-that-submit-workflows) closes that gap. ## Key Takeaways - Fuzzball 4.2 ships a native MCP server: any MCP-compatible agent can now inspect, submit, and monitor HPC jobs under operator-defined permissions. - The self-service workflow API lets running jobs spawn additional jobs using auto-injected, workflow-scoped credentials — enabling dynamic compute pipelines without external orchestration. - AMD ROCm support, multi-tenant organization controls, and per-workflow resource accounting make 4.2 a practical upgrade for mixed GPU enterprise environments.