AI Agent tool actions
The common mechanism through which Appian AI Agents select and invoke configured tools to retrieve information, execute business logic and, where supported, perform persistent actions. Documented tool types include system tools (Query Records, document tools), custom tools (Process Model, Expression Rule, AI Agent/sub-agent) and external MCP Server tools. Process agents run within process models and can operate unattended with straight-through processing; chat agents operate interactively through a conversational interface. Both use the same tool mechanism, and current evidence does not establish materially different tool scope, permission basis or confirmation mechanism between them.
Recorded characteristics
- Function
- An Appian AI Agent reasons over a configured toolset and selects tools to invoke. Documented tool types: system tools (Query Records, document tools), custom tools (Process Model, Expression Rule, AI Agent), and external MCP Server tools. Multiple tool calls may be issued in parallel within a reasoning step. Process agents are invoked in process models through the Execute AI Agent smart service and can run unattended as part of straight-through processing; chat agents are invoked interactively through a chat interface component.
- Data access
- Tools determine data reach. Query Records and document tools are read-oriented retrieval mechanisms; expression rule tools provide logic and data. Record- and field-level security applies to data reached through tools.
- Actions
- Can take actions
- External actions
- Unknown
- Human confirmation
- Not established
- Permission basis
- User permissions
- Administrative control
- Appian administrators control AI guardrails and optional AI input/output audit logging. Builders control which tools an agent has, and process model and record security govern what those tools may do.
- Default state
- Conditional
- Availability
- Appian documents AI Agents as part of its advanced and premium capability tiers, with usage limits potentially applying. Exact tier entitlement boundaries are not established by the reproduced evidence.
- Licensing
- AI Actions are described as metered; precise consumption limits are not established by the reproduced evidence.
- External model or provider
- Not fixed. Model and provider are configurable, including an Auto option; no specific model or provider is attributed.
- Limitations and uncertainty
- Persistent action is established through the documented process-model tool path (for example writing records, updating records, routing cases, starting workflows and downstream processes, and sending notifications). Not every tool performs persistent writes: Query Records is read-only, document tools are retrieval-oriented, and expression rules provide logic and data. External action is recorded as unknown: agent invocation of external MCP Server tools is established, but a specific agent-invoked persistent mutation of an external system is not established by the reproduced evidence. Human confirmation is not established: process agents can operate autonomously with no human present, and builder-designed escalation, manual review, human tasks or confidence thresholds are not a platform-enforced pre-action approval gate. User initiation, authentication, permission checks, process model security, guardrails, audit logging and the ability to interrupt a run are not treated as confirmation. Permission basis is the initiator: Appian states AI features operate with the initiating user permissions and cannot exceed user-level access, and sub-agents inherit the initiating context. MCP connected systems may authenticate with API keys or OAuth client credentials; this is an external system credential arrangement and does not establish a dedicated Appian agent identity, and MCP end-user identity mapping is unresolved. AI Agent/sub-agent invocation is recorded only as a documented tool type within this capability. Further unresolved points: whether an agent-invoked MCP tool can perform a documented persistent external mutation, exact capability-tier entitlements, AI Action consumption limits, and any general native runtime action-confirmation mechanism.
Evidence
- About AI Agents
Supports: General · Function · Primary source
Appian documents AI Agents built in Agent Studio, distinguishing process agents and chat agents.
Agents reason over a configured toolset and select tools to invoke.
- AI Agent Reference
Supports: Function · Actions · Default state · Primary source
Reference describes tool types, tool selection and parallel tool calls within a reasoning step.
Documents that tool execution can produce side effects rather than only generated output.
An agent starts with no configured tools; builders add and configure tools.
- Create and Configure an AI Agent
Supports: Default state · Availability · External model · Primary source
Creating an agent requires explicitly adding and configuring tools before use.
AI Agents are described within Appian advanced and premium capability tiers.
Model and provider are configurable, including an Auto option; no fixed model is attributed.
- Use AI Agents in a Process
Supports: Actions · Human confirmation · Primary source
Process agents invoke process models that can write records, route cases, start workflows and send notifications.
Process agents can operate unattended as part of straight-through processing, with no documented platform approval gate.
- Execute AI Agent Smart Service
Supports: Function · Actions · Primary source
The Execute AI Agent smart service invokes an agent from within a process model.
Establishes the documented path from agent execution to persistent process actions.
- AI Agent Screen Reference
Supports: Function · Data access · Primary source
Screen reference documents system, custom and external tool configuration surfaces.
Query Records and document tools are retrieval-oriented rather than write mechanisms.
- MCP Tools for AI Agents
Supports: External actions · Permission basis · Primary source
Agents can invoke external MCP Server tools; persistent external state change is not established.
MCP connected systems may use API key or OAuth client credentials; no dedicated Appian agent identity is established.
- AI Guardrails
Supports: Permission basis · Admin controls · Limitations · Primary source
Appian states AI features operate with the initiating user permissions and cannot exceed user-level access.
Administrators control AI guardrails and optional AI input and output audit logging.
Guardrails and audit logging are governance controls, not a pre-action confirmation mechanism.