Build Agent Reference

The Build Agent is an AI assistant in the Module Builder. Describe what you want in plain language. The agent creates a plan, builds the components, connects the logic, and runs tests to verify the result.

The Build Agent can:

• Build modules and multi-module applications from plain-language descriptions.

• Create, edit, and use Smart Components across modules.

• Generate complex logic or data transformations.

• Edit existing applications and modules.

• Understand, explain, and debug module configurations.

• Automate repetitive configuration tasks.

• Analyze configurations for accessibility improvements.

• Work across modules in the same workspace — reading any module for context, writing to modules in other applications with confirmation.

Accessing the Build Agent

The Build Agent panel displays on the left side of the Module Builder. The panel has two tabs: Active Task for the live conversation, and History for all past tasks and plans. See Build Agent for the full panel reference.

How the Build Agent Works

When you send a message, the agent:

1. Reads your module's current state — all components, settings, and connections.

2. Understands your request — interprets the natural language instruction.

3. Creates a plan — in Plan & Build mode (the default), the agent generates a structured plan before building anything. Review the plan, then select Build Plan to proceed.

4. Executes — creates components, sets configurations, and generates logic. The agent self-corrects issues it encounters during execution.

5. Runs tests — if Auto-test is on, tests run automatically to validate the result.

6. Summarizes — lists all components configured, tests passed, and tasks completed.

During execution, Reasoning and Tool Calls display as collapsible items in the chat. Expand them to see the agent's internal thinking and the actions it is taking at each step.

When the agent needs more information to proceed, it pauses and displays a question with selectable options in the chat. Respond to continue.

Writing Effective Instructions

Clear instructions produce better results.

Be Specific

Tell the agent exactly what you want, not the general idea alone.

Vague:

Add a form.

Specific:

Create a contact form with fields for first name, last name, and email address. Make all fields required. Submit the data when the Creator clicks the button.

Once the agent builds the form, use follow-up prompts to refine it incrementally:

Add validation to show an error message if the email address format is invalid.

After successful submission, navigate the Creator to a confirmation page.

Describe the Goal, Not the Steps

Let the agent figure out the implementation. Describe what you want to accomplish, not how to do it.

Step-by-step:

Create a Data Workflow component. Add a filter operator. Configure the input and output fields manually.

Goal-oriented:

Filter the submission data to only include records where status equals 'approved'.

Provide Context

If the agent must work with existing components or data, mention them by name. Use @ in the prompt field to mention a specific module or application from the current workspace — the mentioned item appears as a chip in the context strip and is included as context in the next message.

Without context:

Add a filter.

With context:

Add a Data Workflow component that filters the data in the submissionData Hidden component to only include records from the last 30 days.  the result to filteredData.

Use Examples

When the result depends on specific values or formats, give examples.

Without example:

Format the phone number.

With example:

Format the phone number in the format (555) 123-4567. Take the raw value from phoneInput and output the formatted result to formattedPhone.

Smart Components

For many tasks, the Build Agent creates Smart Components: reusable component definitions. The agent chooses between a Smart Component and a standard component based on what the task requires.

Logic Smart Components handle data processing. They run when triggered and return output data. Logic Smart Components are Private by default; when promoted to Public, they appear in the component tray.

UI Smart Components render interface elements: forms, displays, and custom layouts. They receive data from submission data and other components and return data to the module through their output type. UI Smart Components are Private by default.

Both types are created as Private components. To reuse a Build Agent-created Smart Component across modules, open it in the Module Builder, select the Smart Component to open the Focused Smart Component View, and select Make Public. See Using Smart Components in a Module for editing and promoting details.

Common Use Cases

Collecting User Input

Describe the fields, validation requirements, and how data should be submitted.

You:

Create a contact form with fields for first name, last name, and email address. Make all fields required. Add a Button component with a Submit label.

The agent will:

1. Create three input components (Text Field components for names, Email component for email address).

2. Set each field's Required toggle to ON.

