A client wants one assistant for HR, legal and finance, and each has different data rules. What is the key design decision?
Why C is the answer
How to enforce data boundaries, so that one user cannot reach another area
Different data rules make isolation the deciding factor. It has to hold in the architecture, not only in the prompt.
In detail
- Different data rules make isolation the deciding factor.
- It has to hold in the architecture, not only in the prompt.
- Test the boundary with attempts to cross it.
Use case
An illustrative scenario, not a real incident.
One assistant serves HR, legal and finance. Access is enforced by each user's identity at retrieval, so a finance user can never reach HR files, however they ask.
See it in different ways
sequenceDiagram participant U as User participant A as Agent participant S as Source system U->>A: Request with user identity A->>S: Call scoped to that user S-->>A: Only what the user may see
sequenceDiagram participant U as User participant A as Assistant participant S as Source system U->>A: Question, with identity A->>S: Query, scoped to that user S-->>A: Only permitted documents A-->>U: Answer S->>S: Audit log names the user
flowchart TD
Q{"Who is asking?"}
Q -->|"HR staff"| A0["HR data only"]
Q -->|"Legal staff"| A1["Legal data only"]
Q -->|"Finance staff"| A2["Finance data only"]Key point: Isolation belongs in the architecture.
Why the other options are wrong
- A. Which single tone of voice suits all three departments equally well
- Tone does not protect anyone's data.
- B. How many example questions to place in the shared system prompt
- Examples do not create boundaries between departments.
- D. Whether the assistant should have a name and a character of its own
- A name or character has no bearing on access.