Skip to main content

​
Writing a Great First Prompt

The better the context you give Architect, the better your app will be — on the first try. A strong initial prompt covers:
  • What you want to build — describe the app in plain terms. You don’t need to mention agents or architecture. Architect will figure those out on its own.
  • The goal — what problem is this app solving, and for whom?
  • Inputs — what data or information will users provide?
  • What the app should do — the core functionality, step by step.
  • Output — what should the user see or receive at the end?
  • Design preferences — any branding, tone, or visual style you have in mind.
  • Integrations — if you want to connect a specific tool or MCP (e.g. Gmail, Slack, a custom API), mention it upfront so Architect builds with that context from the start.
You can write a prompt in just two or three lines — but then expect to iterate more. The more clearly you define goal, inputs, outputs, and functionality upfront, the closer the first build will be to what you want.
You do not need to tell Architect which agents to create. Just describe the app — Architect will decide the agent architecture on its own.

​
Keep Agents Lean

More agents does not mean a better app. In fact, the more agents there are, the higher the chance of hallucination and unexpected behavior. Aim for 4–5 agents maximum for your starting point. Even complex use cases can be handled well within this range. You can always iterate and add more agents later, but start focused. A lean, well-scoped set of agents will produce a more reliable and predictable app than a sprawling one.

​
Before You Start Building

Once you’ve submitted your initial prompt and Architect has generated the PRD and App Mockup, take a moment before hitting Start Building:
  1. Read the PRD — check the agents Architect plans to create, the features it’s scoping in, and the overall structure. If something is off, adjust in the plan phase before any code is written.
  2. Set your theme — this is a good time to create a custom theme, import your design guidelines from Figma or GitHub, or choose a brand style. Doing it before the build means the generated app looks on-brand from the start. → Bring Your Own Design System
  3. Finalize before proceeding — once you’re happy with the PRD and mockup, proceed to build agents, and then to the app. Changes made in the plan phase are much cheaper than changes made after the app is built.

​
Connecting Tools & Integrations

Architect has a built-in list of tools it can connect to directly — you’ll find the full list in the Integrations section. To use any of these, just mention the tool in your prompt and Architect will wire it up. For custom tools or MCPs outside that list:
  • Go to Lyzr Studio, open the agent Architect created, and connect your custom tool or MCP there manually.
  • Architect creates the agents in Studio — any tool you connect in Studio will work inside the Architect app.
If a tool or MCP isn’t working as expected:
  • Open the agent in Lyzr Studio directly and test it by giving it a sample input.
  • Check whether you’re getting the right output from Studio. If it doesn’t work in Studio, it won’t work in Architect either — Studio is where you debug the connection first.

​
Handling Errors

Most errors you’ll see in the app UI are fixable by Architect automatically. If you hit something:
  • Take a screenshot of the error and paste it into the Architect chat.
  • Tell Architect what you were trying to do and what went wrong.
  • Architect will diagnose and fix it on its own in most cases — UI errors, broken components, API errors, missing data.
If a response isn’t coming through, a UI component isn’t rendering, or an agent isn’t behaving correctly — a screenshot plus a clear description is almost always enough for Architect to resolve it.

​
Iterating on Your App

Once your first version is built, keep these in mind as you refine it:
  • Don’t stack multiple unrelated changes in one prompt. If you want to change the design, fix a bug, and add a new agent — send those as separate prompts.
  • Club similar changes together. If you have a few UI tweaks that are related, you can combine them into one prompt. The rule of thumb: changes that touch the same thing can be grouped; changes that touch different parts of the app should be separate.
  • Redeploy when you’re ready. After iterating, check the live preview and press Re-deploy when you’re satisfied. Changes don’t go live until you redeploy. → Deployment

​
Advanced: GitHub for Complex Apps

For high-complexity apps or team collaboration, connect your app to GitHub early:
  1. Connect GitHub from the top-right corner of your app. → Connecting Your GitHub
  2. Every change Architect makes is auto-committed to your repo.
  3. You can clone the repo locally, work on it in your own editor, push changes back to GitHub, and pull them back into Architect.
  4. Use branch switching to work on features in separate branches — create a branch locally, push it, and switch to it in Architect.
This gives you the full flexibility of local development alongside Architect’s AI-powered building.