Skip to main content

Builds

The Builds feature allows you to create versioned snapshots of your agent workflow. Each build captures the current workflow configuration, including all connected nodes, settings, and relationships, and packages it into a deployable version.

Every build is assigned a unique version number, allowing you to track changes, manage multiple versions, and safely deploy updated agent workflows.

Why Use Builds?

Builds help you:

  1. Create versioned snapshots of your agent workflow.
  2. Track changes made over time.
  3. Validate workflow configurations before deployment.
  4. Maintain a history of workflow versions.
  5. Publish stable versions of an agent.
  6. Restore or compare previous versions when required.

Creating a Build

tip

You can create a build in either of the following ways:

  • From the Workflow page by clicking Build after completing your workflow configuration.
  • From the Builds tab by clicking New Build.

To create a build:

  1. Open the required agent.
  2. Navigate to the Workflow page or the Builds tab.
Figure 1: Click on build

Figure 1: Click on build

  1. Click Build (from the Workflow page) or New Build (from the Builds tab).
  2. Enter the following information:
    • Build Name
    • Description (Optional)
Figure 2: Create Build

Figure 2: Create Build

  1. Click Build.

During the build process, Agent Lab validates the current workflow configuration and generates a new version of the agent.

note

Creating a build from either the Workflow page or the Builds tab produces the same result. Both options create a new version of the current workflow configuration.

Publishing a Build

Once the build has been successfully created, click Publish to make it available for deployment.

When you publish a build:

  1. The selected build becomes the active version of the agent.
  2. The previously published build is automatically marked as Deprecated.
  3. If an Agent Pool does not already exist, one is automatically created for the published build.
  4. The Agent Pool is displayed on the Scaling page, where you can manage deployment and runtime settings.
Figure 3: Publish Build

Figure 3: Publish Build

note

After publishing, navigate to the Scaling page to view and manage the associated Agent Pool. From there, you can deploy, monitor, or update the pool configuration as needed.

Build Versions and Status

Build Versions

Every successful build creates a new version of the agent. Each version represents a snapshot of the workflow configuration at the time the build was created.

Version numbers are assigned automatically and increment sequentially with every new build.

For example:

BuildVersion
First Buildv1
Second Buildv2
Third Buildv3
Fourth Buildv4
......
Nth BuildvN

There is no limit to the number of builds you can create. Each new build generates a unique version, allowing you to maintain a complete history of your agent's workflow.


Build Status

Each build displays its current status.

StatusDescription
DraftCThe build has been created but is not yet completed.
BuiltMThe build completed successfully and is ready to be published.
PublishedThe build is currently active and available for deployment.
DeprecatedThe build has been replaced by a newer published version.
FailedThe build could not be completed because of validation or configuration errors.

Managing Builds

The Builds page is your central hub for managing all builds created for the selected agent.

Building & Versioning

  • Create new builds to capture workflow changes
  • View build versions to access your complete build history

Monitoring & Discovery

  • Monitor build status in real-time
  • Filter builds by status to quickly find what you need

Deployment & Cleanup

  • Publish completed builds to activate them for deployment
  • Retry failed builds without starting from scratch
  • Delete unpublished builds to keep your build list organized
Figure 4: Builds Page

Figure 4: Builds Page

Viewing Build Details

Selecting a build displays additional information about that version.

Identification & History

  • Build Name: User-defined identifier for the build
  • Build Version: Unique version number (auto-assigned)
  • Created Date and Time: When the build was created

Configuration Details

  • Build Status: Current lifecycle state
  • Build Description: Optional notes or change summary

Quality Assurance

  • Validation Messages: Build validation results
  • Errors and Warnings: Issues requiring resolution
Figure 5: Build Details

Figure 5: Build Details

Before Publishing

Review the build details before publishing to ensure that the workflow has been built successfully.

When Should You Create a New Build?

Create a new build whenever you make changes to your workflow, including:

  1. Adding or removing nodes.
  2. Updating prompts.
  3. Changing model configurations.
  4. Modifying memory settings.
  5. Adding or updating Tool Connectors.
  6. Configuring Data Type nodes.
  7. Updating Media nodes.
  8. Modifying Knowledge Base settings.
  9. Adding or updating Skills.
  10. Changing workflow connections.

These changes are included in the agent only after a new build is created.

note

Changes made only to Scaling settings, such as Pool Size, Idle Timeout, or Maximum Lifetime, do not require a new build because they affect runtime deployment rather than the workflow configuration.

Build vs Publish

Building and publishing are separate operations.

BuildPublish
Creates a versioned snapshot of the current workflow.Makes the selected build the active version.
Validates the workflow configuration.Activates the build for deployment.
Generates a new version number.Replaces the previously published version.
Does not affect runtime deployment.Makes the published version available through the Scaling page.