This topic explains how to create and manage config and judge variations.
An AgentControl config is a resource that you create in LaunchDarkly. You can use AgentControl to customize, test, and roll out new large language models (LLMs) within your generative AI applications.
A judge is a specialized AgentControl config that uses a large language model (LLM) as a judge to evaluate responses and return numeric scores that represent quality signals related to accuracy, relevance, toxicity, or custom signals you define.
Both configs and judges use similar configuration patterns. The documentation in this topic can be used for either config or judge configuration, except where otherwise indicated. To learn more, read Custom judges.
Within each config, you define one or more variations. Each variation defines a unique combination of model settings and prompt content, using messages in completion mode or instructions in agent mode. A variation can be in one of two states: “published” or “archived.”
You can create config variations in either completion mode or agent mode:
To learn how instructions and tools are defined and used in agent mode, read Agents.
You can create variations for a config using the LaunchDarkly UI. Each variation defines a unique combination of model settings and prompt messages. In completion mode, this content consists of messages. In agent mode, it consists of instructions. You can create multiple variations in the UI at the same time.
To create one or more variations in the LaunchDarkly UI:
In the left navigation, click Agents. The AgentControl menu appears.
Click Configs.
Click the name of the config you wish to edit. a. To edit a judge, navigate to the library, then the Judges tab and click the name of the judge you wish to edit.
Click the Variations tab.

Click Add variation.
Enter a variation Name. Use this name to refer to the variation when setting up targeting rules.
Click Select a model and choose a model to use.
LaunchDarkly does not transmit any information you provide when creating a config and its variations to external models. We do not use any of this data to fine-tune or train any models. Your model selection is solely used to suggest parameter values and help you organize which messages are associated with each model. This list of available models is updated regularly. If you want us to add a new model, click the Give feedback option to share your request.
After you assign a model to a variation, click Add parameters and configure model or custom parameters for the variation. To learn more, read Add parameters.
(Optional) In completion mode, use the dropdown menu to select the message role for the first message in this variation. The default value is “system” but you can also choose “assistant” or “user.” Not all model providers support every role.
(Optional) In completion mode, enter the text of the message. You can use standard Markdown formatting within the message.
This is an {{ example }} message if you want to replace {{ example }} with some other value in your application code when an end user encounters this variation.ldctx prefix, and dot (.) notation to indicate context attributes whose values you want to use at runtime. For example, enter Describe the typical weather in {{ ldctx.city }} to replace {{ ldctx.city }} with the city attribute from each context that encounters this config.(Optional) Click + Add message and repeat steps 8 and 9 to include another message in this variation.
(Optional) Click Add tools to incorporate built-in tools into the config variation. To learn more, read Tools.
(Optional) For an AgentControl config, click Add judges to incorporate a judge into this variation. To learn more, read Judges.
Click Review and save to save the variation.
You can also use the REST API: Create config variation. The REST API supports creating individual variations only.
After creating a config and its variations, you can set up targeting rules and use the config in your SDK.
After you assign a model to a variation, an Add parameters button appears. Use this button to configure model or custom parameters for the variation.
To add parameters:
temperature or max_tokens, from the list. The available parameters vary depending on the model you select.{}).You can continue creating or editing additional variations, or complete the variation creation process:
Parameters display next to Add parameters
Any parameters you’ve added appear next to Add parameters in the variation.
You can update variations for a config using the LaunchDarkly UI. You can edit multiple variations in the UI at the same time.
To update one or more variations in the LaunchDarkly UI:
You can release a new variation gradually using a guarded rollout. Guarded rollouts reduce risk and let you monitor key metrics as the change rolls out.
You can also use the REST API: Update config variation. The REST API supports updating individual variations only.
Often, when you create a new variation for a config, you want the new variation to be very similar to an existing variation. You may only be changing the messages slightly or adjusting the model parameters. Instead of creating a new config from scratch, you can duplicate an existing config variation and make changes to the copy.
To duplicate an existing config variation:
Navigate to the detail page for the config.
Select the Variations tab.
Find the variation you want to duplicate.
Click the three-dot overflow menu for the variation and select Duplicate:

The new variation has the same name as the one you duplicated, appended with “(Copy)”. Update the new variation as needed.
Click Review and save.
Each config variation can be in one of two states: “published” or “archived.”
By default, all variations are published. You can only use published variations in targeting rules.
You can mark a variation as archived if you want to keep it for reference or comparison purposes, but no longer need to use it in targeting rules or running experiments.
To archive a config variation:
The variation moves to the archived view on the Variations tab, and its version number is incremented. If you compare the new variation version to the previous one, there will be no differences in the model configuration or variation content. The only difference between the two variation versions is the publication state.
To view archived config variations:
To restore an archived config variation:
The variation moves to the published view on the Variations tab, and its version number is incremented. If you compare the new variation version to the previous one, there will be no differences in the model configuration or variation content. The only difference between the two variation versions is the publication state.
To delete a config variation:
Changes to config variations may require approval before they take effect. For example, updating or deleting a variation value can trigger an approval workflow, depending on your environment’s approval settings. Some changes, such as adding a new variation or updating a variation’s name, do not require approval.
For information about configuring approvals, read Configuring approvals for an environment.