Build Agent Reference

The Build Agent is the IDE's AI assistant for building Unqork modules. 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.

Use the Build Agent to do the following:

• Generate complex logic or data transformations.

• Prototype module structures.

• Understand or debug module configurations.

• Automate repetitive configuration tasks.

Accessing the Build Agent

The Build Agent displays in the Build Agent panel in the left panel of the Module Builder. The panel has two tabs: Active Task and History.

To open the Build Agent:

1. Open any module in the Module Builder.

2. Locate the Build Agent panel in the left panel.

3. Click the tab to open the agent.

How the Build Agent Works

The Build Agent is a conversational AI assistant trained to understand Unqork's platform, components, and patterns. When you send a message, the agent does the following:

1. Reads your module's current state: All components, settings, and connections.

2. Understands your request: Natural language instructions about what you want to build or change.

3. Creates a plan: Generates a task plan in the canvas area covering Analysis, Detailed Component Specifications, Tests, and an Execution Plan before building anything.

4. Waits for approval: The plan displays in the canvas area with an Open status. Review it, then click Build Plan to proceed. The status changes to In Progress while the agent executes.

5. Executes the plan: Creates components, sets configurations, and generates logic. The canvas is locked during this phase. To make manual edits, navigate to the Components tab. The agent self-corrects issues it encounters during execution.

6. Runs tests automatically: Executes the test cases from the plan and displays a Test Execution Report with pass/fail results.

7. Summarizes the result: Lists all components configured, tests passed, and execution tasks completed. The canvas displays a read-only view of the added components. When done, the agent prompts you to begin a New Task for additional work.

During execution, the Build Agent panel displays Reasoning and Tool Calls as collapsible items. These show the agent's internal thinking and the actions it is taking. They are collapsed by default. Expand them to see what the agent is doing at each step.

If the agent encounters an issue it cannot resolve on its own, it displays an Asking for Expert Help message. This is normal behavior. The agent is pausing to request additional context. Provide more specific instructions, relevant documentation, or details about the issue, and the agent will attempt to continue.

The Build Agent can do the following:

• Create components: Add Text Field, Button, Data Workflow, and other components to your module.

• Configure settings: Set labels, Property IDs, triggers, validations, and any other component settings.

• Connect components: Wire triggers, watchers, and data flows between components.

• Read and explain: Describe what a module does, explain component configurations, or identify issues.

• Preview changes: Render the module in the preview pane to show you what the end-user will see.

• Undo changes: Roll back to an earlier version if the result is not what you expected.

• Suggest accessibility improvements: Recommend ARIA labels and ensure components follow accessibility patterns.

• Support testing: Generate test data and simulate API calls to verify logic in API modules.

• Work across multiple modules: Read and understand other modules in your application to inform planning, testing, and development in the current module. The agent can only edit the module it is currently open in. Each module has its own agent instance and conversation context does not transfer between modules.

• Analyze for performance: Review existing configurations and suggest more performant ways to structure logic, like optimizing Data Workflow component configurations.

Writing Effective Instructions

The Build Agent responds to natural language, but 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.

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.

Common Use Cases

Collecting User Input

One of the most common use cases for the Build Agent is generating input forms quickly. Describe the fields you need, any validation requirements, and how the 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 can wire triggers between components without requiring you to configure each setting manually. Describe the interaction you want 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 other modules in your application to inform what it builds in the current module. Open the agent in the module you want to build or modify, then describe the cross-module context you need.

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.

You:

I want to refactor this front-end module to move data submissions and logic into a separate API module. Guide me through the process.

The agent will:

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

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

3. For refactoring guidance, describe which modules to create, what to build in each, and what prompts to use. Execute those steps manually in each module.

Each module has its own the Build Agent instance. Conversation context does not transfer between modules, and the agent can only edit the module it is currently open in.

Best Practices

Start Small

Build modules incrementally. Ask the agent to create one section at a time, test it, then add more. The agent has token limits that can affect performance on large modules. Working in smaller chunks produces more reliable results.

Instead of:

Build a complete user registration system with validation, API calls, and email confirmation.

Start with:

Create a registration form with email and password fields.

Then refine incrementally:

Add email format validation. When the Creator clicks the register button, call the registration API.

Review the Agent's Changes

Always preview the module after the agent makes changes. The agent generates working configurations, but you should verify the result matches your expectations.

Give Feedback

If the agent produces a poor result, click the thumbs down icon in the chat to flag the response. Refine your prompt with more specific instructions and try again.

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 or add a Knowledge Nugget with your team's standard.

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

Output Consistency

The agent's output might vary between runs. The same prompt does not always produce identical results. Component configurations, wiring, and test outcomes can differ. If the agent produces an incomplete or unexpected result, refine your prompt and try again, or configure the affected components manually in the Components tab.

The Agent Cannot

