How Composer Works

Composer follows a plan-approve-execute cycle for every request. Composer interprets natural language, translates requests into tasks across design objects, and executes those tasks in dependency order.

This page describes how Composer coordinates multi-object changes and what Composer can do.

Plan-approve-execute cycle

Composer processes every request through a structured cycle that keeps the developer in control at each stage.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

The following walkthrough shows each stage of the cycle as it appears in Composer:

1. Interpret: Composer analyzes the request and identifies which design objects need to be created or modified.
   

   Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

2. Plan: Composer proposes a task plan, or an ordered list of operations. Each task corresponds to one design object operation (create, modify, or wire).
3. Approve: The developer reviews the proposed plan before execution begins. At this stage, the developer sees a high-level description of what Composer intends to do, not the updated code or a diff view. The developer can accept, reject, or request changes to the plan.
   

   Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

4. Execute: Once the plan is approved, Composer carries out each task in sequence, creating or modifying design objects in Appian Designer.
   

   Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

5. Review: After the object updates are complete, the developer can inspect the changes by comparing object versions, course-correct if necessary, and then proceed to the next prompt or step in the plan.

Cross-object reasoning

Composer works within the context of the application in Appian Designer. When a developer makes a request, Composer considers the existing application structure—including record types, their fields and relationships, interfaces, process models, and expression rules—to determine what needs to change. The developer does not need to enumerate every object.

Composer also resolves dependency order automatically. Record types must exist before interfaces can reference them. Process models must reference existing interfaces and record types. Composer sequences tasks accordingly so each object is available when later tasks need it.

For example, if a developer asks Composer to add a start date field to an interface, Composer detects that the field does not exist on the record type. Composer updates the record type first, then adds the field to the interface. The developer sees both changes in the plan before approving.

Error handling

If a task fails during execution, Composer surfaces the error to the developer with details about what went wrong. The developer can then adjust the request, modify the plan, or address the underlying issue before retrying.

Attribution and audit logging

All changes Composer makes are attributed to the developer's user account. Every update appears in version history and audit logs as if the developer made the change directly. Composer does not have a separate user identity.

Composer modes

In the Build view, Composer offers two chat modes you can choose from depending on the type of work you're doing. Select your mode from the dropdown in the Composer chat pane before you start.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

The mode you select applies to the current session.

Chat Mode	Description
Standard	(Default) For structured development work. Use Standard mode when you're executing user stories or building out a planned application.
Fast	For ad-hoc development. Use Fast mode when you want quicker results on smaller, unplanned changes.

Composer capabilities

Composer can plan and execute work across the core building blocks of an Appian application.

Supported design objects

Composer can create and modify the following design objects:

• Interfaces
• Record types
• Expression rules
• Constants
• Connected systems
• Web APIs
• Integrations
• Process models
• Sites
• Groups

Types of operations

Composer performs the following operations:

• Create new objects: Composer generates new design objects from a natural language description.
• Modify existing objects: Composer updates fields, configurations, views, or logic on existing design objects.
• Wire dependencies: Composer connects objects to each other—for example, linking an interface to a record type or wiring a process model to reference an interface.
• Populate reference and sample data: Composer generates realistic data so interfaces and expressions work without validation errors.

Complex operations

Composer handles operations that span multiple objects and require coordination:

• Multi-object coordination: The developer says "Add a field to a record type and update the dashboard to show it." Composer updates both the record type and the interface in dependency order.
• Record action creation: The developer says "Add a record action to edit this case." Composer creates the process model, configures the interface, and wires the record action into the record type.
• Complex expression generation: Composer generates expression rules with sophisticated logic, including conditional branching and data transformations.
• Process workflow configuration: Composer adds nodes, configures smart services, sets up decision logic, and wires inputs and outputs across process models.
• Site structure with role-based visibility: Composer creates sites with pages configured for different user groups.
• AI capabilities planning: Composer plans what needs to be built for AI agents, AI skills, and RPA—and how those capabilities fit into the application. If you're using Composer, see the Board tab for structured automation task breakdowns.

Considerations

Composer has the following limitations and best practices to keep in mind:

• Sequential execution: Composer executes tasks one at a time, not in parallel. Complex requests with many tasks take longer to complete.
• Supported object types: Composer works with the design objects listed in the Supported design objects section. Other object types are not supported.
• Request specificity: Composer performs best with clear, specific requests. Broad requests produce less reliable results than focused requests. For example, "add a field to track loan status on the Loan record type" produces better results than "build me a loan servicing application."

Feedback