3. Add a Button component labeled Submit.

4. Connect the Button component to  submission logic.

The agent might also add an Initializer component to configure the module's initial state, following Unqork best practices.

Connecting Components

The Build Agent wires triggers between components without manual configuration. Describe the interaction and the agent sets up the trigger chain.

You:

When the btnSearch button is clicked, trigger the plugDataFetch Plug-In component. After the Plug-In component completes, trigger the dwProcessResults Data Workflow component.

The agent will:

1. Set btnSearch's On Click to the Property ID of plugDataFetch.

2. Set plugDataFetch's Post Trigger to the Property ID of dwProcessResults.

Debugging and Explaining

The Build Agent can read your module and explain what's happening. Ask it why a component or configuration isn't working and it will inspect the relevant components, identify the issue, and suggest a fix.

You:

The btnSubmit button has an On Click trigger set but the form isn't submitting. What's wrong?

The agent will:

1. Read the btnSubmit configuration.

2. Identify that an Event action type only fires the trigger and bypasses form validation and submission.

3. Explain the correct configuration based on your submission method, whether saving to Unqork's database or calling an external API.

4. Offer to update the button configuration for you.

Working Across Modules

The Build Agent can read any module in the workspace to inform what it builds in the target module. It can also write to modules in other applications in the same workspace.

You:

Read the orderApi module to understand the submission data structure, then build a dashboard in this module that displays and filters the order data.

The agent will:

1. Read the referenced module to understand its structure, components, and data.

2. Use that context to build or plan in the current module.

Cross-application writes require confirmation before executing and are scoped to one application per turn. If the target module is not in Editing mode, the agent displays a lock-refusal card with a one-click action to take the editing lock and retry.

Best Practices

Review the Agent's Changes

Always preview the module after the agent makes changes. Verify the result matches what was intended before moving on.

Refine Iteratively

If the agent produces a result that is close but not right, refine your prompt with more specific instructions and continue in the same task. Describe exactly what to change.

Use Descriptive Property IDs

When you ask the agent to create components, suggest clear Property IDs. Descriptive Property IDs make the module easier to maintain.

The agent defaults to camelCase (like firstName or btnSubmit), which is the recommended convention. To use a different naming style, specify it in your prompt.

Whatever convention you use, avoid the following characters, which will break formula references, logic, and grid expressions:

• Periods (.)

• Dashes (-)

• Spaces

• Brackets ([], ())

Property IDs must also begin with a letter.

You:

Add a Text Field component for the user's first name. Use the Property ID firstNameInput.

Ask the Agent to Explain

If the agent generates logic you don't understand, ask it to explain.

You:

Explain what the Data Workflow component you just created does.

The agent will:

• Walk through each step of the pipeline.

• Explain what data goes in and what comes out.

• Describe why each transformation is needed.

Limitations

The Agent Cannot

• Access external systems directly: The agent cannot connect to external databases or APIs on its own. It can call services already registered in Services Administration — configure the service there first, then ask the agent to wire up the Plug-In component that calls it.

• Build or run Workflow Builder workflows: The agent builds modules. It cannot create or execute workflows in the Workflow Builder. To incorporate the agent's work into a workflow, build the required modules with the agent first, then attach them to the workflow manually.

• Modify styles, themes, or CSS: The agent has no access to style or theme tools. Style changes must be made in Style Administration for standard components, or in the Smart Component Theme Builder for Smart Components.

• Deploy changes: The agent modifies the module configuration in the Module Builder. Creators must save and publish the module manually.

• Access production data: The agent cannot read or modify submissions from production applications.

• Set RBAC or manage roles: The agent cannot configure role-based access control. Role management must be done through Creator Role Administration and Express Role Administration.

Tasks

The Build Agent organizes conversations into tasks. Each task begins with a prompt and contains the full conversation, plan, and build history for that piece of work. Task history is saved automatically and persists across browser sessions.

Select the (New Task) button in the Build Agent panel header to begin a new task.

