Fuzzball 4.2 is out, and this release opens the platform to new types of software running with and on it. A new MCP (Model Context Protocol) server lets an AI agent operate a Fuzzball environment, under permissions you set. Every workflow is now able to reach the Fuzzball API itself, so a running workflow can submit, track, and stop more work. Alongside those, 4.2 adds organization-level multi-tenant controls, broader AMD ROCm support, and a set of reliability and platform fixes.
Driving Fuzzball… with Fuzzball
Before Fuzzball 4.2, if you wanted a running job to submit another Fuzzball workflow, you had to carry a credential into the container yourself. That meant provisioning a token out of band, embedding it in your workflow or manually setting it as a Fuzzball secret, and handling token expirations yourself. Most people did the reasonable thing and ran their controller outside of Fuzzball instead.
Starting with Fuzzball 4.2, Fuzzball workflows automatically come equipped with automatically-generated and scoped credentials that allow your workflows to access the Fuzzball API directly. A running job can submit a new workflow to continue an arbitrarily complex pipeline based on the runtime results. A long-lived service can provide an application-specific interface to high-performance computing resources. Credentials are handled automatically by Fuzzball, without a need to generate or rotate tokens manually.
You can access the API with “curl” directly, if you prefer…
curl -H "Authorization: Bearer ${FB_TOKEN}" "${FB_OPENAPI_URL}/v4/workflows"…but it’s also easy to download the CLI from Orchestrate and use it within your workflow.
wget -q -O fuzzball \
--header "Cookie: fwi.access-token=${FB_TOKEN}" \
"https://${FB_UI_HOST}/api/download/cli/linux/amd64"
chmod +x fuzzball
./fuzzball workflow list --parent "${FB_WORKFLOW_ID}"Agentic access and assistance
Fuzzball 4.2 ships an MCP (Model Context Protocol) server as part of the Fuzzball command-line interface. Point your existing AI agent at a Fuzzball environment and it can inspect what's there, draft a workflow, submit it, and monitor it while it runs (within privilege limits that you set).
# Build and submit a simple Fuzzball workflow that is at least a little more interesting than "Hello, world"? > Done — authored, validated, and run. Workflow "mandelbrot-strips" finished on stable.Putting them together
These two features can work together: part of our sovereign AI story is to host AI agents and models on Fuzzball. Now an agentic workflow, hosted on Fuzzball, can itself use Fuzzball to access arbitrary computing resources, beyond its local environment (within, of course, limits you set for your environment).
A training controller running on Fuzzball can craft an independent workflow and launch it on additional resources. A pipeline that used to drive the CLI from outside can move inside the cluster and become a workflow like any other, with the same provenance and access to the same resources as the work it manages.
For agentic workloads specifically, this lets you control what data your agent is able to access, and what actions it is able to take, without exposing the contents of your local workstation to a model-driven process, or sharing your data with a third-party cloud service.
Architecting for multiple tenants
Fuzzball 4.2 furthers our overall multi-user and multi-tenant architecture with additional organization-level storage isolation and better control over which users have access to which compute resources. This allows several teams at various levels in an organization and beyond to share one large compute environment (whether CPU or GPU) with site-local policy around data, infrastructure, and workflow placement.
Always in progress
Fuzzball 4.2 also contains initial support for node monitoring and per-workflow resource accounting. Both features are still in development, and will continue to evolve over the next several feature releases. In the end, Fuzzball will be able to schedule around flaky or failed resources, take automatic action when resources fail out from under a running workflow, and report on resource use at the workflow and stage level.
We’re excited about the new features enabled by Fuzzball 4.2, and even more by the features planned for upcoming releases: we’re working on turn-key access to AI models and agents, the ability to embed container image definitions in the workflow itself, further improving our integration with existing site resource managers, and more! We hope you’ll reach out to us about any of these or other features that interest you about Fuzzball.
Fuzzball 4.2 is available now, with a few post-release fixes already included in the v4.2.2 release. You can find the latest available documentation, as always, at https://docs.ciq.com/fuzzball.
