Using the Build Agent Effectively

The UnqorkAI Build Agent can accelerate development significantly: configuring complex logic, debugging unexpected behavior, explaining unfamiliar concepts, and drafting configurations for review. Used well, the agent reduces the time between idea and working solution.

When used without care, it introduces errors that are harder to find than mistakes made manually. The agent's output tends to look confident and complete even when it is wrong.

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 IDE, 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 IDE.

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 SSE 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 quality of the agent's assistance depends heavily on how clearly the task is described. Vague prompts produce vague answers.

• Be specific about the goal. Describe the full context: what the module has, what the outcome needs to be, and what is currently happening.

• Include relevant details. Component names, property IDs,  conditions, and what has already been tried all help the agent give a more accurate response.

• State constraints explicitly. If the solution must meet specific requirements, say so upfront instead of waiting for the agent to ask.

• Ask for explanations, not only answers. Understanding why a suggestion works makes it easier to evaluate whether it is correct and builds knowledge for future problems.

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 uses Gemini, which has a significantly larger context window than most AI models. 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 SSE Debugger for server-side logic. If the agent helps configure a server-side execute, use the SSE 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 IDE, 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 IDE. 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.