Documentation

Overview

Botworx is an automation developer workspace that can be used to drive automation using Artificial Intelligence. Developers can define and implement automation programs via configurations in Botworx then invoke them to drive AI-based automation.

The environment allows developers not only to configure automation programs but also to develop, test, and deploy the tools that help drive the automation programs. With Botworx automations, you just create an automation configuration and start building out the necessary capabilities, with no other complex setup required.

In Botworx, every automation program is powered by a configuration. This configuration is a sort of executable that, when invoked, can compose instructions dynamically, integrate context, use tools, invoke AI models, and invoke other automation programs.

Installation of an automation program means simply creating the necessary configuration that defines the automation.

Note that Solvent-Botworx is built on top of the rest of the Solvent platform, consult other product documentation for specific features.

Key Capabilities

• Supports leading model APIs and custom integration, including locally hosted models
• Programmatic instruction composition, including based on UI options and flags
• Full access to the file system for integrating files and directories for instruction context
• UI Control of AI tool and assistant availability
• Out-of-the-box implementation of 20+ automation programs for coding assistance and low-code web app development.
• Ability for developers to build their own custom automation programs and tools, meaning limitless automations.
• Ability to chain automations together and drive Agentic AI automation.
• Multi-modal integration.

Work Sessions & Prompt Management.

Work session are the main organizing construct for AI work in Solvent. think of it as a chat window session. A developer can create and work on a many sessions simultaneously. Each session instance is tied to a specific model.

Prompt Management.

Developers cannot only issue prompt to sessions but can define prompt and reuse them. The support for prompts includes support for parameterizing prompts in ways that support RAG based workflows. This parameterization is fully programmable by the developer with minimal effort.

Prompt management relies on the Solvent-Configr object modeling technology, thus making all the capabilities of that platform available for creating prompt and AI solutions.

Botworx Configuration

Every user profile gets a copy of a baseline Botworx configuration in the user home directory. Developers can build their automation programs off this local configuration.

There is a system-wide configuration that is dynamically integrated into the runtime behavior of Botworx. Automations developed to serve all users can be installed within the system profile (i.e., sysadmin user) and will be automatically made available to all users.

In other words, Botworx configurations, like other Solvent module/plugin configurations, are inheritable, i.e., the system-level version is the default, and a user-defined version overrides what is defined at the system level. Inheritance is done via object deep-merging, i.e., a user-specific object gets merged into any system default.

All UI components of Botworx are driven by this configuration. The sessions that users create are stored as part of a user's configuration. Unlike automation programs, session information is meant to be local (per user account) and transient.

Model Authentication

Model provider authentication is per user, i.e., each user must specify their own credentials in the appropriate aiProviders{} object entries.

If system-level credentials are in effect and a user does not override them by defining aiProviders{} object entries, then that will be used at runtime.

For example, if credentials are specified for an Anthropic provider in the system user profile and a developer user does not define a replacement for it, then the system-defined one can be referenced and used without the developer having to specify their own credential. This is an easy way to allow all developers or automation programs on a system to use a shared credential.

Automation Programs

Botworx implements the concept of automation programs, this is a conceptual combination of AI model capabilities, tools (implemented in Solvent dev environment) and access to the Solvent platform (including file system) to drive automation.

Developers build these automation programs and Botworx facilitates the development, testing and deployment of these programs. "Agents" is another AI jargon that could be used to describe automation programs.

Automation programs are defined via configuration entries under an appropriate category within the automations{} object. There is a template automation program that developers can copy as a starting point for a new program. It is important to ensure all automation programs have a unique sourceId (this is the true identifier of the program) and id (this is changed per runtime invocation) defined and given an appropriate name.

Instruction Composition

Automation programs rely on instructions (aka prompts); these instructions can be composed via partial instructions to build complex instructions sent to models. Botworx offers full programmability both in terms of the tools that the automation programs have access to and the ability to include dynamic access to code inside instructions. Instructions are evaluated within a context that exposes the following objects for programmatic interaction:

• aiInterface:

  An object that exposes the Botworx implementation and offers APIs for invoking other automations and interacting with models. This represents different objects depending on if the automation is running on the frontend or backend.

• config:

  This is the evaluated form of the Botworx config, giving programmatic access to the Botworx configuration.

• session:

  The session within which an automation is being invoked.

• appBuilder:

  For the frontend, this object is a "god" object that provides access to the Solvent platform, see further documentation. When an automation is invoked to run on the backend, this is always null as there is no backend equivalent, but there are other APIs for accessing backend capabilities.

