SoftTech AI Registry
Moveworks · Agent Studio

Plugin action execution

Moveworks' AI reasoning system interprets a request, selects an appropriate plugin, determines and populates its inputs and initiates it; the plugin then executes configured actions and processes built in Agent Studio, which can make persistent changes in external systems. Deterministic process and action steps are distinct from the AI reasoning that selects and initiates them. Covers conversational, scheduled and webhook-triggered runs.

Recorded characteristics

Function
Reasoning vs execution: the Moveworks Agentic Reasoning Engine interprets requests, selects plugins, determines and populates inputs (slots) and formulates an execution plan. Configured Agent Studio conversational processes and actions then execute the defined operations. Compound Actions and Conversational Processes can contain deterministic logic (sequencing, switches, loops, error handling); not every step in a plugin is AI-selected, and the whole process is not described as autonomous AI decision-making. LLM Actions are separate text-generation steps within processes. The Action Orchestrator is a supporting runtime/orchestration mechanism that constrains and coordinates longer processes; it is not a separate AI reasoning system. Documented persistent actions: ServiceNow record changes (e.g. changing incident priority or assigned_to, creating incidents, bulk state changes) in the Data Transaction Cookbook, which frames writes to systems of record such as ServiceNow, Workday and Snowflake; an expense-approval ambient agent (Quickstart #6) that updates the approval in the source system via PATCH; Quickstart #2 updating a feature request via PATCH; LDAP / Active Directory search, create (add) and modify operations via HTTP -> LDAP Actions through the on-premise Moveworks Agent. HTTP Actions support GET, POST, PUT, PATCH and DELETE. Scheduled triggers and webhook triggers (ambient/background agents) are kept in this capability: background execution can occur without an immediate conversational user prompt.
Data access
Determined by the connectors and actions configured in each plugin and the authentication each connector uses; see permission basis under limitations.
Actions
Can take actions
External actions
Yes
Human confirmation
Conditional
Permission basis
Mixed
Administrative control
Runtime confirmation: an Activity Confirmation Policy can be configured on individual action activities; when enabled the assistant presents the collected values and asks the user before the action executes (Moveworks example: "I'm about to change INC0012345 priority from Moderate to Critical. Should I proceed?"). Background/ambient processes can include optional human approval steps sent to another person (e.g. a manager). Kept distinct: requester confirmation, approval by another person, publishing, plugin launch, and authentication. Not stated: whether confirmation is on or off by default, or whether administrators can universally require it. Launch governance: Launch Configuration controls which people can start a plugin (selected users, everyone, blocked users, or attribute rules such as department, role or location); permission to launch a plugin is not authority to perform the downstream action. Logging: logs cover areas including messages, webhook triggers, multi-step execution and individual action calls; the log viewer defaults to the last 6 hours and can search back a maximum of 14 days (a search window, not a stated retention period); standard redaction applies, stricter redaction is optional, and passwords, keys and tokens are always hidden. Complete auditability is not claimed.
Default state
Conditional
Availability
Default is conditional: depends on the plugin being created and configured, published, launch permissions, action/process configuration, connector/authentication configuration, and activation of background triggers where used. Active; no beta or preview label was found for this capability in the reviewed current documentation. No GA date. Plan and regional availability not established.
Licensing
Plan requirements not established.
External model or provider
Not established for the runtime reasoning engine. (Gemini 3.1 references apply to Agent Architect, Moveworks' building assistant, and are not evidence for this capability.)
Limitations and uncertainty
Permission basis = mixed, positively established: (A) individual-user authority — OAuth 2.0 Authorization Code (with PKCE) and JWT user-based mechanisms can let downstream actions run with the individual person's authority; (B) shared/configured authority — client credentials, API keys, basic and other configured shared authentication run actions under separately configured credentials. Not every plugin preserves the individual user's permissions, and not every plugin uses shared credentials. Background identity: the exact execution identity used by scheduled and webhook-triggered runs was not established by the reviewed first-party documentation; no inference is made that such runs use a service account, the initiating user, the plugin builder, the connector owner or a dedicated agent identity. No claim is made that scheduled execution bypasses confirmation. LDAP / Active Directory: confirmation and credential identity for LDAP writes specifically are not established. Excluded as evidence: Action Catalog / ToolSmith, RPA/browser automation, unverified builder role names and permission chain, and an unconfirmed scheduled-plugin log type. Unresolved: (1) default state of the per-action confirmation setting; (2) whether administrators can universally mandate confirmation; (3) identity/credential behaviour for scheduled runs; (4) identity/credential behaviour for webhook/background runs; (5) complete builder permission-chain details; (6) precise lifecycle/GA date; (7) plan availability; (8) regional availability; (9) runtime reasoning model/provider; (10) log retention period.

Evidence