​
Apps

Apps in agenta are individual projects. Each app is designed for a specific use case, like a chatbot or an automated summarization tool.

​
Variants

Variants provide alternative solutions for an app. Each variant is made up of two main components:

  • Codebase: The underlying code that sets the strategy for solving the problem.
  • Configuration: This includes elements like prompts, model parameters, and additional settings such as hyperparameters, tailored to the codebase.

For instance, consider you’re building a summarization application. You could employ two strategies: one using map-reduce and another based on a single prompt. For these strategies, you’d write separate codebases and create corresponding variants. Each variant would have its own codebase and a default configuration.

​
Naming Conventions

All variants adhere to a naming format: base_name.config_name. When you create your first variant, the config_name is automatically set to default.

For example, if you’ve developed two codebases for a summarization app, your initial variants would be named mapreduce.default and oneprompt.default.

​
Updating Configurations

You can add multiple configurations to an existing variant. If you wish to experiment with different settings for the map-reduce strategy, simply create a new configuration and name it mapreduce.newconfig.

​
Database Schema

The database schema consists of four key objects:

  • App: Holds the appid (e.g., app123) and app_name (e.g., “Summarizer”).
  • AppVariant: The main object that contains detailed information about an app.
  • Base: Contains details about the codebase for a variant. Multiple variants can share the same base but have different configurations.
  • Configuration: Stores specific parameters for a variant.

Note: An AppVariant is associated with an App and can have multiple Base and Configuration objects linked to it.

​
Creating an App

You have two options for creating an app:

  1. From the UI: A backend call generates both the app and its default variant. This variant will use a base from the chosen template and begin with an empty default configuration.

    • Endpoint: POST /apps/app_and_variant_from_template
    • This triggers the backend to add a variant based on the selected image and start it. The URI and state of the Base are saved in the Base object.

  2. From the CLI: Run agenta init to create an app without any variants.

    • Endpoint: POST /apps/
    • Provide the app name to get an app ID in return.

​
Creating a Variant with a New Base

  1. From the UI: The process is identical to creating an app from the UI.

    • Endpoint: POST /apps/app_and_variant_from_template
    • This action will add a variant based on an image and then start it. The URI and state of the Base are stored in the Base object.

  2. From the CLI: Use agenta variant serve to create or update a variant. This also creates or updates the base and sets an empty default configuration.

    • Endpoints:
      1. POST /containers/build_image
      2. POST /apps/{app_id}/variants/from-image
      3. PUT /variants/{variant_id} (status: start)
    • The last step saves the URI and state of the Base in the Base object.

​
Creating a Variant with a New Configuration

  1. From the UI: Fork a variant to create a new one.

    • Endpoint: POST /variants/from-base
    • Payload: base-id, config_name, parameters, overwrite
    • Returns a new variant ID

  2. From the Code: Push a new configuration to an existing variant.

    • Endpoint: POST /variants/from-base
    • Payload: base-id, config_name, parameters, overwrite
    • Returns a new variant ID

  3. From the CLI: Use agenta config push to add a new configuration.

    • Endpoint: POST /variants/from-base
    • Payload: base-id, config_name, parameters, overwrite
    • Returns a new variant ID

To determine where to make the endpoint call, the URI of the container and its status should be included in the response from GET /variants.

Was this page helpful?