Worked Answer: 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.
1. Clarify
Ask:
- Which workflow is in scope for v1?
- Which user roles can use it?
- What sources can retrieval access?
- Which components can be generated?
- Which tools are read-only, draft-only, reversible, or destructive?
- What requires approval?
- What eval failures block launch?
Assumption: v1 supports renewal prep and support-policy lookup for account managers. It can draft messages but cannot send or modify records in beta.
2. Architecture
3. Boundaries
| Boundary | Decision |
|---|---|
| app shell | deterministic navigation, auth, and route ownership |
| retrieval | permission filters before context assembly |
| generated UI | registry-only schemas; no arbitrary HTML |
| tools | server-owned, side-effect classified |
| approval | required for risky/reversible/destructive thresholds |
| fallback | deterministic search/checklist remains available |
4. Component registry
Allowed:
- policy answer card
- citation list
- renewal summary panel
- support ticket list
- email draft panel
- approval request panel
Denied:
- arbitrary iframe
- arbitrary HTML
- raw link button
- destructive action without approval
- payment/discount component in beta
5. Tool risk matrix
| Tool | Class | Approval | Beta |
|---|---|---|---|
| search policies | read | no | yes |
| summarize account | read | no | yes |
| draft email | draft | user review | yes |
| send email | external side effect | explicit approval and audit | no |
| update CRM | durable write | explicit approval, idempotency | no |
| create discount | financial/destructive | specialist review | no |
6. Eval gates
Release blockers:
- unauthorized retrieval
- prompt injection changes policy
- generated UI schema bypass
- unsupported tool call
- inaccessible approval flow
- missing citation on factual claim
- cost per successful workflow above budget
- no deterministic fallback
7. Observability
Trace:
- workflow id
- role and tenant class
- prompt/model/retriever/component versions
- retrieved source ids and freshness
- generated component type
- validation result
- tool request and policy decision
- approval outcome
- correction/rejection reason
- latency and cost
8. Failure modes
| Failure | Behavior |
|---|---|
| retrieval unavailable | ask user to select source or use deterministic search |
| invalid generated UI | render plain summary fallback |
| model timeout | preserve workflow and retry |
| unauthorized source | refuse and log policy denial |
| tool succeeds but stream drops | audit and reconcile through workflow status |
| generated UI inaccessible | disable component version |
Strong close
The key is that the model never owns product authority. Product authority stays in deterministic policy, registry validation, server-side tool controls, approval, audit, and eval gates. I would launch one bounded workflow first, with kill switches for model, retrieval, tool, component, and streaming layers.