@uipath/maestro-builder-sdk 6.42.0 → 6.44.0

package/dist/core/actions.d.ts

@@ -228,6 +228,15 @@ export interface AskedField extends FormFieldSettings {
     direction: 'output';
     /** Reviewer must fill it in before the task can be completed. */
     required?: boolean;
+    /**
+     * The flow variable the answer lands in, read downstream as `$vars.<variable>`
+     * (`v('<variable>')`) — the name only, without the `vars.` prefix. Defaults to
+     * the field id. Studio Web names it `<Step>_<field>` (`P_comments`) and later
+     * steps read `$vars.P_comments` or bind `vars.P_comments`; declaring it here is
+     * what makes those reads resolve, so a designer-saved approval flow round-trips
+     * through the SDK. The answer is also always `out('<step>', '<id>')`.
+     */
+    variable?: string;
 }
 /**
  * A value the reviewer READS **and can correct**: pre-filled from the flow,
@@ -248,151 +257,6 @@ export interface InOutField extends FormFieldSettings {
     required?: boolean;
 }
 export type FormField = ShownField | AskedField | InOutField;
-/**
- * How a conversational agent gets its turn — the node's own
- * `conversationalAgentSettings` sub-object.
- *
- * @remarks
- * `'simple'` (the default) derives everything from ONE conversation-context
- * binding: `context` is the whole context object, and the platform reads
- * `conversationId` / `latestExchangeId` / `messages` / `userSettings` out of
- * it. `'custom'` binds each field yourself — for a flow that assembles a turn
- * from more than one source.
- */
-export interface ConversationalAgentSettings {
-    mode?: 'simple' | 'custom';
-    /** The whole conversation context — `'simple'` mode's single binding. */
-    context?: Expr | string;
-    /** `'custom'` mode: the conversation id. */
-    conversationId?: Expr | string;
-    /** `'custom'` mode: the exchange id. */
-    exchangeId?: Expr | string;
-    /** `'custom'` mode: the chat history array. */
-    messages?: Expr | string;
-    /** `'custom'` mode: the caller's per-user settings object. */
-    userSettings?: Expr | string;
-}
-export interface ConversationalAgentInputs {
-    /**
-     * The agent's standing instructions for the conversation. Plain text — a
-     * conversational agent's turn comes from the transcript, not from flow
-     * arguments, so there is no `{{input.…}}` templating.
-     */
-    systemPrompt: string;
-    /** The MODEL to run, e.g. `'gpt-5.4'`. Required by the node's definition. */
-    model: string;
-    /**
-     * How the agent gets its turn. The common case is
-     * `{ context: out('<waitStep>', 'conversationContext') }` — one binding the
-     * platform reads conversation id, exchange id, history and user settings out
-     * of. See {@link ConversationalAgentSettings}.
-     */
-    settings: ConversationalAgentSettings;
-    /**
-     * Whether the agent's reply CLOSES the exchange.
-     *
-     * @deprecated Has no effect and is not emitted. The platform retired the input:
-     * the conversational agent's v1.7 node migration removes it, and the converter
-     * always sends `conversationalService.endExchange = ''`. Wait-for-message and
-     * the end of the conversation close open exchanges.
-     */
-    endExchange?: boolean;
-    /** Sampling temperature, 0–1. */
-    temperature?: number;
-    /** Max tokens in one response. */
-    maxTokenPerResponse?: number;
-    /**
-     * The model's own context ceiling.
-     *
-     * @deprecated Has no effect and is not emitted. Studio Web derives it from the
-     * selected model.
-     */
-    modelMaxTokens?: number;
-    /** How many tool-calling rounds one turn may take, 1–100. */
-    maxIterations?: number;
-    /** Safety rails, the same array `inlineAgent` takes. */
-    guardrails?: AgentGuardrail[];
-    /**
-     * The agent's own directory name (a UUID) — the node carries it as `source`
-     * and the compiler writes `<source>/agent.json` beside the flow. Derived from
-     * the flow id + step name when omitted.
-     */
-    source?: string;
-}
-export interface CreateOutgoingCallInputs {
-    /**
-     * The number to call FROM — a provisioned number on the tenant's telephony
-     * provider, in E.164 (`'+15551234567'`). Required.
-     */
-    from: string | Expr;
-    /** The number to call, in E.164. Required. */
-    to: string | Expr;
-}
-export interface EndCallInputs {
-    /**
-     * The call to hang up — bind the `callContext` published by the incoming-call
-     * trigger (`out('start', 'callContext')`) or by `createOutgoingCall`
-     * (`out('<step>', 'callContext')`). Required.
-     */
-    callContext: Expr | string;
-}
-/**
- * The audio settings a voice agent speaks with.
- *
- * @remarks
- * `model` is a VOICE model (a live/realtime one — not the text models
- * `inlineAgent` takes), and `persona` is one of that model's own voices, so the
- * two travel together. The platform's catalog today is
- * `'gemini-3.1-flash-live-preview'` (personas Aoede, Charon, Fenrir, Kore,
- * Leda, Orus, Puck, Zephyr) and `'gpt-realtime-2'` (alloy, ash, ballad, coral,
- * echo, sage, shimmer, verse); omit both for the platform default.
- */
-export interface VoiceSettings {
-    /** The voice model, e.g. `'gemini-3.1-flash-live-preview'`. */
-    model?: string;
-    /** One of that model's personas, e.g. `'Kore'`. */
-    persona?: string;
-    /** Sampling temperature, 0–1. */
-    temperature?: number;
-    /** Max tokens per response. */
-    maxTokens?: number;
-    /** The model's own context ceiling — informational. */
-    modelMaxTokens?: number;
-}
-export interface VoiceAgentInputs {
-    /**
-     * The agent's standing instructions — who it is on the call and what it must
-     * do. Use `{{input.<name>}}` placeholders for values declared in `inputs`;
-     * the caller's audio remains the conversational turn.
-     */
-    systemPrompt: string;
-    /**
-     * Flow values made available to `systemPrompt` placeholders. Each key must
-     * be referenced as `{{input.<key>}}`; the compiler emits the node's runtime
-     * argument binding and the matching agent.json input contract together.
-     */
-    inputs?: Record<string, unknown>;
-    /**
-     * The call to attach the agent to — the `callContext` from the incoming-call
-     * trigger or `createOutgoingCall`. Required: without it the agent has no
-     * audio channel to join.
-     */
-    callContext: Expr | string;
-    /** How the agent sounds. Omit for the platform default voice. */
-    voice?: VoiceSettings;
-    /**
-     * How many tool-calling rounds the agent may take in one turn. The node's
-     * schema allows **1–8** — a tighter ceiling than a text agent's, because a
-     * caller is waiting.
-     */
-    maxIterations?: number;
-    /**
-     * The agent's own directory name (a UUID) — the node carries it as `source`
-     * and the compiler writes `<source>/agent.json` beside the flow. Omit and one
-     * is derived from the flow id + step name, so a recompile is not a diff.
-     */
-    source?: string;
-}
 /**
  * Split an extractor's node type into the two GUIDs its tail packs.
  *
@@ -491,107 +355,6 @@ export interface IxpExtractInputs {
  * (`'in-solution'`). Shared by `rpaWorkflow`, `agenticProcess` and `agent`.
  */
 export type ProcessLocation = 'published' | 'in-solution';
