Export a space

You can take a portable copy of a space's workflow configuration — its task types, checks, rules, pools, workers, and the workflows themselves — as a single JSON document. You read that document to stand the same configuration up elsewhere, by making the ordinary configuration calls yourself. There is no import that applies it back, and this guide is plain about that from the start.

You do this over the Model Context Protocol endpoint, with one tool: space_export. For the exhaustive shape of what comes back, see Spaces, teams, and tags → Export a space.

Before you start

Exporting a space needs read on it — any member can do it, so it is not admin-gated. See Authentication. This guide uses the example space key OPS.

Decide which workflows you want to export. The export covers the workflows you name and everything they depend on, so name every workflow whose configuration you want to carry.

Export the configuration

Call space_export with the space key and a non-empty list of workflow slugs:

// space_export
{ "space_key": "OPS", "workflow_slugs": ["delivery", "triage"] }

You must name at least one workflow. What comes back is a single JSON reference document, under artefact:

{
  "artefact": {
    "schema_version": "2.0",
    "space": { "key": "OPS", "name": "Operations" },
    "task_types": [ … ],
    "checks": [ … ],
    "images": [ … ],
    "agent_skills": [ … ],
    "workers": [ … ],
    "pools": [ … ],
    "rules": { "assignment": [ … ], "check": [ … ], "sentinel": [ … ], "resolution": [ … ], "property": [ … ] },
    "workflows": [ … ]
  }
}

The document covers the workflows you named and everything they depend on: the task types and checks their rules use, the pools that staff their stages, the workers and agent skills those pools run, the images those workers use, all five families of stage rule — assignment, check, sentinel, resolution, and property — and the workflows themselves. Every object is named by its stable key — workflow and task-type slugs, check codes, image references, stage and stage-group names — never by an internal database id, so the document reads the same wherever you take it.

There is no import

Read this before you plan to rely on the export. space_export produces a reference document, not a machine-applied import. Cadence has nothing that takes the document back and rebuilds a space from it. To replicate a space, you read the document and re-issue the ordinary configuration calls yourself — creating the task types, registering the checks, standing up the pools and workers, and writing the rules — in the destination space. Nothing happens on its own: the export is what you read, and the configuration calls are what you run.

When you re-create an agent worker version, give it the llm_vendor, model and effort the export shows for it. An exported version carries llm_vendor and effort only when they were set. If it shows no llm_vendor — an older version made before vendors were required — choose one, or the draft is refused with Llm vendor must be chosen (…).

An older export's model may no longer be defined for its vendor, or may since have been deprecated, and its effort may no longer be one the model lists. The draft or the publish is then refused. Most of these refusals name what you can choose instead; two effort refusals do not. … can't be set: "<model>" defines no efforts means the model takes no effort, so leave effort out. … can't be set: "<model>" has no defined efforts for <vendor> means the model is not defined for that vendor, so choose a model that is. Before you re-create the version, call llm_models_list for the vendor and check that the model is listed, is not deprecated, and lists the effort. See Fleet § What a draft refuses and What publishing refuses.

The destination also needs an account registered with that vendor holding a token Cadence can serve: in the destination space, or, only if that space has no registration of the vendor, for the whole instance. Without one, the re-created pool's workers do not start, and each task they lease is held until a person fixes the token and clears the hold. See Hold a task and clear a hold § 3. Tokens never appear in an export; you enter them in the browser. See LLM providers.

What the export refuses

An export must name a real workflow, be able to resolve every image it references to an exact pinned version, and find every worker and agent-skill version a live pool pins ready to run. When it cannot, the whole call is refused with the reason and nothing is exported:

• a workflow slug that is not in the space is refused — unknown workflow slug "widgets";
• an image that cannot be resolved to an exact pinned version is refused, and every such image is named at once so you can fix them in one pass;
• a live pool that pins a worker or agent-skill version that is not ready — one that was archived, or never left draft — is refused, naming the pool and the version so you can re-pin a ready one.

Fix what the refusal names and call space_export again.