Using the Build Agent Effectively

The Build Agent assists with tasks that have clear structure or a well-defined pattern: explaining how parts of a module relate, suggesting debugging starting points, and drafting configurations for review. Incorrect suggestions are common. The agent's output looks confident regardless of accuracy.

How the Build Agent Can Help

The agent works best for tasks that have a clear structure, a known answer, or a well-defined pattern. The following are the strongest use cases:

• Explaining concepts and behavior: How parts of a module relate to each other and why it behaves the way it does.

• Configuration guidance: Which settings to use for a given outcome, what values are valid, and how components connect.

• Debugging starting points: Suggesting where to look when something is not working as expected.

• Drafting logic or configuration: Producing a first version for review instead of a final answer to apply directly.

The agent does not replace understanding. A Creator who does not understand the underlying concept cannot evaluate whether the agent's suggestion is correct. Incorrect suggestions are common.

What the Agent Can and Cannot See

What the Agent Can See

The Build Agent has awareness of the current module context in the UnqorkAI platform, including the following:

• The module structure and component tree.

• Component settings as configured in the properties panel.

• The current mode (UI View, Logic View, Config View) and active state of the UnqorkAI platform.

These capabilities make the agent effective for questions about component configuration, module structure, and how parts of an application relate to each other.

What the Agent Cannot See

The agent cannot access the live application state, which includes the following:

• Submission data from the database.

• Live API responses or network traffic from a running module.

• Environment configuration, service credentials, or RBAC setup.

• What is rendering in Express View or what an end-user is experiencing at a given moment.

For issues that depend on live state, use the tools built for that purpose: DevTools, service logs, the API Debugger, or the Express Preview Bar. The agent can help interpret findings once results are shared with it.

When Not to Use the Agent

The agent adds overhead: prompting, reviewing, and verifying output takes time. For simple, well-understood tasks, that overhead can exceed the benefit. Direct work is often faster when the task is clear, the answer is known, or the steps are straightforward.

A useful test: if verifying the agent's output requires more effort than doing the task directly, skip the agent.

Prompting Effectively

The agent reads the active module's component tree and property settings. Prompts that work with that context produce better results than prompts that describe the UI in general terms.

• Use Property IDs, not labels. Components are referenced by Property ID in the platform's logic layer. "Set the value of totalAmount" is precise; "update the total field" requires the agent to guess which component you mean.

• Name the  condition. Describe when the logic should run: on a button click, when a field changes, on module load. If a trigger is not specified, the agent may default to a pattern that does not match how the module is used.

• Specify the Smart Component type when it matters. If the task calls for a Logic, UI, Query, or Agentic Smart Component, say so. Otherwise the agent picks the type it considers most appropriate.

• Name the output destination. Tell the agent which component should receive the result. Without a target, it may create a new Hidden component instead of writing to an existing one.

• One clear task per prompt for complex builds. Multi-part prompts can produce incomplete results. Break a complex build into sequential steps and send them one at a time.

• Review the plan before building. The agent shows a plan before it builds. Read it — if a component type or Property ID looks wrong, add a comment and click Request Changes before proceeding. Changes after building require a rollback.

Working Iteratively

The agent rarely produces a final answer in one prompt. The typical workflow is a refinement loop: ask, review, push back, narrow, and ask again. Treating the first response as a final answer is one of the most common ways to get poor results. It is a starting point for dialogue, not the end of the conversation.

If a response is close but not quite right, say so specifically. "That's almost right, but X is wrong" produces better results than starting over with a new prompt.

If a response misses the mark entirely, consider whether the original prompt provided enough context. A wrong answer is often a signal to restate the goal more clearly, not to try again with the same prompt.

Session Management

The Build Agent manages context automatically across a session. Sessions stay coherent for longer before context degradation becomes noticeable.

The agent also manages context automatically. When a session approaches its context limit, older conversation history is compressed into a summary, and key module state signals are re-injected so the agent retains awareness of the current configuration. The most recent exchanges are always preserved in full.