• prompt:

  This is the evaluated form of the currently executing automation.

• aiImplPlugin:

  This exposes various APIs to support tools. While backend and frontend implementations of this object are different, the APIs exposed are the same for both.

• tools:

  List of tool implementations accessible to the automation, see section on how tool access resolution is done. This is just the output from calling aiImplPlugin.getToolImpls.

Programmatic instruction composition allows for embedding instructions in ${config.shared.additionalInstructions.moreInstruction} to access additional capabilities, including access to other instructions via access to the core configuration objects.

There is a config object available during the composition of instructions that can be used to access other configuration objects, including additional instructions. These can allow for conditional instructions control via UI options when users invoke an automation program. The "config" object has a set of shared objects that are used by automation configurations.

Execution Environments

The Botworx solution supports using both frontend (browser) and backend (server) environments to drive automation. An automation invocation can be specified to be executed either on the frontend or the backend.

The tools that power automation behavior can be implemented both as frontend or backend tools. The automation can be made to bounce seamlessly between backend and frontend execution depending on the tools used and executionEnvironment ("front-end | back-end") directive.

Some tools are only suitable for frontend execution (for example, opening a file in an editor), and others may be only suitable for backend execution. The platform can flexibly accommodate the mix within a given automation or even between automations (when automations are chained via assistants).

Automation Scheduling

Automation programs can be scheduled to execute as long-running tasks. Developers specify the task schedule arguments in the taskSchedule{} config object.

All scheduled automation programs run in the backend environment and will automatically start when the system is started. The UI also supports the start/stop of automation program tasks.

Not only can automation programs run in the background on the server, but they can also interact with the clientside if a tool call is invoked that is intended for frontend execution and an active frontend session is available. This can facilitate the implementation of assistants that implement monitor-and-report type functionality while the human user is logged in working within the Solvent environment.

There are also some general schedule settings available via the object shared{}/miscSettings{}/taskSchedule{}.

• threadPoolSize:

  Set to the number of threads to initialize the Execution service; this is for the JDK platform.

• enableAsyncFrontEndToolCalls:

  Set to "true" to enable async client-side tool call processing by automation task running in the background.

• websocketKeepAlivePingInterval:

  Set to control ping frequency to maintain websocket connection. Our testing shows this should remain at the default of 15 seconds to be effective. In the future, we will do more work to address idle timeout related to websockets.

Configuring automation task-schedule can be enabled via the taskSchedule{} directive.

• seqGroupId:

  Represents a group ID for a set of automation tasks that must be run in sequence.

• sequenceNumber:

  If an automation task is part of a sequence group, this number indicates their position in the sequence.

• useSessionProfile:

  A session profile to run this automation task against; otherwise, it defaults to the same as the automation configuration value.

• period{}:

  This option defines the frequency and interval for running the automation task.

• sleepInterval:

  The interval between runs.

• runLimit:

  When specified, it indicates how many times the task must be run before it is unscheduled. If omitted, the task is run indefinitely.

• scheduleHandler{}:

  This is optional, but if specified, it can be an object ({"script","scriptType"}) or a path to an executable. This will be invoked on every schedule run to determine if a task must be run. If it returns "terminate," the task is unscheduled and no longer considered for subsequent runs. If it returns "skip," the task is skipped for the current run. Otherwise, the task is run per configured settings.

  This handler is supplied an argument called "task," which represents a task object with getters for the taskSchedule{} object properties.

Tool Integration

Out of the box, Botworx comes with the following core tools built-in shared{}/tools{}/available{}. Beyond the built-in tools, developer-supplied tools can be integrated by implementing the tool integration interface.

Below are the tool implementation interfaces for both backend and frontend tools:

• LightWeightToolImpl.js
• LightWeightToolImpl.ste

Each implementation must also provide a tool definition configuration in the following format for all the tools/functions exposed by the integration: tool-defs.json.

In addition to exposing tools, each implementation can also expose automations that can be used as assistants. To expose assistants, the implementation must provide an assistant definition configuration in the following format for all the automations exposed by the integration: assistant-defs.json.

For tool definition, Botworx standardizes on the OpenAI format, meaning specifying tools/functions must be in the OpenAI format regardless of the actual model provider used. The Model provider-specific implementation is responsible for converting from the OpenAI format to its own format.

Developers can write Java, Groovy for back-end tools and JavaScript (plus TypeScript via transpiling) for frontend code.

