OpenFactory is Now an OpenClaw Skill

We just published the OpenFactory skill on ClawHub. Install it in OpenClaw, and your AI agents can build custom Linux ISOs, spin up VMs, run compliance tests, and download the finished images — all through conversation.

What This Means

OpenClaw is an open-source AI agent framework that connects LLMs to external tools through skills. A skill is a structured document that tells the agent what tools are available, how to authenticate, and what workflows are possible.

OpenFactory already exposes a full MCP (Model Context Protocol) server with 19 tools for building ISOs, managing recipes, running tests, and controlling VMs. The OpenClaw skill documents all of these tools in a format that any OpenClaw-connected agent can understand and use.

An Agent That Builds Its Own Infrastructure

For most of its short history, an “AI agent with tools” has meant an agent that reads APIs: search the web, query a database, send an email. The interesting frontier is agents that produce infrastructure rather than just consume data — agents that can compile an operating system, boot it, and check that it works. That is a different kind of loop, and it only becomes practical when three things are true: the agent can describe what it wants in natural language, it can act through a stable tool interface, and it can observe the result well enough to decide what to do next.

MCP is what makes the second condition portable. Introduced by Anthropic in late 2024 and now an open standard adopted across the major agent runtimes, MCP defines a single way for a model to discover tools, read their schemas, and call them. Expose your capability once as an MCP server and every compliant client — Claude, Cursor, Windsurf, OpenClaw — can drive it without a bespoke plugin. OpenFactory's build, test, and VM tools are exactly that surface. The skill simply packages them so an agent knows the recommended order of operations.

What the Agent Can Do

With the OpenFactory skill installed, an agent can handle the full lifecycle:

• Build — Create a custom Linux ISO from a recipe. Pick a base (Debian, Ubuntu, Fedora, openSUSE), add features (SSH, Docker, desktop, AI tools), configure users, networking, and security.
• Test — Spin up the ISO in a VM and run automated tests: boot verification, package checks, network connectivity, service health, CIS benchmark compliance.
• Deploy — Create VMs from built ISOs, take screenshots, get console access. The agent can visually verify the desktop, check running services, and interact with the system.
• Iterate — If tests fail, the agent can inspect results, modify the recipe, and rebuild. Templates and recipe validation catch issues before the build even starts.

Install It

If you already have OpenClaw running:

openclaw skills install ziegenbalg/openfactory

Or browse it on ClawHub.

Example: “Build Me a Docker Server”

Tell your agent:

“Build me an Ubuntu server with Docker and SSH. Add an admin user. Run tests to make sure it boots and Docker works. Give me the ISO download link.”

The agent will call create_build with the right recipe, poll get_build_status until it's done, run tests with run_tests, check results, and hand you the download URL. No clicking through UIs, no writing YAML.

Why MCP

MCP is becoming the standard protocol for connecting AI agents to external tools. Instead of building custom integrations for each agent framework, we expose one MCP server and any MCP-compatible client can use it — Claude Desktop, OpenClaw, Cursor, Windsurf, or anything else that speaks MCP.

The OpenFactory MCP server runs at build.openfactory.tech/api/mcp/sse over SSE transport. Authenticate with an API key (generate one in the console) or use session tokens for guest access. Prefer a terminal? The same operations are available through the openfactory CLI, which is handy when you want a scripted agent or a CI job to call the build engine without an interactive model in the loop.

Why The Feedback Loop Is The Point

Plenty of tools can start a build. What makes an agent useful is that it can read the outcome and decide what to do next. The OpenFactory tools are designed so the model never has to guess: get_build_status reports progress, get_test_results returns structured pass/fail data with logs, and the desktop tools let the agent take a screenshot of the booted VM and literally look at the result. That closes the loop drawn above: describe, build, boot, observe, refine.

Recipe validation tightens the loop further. Before a build even starts, the agent can call validate_recipe to catch a missing package or an impossible combination of features, so it spends its compute on real failures instead of typos. This matters because autonomous build loops can otherwise burn time and money retrying the same broken configuration — the cheapest failure is the one the agent never submits.

Give The Agent A Sandbox, Not Your Server

An agent that can build and boot operating systems is powerful, which is exactly why it should run somewhere disposable. The image it produces is also the image it can be confined to: build a minimal VM with only the runtimes the task needs, run the agent inside it, and destroy it when the job is done. We make the full case for this in Give Your AI Agent a Computer — Securely, but the short version is that hardware-isolated, throwaway VMs keep a compromised or confused agent from touching anything you care about. The same OpenFactory that the agent calls to build images is the tool you use to build the box it lives in.

Quick Questions

• Do I need OpenClaw specifically? — No. OpenClaw is one MCP client and the skill is convenient there, but any MCP-compatible agent can call the same OpenFactory tools, and the CLI works with no agent at all.
• What stops the agent from running up a bill? — Validate first, and scope the agent's API key. Builds and test runs are explicit tool calls you can review in the console, so there is an audit trail of exactly what the agent asked for.
• Can it really tell whether a build worked? — Yes — that is what run_tests and the screenshot tools are for. The agent verifies boot, services, and CIS-benchmark checks rather than assuming success.

What's Next

This is just the beginning. We're working on:

• Agent containers — Deploy entire teams of AI agents as systemd-nspawn containers inside a single VM, with inter-agent communication over local email (Postfix/Dovecot).
• Build verification — Agents that can verify build integrity, generate SBOMs, and check compliance standards automatically.
• Multi-agent workspaces — Org structures where each role (QA engineer, security auditor, DevOps lead) is an AI agent with its own persona and tool access.

Install the skill on ClawHub →

View the source on GitHub →