Build the AI solution once. Deploy it to every client environment.

You build an AI solution for one client. It works. The next client wants the same thing — but their data can never leave their network, or they run on a different cloud, or their environment has no outbound internet at all. On most platforms, that second deployment isn't a copy. It's a rebuild.

That's the tax that quietly kills deals for IT solutions companies and the regulated clients they serve. The solution was never the hard part. Moving it is.

The real dealbreaker: design and runtime welded together

Most AI platforms couple where you design with where you run. The builder and the execution engine are the same hosted service, or the engine calls back to a control plane you don't operate. Either way, the place you designed the solution and the place it executes are the same place — or close enough that you can't pull them apart.

For a regulated buyer, that coupling is the whole conversation. A bank, a hospital, or a government agency that hears "it runs in our vendor's cloud" is done listening. They need AI inside their own security perimeter — their cloud tenancy, their datacenter, sometimes a network with no route to the public internet at all.

For the consultancy serving them, the same coupling wrecks the economics. If every client environment forces a re-architecture, you're not deploying one solution to twenty clients. You're building twenty solutions. The reusable asset you thought you were selling evaporates on contact with the first deployment that doesn't match where you built it.

What MachineCraft separates — and how

MachineCraft separates the act of designing a solution from the act of running it. Today that separation lives at the code and deployment-artifact level, and it rests on two mechanisms — both real now.

A workflow is a portable artifact. Everything you build in the visual builder exports as a single JSON definition: the components, how they're wired, the configuration. That definition is independent of the environment it was designed in. It does not bake in secrets, model endpoints, or infrastructure — those are supplied by the environment at deploy time, not frozen into the file. The artifact describes what the solution does; the environment decides where and with what.

The runtime has no external dependency. The execution engine doesn't phone home, doesn't require a cloud API to function, and doesn't depend on the design environment being reachable. Once it's deployed, it runs on its own — which is exactly the property an air-gapped network demands, because there's nothing for it to call out to.

Put those together and the deployment story is plain: the same Docker image, with the same Kubernetes manifests, deploys to AWS, a private cloud, bare-metal on-prem, or a fully air-gapped network. The only thing that differs between targets is environment variables — which model endpoint to call, which credential store to read, where to write the audit log. Design once, deploy anywhere, with env-var-only differences between environments.

Walkthrough: build once for a bank, redeploy into an air-gapped agency

Make it concrete. Say you're a consultancy building a document-processing solution.

1. You design it once. In the visual builder, you assemble a pipeline on the Workflow Engine — intake, extraction, classification, routing — from the component library. Edge cases that need judgment can escalate to a reasoning step on the Agent Engine, with an approval gate where a human signs off before anything irreversible happens. (The Agent Engine and HITL approval gates are BETA; the document pipeline itself ships today. More on choosing between the two engines in Workflows vs. agents.)

2. The solution becomes a JSON artifact. When you're done, the whole thing is one portable definition. No bank-specific endpoint, no credential, no storage bucket is hard-coded into it. Those are deployment details, not design details.

3. You deploy into the bank. Same Docker image, same manifests. Environment variables point the runtime at the bank's own model endpoint, its credential store, and its storage. The audit trail writes to the bank's own system, and because the runtime never calls out, nothing about their data leaves their perimeter. (How audit and approval hold up under a regulator's questions.)

4. A government agency wants the same thing — air-gapped. Their network has no outbound internet. You take the same JSON artifact, build the same image inside their environment, and set environment variables for their on-prem model endpoint, their secrets, their storage. Nothing has to reach the public internet for the runtime to work, because it has no external dependency to begin with. No re-architecture, no second codebase. The difference between the bank deployment and the agency deployment is a config file.

The compliance machinery travels with the solution rather than living in a vendor cloud you'd have to argue about: credentials encrypted at rest with Fernet (AES-128-CBC), and an action-level audit trail built toward SOC 2 Type I and ISO 27001 / 27017 / 27018 aligned infrastructure — running inside each client's own environment, on each deployment.

Where this is today — and where it's headed

Be precise about what "separated" means right now, because a technical evaluator will check.

That distinction matters because it's the difference between a claim you can demo and a claim a buyer's architect catches in the first technical review. The portable artifact and the no-phone-home runtime are demonstrable now. The elastic, independently scaled services are where the architecture is going, not where it is.

Why this changes the math for IT providers

For a solutions company, the payoff isn't a feature — it's a business model. One solution, built once, becomes a deployable asset you can take to the next regulated client without rebuilding it for their infrastructure. The client's environment — cloud, on-prem, or air-gapped — stops being a blocker to the deal and becomes a deployment parameter. You build the expertise once and amortize it across every engagement, instead of starting over each time the network diagram changes.

That's the version of "deploy anywhere" that holds up: not a slogan, but a portable artifact plus a runtime that asks nothing of the outside world.