There are two primary ways to make tools available to automation programs: one by creating a RADKit project and implementing your tooling functionality in the project, and the second by pointing to local (per user account) code either inline within the automation configuration or by specifying a path to the implementation.

RADKit projects can be installed system-wide, thus their tools can be made available to all users on a system. For local tools, if it is inline within a configuration, then it is, of course, only available to the automation program it is defined on. If it points to a file, then it is accessible only for the user whose home directory the file is located in.

An automation program configuration can use the directive useToolImplPlugins[] to provide access to developer-provided tools. The entries of this directive can be either:

1. A string that references tools defined in the shared tool registry shared{}/miscSettings{}/toolImplPlugins{}.
2. An object that contains either an inline tool integration or points to an external file.

For core tools, they are all defined in shared{}/tools{}/available{}. The core tools that are accessible by default are specified in shared{}/tools{}/defaults{}. For core tools not accessible by default, they can be imported into an automation program by specifying them in the config apiRequest{}/tools[].

In other words, the useToolImplPlugins[] directives and apiRequest{}/tools[] list and the shared{}/tools{}/defaults{} set form a union of the set of tools available to the automation program.

Additionally, this available set of tools can be overridden with a directive toolSetOverride[], which is a list of tool names explicitly specified that must be used in lieu of the aforementioned union.

Assistant implementations are similarly referenced via useAssistantImplPlugins[] directive, see the section on assistants for details.

UI and Server Tools

In addition to the two primary means for specifing tools noted above, tools can also be defined as either ui targeted tools and speicified in /uiTools{} or defined as server based tools and specified in /serverTools{}.

/uiTools{} are implemented as methods in the vuejs implementation of automation assistants, meaning the method name should be equal to the name of tool defined above and entered in /uiTools{}. A name property must be set as name for the corresponding property entry in /uiTools{}.

/serverTools{} are implemented as Java classes to match the interface noted above (LightWeightToolImpl.ste). A name property must be set as name for the corresponding property entry in /serverTools{}. Server tools must also specify a handler property with fields scriptType and script, the script field specifies the code of the implementation class.

/serverTools{} are simply an additional mechanism for implementing backend tools.

Note that for both /uiTools{} and /serverTools{}, the tool must still be defined for inclusion in the model request just as any other tool.

Assistants

Assistants are automation programs exposed to other automation programs. For instance, an automation program that writes code can be used by another automation program that needs to have code written for it.

An automation program representing a doctor can use an assistant that reviews a medical image and provides diagnostic information.

These assistants are an additional form of tooling available to automation programs and are exposed in the configuration in a similar fashion. See shared{}/assistants{} for examples of how to declare an automation as an assistant. Once an assistant is declared, it can be referenced within an automation either via the useAssistants directive or the assistantSetOverride directive.

Passing arguments to assistants is done via directives invokeContextData, copyActiveContextData, invokeContextDataOverride, and the "context" of the invocation.

• invokeContextData:

  This maps to "invokeContext.contextData," meaning the values specified will override any values set as default in invokeContext.contextData of the target automation's own configuration.

• copyActiveContextData:

  When set to true, the invokeContext.contextData of the automation invoking the assistant will be copied to create the new invoke context for the target assistant invocation. If set to an array, the fields listed are the ones that will be copied.

• context:

  When an assistant is invoked, a context object is set that represents any arguments specified directly via the AI instruction. These contextual arguments will override values set via the above methods.

• invokeContextDataOverride:

  This is a list of fields that overrides the values above; in other words, this takes the highest precedence.

The following automation contains examples of how to use assistants in general: automations{}/experiments{}/tool-tester{}.

Multi-modal Automation

The Botworx environment supports multi-modal (audio, video, image, text-to-speech) model interactions. Multi-modal support is also built into the file-system access so that, for instance, models that can understand a given modality can access files for the modality and directly read in the appropriate prompt messages.

This means multi-modal automation programs can be created for both frontend and backend-oriented use cases.

Adaptive Modality Support

AI providers can be configured to seamlessly use modality support from another provider. For instance, if you are using a session set to Anthropic as the provider and you want to use voice (which, as of this writing, Anthropic does not support), you can set up the Anthropic provider to use another provider (e.g., Gemini) for speech service. This feature lets the provider that provides the modality describe the content (e.g., audio file), and that description is relayed to the referencing session.

