Bridge Application
Bridge Configuration
A run is described by BridgeProperties. Those properties can be supplied ad hoc (query
parameters, a JSON body or CLI options), or stored as a named configuration and grouped into a
test case so the same test can be repeated and scheduled.
The model lives in common (ai.promethist.bridge), so the platform backend can read and write
configurations that the bridge then executes.
Run Properties
BridgeProperties — JSON field names are hyphenated, as shown.
| Property | Default | Meaning |
|---|---|---|
|
required |
Pipeline key of the tester agent, e.g. |
|
required |
What the tested application runs on — see Devices. |
|
Engine the tester connects to. |
|
|
— |
URL the device should open, typically an agent link ( |
|
— |
Relay service to route audio through, for device types that cannot receive it directly. |
|
empty |
Extra query strings appended to the device URI; each entry produces its own run. |
|
|
Device ref reported to the engine. |
|
|
Conversation locale. |
|
platform default |
Audio sample rate used in both directions. |
|
|
Pacing multiplier for audio sent to the device. |
|
|
Run the conversation as text, without speech synthesis. Cannot be combined with
|
|
|
Suppress the engine’s own system prompt for the tester, so only the agent’s instructions apply. |
|
|
Enable server-side speech processing (facial animation data). |
|
|
Overall run timeout in seconds. The most reliable stop condition — use it as the primary limit. |
|
— |
Cap on turns per session. Has no effect for browser tests, where the turn-end command never
arrives in realtime mode; rely on |
|
|
How many consecutive conversations the run holds. |
|
|
Seconds to wait between consecutive sessions. |
|
|
How many devices to run in parallel from this configuration. |
|
— |
Realtime configuration to force on the tester’s session. |
|
— |
The saved configuration this run came from; set automatically. |
|
— |
Identifier grouping several runs into one logical execution. |
|
|
Marks the tester’s session as test data in the engine. |
|
|
Marks the tested agent’s session as test data. Only settable where the bridge owns that connection, i.e. for a virtual device. |
|
empty |
Weights per evaluation metric, used to compute the run’s weighted average score — see Results and Evaluation. |
testMode matters: leave the defaults in place so automated runs do not pollute production
analytics and billing.
Saved Configurations
A BridgeConfiguration is a stored, named set of properties. It is polymorphic — the type
property selects the variant, which decides which fields are relevant:
type |
Describes |
|---|---|
|
A conversation against another engine session. Adds |
|
The mobile app on a BrowserStack device. Adds |
|
A BrowserStack desktop browser. Adds |
|
The web client in a BrowserStack browser, driven through the relay. Adds |
|
A real client reached over its link WebSocket. Adds |
Every variant carries the shared fields description, key, locale, deviceRef,
sessionCount, deviceCount, timeout, maxTurnsPerSession, noSystemPrompt, sampleRate,
audioSpeed, speechProcessing and testerTestMode, and converts itself to BridgeProperties
when the run starts.
Configurations are managed through the configuration endpoints.
Test Cases
A BridgeTestCase is a name plus a list of configuration IDs:
{
"id": "…",
"name": "Support agent regression",
"configurationIds": ["…", "…"]
}
Running a test case runs every configuration in it, which is how one test covers several device types or agents at once. The resulting runs carry the test case ID, so they can be listed and compared together.
Variable Groups
Configurations can be written with $VARIABLE placeholders instead of literal values. On every
run the bridge resolves them from a named variable group, selected with the variable-group
parameter (default default).
Substitution applies to key, locale, engineUrl, clientUrl, relayUrl, deviceUri and
each entry of deviceQueries. This is what lets the same test case run against different
environments and different agent refs — the scheduled test jobs in the deployment use exactly this
mechanism.