@uipath/skills 1.204.0 → 1.204.1

package/skills/uipath-maestro-flow/references/or-processes.md

@@ -1,91 +0,0 @@
-# Orchestrator Processes
-
-Orchestrator has several process types:
-
-- Agent - see [Agent](agent.md)
-- Api - see [API Workflow](api-workflow.md)
-- CaseManagement
-- Flow
-- Function
-- Process
-- ProcessOrchestration - see [Agentic Process](agentic-process.md)
-- TestAutomationProcess
-- WebApp
-
-## Finding a process
-
-List the available processes with the process type using either of the following commands, depending on if you know the folder:
-
-```shell
-uip or processes list --all-folders --process-type !!ProcessType!! --limit 200 --output json
-uip or processes list --folder-path '<folder>' --process-type !!ProcessType!! --limit 200 --output json
-```
-
-Replace `!!ProcessType!!` with the process type, e.g. `Agent` or `ProcessOrchestration`.
-
-The `list` command is paginated.
-If the output field *Pagination.HasMore* flag is true, there are more results available.
-Use `--offset` to move to the next set of results.
-
-The resulting list will have *Name*, *ProcessKey*, and sometimes *Description* fields that may help identify the process you need.
-Note that there is a flag *IsLatestVersion* in case there are multiple published versions with the same process key.
-The *Key* field (GUID) is the unique id for the process.
-
-## Getting the inputs and outputs
-
-Once you find the process, you must use the `get` command with the *Key* to retrieve more details.
-The inputs and outputs of a published process are buried in the *ArgumentsV2* field that is only exposed when using the `--all-fields` option.
-The *Input* and *Output* parameters inside *ArgumentsV2* are escaped JSON strings.
-The following CLI command can be used to extract inputs and outputs as JSON text:
-
-```shell
-uip or processes get BAADF00D-BAAD-F00D-BAAD-F00DBAADF00D --all-fields --output json 2>/dev/null \
-  | jq '.Data.ArgumentsV2 | {Input, Output} | map_values(if (. // "") == "" then null else fromjson end)'
-```
-
-Here is an example output of this command:
-
-```json
-{
-  "Input": {
-    "type": "object",
-    "properties": {
-      "productId": {
-        "type": "integer",
-        "title": "productId"
-      }
-    },
-    "required": []
-  },
-  "Output": {
-    "type": "object",
-    "properties": {
-      "status": {
-        "type": "boolean",
-        "title": "status"
-      }
-    },
-    "required": []
-  }
-}
-```
-
-The defined inputs and outputs would be represented in an action similar to the following:
-
-```ts
-.step('intake',
-  agenticProcess({
-    key: 'BAADF00D-BAAD-F00D-BAAD-F00DBAADF00D',
-    name: 'ProcurementProcess',
-    folderPath: 'Shared',
-    inputs: { productId: 1 }, // input object
-    returns: { status: 'boolean' } // output object
-  }))
-```
-
-## Notes
-
-Sometimes you need to search across multiple process types.
-For example, the **ProcessOrchestration**, **CaseManagement**, and **Flow** process types could all be considered "Agentic Processes".
-The `--process-type` filter does not accept multiple entries.
-When performing a `list` command, the default fields returned do not include *ProcessType* so you will need either to use the `--all-fields` option or run multiple `list` commands with each process type.

package/skills/uipath-maestro-flow/references/parallel-merge.md

@@ -1,21 +0,0 @@
-# Parallel / Merge
-
-Parallel fans control into two or more arms and joins them on a Merge.
-
-Signature: `.parallel(name, [armFn, armFn, ...])`; `name` identifies the Merge.
-
-```ts
-.parallel('ready', [
-  (a) => a.step('weather', http({ url: weatherUrl, managed: false })),
-  (b) => b.step('news', http({ url: newsUrl, managed: false })),
-])
-.step('combine', script({ code: 'return "ready";' }))
-```
-
-Use parallel only when the arms are independent: neither arm may require the
-other's result before the join. It expresses graph independence, not a promise
-that every executor schedules work concurrently; the local executor processes
-arms in authored order.
-
-Work after `.parallel(...)` continues from its `output` port and can read the
-outputs of each arm.