This means the referencing session is limited to relying on the description and not able to directly interrogate the content. Each provider configuration (aiProviders{}) can specify useModel{} directives to indicate which of its own models to use for any given modality.

Additionally, it provides the useProviders{} directive to specify which alternate provider to use for a given modality. If no useModel{} or useProviders{} directive is specified and there is no model for a provider that supports a given modality, an attempt would be made to look at the other providers for an appropriate model, otherwise, an error is thrown to reflect a lack of appropriate modality support.

Automation Life-cycle Hooks

There are hooks into the life-cycle of automation execution. These hooks can be implemented by automation developers to perform actions during the processing of automation. promptProcessor{} directive can be used to hook into pre and post processing of automation invocation both on the frontend and backend.

Context Integration

Through tooling, an automation program can integrate whatever context data is needed to drive automation. The core Botworx platform exposes a set of API methods designed to make access to file system data and remote endpoint data trivial. Additionally, the fileSystemContextIncludes{} directive can be used to integrate UI support for access to context.

The entries in this directive define access to the asset tree UI so users can select files and directories, the selection along with data can then be seamlessly integrated into automation instructions as context. In concrete terms, context integration is done by including the context in AI instructions. This means referencing sub-instructions and data in a given instruction.

For automation programs, the entry point for instructions and context is the text property of the automation program configuration. From the content of text, you can reference additional context via available API and configuration objects.

Additionally, a dialogText property is available, which is used as an alternative to text. This is used to support continuous invocation of an automation program within the UI flow. If you think of text as representing the executable program "code" of the automation, subsequent invocation may not need to execute the code but rather may simply need to reuse the state derived from a previous "code" execution.

Using dialogText you can bypass "code" execution while still being able to reuse previous state to provide context to a model and drive automation. See the low-code automations for examples of how dialogText is used, typically it simply extracts the user instruction and provides that (along with the existing context) to the model to support ongoing dialogue. For async calls use the keyword botworx-await to ensure async wait in JavaScript on the frontend.

Note: We use botworx-await as a keyword because it is unique and can be replaced for backend execution with a simple find & replace on the instruction text.

Service Provider API Request Configuration

The apiRequest object represents the API request for a given model service provider (OpenAI, Anthropic, Gemini, AWS Bedrock...etc), and it can be used to specify necessary API arguments. The apiRequest/Tools[] object is where to specify tools to include in the API request, see the section on tool integration for how this tool set is ultimately determined.

API Entry Points

This is a "god" object for access to the Solvent frontend environment. We are still working on building ergonic APIs suitable for developers but for now this object provides access to Solvent for integration purposes.

Via this object you can get access to the frontend modules of the platform. It is what powers all frontend tool implementations that target parts of the Solvent platform.

Below is the platform API manifest exposed via this object along with their backend counterparts. Solvent API Manifest

This is the AI implementation, it has a frontend and backend implementation. In the manifest above, it refers to the entries with name "ai-implementation-frontend" and "ai-implementation-backend".

The Invoke Context

The concept of an invocation context is that every run of a request sent to an AI model via an automation program represents an invocation with associated settings and values. Each invocation context has an id and may have a named label (useful for conversation forking). The invokeContext{} object is a template that represents each invocation of an automation program. It contains properties that the Botworx platform is aware of:

• formTemplate
• hooks
• contextData:

  Context data represents properties/arguments that are invocation specific, for instance, the language for software assistant automation. Basically, this is where developers should define the state properties that the automation program UI relies on and other non-UI properties. This is also used to pass arguments to assistants.

Automation Program Access via Botworx UI

All automation programs are exposed via an object structure that is used to categorize them. The Botworx platform uses this structure to build out the automation access menus available in various parts of the platform UI.

Automation programs can be run in modal and non-modal form. All invocations that happen via the asset tree context menu are launched in a modal window.

Non-modal launches are in "assistant-mode", which allows the automation program to persist within an open session tab. In this mode the user can repeated interact with the program to drive automation.

Automation programs expose configuration options that allow for UI control implementation. The developer of the program has access to a VueJS template along with access to VueJS option object that they can use to plug into the program UI/UX.

The invokeContext{} object of the automation program configuration exposes a formTemplate property that can be used to implement the program UI.

The "vueConfig" property of the invokeContext{}/hooks{}/frontEnd{} object is the VueJS option that the developer can implement to plug into the automation program UI/UX.

The "mounted" lifecycle method is invoked by the VueJS lifecycle mounted, in other words the version of mounted in vueConfig is a proxy that will get called by Botworx with relevant arguments.

