Create a workload

Create a workload to describe the AI capability your team wants to build. Registration records its owner and authoring settings; it does not activate a release or make the workload ready to run.

Before you start

Select the workspace where the workload will belong. You need permission to create workloads and access to an appropriate owner. Prepare its purpose, intended users, interface, and data-handling requirements. Ask your workspace administrator if an owner or required resource is missing.

1. Open the guided setup

Open Build → Workloads and select New Workload. Work through the guided steps before registering.

2. Describe the basics and interface

Enter the workload’s slug, display name, owner, and description. The slug is its stable identifier. Choose the invocation interface and complete the details needed for the intended users.

If the slug or owner changes after you have matched a sandbox, run matching again so the selection reflects the new workload identity.

3. Declare the governance requirements

Record the service lane, release lane, data classification, and whether a human decision is required. Ask the workload owner or governance administrator if you are unsure which values apply. These settings describe the intended workload; they do not activate it.

4. Find a suitable sandbox

A sandbox defines the permissions and operating limits that constrain execution.

1. Describe the workload’s data sensitivity, retrieval and memory needs, tools, external connections, and evidence needs. Where a tool-family identifier is required, use the canonical identifier shown by the platform. The HTTP Request tool uses http_request.
2. Select Find compatible sandboxes.
3. Review each candidate’s Required changes and Review before use findings.
4. Select a compatible candidate or an exact-fit baseline with no required changes. If changes are required, use Derive a workspace copy and review the proposed changes as one plan.
5. If the plan loosens permissions or limits, acknowledge that change and provide the required rationale before confirming.

A baseline with required changes, a near-fit candidate, or a blocked candidate cannot be used directly. Its required changes must pass guided derivation and rechecking first. Optional review improvements do not by themselves block a compatible candidate.

Changing the declared workload requirements invalidates the previous matching result. Run Find compatible sandboxes again before relying on an earlier selection.

While derivation is running, the setup controls and registration are locked. Wait for the result. A successful operation selects the returned sandbox version. If the result cannot be confirmed, check the workspace’s sandboxes for the submitted slug before continuing with a new slug; the current draft will not safely resubmit the unconfirmed slug.

A workload harness records the tests and checks used to assess the workload. It can remain pending while you prepare the flow and assets; generate or attach it before the applicable release policy requires it.

5. Review and register

Review the workload identity, governance requirements, and selected profiles on Review, then select Register workload. The registration action appears only on that final step.

Open the workload detail page and check the saved information. Registered means the workload record exists. Its readiness information separately shows Ready or Blocked, together with requirements such as an active release, service-lane binding, or a required human decision or connection handoff.

If setup fails

Expand Support details when reporting a failure. Include the stage, bounded error code, and request identifier if one is shown. A network failure may have no request identifier.

Next

Manage assets and versions, then prepare a release. Integrators can consult the technical workload reference for runtime authority details.