• Access external systems: The agent works in the IDE and cannot connect to external databases, APIs, or services outside the Unqork platform.

• Run workflows: The agent builds and previews modules, but cannot execute Workflow Builder workflows.

• Deploy changes: The agent modifies the module configuration in the IDE. You must save and publish the module manually.

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

• Update roles: The agent cannot manage Creator or Express roles. Role management must be done through Creator Role Administration and Express Role Administration.

When Not to Use the Build Agent

• Learning the platform: If you're new to Unqork, build modules manually first to understand how components work. The agent is a productivity tool, not a learning substitute.

• Complex business rules: For deeply complex logic with many edge cases, writing the configuration manually might give you more control.

• Exact pixel-perfect layouts: The agent focuses on functional configuration. For precise visual design, configure layout components manually.

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.

Click + at the top of the Build Agent panel to begin a new task. Click the list icon to open Previous Tasks, which displays all tasks as tiles showing the original prompt and timestamp. The currently active task displays an Active badge. Click the open icon on any tile to switch back to that task, or the trash icon to delete it permanently.

Deleting a task permanently removes its conversation history. This action cannot be undone.

Knowledge Nuggets

Knowledge Nuggets are context statements that the Build Agent references when generating responses. Nuggets let you provide the agent with environment-specific knowledge to improve the accuracy of its output.

Nuggets must be selected to take effect. Only checked nuggets are injected into the agent's context. Adding a nugget to your list does not select it automatically.

Click the book icon at the top of the Build Agent panel to open Knowledge Nuggets.

You can edit or delete nuggets you own. Default nuggets created by UnqorkAI can be copied but not edited.

Writing Effective Nuggets

Nuggets work best when they capture a specific lesson or constraint the agent would not otherwise know. The most effective nuggets follow a lesson-learned pattern: describe the problem, explain the fix, and include a concrete example.

Effective nuggets:

• Lessons learned: Capture a mistake you encountered and the correct approach. Include the specific configuration or Property ID pattern that resolved it.

• Environment-specific rules: "All Property IDs in this environment must use snake_case."

• Business constraints: "This module must support WCAG 2.1 AA accessibility standards."

• Data structure notes: "The submissionData object always contains a userId field populated by the Initializer component."

• Component conventions: "Always use a Plug-In component for external API calls. Never hardcode endpoints in Data Workflow component pipelines."

Less effective nuggets:

• General platform knowledge: The agent already knows how Unqork components work. For example, "Text Field components store string values."

• Vague guidance: Instructions without a clear, actionable rule. For example, "Build things well."

• Prompt-level instructions: Context that only applies to a single task belongs in the prompt, not a persisted nugget.

Nuggets support up to 100,000 characters, which is enough to include JSON configuration examples alongside the explanation.

Test Case Management

Click the test tube icon at the top of the Build Agent panel to open Test Case Management. Tests generated during a build are saved here and can be run, edited, or deleted at any time.

Tests are organized in a tree by category in the left section of the panel. Select a category or individual test to manage it on the right.

Tests Tab

Logs Tab

Additional Controls

Plans

Use the Plans drop-down at the top of the Build Agent panel to manage plans across tasks. The drop-down shows Active Plans (plans with an open or in-progress status) and Other Plans (completed or cancelled plans). Select All Plans to open Plan Management, a full table view of all plans. Each row shows the plan title, status, created date, and updated date, with a View button to open the plan in the canvas area.

Rollback

Rollback displays as a checkpoint in the Build Agent panel at key stages during execution. Click it to undo the agent's changes up to that point. A confirmation dialog displays every time before the rollback completes.

Important: Rolling back overwrites your current module with the saved checkpoint and deletes all conversation history made after that point. This action cannot be undone.

Rollback reverts the module configuration, conversation history, plans, tests, and the module preview simultaneously.

To stop an in-progress build, click the Stop button in the Build Agent panel. Stopping halts execution but does not remove components the agent already added. Use Rollback after stopping to fully revert the module, or navigate to the Components tab to remove unwanted components manually.

Version History

The Build Agent automatically saves each change as a minor version during a session. To view and restore previous versions, use Module History in the module toolbar.

Prompt Input

Type your prompt in the input field at the bottom of the Build Agent panel. Press Enter to send or Shift+Enter to add a new line. The input supports up to 100,000 characters.

Click the paperclip icon to attach a file. The agent reads the attachment and uses it as context for your prompt.

Maximum file size: 20 MB per attachment.

Agent Tools

Select the Agent Configuration button in the prompt input area to open the configuration panel. These controls configure how the Build Agent behaves during a build.

Auto-Approval controls how the agent handles confirmation prompts. This setting is disabled when Ask Mode is ON.

Data and Privacy

The Build Agent uses Google Gemini to process your requests. When you send a message, the agent might include module configuration data from your environment to provide accurate responses.

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 Unqork 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 generating a plan based on a stale understanding of the module.