The History tab displays all tasks and plans for the current module, grouped by time (Today, Yesterday, Older). Each task row shows the first message as the title and a timestamp of the last update. An active indicator on the left edge of the row marks the currently open task.

Select the (ellipsis) button on a task row to open the task actions menu.

Use the Search tasks and plans... field, Tasks and Plans toggle pills, and Status dropdown at the top of the History tab to filter and find specific tasks and plans.

Plans

When Mode is set to Plan & Build, the agent creates a plan before building. Plans appear as indented rows beneath their parent task in the History tab. Each plan row shows the plan title and a status badge.

Rollback

A Rollback checkpoint displays in the Active Task tab at key stages during execution. Selecting it rewinds all agent changes — module configuration, conversation history, plans, and tests — to the state at that checkpoint. A confirmation dialog displays before the rollback runs.

Rollback cannot be undone.

To stop an in-progress build, select Stop Build in the Active Task tab. Stopping halts execution but does not remove components the agent already added. Use Rollback to fully revert the module, or remove unwanted components manually.

Managing Tests

Tests generated by the Build Agent are accessible in the Tests area of the Module Builder — select Tests in the area selector above the canvas. The Tests area is only available when AI is enabled in the environment.

The Tests area has two panels:

• Left panel: Lists all test cases with their name, description, and status. Use the search field, Active/Inactive filter, Run All button, and Create Test button to manage the list.

• Right panel: Shows the selected test's full details and a Test History table of past runs, each showing the date, time, and execution time.

Version History

The Build Agent automatically saves each change as a minor version during a session. To view and restore previous versions, select History in the Module Builder area selector, then open the Module History view.

Prompt Input

Type your prompt in the input field at the bottom of the Active Task tab. Press Enter to send or Shift+Enter to add a new line. The field accepts up to 100,000 characters.

Type @ to open the mention popup. The popup lists modules and applications in the current workspace — type to filter, then select an item to add it to the context strip above the prompt. The item is included as context in the next message sent. Select × on any context chip to remove it.

Select the Attachments button to attach a file. The agent reads the attachment and uses it as context for your prompt.

Maximum file size: 10 MB per attachment.

Agent Configuration

The composer toolbar displays two configuration chips: Mode and Approvals. Select either chip to open its selector and adjust how the Build Agent behaves.

Mode sets the agent's approach to a request.

The Mode selector includes two toggles. Both are disabled when Mode is set to Ask.

Approvals controls whether the Build Agent pauses for confirmation during execution. This selector is unavailable when Mode is set to Ask.

Manual is the default setting. Use Manual when reviewing every change matters, such as when working in a production-adjacent environment. Use Protected to speed up builds while retaining a check before deletions. Use Automatic only when full autonomy is intentional — the agent will delete components and data without confirmation.

A risk caption displays below the prompt input when certain mode and approval combinations are active:

Data and Privacy

When a Creator sends a message, the agent may include module configuration data from the environment for context.

Troubleshooting

Tests Fail on Slow-Loading Applications

The Build Agent automatically extends its wait time when it detects that an application is slow to load, up to a maximum of 15 seconds. If an application consistently takes longer, for example because it queries a slow external data source, the agent might take a screenshot before the data loads. The test is then marked as failed even though the application is working correctly.

To work around this, tell the agent explicitly how long to wait before capturing a screenshot:

"It is normal for this application to take about 20 seconds to load. Wait at least 30 seconds before taking the screenshot."

The Build Agent respects explicit wait time instructions and overrides the automatic cap.

Build Agent Does Not Detect Manual Changes

The Build Agent tracks module state through the UnqorkAI platform. Changes made outside the agent during an active session are not detected automatically. This includes a Creator manually editing a component, deleting a test, or modifying a module in a separate tab.

If manual changes affect what the agent does next, tell it explicitly before continuing:

"I manually updated @MyModel. Read it again before updating the title."

Providing this context prevents the agent from building on outdated module state.