In practice, sessions can run longer than with other AI tools before needing a reset. The following are signs that a session must be reset:

• Suggestions begin contradicting earlier advice from the same session.

• The agent asks for information already provided.

• Responses feel generic instead of tailored to the specific problem.

• A simple follow-up question produces a surprisingly long or off-topic answer.

When work shifts to a meaningfully different area of the module, or after resolving a complex issue, beginning a new session avoids carrying stale assumptions into the next problem. New sessions are routine. Provide the agent with relevant context at the start of each one rather than assuming it will reconstruct what was established before.

The Build Agent does not detect manual changes made outside the agent during a session. If a module, test, or component is edited outside the agent, tell it what changed before continuing a task. For example: "I manually updated @MyModel—read it again before updating the title."

Verifying Results

Always test the agent's output before using it. Testing is not optional.

The agent produces plausible-sounding configurations, not verified ones. A result that looks correct might fail in practice. The agent might have worked from incomplete context, made an incorrect assumption, or matched a pattern that does not fit the situation.

Do not skip testing because the agent sounds confident. An incorrect configuration with a detailed, confident explanation is still incorrect. Confidence does not correlate with accuracy.

In Unqork, apply the following verification practices:

• Check settings panels directly. Confirm that the settings the agent recommended exist and match what was configured.

• Preview in Express View. A configuration that looks correct in the Module Builder might behave differently at runtime. Test in Express View before promoting.

• Use the API Debugger for server-side logic. If the agent helps configure a server-side execute, use the API Debugger to verify the execution flow step by step.

• Check service logs for API issues. If the agent suggests a Plug-In component configuration, confirm the call succeeds by reviewing service logs after a test run.

If the Build Agent flags a test as failed on a module that loads slowly, for example one backed by a slow data source, tell the agent explicitly to wait longer before taking its screenshot. The agent respects that instruction and overrides the automatic 15-second cap.

Hallucinations

A hallucination occurs when the agent confidently asserts information that is factually wrong. Hallucinations occur across all AI systems and are not a defect — they are a characteristic of how these models generate responses.

Hallucinations most commonly present as the following:

• Invented settings: The agent describes a component setting that does not exist in the UnqorkAI platform, or uses the wrong name for a real setting.

• Wrong component behavior: The agent states that a component behaves in a way it does not.  types, trigger conditions, and validation behavior are common sources of error.

• Outdated information: Unqork's platform evolves frequently. The agent might reference behavior, settings, or component names from a previous version that no longer apply.

• Plausible but wrong logic: An expression or configuration looks correct but produces incorrect output.

When the agent describes a setting or behavior that does not match what is visible in the settings panel, trust the UnqorkAI platform. Hallucinations are more likely when the prompt is vague, when the topic is highly specific, or when the agent is asked about recent platform changes.

Privacy and Data Safety

Do not include any of the following in agent prompts:

• Credentials, API keys, authentication tokens, or passwords configured in Services Administration.

• Personally identifiable information (PII), including names, email addresses, identification numbers, or any data that identifies a specific person.

• Real end-user responses, form submissions, or production data. Use synthetic or anonymized examples when describing data structure.

• Confidential client or business data not intended for external systems.

• Proprietary configurations or architecture details subject to confidentiality obligations.

Prompt content is transmitted externally for processing. Apply the same judgment to agent prompts as to any other external communication.

Long-Term Projects

AI assistance across a long project requires more intentional management than a single-session question.

• Document decisions, not only outputs. When the agent helps reach a decision, record why, not only the result. Sessions do not persist between conversations, and the reasoning behind a decision is easy to lose.

• Re-brief at the start of each session. Provide a short summary of the relevant module context before asking for help. The agent has no memory of previous sessions.

• Maintain a session handoff document. Some teams keep a brief running document that captures where work stands, what was decided, and what comes next. Update it at the end of each session and paste it at the start of the next.

• Treat output as a starting point. For complex or high-stakes configurations, use the agent's output as a first draft to review and adjust, not a final answer to apply directly.