-/**
- * Which KIND of agent project was published behind a `uipath.core.agent.<key>`
- * resource. Display-only — see {@link AgentInputs.flavour}.
- */
-export type AgentFlavour = 'coded' | 'lowcode';
-export type AgentLocation = ProcessLocation;
-export interface AgentInputs {
-    /**
-     * The agent resource key (a GUID). It becomes the node's TYPE,
-     * `uipath.core.agent.<key>`. For a published agent this is the Orchestrator
-     * release key; for an in-solution sibling it is `resource.key` from
-     * `resources/solution_folder/process/agent/<project>.json`.
-     *
-     * Find it with `uip or processes list --all-folders --process-type Agent` (an agent's
-     * `ProcessKey` reads `<project>.agent.<name>`; the GUID you want is the row's
-     * **`Key`**) or `uip maestro flow registry search uipath.core.agent`.
-     *
-     * Pass `--limit`: `--all-folders` returns 50 rows and reports the truncation
-     * only in `Pagination.HasMore`, so an agent that exists can look absent.
-     */
-    key: string;
-    /** The agent project name. */
-    name: string;
-    /**
-     * Where the referenced agent lives. Published is the backward-compatible
-     * default. Use `in-solution` only after registering a sibling agent project
-     * with `uip solution projects add`.
-     */
-    location?: AgentLocation;
-    /**
-     * The Orchestrator folder holding it — e.g.
-     * `'Shared/uipath-maestro-flow/CountLetters LowCode'`.
-     *
-     * **Not optional, and not cosmetic.** Agent names are unique per FOLDER, not per
-     * tenant: `codereval/DefaultTenant` carries two agents called `CountLetters`,
-     * one in `Shared` and one in `Shared/uipath-maestro-flow/CountLetters CodedAgent`,
-     * with different release keys. The release is resolved by listing THIS
-     * folder, so the folder is what picks the agent you meant. Required for a
-     * published agent; omit it for an in-solution sibling.
-     */
-    folderPath?: string;
-    /**
-     * The sibling agent project's `resource.projectKey`, read from
-     * `resources/solution_folder/process/agent/<project>.json`. Required only
-     * when `location` is `in-solution`.
-     */
-    projectId?: string;
-    /**
-     * The AGENT's own input arguments, by its own argument names (e.g.
-     * `{ inputString: 'arrow' }`). Every agent declares its own — read them from
-     * `uip maestro flow registry get uipath.core.agent.<agent>` under
-     * `inputDefinition.properties`.
-     *
-     * **Required, unlike the other job families' `inputs`.** An agent node with
-     * nothing bound is one the platform REWRITES behind your back: flow-v1's
-     * `applyEmptyInputFloor` seeds `JobArguments: { input: <empty-for-declared-type> }`
-     * — a key named `input`, which is not in the agent's own schema unless the agent
-     * happens to declare one — because the Python agent runner validates the body
-     * against a schema with a required `input` field and rejects a bare `{}` with
-     * *"Field required: input"* (the pod then exits `0x33`). Locally the envelope
-     * passes straight through and the run is green, so nothing but a checker can see
-     * it. Pass `{}` explicitly if you really mean "no arguments" and `check` will
-     * tell you what the platform will do with it.
-     */
-    inputs: Record<string, unknown>;
-    /**
-     * The agent's OUTPUT fields and their types (e.g.
-     * `{ count: 'integer', inputString: 'string' }`). Required if anything reads the
-     * step's output, for the same reason as `rpaWorkflow`'s: the schema lives on the
-     * tenant and authoring happens offline, so an undeclared read is rejected —
-     * rightly, since nothing offline could tell a real field from a typo.
-     *
-     * `uip maestro flow registry get uipath.core.agent.<agent>` shows what the
-     * platform declares, under `outputDefinition.output.schema.properties`.
-     *
-     * **Case matters.** The agent answers with the field names its own definition
-     * declares (`count`, not `Count`). It used to be a live-only trap: a poller that
-     * read the job through `uip agent run status` got a PascalCased envelope, so a
-     * read of `count` was right offline and `undefined` live (flow-builder-sdk #122).
-     * Declare the names the definition declares.
-     *
-     * @enforcedBy AGENT_READ_WITHOUT_RETURNS Reading a field off the result requires
-     * declaring it here.
-     */
-    returns?: Record<string, ReturnFieldType>;
-    /**
-     * Whether the published resource is a CODED agent project (LangGraph /
-     * LlamaIndex / OpenAI Agents) or a low-code one built in Agent Builder.
-     *
-     * **Display-only, and it is the only thing that differs.** `registry get` on a
-     * coded and a low-code agent returns the same node type, the same
-     * `Orchestrator.StartAgentJob` service type, the same `sortOrder` and the
-     * same bindings shape; the single difference is `display.icon` —
-     * `coded-agent` vs `autonomous-agent`. Which one a given resource is cannot be
-     * known offline, so it is stated here rather than guessed. Check with
-     * `uip maestro flow registry get uipath.core.agent.<agent>` → `display.icon`.
-     *
-     * Defaults to `'lowcode'`. Nothing in the runtime keys on it.
-     */
-    flavour?: AgentFlavour;
-}
 /** A JSON-schema-ish type for one field of an inline agent's input/output schema. */
 export type InlineAgentFieldType = 'string' | 'number' | 'integer' | 'boolean' | 'object' | 'array';
 /**
@@ -607,7 +370,7 @@ export type InlineAgentFieldType = 'string' | 'number' | 'integer' | 'boolean' |
  * This type exists so that stays true. It was previously spelled inline at
  * seven sites, `'integer'` was added to three of them, and the four left behind
  * were not distinguishable by any contract — `rpaWorkflow` in particular is
- * decompiled by the SAME line of `emitPublishedResource` as `apiWorkflow`, so a
+ * decompiled by the SAME lift (`liftProcess`) as `apiWorkflow`, so a
  * deployed process with an integer output round-tripped to source that would
  * not compile.
  */
