Prompt: Design a GenUI Copilot
Prompt
Design a GenUI copilot for customer operations. It answers policy questions, retrieves sources, renders generated UI, calls tools, and asks for approval before risky actions.
Clarifying questions
- What actions can the copilot take?
- Which actions require human approval?
- What sources can retrieval use?
- What generated components are allowed?
- What is the fallback when the model, retrieval, or tool layer fails?
- What evals block release?
Model answer outline
The architecture should keep deterministic product authority:
- fixed app shell and navigation
- server-owned model gateway
- retrieval service with permissions and citations
- registry-only generated components
- schema validation before rendering
- risk-classified tools
- approval UI for irreversible actions
- eval suite for prompts, retrieval, schemas, tools, and injection attempts
- observability for cost, latency, correction, fallback, and tool outcome
Architecture diagram
Key tradeoffs
| Decision | Safer choice | Cost |
|---|---|---|
| UI generation | registry-only components | slower component expansion |
| Tool execution | backend-owned with approvals | more workflow complexity |
| Retrieval | citations and freshness checks | higher latency and eval burden |
| Release | eval-gated canary | slower iteration, safer rollout |
Weak answers
- Model returns arbitrary React or HTML.
- No component validation.
- Tool calls authorized in the browser.
- No citation requirement.
- Evals are manual demos only.
Scoring
Strong answer: deterministic shell, registry contract, RAG policy, tool risk matrix, approval UX, evals, observability, security/privacy boundary, and fallback behavior.
For a complete calibrated answer, read worked-answer-genui-copilot and compare it with capstones/capstone-solution-pack-genui-copilot.