Designing a useful, narrow assistant

The narrow-assistant principle

A narrow assistant does one specific thing well. It has:

• A single, clearly-named user role it serves.
• A specific set of tasks it handles.
• Explicit, publicly-declared limits on what it won’t do.

Compare two designs for a Nepali NGO’s internal AI:

Broad (“just chat with our AI”):

“An AI assistant that can answer any question about our organisation, help you draft anything, and be your workplace companion.”

Narrow (“policy Q&A”):

“A Q&A tool for looking up our HR, grant, and procurement policies. Ask a policy question, get a cited answer. For anything else, contact your team lead.”

The narrow version is defensible. It has clear success criteria (does it correctly answer policy questions?), clear failure modes (it can’t handle non-policy questions), and clear boundaries (users know what it does and doesn’t do). The broad version has none of these — success is undefined, failure is undetectable, and users leave disappointed for reasons no one can articulate.

The five design questions

Before writing prompts or code, answer these five in writing:

1. Who is the user?

Name a real person or narrow role, not “everyone”.

Bad: “Employees at our company.” Good: “Grant program managers at our NGO who need to look up specific procurement rules while writing budgets. Roughly 4 people. Each uses the tool 3-10 times per week.”

Named users lead to specific design decisions. “Everyone” leads to bloat.

2. What single job does the assistant do?

One primary task, stated as a verb + object.

Bad: “Help with HR.” Good: “Look up specific answers in the HR policy manual and return them with source citations.”

The verb is look up. The object is specific answers in the HR policy manual. Everything else is out of scope.

3. What is explicitly out of scope?

The most important part. State what the assistant won’t do so users know when to look elsewhere.

Good scope-out list:

• Legal advice, even for HR-adjacent questions
• Medical information, including sick leave (redirect to HR person)
• Interpreting policies (the tool retrieves; a human interprets)
• Answering questions about people (no personnel data)
• Multi-step reasoning across many policies (retrieval finds one policy at a time)

Every declared out-of-scope becomes a natural refusal the assistant can give (“I don’t handle legal advice; please consult HR”).

4. What does success look like?

A measurable outcome, not a vibe.

Bad: “Users are happy.” Good: “80% of policy questions asked in a week are correctly answered with a cited source, verified by weekly review of a random sample of 20 interactions.”

Measurable success creates accountability and lets you iterate against a target.

5. What are the honest failure modes?

Name them upfront. If you can’t name them, you haven’t thought hard enough.

A working list:

• Retrieval misses the relevant policy → user has to rephrase or ask a human.
• Multiple policies conflict → assistant returns both; user must choose.
• Question is about a person → declines; redirects.
• Question is out of scope → declines; suggests where to go.
• Model hallucinates despite RAG grounding → weekly audit catches this.

Naming failures makes them addressable. Ignoring them makes them ambush you later.

Naming the assistant

A named assistant is more usable than an anonymous one. Not because names have magic power, but because a name forces you to commit to a personality — cheerful vs. formal, verbose vs. terse, warm vs. crisp — that stays consistent across the app.

Good assistant names:

• Short (one or two syllables).
• Culturally appropriate (Nepali names for Nepali users; not “Alexa” or “Siri” which feel imported).
• Not confused with the app’s actual name.
• Not misleading about capabilities (don’t call it “Dr. AI” if it can’t give medical advice).

Examples for Nepali contexts:

• chiya — for a general Nepali chat assistant (we used this in Chapter 3).
• niyam (नियम, “rules”) — for a policy Q&A bot.
• kirana (किराना, “grocery store”) — for a small-shop assistant.
• darwan (दरवान, “gatekeeper”) — for a security/access-control assistant.

Choose warmth and specificity. Avoid grandiosity.

The scope-declaration principle

Explicitly declare the scope in the assistant’s system prompt AND in the user interface. Not just once, in both places.

In the system prompt:

"You are niyam, a policy Q&A tool for our NGO. You answer questions
about HR, grants, and procurement policies using the retrieved
passages provided.

You do NOT:
- Give legal advice.
- Give medical advice.
- Handle questions about specific people or personnel data.
- Interpret policies — only retrieve them.
- Answer questions unrelated to our organisation's policies.