The signature for the mounted method of vueConfig is: async function(vueInstance,stage,prompt,promptEditor,idPrefix,appBuilder,modal)

• vueInstance:

  VueJS (Vue 2) object instance, this exposes properties such as $data,$refs etc.

• stage:

  set to "before" for when the user clicks the sumbit button to send AI instruction but before it is actually sent. Set to "after" for after AI instruction has been sent and processed.

• prompt:

  The current automation config being processed. Every new invocation (via submit button) leads to a new clone of the automation config object, it is represented by this object. This object will have a new "id" and some other feilds may be reset to the default values while other fields (ex:user defined fields) retain their value.

• promptEditor:

  The CodeMirror (v5) editor object representing the instruction input.

• idPrefix:

  This is an id prefix that can be used for assigning ids to UI elements within the browser DOM. It ensures element ids do not conflict. appBuilder: The "god" object that provides access to the Solvent platform frontend environment.

• appBuilder:

  The "god" object that provides access to the Solvent platform frontend environment.

• modal:

  An object representing a modal window, when the automation is in modal mode, otherwise null.

The executeAutomation is called before and after an instruction is sent to a model. Developers can hook into this process.

The signature for this method is: async function(vueInstance,stage,prompt,promptEditor,appBuilder,modal) The arguments are described as in the signature for the mounted method.

The vueConfig can include other VueJS options such as computed,watch ..etc

The initUIState is called to init/refresh automation program UI. This handler as the name suggest is called to initialize the UI state, it is a way for the automation program to do preprocessing (initialization) when the an automation is loaded or a state change on the underlaying automation config object necessitates a UI refresh.

As with other frontend and backend handler, it has full access to the Solvent platform, so there are no limitation as to the type initialization that can be performed. Review the out of the box automations (shared{}/lowcodrInvokeContext{}/hooks{}/frontEnd{}) that come with Solvent-Botworx to see examples of how this handler is used.

Human-in-loop Assistants

Automations can be built to support human-in-loop assistant functionality, ie the automation runs and act in the background but pulls in a human when a given task calls for it. A human-in-loop task is also a tool call like other tool calls, in addition to defining the tool, it must be specified as part of the automation's configuration as /humanInLoopTools{}.

This object can contain fields that are configurations of the form:

      {
        "appURL" : "/HumanInLoop/appserver/price-quote/PriceQuote{}.index.html",
        "appDirPath" : "/work/HumanInLoop",
        "name" : "software_license_quote_provider",
        "appLabel" : "Software Price Quote".
        "externalWindow":{
          "target":"target name",
          "windowFeatures":"name value pair of browser window features, see MDN docs"
        }
      }
    

name is the corresponding name of the model tool, it is required.

Web applications as human task tools

A human in the loop ussually also uses tools to support the automation assistant. When using Solvent based web apps as human tools, the following fields are relevant:

• appURL refers to the context path for a solvent based web app.
• appDirPath refers to a file system path (relative to user or system home dir) of the web app.
• externalWindow is specified to indicate you want the app opened outside of the Botworx environment in an external window or tab. All fields of externalWindow are optional, it can alternatively be specified as a simple boolean without the customization fields.

For Solvent web apps acting as human tools and running locally on the same Botworx instance, Botworx writes the automation assistant provided input arguments to /botworx/data/human-tasks/invocation-${aiTaskId}/input.json of the web app directory.

When the web app is invoked by Botworx, it is supplied a url parameter aiTaskId, the application should use this to read the input argument provided by the automation assistant to initialize the application state and allow the human user to complete their task. The /demos/HumanInLoop demo web app shows how the flow works.

In addition to using Solvent based web apps as human tools, custom app access can be setup by implementing the tool invocation logic directly, for instance using external apps including SaaS app.

To implement a custom tool access, implement the following method as part of your assistant frontend vuejs implementation:

• humanTaskConfig:

  Simply refers to the corresponding /humanInLoopTools{} field.

• toolCallArgs:

  Refers to the tool call arguments, these should serve as input to the external human tool.

• tool_call:

  The tool call object.

• resolve:

  This is a Javascript function that should be called back after the external tool is ready to provide output back to the assistant.

• respMsg:

  This is an output object that should be passed to the resolve function, it should set the property content as a string representing the output from the human task tool.

invokeHumanTaskTool may optionally return a window object if it launches a window or iframe tab (within Botworx), this window can be used to exchange input and output between Botworx and any launched browser app.