package/skills/uipath-maestro-flow/references/placeholder.md

@@ -1,70 +0,0 @@
-# Placeholder
-
-*Exact signatures, fields, and defaults: `mock()`.*
-
-A placeholder says that a real capability belongs at this point in the graph
-but does not exist yet.
-
-Signature: `mock()`.
-
-```ts
-.step('extractInvoice', mock())
-.step('continueWithInput', script({
-  code: 'return $vars.assumedInvoiceId;' }))
-```
-
-Use a real script when downstream work needs temporary fixed data; that script
-has the same behavior locally and after deployment. A script is never a
-stand-in for the capability itself (an extraction, an external service, a
-connector action). Search first, as [SKILL.md, "Choose the node before
-writing it"](../SKILL.md) says, and use the node it finds; for extraction, an
-agent, or a process, run the search exactly as the family reference gives it
-([`ixp.md`](ixp.md), [`agent.md`](agent.md)). Use a placeholder only when that
-search comes back empty; it makes the missing capability visible. Do not use it
-merely to disable a step or as the only work in a finished Flow.
-
-When `check` reports `MOCK_HAS_NO_OUTPUT` because a later step reads the mock,
-keep the mock and feed that step from a separate step, as in the example above;
-never replace the mock with a script that fakes its output.
-
-## Unknown node types
-
-`mock()` is a deliberate placeholder — a node that stands in for work not yet
-decided. It is NOT the way to carry a node the SDK has no factory for: it
-compiles to `core.logic.mock`, so the original type is gone.
-
-For that, use `rawNode({ nodeType, version, manifest, inputs? })`. It carries
-the definition the platform serves for that `nodeType@version`, so the node
-keeps its identity and its inputs:
-
-```ts
-.step('exotic', rawNode({
-  nodeType: 'uipath.exotic.thing', version: '2.1',
-  manifest: exoticManifest,        // verbatim from `registry get`
-  inputs: { where: input('scope') },
-}))
-```
-
-Two rules. **The manifest must be real** — an exact copy of what
-`uip maestro flow registry get <nodeType>` returns (after
-`registry pull --force`, since registry reads are cached). A hand-written
-manifest validates locally and fails on the tenant, which resolves the node
-against its own catalog. **Prefer a typed factory** whenever one exists: it
-carries the family's check rules, its defaults and its output contract, none of
-which a raw node can know.
-
-**Never for a connector.** A `uipath.connector.*` node type is refused by
-`check` (`RAW_NODE_CONNECTOR`) and by `compile`. A raw node keeps its inputs
-verbatim, so the emitted connector node has no `inputs.detail` and no
-connection binding: `uip maestro flow validate` only warns ("Connector is not
-configured") and the run can never reach Integration Service. Measured on the
-eval archive, every Data Fabric flow authored this way failed its checker. The
-situation that tempts it — `compile` refusing a body field as `unknown input`
-because the static library does not carry it — is what
-`uip maestro registry prepare <key> <action>` exists for (add
-`-f entityName=<Entity>` for a Data Service operation); see the
-[parent-field loop](connector-params.md#schema-dynamic-operations-the-parent-field-loop).
-
-`decompile` emits `rawNode(...)` for any node type it cannot name, hoisting the
-manifest to a `const` beside the flow. So `mock()` in decompiled source means
-the flow really contains a placeholder.

package/skills/uipath-maestro-flow/references/published-function.md

@@ -1,66 +0,0 @@
-# Published function
-
-*Exact signatures, fields, and defaults: `publishedFunction()`.*
-
-A **Function** is a small, single-purpose unit of code deployed to Orchestrator
-as its own resource. `publishedFunction()` invokes one as a single step
-(`uipath.core.function.<key>`, dispatched as
-`Orchestrator.ExecuteFunctionAsync`).
-
-Signature: `publishedFunction({ key, name, folderPath, inputs?, returns? })`.
-
-```ts
-.step('echo', publishedFunction({
-  key: '7059bdb5-fdd7-4e13-9d7b-1748aaeb129d',
-  name: 'acme-echo',
-  folderPath: 'Shared/acme-echo',
-  inputs: { message: input('message') },
-  returns: { echoed: 'string' },
-}))
-.step('relay', script({ code: 'return $vars.echo.output.echoed;' }))
-```
-
-## Identity
-
-Three fields, none of them derivable:
-
-- **`key`** — the function's GUID; it becomes the node type's suffix, so a wrong
-  one emits a node the tenant cannot resolve. Find it with
-  `uip maestro flow registry search "uipath.core.function"` (after
-  `registry pull --force`, since registry reads are cached).
-- **`name`** — the function's own name in Orchestrator.
-- **`folderPath`** — the folder it is deployed in. **A function is usually
-  deployed into a folder of its OWN name** (`'Shared/acme-echo'`, not
-  `'Shared'`). The binding's `resourceKey` is `<folderPath>.<name>`, so
-  assuming `'Shared'` points the dispatch at nothing while still validating.
-
-Two steps on the same function share ONE binding pair, exactly as the other
-published families do.
-
-## Declaring what it returns
-
-`returns` is required if anything reads the step's output. The function's real
-output arguments live on the tenant and authoring is offline, so an undeclared
-read is rejected (`FUNCTION_READ_WITHOUT_RETURNS`) — nothing here could tell a
-real field from a typo. `registry get uipath.core.function.<key>` shows what the
-platform synthesizes for a deployed one.
-
-## Which family to reach for
-
-| The deployed thing | Factory |
-| --- | --- |
-| A Function (a unit of code, its own resource) | `publishedFunction()` |
-| A coded API workflow | `apiWorkflow()` |
-| An RPA process | `rpaWorkflow()` |
-| A Maestro process orchestration | `agenticProcess()` |
-
-They share one emit path and differ only in service type and binding subtype, so
-picking the wrong one produces a flow that validates and dispatches nothing.
-Match the family the scenario names.
-
-## Evidence boundary
-
-Offline `validate` proves the node type, the binding pair and the declared
-output schema. That the function exists, accepts those arguments, and returns
-those fields is platform evidence — `.onError(...)` is supported for the
-dispatch failing.

package/skills/uipath-maestro-flow/references/queue.md

@@ -1,53 +0,0 @@
-# Queue Item
-
-*Exact signatures, fields, and defaults: `queueItem()`.*
-
-Create work on an Orchestrator queue, optionally waiting for another automation
-to process it.
-
-Signature:
-`queueItem({ queue, folderPath, key, item, priority?, reference?, deferDate?, dueDate?, wait?, returns? })`.
-
-```ts
-.step('enqueue', queueItem({ queue: 'Invoices', folderPath: 'Shared',
-  key: queueKey, item: { InvoiceId: input('invoiceId') },
-  reference: input('invoiceId'), wait: false }))
-```
-
-## Reading what the create returned
-
-The node's output carries the Orchestrator record of the item it created — `Id`,
-`Key`, `UniqueKey`, `Reference`, `Status` and the rest of the queue-item schema.
-Read a field with `out('<step>', '<Field>')`; do NOT add a script step to
-re-derive it, and do not invent a variable for the item:
-
-```ts
-.step('enqueue', queueItem({ queue: 'Invoices', folderPath: 'Shared',
-  key: queueKey, item: { InvoiceId: input('invoiceId') } }))
-.return({ itemKey: out('enqueue', 'Key') })
-```
-
-`out('enqueue', 'Key')` is the whole read. It serializes to
-`$vars.enqueue.output.Key`, the spelling the runtime resolves. A `script()` step
-that reads the node and republishes the key is longer and adds nothing.
-
-## Tenant settings
-
-Queue-level settings are not present in source. A queue may require unique
-references or enforce an item schema. Inspect it with
-`uip or queues list --all-folders`; derive a required reference from run input
-rather than using a constant that works only once.
-
-## Whether to wait
-
-Use `wait: true` only when the current Flow needs the consumer's result and a
-real automation drains the queue. Otherwise enqueue and let a separate process
-own consumption. For a waiting step, decide whether failed/abandoned processing
-should be handled or should fault this Flow.
-
-## Evidence boundary
-
-Replay uses a synthesized item/result. Live mode creates a real item and, for a
-wait, polls its real state. A green create proves the producer side only; a
-green wait also depends on the external consumer and should preserve its item
-key and terminal state as evidence.

package/skills/uipath-maestro-flow/references/return.md

@@ -1,20 +0,0 @@
-# Return / End
-
-Return ends the current path and binds the Flow's declared outputs.
-
-Signature: `.return({ outputName: expression, ... })`.
-
-```ts
-.branch('valid', out('check'),
-  (yes) => yes.return({ status: 'accepted' }),
-  (no) => no.return({ status: 'rejected' }))
-```
-
-Returning in each arm is appropriate when those paths are complete. Let arms
-fall through to a shared successor when they need common work before the final
-answer. This is different from `.terminate(...)`: Return completes its path
-with values; Terminate aborts the whole run.
-
-Any dangling tail gets an End automatically; an explicit `.return(...)` is required
-only when values must be bound. Multiple path ends are emitted as `end`, `end2`,
-`end3`, and so on.

package/skills/uipath-maestro-flow/references/rpa-workflow.md

@@ -1,27 +0,0 @@
-# RPA Workflow
-
-*Exact signatures, fields, and defaults: `rpaWorkflow()`.*
-
-Run a published robotic process and wait for its output arguments.
-
-Signature: `rpaWorkflow({ key, name, folderPath, inputs?, returns? })`.
-
-```ts
-.step('title', rpaWorkflow({ key: releaseKey,
-  name: 'RPA Workflow', folderPath: 'Shared',
-  inputs: { problemId: 123 }, returns: { title: 'string' } }))
-```
-
-## Tenant contract
-
-The release key, name, and folder must identify the same deployed process.
-Inputs and returns are that process's own argument names and exact casing; the
-offline SDK cannot discover their truth. Inspect the registry/process listing
-and the deployed contract rather than copying values from a different folder.
-
-## Evidence boundary
-
-Replay proves the graph with synthesized job output. Live evidence should show
-a real Orchestrator job, the intended input arguments, completion, and the
-returned values. Whether the robot performed the right UI/business work is a
-separate assertion from job completion.

package/skills/uipath-maestro-flow/references/scheduled-trigger.md

@@ -1,34 +0,0 @@
-# Scheduled Trigger
-
-*Exact signatures, fields, and defaults: `scheduled()`.*
-
-A scheduled trigger asks the platform scheduler to start a Flow repeatedly.
-
-Signature: `.trigger(scheduled({ every: string }))`.
-
-```ts
-export default flow('nightly')
-  .trigger(scheduled({ every: 'R/P1D' }))
-  .step('rollup', script({ code: 'return { ok: true };' }))
-  .build();
-```
-
-## Authoring judgment
-
-A timer usually has no caller, so prefer `.var(...)` defaults or tenant-backed
-steps over required caller inputs unless the deployment supplies configured
-values. Pick the interval from the business requirement rather than from what
-is convenient to test.
-
-## Evidence boundary
-
-Local execution starts the graph directly. It proves the scheduled node was
-emitted with the authored interval and that the downstream graph runs; it does
-not prove the platform scheduler fired. The scheduling claim requires a
-deployed run observed at the requested cadence.
-
-`every` is an ISO-8601 repeating interval (`R/PT30M`, `R/PT1H`, `R/P1W`) or a
-Quartz cron expression (`0 0 2 * * ?`, `0 30 9 ? * MON-FRI`). A cron `every`
-selects the trigger's 1.2 definition automatically and emits `timerValue`; an
-ISO interval stays on 1.1 byte-identically. Pinning `{ version: '1.1' }` with a
-cron expression is a compile error.

package/skills/uipath-maestro-flow/references/script.md

@@ -1,52 +0,0 @@
-# Script
-
-*Exact signatures, fields, and defaults: `script()`.*
-
-Script runs inline JavaScript for a computation that has no first-class Flow
-node. Upstream data is available through `$vars`; the result is read with
-`out(step, path?)`.
-
-```ts
-.step('normalize', script({ code: `
-  const amount = Number($vars.amount);
-  return { amount, valid: Number.isFinite(amount) };
-` }))
-```
-
-Use the named first-class node when the scenario needs a connector or HTTP for
-any external data or API call, Transform, Delay, or another product capability,
-whether or not the request names the node. A script is appropriate for
-local calculation, reshaping that needs arbitrary code, or computing a value
-before passing a bare reference to another node.
-
-Return an object literal for named fields and read them with `out('parse', 'tag')`;
-read a scalar return with `out('parse')`.
-
-## What the step publishes
-
-The node's own definition can only say `output: {type: 'object'}` — a node TYPE
-cannot know what a particular body returns — so the designer would type every
-script read as `Record<string, any>` and reject mapping one into a `string` flow
-output. The compiler therefore reads the body and declares what it plainly
-returns, so this needs nothing from you:
-
-```ts
-.step('flag', script({ code: 'return "pending-approval";' }))
-.return({ status: out('flag') })          // status: types.string — fine
-```
-
-It types, it does not enumerate: an object return stays the open object rather
-than gaining a field list, and nothing is declared unless every `return` in the
-body agrees. A body whose return type is not written down — a runtime read, a
-call — declares nothing, which is where `returns` comes in:
-
-```ts
-.step('policyLimit', script({
-  code: 'return $vars.fetchPolicy.output.body.limit;',
-  returns: 'number',
-}))
-```
-
-`returns` always wins over the body, and takes either a type
-(`'string' | 'number' | 'boolean' | 'object' | 'array'`) or, to name the fields
-of an object return, a map — `returns: { total: 'number', currency: 'string' }`.

package/skills/uipath-maestro-flow/references/subflow.md

@@ -1,33 +0,0 @@
-# Subflow
-
-*Exact signatures, fields, and defaults: `subflow()`.*
-
-Subflow packages a child Flow authored in the same source file as one parent
-step.
-
-Signature: `subflow(childFlow, { childInput: expression, ... })`.
-
-```ts
-const child = flow('normalize').input({ raw: types.string })
-  .output({ clean: types.string })
-  .step('trim', script({ code: js`return ${input('raw')}.trim();`.js, returns: { clean: 'string' } }))
-  .return({ clean: out('trim', 'clean') }).build();
-export default flow('parent').input({ text: types.string }).output({ clean: types.string })
-  .step('normalized', subflow(child, { raw: input('text') })).return({ clean: out('normalized', 'clean') }).build();
-```
-
-Read the child's own inputs with `input(...)`, not a hand-written `$vars.raw`. A
-declared input is bound to the node that starts its flow, and a child's start
-node is named after the CALLER — `<callerStepId>Start`. The script above emits
-`return $vars.normalizedStart.output.raw.trim();`, so hand-writing the reference
-would both be wrong and break the moment the parent step is renamed. See
-[`manual-trigger.md`](manual-trigger.md).
-
-Use a child for a meaningful contract or a unit of reuse, not as a speed
-optimization or an arbitrary split. Local instrumentation observes the parent
-step's data path; it does not turn that boundary into a separate deployed job.
-
-Read a child output by its declared name — `out('reverse', 'reversed')`, never a bare
-`out('reverse')`. The compiler serializes each call's body under top-level `subflows`.
-The same child can be reused at any nesting depth; copied node ids and references
-are re-keyed together so every call site remains isolated.

package/skills/uipath-maestro-flow/references/summarize.md

@@ -1,20 +0,0 @@
-# Summarize
-
-*Exact signatures, fields, and defaults: `summarize()`.*
-
-Reads an attachment and produces a summary given a prompt.
-
-Signature: `summarize({ attachment, prompt, returnCitations? })`
-
-```ts
-.step('digest',
-  summarize({
-    attachment: out('previousNode', 'document'),
-    prompt: 'Summarize decisions and owners.',
-    returnCitations: true
-  }))
-```
-
-## General
-
-- Error **460005** can be transient; retry it once before classifying the failure

package/skills/uipath-maestro-flow/references/switch.md

@@ -1,20 +0,0 @@
-# Switch
-
-Switch routes one value among several cases.
-
-Signature:
-`.switch(name, on, [{ value: string | number | boolean, label?, body }], defaultFn?)`.
-
-```ts
-.switch('priority', input('priority'), [
-  { value: 'high', body: (b) => b.step('page', script({ code: 'return 1;' })) },
-  { value: 'low', body: (b) => b.step('queue', script({ code: 'return 2;' })) },
-], (other) => other.step('normal', script({ code: 'return 3;' })))
-```
-
-Prefer Switch when one discriminant selects three or more paths; Branch is
-usually clearer for two. Decide whether cases end independently or rejoin a
-shared successor.
-
-Cases compare strictly (`===`) from top to bottom. Each case gets a generated
-`case-<id>` port; the optional final callback uses `default`.

package/skills/uipath-maestro-flow/references/terminate.md

@@ -1,22 +0,0 @@
-# Terminate
-
-Terminate stops the entire run. In a parallel arm it aborts sibling work; it
-does not complete the Flow with output values.
-
-Signature: `.terminate(name, label?)`.
-
-```ts
-.branch('fatal', input('fatal'),
-  (yes) => yes.terminate('abort', 'Abort run'),
-  (no) => no.step('continue', script({ code: 'return "ok";' })))
-```
-
-Choose Terminate only when the requirement is stop-all rather than return an
-answer from one path. A green run alone is weak evidence for this node. Use an
-abort-specific witness: for example, show that a sibling side effect never
-happened or that the run reached the terminated state without producing normal
-Flow outputs.
-
-Inside a parallel arm it aborts sibling arms, whereas `.return(...)` only ends its
-own path. Its mappings are terminal metadata, not a readable action result:
-`out('<terminate>')` remains invalid.

package/skills/uipath-maestro-flow/references/transform.md

@@ -1,32 +0,0 @@
-# Transform
-
-*Exact signatures, fields, and defaults: `transform()`.*
-
-Transform applies filter, map, or group-by operations to an array.
-
-Signature:
-`transform({ collection, operations, variant?: 'filter' | 'map' | 'group-by' })`.
-Operations are the SDK's `filter`, `map`, and `groupBy` discriminated shapes.
-
-```ts
-.step('active', transform({ variant: 'filter', collection: input('rows'),
-  operations: [{ type: 'filter', filters: [
-    { field: 'status', condition: 'equals', value: 'active' },
-  ] }] }))
-```
-
-## Choosing the shape
-
-Prefer a named variant for one standard operation so the canvas communicates
-intent. Use generic Transform for a chain; use Script when the requested
-calculation does not fit the transform operations.
-
-## Data-dependent review
-
-Operations run in order. A map can remove a field that a later filter or group
-expects, and a plausible misspelled field on untyped input can yield empty
-rows without a structural failure. Review the chain against representative
-items and assert the resulting values, not merely that the node ran.
-
-Omit `variant` for the generic node. Set `variant: 'map' | 'filter' | 'group-by'`
-for a single-purpose node; `operations` must then contain exactly one entry.

package/skills/uipath-maestro-flow/references/voice.md

@@ -1,70 +0,0 @@
-# Voice
-
-*Exact signatures, fields, and defaults: `voiceTrigger()`, `createOutgoingCall()`, `endCall()`, `voiceAgent()`.*
-
-A voice call is a conversation with an audio front end. It is identified by a
-`callContext` OBJECT — not a bare conversation id — and that object is what
-every voice step is keyed by.
-
-```ts
-// Inbound: the platform hands you the call.
-export default flow('support-line')
-  .trigger(voiceTrigger())
-  .step('greet', voiceAgent({
-    systemPrompt: 'Greet {{input.customerName}} and find out why they called.',
-    inputs: { customerName: input('customerName') },
-    callContext: out('start', 'callContext'),
-    voice: { model: 'gemini-3.1-flash-live-preview', persona: 'Kore' },
-  }))
-  .step('hangUp', endCall({ callContext: out('start', 'callContext') }))
-  .build();
-
-// Outbound: the flow places the call.
-.step('dial', createOutgoingCall({ from: '+15550001111', to: input('customerPhone') }))
-.step('talk', voiceAgent({
-  systemPrompt: 'Remind {{input.customerName}} about {{input.amount}}.',
-  inputs: { customerName: input('customerName'), amount: input('amount') },
-  callContext: out('dial', 'callContext'),
-}))
-```
-
-## The call context
-
-`out('start', 'callContext')` (inbound) or `out('<dialStep>', 'callContext')`
-(outbound) is the whole object — `{ type, id, conversationId, … }` — and that is
-what to pass. **Reaching inside it is the mistake this family invites**:
-`out('dial', 'callContext.conversationId')` is a string, the node's schema types
-the field as `object`, and a scalar there passes the file's schema and then
-fails at dispatch. `check` catches it (`VOICE_CALL_CONTEXT_NOT_OBJECT`).
-
-Both numbers on `createOutgoingCall` are E.164 — a leading `+` and 7–15 digits
-(`'+15551234567'`). `from` must be a number provisioned on the tenant's
-telephony provider; anything else is rejected when the call is placed, not when
-the flow is validated. `endCall` reads `out('<step>', 'ended')`.
-
-## How the agent sounds
-
-`voice` takes a VOICE model (a live/realtime one — not the text models
-`inlineAgent` takes) and one of THAT model's personas; the two travel together:
-
-| Model | Personas |
-| --- | --- |
-| `gemini-3.1-flash-live-preview` (default) | Aoede, Charon, Fenrir, Kore, Leda, Orus, Puck, Zephyr |
-| `gpt-realtime-2` | alloy, ash, ballad, coral, echo, sage, shimmer, verse |
-
-Omit `voice` entirely for the platform default. `maxIterations` is capped at
-**8**, tighter than a text agent's 100, because a caller is waiting on the turn.
-The caller's turn arrives as audio, but the system prompt can use flow context.
-Declare each value under `inputs` and reference it as `{{input.<name>}}`; compile
-emits the runtime bindings and matching sidecar schema. There are no declared
-`returns`: the definition declares what comes back. Compile writes a
-voice-dialect `<source>/agent.json` sidecar (`settings.mode: 'voice'`) beside
-the `.flow`.
-
-## Evidence boundary
-
-`uipath.agent.voice` is served on this tenant; the trigger and the two call
-actions are `AvailableOnTenant: false` and ship bundled from the workbench
-manifests. Nothing local dials a phone: a green ladder proves the node types,
-the call-context threading and the voice settings. A real call, real audio, and
-what the caller heard are platform evidence.