For any of the above, politely decline and suggest the appropriate
contact (HR person, team lead, legal counsel)."

In the UI (a visible banner or intro text):

"niyam looks up NGO policy answers from our HR, grants, and
procurement documents. It cannot give legal or medical advice,
and cannot answer questions about specific people. For those,
contact your team lead or HR."

Both matter. The system prompt shapes behaviour; the UI shapes expectation. Users who know what the tool does never feel misled by it.

A worked design — the NGO policy assistant

Applied end-to-end to the assistant we built in Chapter 5:

## Name
niyam (नियम, "rules")

## User
Grant program managers, HR staff, and procurement officers at our
NGO. Roughly 15 people, using the tool 3-10 times per week each.

## Single job
Look up specific rules, policies, or procedures in our internal
policy documents (HR manual, grant policies, procurement guidelines)
and return them with source citations.

## Out of scope (explicit)
- Legal advice
- Medical advice
- Questions about specific people or personnel data
- Interpreting policies (returns text, doesn't reason)
- Anything outside HR / grants / procurement
- Real-time information (payroll balances, project status)

## Success metric
Weekly review: 80% of the 20 randomly sampled interactions correctly
answer the user's question with a citation to the right source
document.

## Failure modes
1. Retrieval misses relevant policy → user rephrases; if repeated,
   log for retrieval improvement.
2. Question is out of scope → assistant declines; suggests contact.
3. Multiple policies apply → returns each with sources; user judges.
4. Hallucinated answer despite RAG → caught in weekly audit; treat
   as bug.
5. Nepali/English phrasing mismatch causes miss → improve retrieval,
   consider query rewriting.

## What's next after v1
- Add feedback thumbs (up/down) per answer.
- Track "I don't know" rate weekly.
- Add per-document access control (later; not v1 concern).

One page. Every design decision downstream is justified by, or contradicts, something on this page. This is what serious product design looks like at the LLM app scale.

The temptation to expand

You will be tempted, once niyam works, to expand its scope. “It’s already good at policy Q&A — can we also make it draft the response emails?” “Can we make it summarise policy changes?” “Can we plug it into our HR system?”

Each of these is a new product, not a feature. Every expansion doubles the surface area of possible bugs, doubles the number of failure modes to handle, and doubles the design work. The right instinct is:

• Ship niyam v1, get user feedback, prove it works.
• Talk to users about which adjacent problems matter most.
• Design the second product separately, with its own scope document.
• Ship it under a new name if it’s genuinely different, or as niyam v2 if it’s a clean extension.

The wrong instinct — “just add features” — is how the successful policy Q&A becomes a struggling half-baked everything-tool six months later.

Check your understanding

Quick check

—

A colleague proposes an internal AI called 'workspace-buddy' that can 'help with anything.' What's the professional response, in the language of this section?

1. AGreat — the broadest scope is best.
2. BPush back on the scope. Ask: who is the primary user, what specific job does the assistant do, what is explicitly out of scope, and how will we measure success? 'Help with anything' has no defensible answer to any of those. Almost certainly the useful version of this project is one narrow assistant (e.g. 'policy Q&A' or 'meeting notes summariser') rather than one broad one. Convert 'anything' into a specific task; expand later if it works.
3. CSuggest making it broader.
4. DSuggest naming it after the CEO.

Check answer→

Quick check

—

A narrow assistant has just launched and users are asking for a feature — automatic email drafting based on retrieved policies. What's the right sequence of moves?

1. AAdd the feature immediately.
2. BSlow down. Talk to users about how important this actually is. Design the email-drafting task as a separate scoped product (with its own users, job, out-of-scope list, success metric, failure modes). Ship it as a distinct sub-tool or feature only after prototyping and evaluation. Feature-creep — adding capabilities without repeating the design process — is how narrow assistants become confused broad ones. Preserve the narrow success by scoping additions deliberately.
3. CRefuse forever.
4. DRebrand and start over.

Check answer→

What comes next

You’ve scoped the assistant. The next section adds tools and data connections — the technical mechanisms (function calling, tool use) that let the model act, not just talk. And the last section handles testing for safety, bias, and Nepali context — the pre-launch discipline that separates useful assistants from harmful ones.