In order for message passing to work, an origin whitelist must be specified in /messageOriginWhitelist{}. Each property must represent a whitelisted origin and must have a property origin set to the corresponding origin. If no whitelist is specified, messaging will only work for the origin hosting the running Botworx instance or the appURL origin which is implicitly trusted.

Providing human tool input

In addition to using the file system based approach to exchanging input (and output) for Solvent web apps hosted on the same Botworx instance, window messaging can be used to exchange input/output for non-locally hosted apps.

An application can request input information via the following message:

		(window.opener?window.opener:(window.parent?window.parent:window)).postMessage(Object.assign({},{
             "messageTarget":"botworx",
             "message":"get-human-task-input",
             "args":{
                 "aiTaskId":aiTaskId
             }
         }),"whitelisted-origin");    
    

If successful, a response will be dispatched with input information via the following message:

		(this.humanTaskToolWindow?this.humanTaskToolWindow:window).postMessage(Object.assign({},{
             "messageTarget":"botworx",
             "message":"set-human-task-input",
             "args":{
                 "aiTaskId":reqEvent.data.args.aiTaskId,
                 "humanTaskArg":JSON.stringify(humanTaskArg)
             }
         }),reqEvent.origin);    
    

reqEvent is the message for the input. humanTaskArg is the tool call argument from the automation assistant that represents the input. this.humanTaskToolWindow points to the window object launched either directly by Botworx or returned from invokeHumanTaskTool, this object is attached to the vuejs instance for the automation assistant.

Providing human tool output

In order for a human task tool running as a web app to provide output back to Botworx, it must post a message similar to:

		(window.opener?window.opener:(window.parent?window.parent:window)).postMessage(Object.assign({},{
             "messageTarget":"botworx",
             "message":"set-human-task-output",
             "args":{
                  "aiTaskId":aiTaskId,
                  "humanTaskOutput":JSON.stringify(calculationObject)
             }
         }),"whitelisted-origin");
    

Incorporating Tools into an Automation Configuration

Out-of-the-box tools are defined in the object shared{}/tools{}/available{}, and those referenced in shared{}/tools{}/defaults{} are enabled by default for all automations. Within an automation, to specifically reference a tool not available by default, the tool definition object must be referenced in the array apiRequest{}/tools[].

The directive toolSetOverride can be used to explicitly set the tools available to an automation, thus overriding the above tool resolution.

As with tools, assistants can also be incorporated into automations as additional tools. See the section on assistants for details.

General Settings

There are other generic settings defined in the shared{}/miscSettings{} object. These settings include both platform level settings and setting relevant to specific automation implementations. Developers are free to use it for their own automations and create other configuration structures. Below are some general platform settings.

This indicates which setting should be used as default for AI instruction invoked from an open text editor but not via an automation program. Automation programs reference their own sessions and that takes precendence.

This is used by send_email tool, it can be used to define various settings for configuring email. By default it defines a connectionSettings{} object that can be used for configuring email connectivity.

The "sender" field represents the default sender of emails from your platform instance, you can override this via AI instructions. This object is used to configure a Solvent EmailSender executable, see platform documentation for details.

Additionally the emailSenderHandler can be set to an object that represents code that will handle the email sending, in that case the object should be {"script","scriptType"} that will be evaluated, see platform documentation for code evaluation. It can also be a string that represents the path to a Solvent executable that must be invoked to send the email.

shared{}/miscSettings{}/httpRequestHandler{} can be set to an object that represents code that will handle the http connection for the send_http_request tool, in that case the object should be {"script","scriptType"} that will be evaluated, see platform documentation for code evaluation. It can also be a string that represents the path to a Solvent executable that must be invoked to send the email.

The object uiConfig{}/modals[]/ai-prompt{} represents the base UI for all automations, both modal and non-modal. Other objects in uiConfig{}/modals[] represent modal configuration for the Solvent-Botworx platform.

Mapping Model Provider Fields

Within automations the field apiRequest is use to specify the fields that are sent to model APIs. It can also contain definitions for tools referenced by the given automation.

Because different providers have different fields and they all have different names, a mapping object can be used to define the fields for a given provider: shared{}/apiRequestArgMappings{}.

The mapped fields are extracted from the apiRequest object when a request is submitted before the request is prepared and sent to the model endpoint. The name of the map entry represents the field name within apiRequest and the target property refers to the model API corresponding field name.