@@ -720,267 +483,6 @@ export interface BuiltInValidatorGuardrail {
     }>;
 }
 export type AgentGuardrail = CustomGuardrail | BuiltInValidatorGuardrail;
-export interface InlineAgentInputs {
-    /**
-     * The MODEL to run, e.g. `'gpt-5.4'`. Required by the node's definition, and
-     * worth a thought rather than a default: the platform's own scaffold ships
-     * `gpt-4o-2024-11-20`, which is stale, and v1's own smoke check for this node
-     * type FAILS a flow that keeps it. List what the tenant has with
-     * `uip agent model list`.
-     */
-    model: string;
-    /**
-     * The agent's standing instructions — who it is, and what each `returns` field
-     * should hold. Required by the definition (`minLength: 1`).
-     *
-     * **Write it as plain text, and reference a value as `{{input.<name>}}`** — the
-     * agent's own template syntax, and the same names `inputs` declares:
-     *
-     * ```ts
-     * systemPrompt: 'You classify support email. Return a result conforming to the output '
-     *   + 'schema. category: billing | technical | account. priority: low | normal | high.',
-     * userPrompt: 'Classify this email:\n{{input.body}}',
-     * inputs: { body: input('body') },
-     * returns: { category: 'string', priority: 'string' },
-     * ```
-     *
-     * Why a placeholder rather than an interpolated expression: an inline agent is two
-     * artifacts, and its prompt exists in TWO dialects. You write one; the compiler
-     * emits the other into the `agent.json` sidecar. The `.flow` node carries no copy
-     * of the prompt: it is a shell, so Studio Web reads the sidecar.
-     *
-     *   1. yours          `{{input.claim}}`
-     *   2. the AGENT.JSON `{{input.prepare__output__claimRef}}` ← what the runtime SENDS
-     *
-     * The second exists because the platform does not send an agent the names you
-     * declared: it names each argument after the bound reference PATH, `__`-joined.
-     * For a flow input the two coincide (`$vars.notes` → `notes`); for a step output
-     * they do not, and a sidecar still saying `{{input.claim}}` templates against a key
-     * that is not there — the literal text reaches the model. See the inline-agent
-     * node reference (`website/reference/inline-agent.md`) §"The prompt dialects".
-     *
-     * **The answer's shape is `returns`, not the prompt.** `returns` becomes the node's
-     * `agentOutputVariables` and the `agent.json` `outputSchema` — what Studio Web's
-     * Outputs editor writes — and the platform's agent runtime ends each run with a
-     * built-in structured call (`end_execution`) that fills exactly those fields. So
-     * `out('<step>', '<field>')` reads a typed value, not text to parse. Describe what
-     * each field holds, in the product's own wording, as the example above does:
-     * `Return a result conforming to the output schema. <field>: <how to fill it>.`
-     *
-     * Never ask for JSON TEXT as well ("Return ONLY a JSON object with keys …"). The
-     * model then packs its whole answer, serialized, into ONE string field: a writer
-     * declaring `{ subject, body }` came back on 2026-09-23 with
-     * `body: '{"subject":"…","body":"Dear …"}'` in 3 of 3 debug runs, and the flow sent
-     * that text on. A field that should carry structure is declared `'object'` or
-     * `'array'` instead.
-     *
-     * @enforcedBy INLINE_AGENT_PROMPT_JSON_TEXT A prompt that asks for JSON text while
-     * `returns` declares fields is refused; the platform accepts it and the run returns
-     * the packed value.
-     */
-    systemPrompt: string;
-    /**
-     * The per-run request. Required by the definition (`minLength: 1`). Same
-     * `{{input.<name>}}` placeholders as `systemPrompt`.
-     */
-    userPrompt: string;
-    /**
-     * The values the agent gets, by YOUR name for each one — e.g.
-     * `{ body: input('body') }`. These become the node's `agentInputVariables`
-     * descriptor array (`{ id, type, binding }`, the shape 48 of 53 deployed instances
-     * carry) and the `agent.json`'s `inputSchema`.
-     *
-     * **The name is yours only in this file.** Both emitted artifacts carry the
-     * PLATFORM's name — the bound reference's path, `__`-joined
-     * (`out('prepare','claimRef')` → `prepare__output__claimRef`) — because that is what
-     * the runtime keys the agent's JobArguments by, and an `agent.json` speaking any
-     * other name templates against nothing. You never write the long form.
-     *
-     * **Reference each one in a prompt as `{{input.<name>}}`.** Not decoration: the
-     * platform's deployed input list is not necessarily this array. flow-v1's
-     * `preDeriveAgentInputDefinitions` pre-pass scans the node's PROMPTS for `$vars.*`
-     * references, merges what it finds with this list, and — when its caller asks for
-     * pruning — DROPS an entry no prompt reference points at. A referenced entry
-     * survives every one of those paths; an unreferenced one survives only some.
-     * `check` warns when none of them is referenced, which is the case where the agent
-     * would arrive with no arguments at all.
-     *
-     * Two shapes have no platform name and are handled rather than renamed:
-     *
-     *  - a **literal** (`{ tier: 'Enterprise' }`) is INLINED into both prompts — there
-     *    is no argument for one, so a token could never substitute;
-     *  - a **computed expression** is refused by `check`
-     *    (`INLINE_AGENT_COMPOSITE_INPUT`): the platform names one argument per
-     *    reference, so an expression spanning several has none. Compute it in a
-     *    `script` step first and bind that step's output.
-     */
-    inputs?: Record<string, unknown>;
-    /**
-     * The fields the agent must return, and their types — e.g.
-     * `{ category: 'string', priority: 'string' }`. These become the node's
-     * `agentOutputVariables` descriptor array AND the emitted `agent.json`'s
-     * `outputSchema`, and they are what makes `out('<step>', 'category')` a checkable
-     * read.
-     *
-     * Defaults to the definition's own default, `{ content: 'string' }` — which is
-     * the toy scaffold shape, so declare something real if the flow reads fields.
-     *
-     * @enforcedBy INLINE_AGENT_READ_UNKNOWN_FIELD A read outside the declared set is
-     * undefined on every rung and on the platform.
-     */
-    returns?: Record<string, InlineAgentFieldType>;
-    /**
-     * The agent's own directory name — a UUID. The node carries it as `source`, and
-     * the platform resolves the agent's configuration at `<source>/agent.json`
-     * relative to the project (flow-v1 emits `entryPoint: <source>/agent.json`), so
-     * the compiler writes that file next to the `.flow`.
-     *
-     * Omit it and one is derived from the flow id + step name, so a given flow emits
-     * the same uuid every time (a random one would make every compile a diff).
-     */
-    source?: string;
-    /** Sampling temperature, 0–1. The definition's range; omit for the model's default. */
-    temperature?: number;
-    /** Max tokens in one response, 0–16384. */
-    maxTokenPerResponse?: number;
-    /**
-     * The model's own context ceiling, e.g. `128000`.
-     *
-     * @deprecated Has no effect and is not emitted. Studio Web derives it from the
-     * selected model each time the agent is opened, and the sidecar has no field
-     * for it.
-     */
-    modelMaxTokens?: number;
-    /** How many tool-calling rounds the agent may take, 1–100. */
-    maxIterations?: number;
-    /**
-     * The harness the agent runs on — `'standard'` (the default) or
-     * `'advanced'`, written to the `agent.json`'s `settings.mode`. It does not
-     * change the node's version: every inline agent emits the bundle's newest
-     * `uipath.agent.autonomous` definition (1.4).
-     */
-    mode?: 'standard' | 'advanced';
-    /**
-     * Safety rails over the agent's inputs, outputs, LLM calls and tools — the
-     * platform's own array shape ({@link AgentGuardrail}), carried in the
-     * `agent.json` (every bundled definition declares the input).
-     *
-     * ```ts
-     * guardrails: [{
-     *   id: 'no-pii', $guardrailType: 'custom', name: 'Block PII',
-     *   selector: { scopes: ['Agent'] },
-     *   action: { $actionType: 'block', reason: 'PII detected' },
-     *   enabledForEvals: true,
-     *   rules: [{ $ruleType: 'word', fieldSelector: { $selectorType: 'all' },
-     *             operator: 'matchesRegex', value: '\\d{3}-\\d{2}-\\d{4}' }],
-     * }]
-     * ```
-     */
-    guardrails?: AgentGuardrail[];
-    /**
-     * Attach an episodic memory so the agent learns from past runs — one
-     * {@link AgentMemoryRef}, wired to the agent's `memory` handle (declared by
-     * the bundled 1.4 definition, which every inline agent uses).
-     */
-    memory?: AgentMemoryRef;
-    /**
-     * GROUND the agent on tenant knowledge — one or more Context Grounding
-     * (semantic) indexes, wired to the agent's own `context` handle.
-     *
-     * ```ts
-     * inlineAgent({
-     *   model: 'gpt-5.4',
-     *   systemPrompt: 'You decide billing disputes from the SOPs. Return a result conforming to the output '
-     *     + 'schema. determination: valid | invalid | needs_review. rationale: the SOP rule that decided it.',
-     *   userPrompt: 'Dispute: {{input.description}}',
-     *   inputs: { description: input('disputeDescription') },
-     *   returns: { determination: 'string', rationale: 'string' },
-     *   context: [{
-     *     name: 'Billing Dispute SOP Index',
-     *     id: 'cc45b9b4-dbf6-47b3-40ac-08debc0cec5b',
-     *     folderPath: 'Shared/uipath-maestro-flow/BillingDispute',
-     *     query: 'billing dispute resolution policy',
-     *   }],
-     * })
-     * ```
-     *
-     * Each entry becomes its own NODE —
-     * `uipath.agent.resource.context.index.<slug>.<id>` — joined to the agent by an
-     * edge out of the agent's `context` port. That is the platform's own shape: the
-     * agent definition declares the handle with
-     * `allowedTargets: [{ nodeType: 'uipath.agent.resource.context.*' }]`, and the
-     * index's definition declares the mirror
-     * (`allowedSources: [{ nodeType: 'uipath.agent.autonomous', handleId: 'context' }]`,
-     * `maxConnections: 1`). Nothing is a binding: the index's identity is IN the node
-     * type, exactly as a published agent's release key is.
-     *
-     * **Both identifiers are needed and neither is derivable.** The node type carries
-     * a slug of the name AND the index's uuid; the node's inputs carry `indexName` +
-     * `indexId` again, because the designer reads one and the runtime the other. Find
-     * them together — the uuid is the tail of the registry node type:
-     *
-     * ```bash
-     * uip maestro flow registry search "<index name>" --output json
-     * ```
-     *
-     * **Grounding is a CLOUD-side capability.** An offline run has no retrieval
-     * service to reach, so its answer is ungrounded
-     * however this is configured — which is why an offline rung can only assert the
-     * WIRING and a live rung only that the agent answered. Say so in a task rather
-     * than letting a green rung imply retrieval happened.
-     */
-    context?: ContextIndexRef | ContextIndexRef[];
-    /**
-     * Give the agent TOOLS — capabilities it may call while reasoning, wired to
-     * the agent's own `tool` handle. Each entry becomes its own resource NODE
-     * (`uipath.agent.resource.tool.<kind>…`), joined to the agent by an edge out
-     * of its `tool` port — the same artifact shape as `context`.
-     *
-     * ```ts
-     * tools: [
-     *   { kind: 'builtin', tool: 'summarize' },
-     *   { kind: 'connector', connector: 'uipath-atlassian-jira', operation: 'create-issue',
-     *     connection: 'jira', folder: 'shared' },   // bindings.json labels, both required
-     *   { kind: 'process', key: '6235d64e-b190-4b7a-8918-723df964c068',
-     *     name: 'Create TestCase', folderPath: 'Shared',
-     *     inputs: { title: 'string' }, returns: { id: 'string' } },
-     * ]
-     * ```
-     *
-     * WHEN a tool runs is the model's decision at run time — nothing in the flow
-     * calls it. Locally that means tool nodes are never stepped through (they are
-     * artifacts, not steps), so no local rung proves a tool was USED — only that
-     * the wiring and shapes are right. Say so in any task that scores this.
-     */
-    tools?: ToolRef | ToolRef[];
-    /**
-     * Let the agent ESCALATE to a human mid-run — an Action Center app task,
-     * wired to the agent's own `escalation` handle (its TOP port).
-     *
-     * ```ts
-     * escalation: {
-     *   name: 'ContentReview',
-     *   description: 'Escalate uncertain content to a human reviewer',
-     *   app: {
-     *     key: '454921d6-137f-4897-943a-1ebf29b15f80',
-     *     name: 'ContentReviewApp',
-     *     folderPath: 'Shared',
-     *     inputs: { ContentText: 'string' },
-     *     outputs: { ReviewDecision: 'string' },
-     *   },
-     *   recipients: ['reviewer@example.com'],
-     *   outcomes: ['approve', 'reject'],
-     * }
-     * ```
-     *
-     * The emitted node type is `uipath.agent.resource.escalation.coded-action-app`
-     * — the registry's CURRENT spelling (the bare `….escalation` is the pre-split
-     * era; the agent's handle accepts both, and `registry get` resolves only the
-     * suffixed one). The other variant, `escalation.quick-form`, is feature-gated
-     * off on this tenant and not authorable.
-     */
-    escalation?: EscalationRef | EscalationRef[];
-}
 /** The three platform-shipped built-in tools (fixed registry types). */
 export type BuiltinToolName = 'analyzefiles' | 'summarize' | 'batchtransform';
 /**
@@ -1412,30 +914,6 @@ export interface ContextIndexRef extends AgentResourcePlacement {
  * whole body rather than an inputs payload.
  */
 export interface FlowActionSpecs {
-    /** The spec {@link createOutgoingCall} builds. */
-    createOutgoingCall: {
-        inputs: CreateOutgoingCallInputs;
-    };
-    /** The spec {@link endCall} builds. */
-    endCall: {
-        inputs: EndCallInputs;
-    };
-    /** The spec {@link voiceAgent} builds. */
-    voiceAgent: {
-        inputs: VoiceAgentInputs;
-    };
-    /** The spec {@link conversationalAgent} builds. */
-    conversationalAgent: {
-        inputs: ConversationalAgentInputs;
-    };
-    /** The spec {@link agent} builds. */
-    agent: {
-        inputs: AgentInputs;
-    };
-    /** The spec {@link inlineAgent} builds. */
-    inlineAgent: {
-        inputs: InlineAgentInputs;
-    };
     /** The spec {@link ixpExtract} builds. */
     ixpExtract: {
         inputs: IxpExtractInputs;
@@ -1554,187 +1032,6 @@ export declare function builtinTriggerSpec<S extends object>(spec: S): S;
  * @returns An action spec to pass to `.step(name, …)`.
  */
 export declare function ixpExtract(inputs: IxpExtractInputs): ActionSpec;
-/**
- * Place an outgoing phone call
- * (`uipath.conversational.voice.create-outgoing-call`) and get back the
- * `callContext` every other voice step is keyed by.
- *
- * ```ts
- * .step('dial', createOutgoingCall({ from: '+15550001111', to: input('customerPhone') }))
- * .step('talk', voiceAgent({
- *   systemPrompt: 'Confirm the delivery window, then thank them.',
- *   callContext: out('dial', 'callContext'),
- * }))
- * ```
- *
- * @param inputs - The provisioned `from` number and the `to` number to dial.
- * @returns An action spec to pass to `.step(...)`.
- */
-export declare function createOutgoingCall(inputs: CreateOutgoingCallInputs): ActionSpec;
-/**
- * Hang up (`uipath.conversational.voice.end-call`). Reads
- * `out('<step>', 'ended')`.
- *
- * @param inputs - The `callContext` of the call to end.
- * @returns An action spec to pass to `.step(...)`.
- */
-export declare function endCall(inputs: EndCallInputs): ActionSpec;
-/**
- * Put a VOICE agent on a live call (`uipath.agent.voice`) — it speaks and
- * listens for one turn, then the flow continues.
- *
- * ```ts
- * .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' },
- * }))
- * ```
- *
- * Like `inlineAgent`, compile emits the node PLUS a stable
- * `<source>/agent.json` sidecar. Unlike it, the turn's content comes from the
- * call rather than from a user-prompt argument. Flow context can still be
- * supplied through `inputs` and referenced from the system prompt. There are no
- * declared `returns`: read the turn back as
- * `out('<step>', 'uipath__agent_response_messages')`.
- *
- * @param inputs - The instructions, the call to join, and how the agent sounds.
- * @returns An action spec to pass to `.step(...)`.
- */
-export declare function voiceAgent(inputs: VoiceAgentInputs): ActionSpec;
-/**
- * A CONVERSATIONAL agent (`uipath.agent.conversational`) — it answers one turn
- * of a live chat, reading the transcript rather than flow arguments.
- *
- * ```ts
- * .trigger(conversationTrigger())
- * .step('listen', waitForMessage({ conversationId: out('start', 'conversationId') }))
- * .step('reply', conversationalAgent({
- *   model: 'gpt-5.4',
- *   systemPrompt: 'You are a support agent. Be brief.',
- *   settings: { context: out('listen', 'conversationContext') },
- * }))
- * ```
- *
- * The reply is `out('<step>', 'uipath__agent_response_messages')` — the
- * platform's own field name. Like `inlineAgent`, compile emits the node plus a
- * stable `<source>/agent.json` sidecar.
- *
- * `sendMessage` is the alternative when the flow (not a model) decides what to
- * say; this factory is for when the model does.
- *
- * @param inputs - The model, the instructions, and how the turn is bound.
- * @returns An action spec to pass to `.step(...)`.
- */
-export declare function conversationalAgent(inputs: ConversationalAgentInputs): ActionSpec;
-/**
- * Invoke an AGENT resource — either one published to Orchestrator or a sibling
- * agent project registered in the same solution. Both start through
- * `Orchestrator.StartAgentJob`.
- *
- * @remarks
- * **Coded and low-code agents are the same node.** This one factory authors both.
- * `registry get` on a coded agent and on a low-code one returns the same node type,
- * the same service type, the same `sortOrder` and the same bindings shape; the
- * only difference is the icon, which is what `flavour` sets. Which kind a resource
- * is a property of what somebody published, not of the flow — so if a task asks for
- * "a coded agent", what it is asking you to get right is the RESOURCE you point at.
- *
- * **What this factory cannot do, said plainly:** it does not create an agent. A
- * published resource must already be deployed. An in-solution resource must first
- * be scaffolded and registered with `uip solution projects add`; this factory then
- * authors the local reference from the registered resource key and project id.
- *
- * The three identifiers are separate for `rpaWorkflow`'s reason: `agent` is the key
- * the node's TYPE carries (`uipath.core.agent.<agent>`), while `name` +
- * `folderPath` are what the runtime resolves the job by and together are the
- * `resourceKey`, `"<folderPath>.<name>"`. `folderPath` earns its keep twice here —
- * see {@link AgentInputs.folderPath} for the two-agents-called-CountLetters case.
- *
- * The step WAITS for the job and publishes its output arguments under `output`, so
- * `out('<step>', '<field>')` reads a field `returns` declares — using the names the
- * agent's own definition declares, case included.
- *
- * ── the live bar, stated ─────────────────────────────────────────────────────────
- * A green live rung here means **a model responded with the declared output shape**,
- * not that the answer was right. A real Orchestrator job runs, the flow's input
- * reaches it, and its answer reaches the flow's output — all four independently
- * checkable (`ladder.sh job`). Whether the number it returned is the correct number
- * is the model's business, and no rung asserts it. What CAN be asserted is that the
- * flow did not fake it: the offline seeds assert the exact UNFIXTURED value, which a
- * hardcoded answer cannot produce.
- *
- * @example
- * **Start a published agent and read one declared output**
- * ```ts
- * .step('countLetters', agent({
- *   key: '6a47dc5b-5fd4-461f-b97d-6c1817abcaaa',
- *   name: 'CountLetters LowCode Agent',
- *   folderPath: 'Shared/uipath-maestro-flow/CountLetters LowCode',
- *   inputs: { inputString: input('word') },
- *   returns: { count: 'integer', inputString: 'string' },
- * }))
- * .return({ rs: out('countLetters', 'count') })
- * ```
- *
- * @param inputs - The agent to start (`name`, `folderPath`, and `key` or
- * `projectId`), its `inputs`, and the fields you read back via `returns`.
- * @returns An action spec to pass to `.step(name, …)`.
- */
-export declare function agent(inputs: AgentInputs): ActionSpec;
-/**
- * Declare an INLINE AUTONOMOUS AGENT — an agent defined inside this flow's own
- * project rather than published to Orchestrator (`uipath.agent.autonomous`,
- * `Orchestrator.StartInlineAgentJob`).
- *
- * @remarks
- * **Two artifacts, not one.** The node carries the prompts and the variable
- * descriptors, and it points at a directory — `source` — where the platform expects
- * the agent's own configuration (flow-v1 emits `entryPoint: <source>/agent.json`).
- * So `compile` writes `<source>/agent.json` beside the `.flow`, built from the same
- * fields. Nothing to assemble by hand; `source` defaults to a uuid derived from the
- * flow id and step name so a recompile is not a diff.
- *
- * **How this differs from `agent()`.** That one references something already
- * published and started as an Orchestrator job; this one IS the definition, and the
- * platform runs it inside the flow's own debug/publish context. The practical
- * consequences: there is no folder, no release key and no binding pair here — and
- * no `uip` verb that starts one headlessly either.
- *
- * ── the live bar, stated ─────────────────────────────────────────────────────────
- * Weaker than `agent()`'s, and in a specific way. `Orchestrator.StartInlineAgentJob`
- * is Studio-Web-debug-only, so there is no Orchestrator job to point at and no
- * headless verb that starts one. No local runner currently calls a model for this
- * node either — an offline run asserts the WIRING and the declared `returns` shape,
- * never that a model answered. Two differences would remain for any runner that did
- * call one: knowledge grounding (a context handle) is a cloud-side index an offline
- * path does not have, so the call would be ungrounded; and the node's `model` would
- * have to be substituted for one reachable headlessly. Answer quality stays on the
- * offline `expect` seeds; real behaviour needs a Studio Web debug run.
- *
- * @example
- * **Classify an email with an agent defined inline**
- * ```ts
- * .step('triage', inlineAgent({
- *   model: 'gpt-5.4',
- *   systemPrompt:
- *     'You are a support triage assistant. Classify the email into exactly one ' +
- *     'category and one priority. Return a result conforming to the output schema. ' +
- *     'category: billing | technical | account. priority: low | normal | high.',
- *   userPrompt: 'Classify this email:\n{{input.body}}',
- *   inputs: { body: input('body') },
- *   returns: { category: 'string', priority: 'string' },
- * }))
- * .return({ category: out('triage', 'category') })
- * ```
- *
- * @param inputs - The agent defined in this project: its `model`,
- * `systemPrompt`, `userPrompt`, and the `returns` fields it must produce.
- * @returns An action spec to pass to `.step(name, …)`.
- */
-export declare function inlineAgent(inputs: InlineAgentInputs): ActionSpec;
 /**
  * Declare an Integration Service connector action — the typed form, where a
  * generated descriptor supplies the nodeType and statically-checked input types: