How to Design a Narrow AI Assistant

How to Design a Narrow AI Assistant

Design a narrow AI assistant by defining one intended user, one observable job, approved evidence, a required output, explicit non-goals, authority limits, escalation behavior, test cases, and an accountable owner before choosing its personality.

A name and tone can make an assistant pleasant. They cannot make its work dependable.

flowchart LR
    A["One user"] --> B["One job"]
    B --> C["Approved evidence"]
    C --> D["Required output"]
    D --> E["Limits and escalation"]
    E --> F["Representative tests"]
    F --> G["Accountable owner"]

Write the job as an observable transformation

"Help with marketing" is too broad. "Turn an approved episode transcript into three title options, each with a one-sentence rationale and no unsupported guest claims" can be observed and reviewed.

Describe the input, operation, output, and decision that follows. Identify who uses the result and what happens if it is wrong.

If the output changes a customer record, sends a message, offers health or legal guidance, moves money, executes code, or represents a person, the consequence is higher. Narrow the scope and add stronger review.

Name the intended user

The same assistant may behave differently for a domain expert, a new employee, a customer, or the general public.

Record what the user is expected to know, what access they have, what language and accessibility needs apply, and when they need a human.

An assistant designed for the public must assume that some users will misunderstand its role, test its boundaries, or try to manipulate it.

Approve the evidence

List the sources the assistant may use and the facts it must not invent.

For a source-grounded assistant, record the owner, version, effective date, rights basis, sensitivity, audience, source location, and removal path for each item. Define what happens when sources disagree or when no approved source answers the question.

Instructions can tell an assistant to stay grounded. They cannot prove that retrieval worked or that the answer faithfully used the retrieved text.

Specify the output

Define required sections, length, voice, citations, structured fields, uncertainty language, and prohibited claims.

Google's current prompt design guidance explains how clear instructions, constraints, context, and few-shot examples can shape model output. That is a starting point. The output still needs testing on the chosen model and task.

If another system consumes the answer, use a validated schema where available. Do not depend on prose instructions alone to protect a database or authorize an action.

Declare non-goals and authority

Write what the assistant must not do.

Useful non-goals might include diagnosing a condition, interpreting a contract, speaking for an executive, inventing product availability, exposing private records, contacting a customer, or executing an irreversible action.

Separate recommendation from execution. A model can draft a proposed response without having permission to send it.

For tool use, validate arguments outside the model, apply authorization at execution time, minimize permissions, and require human approval for consequential actions.

Design escalation and refusal

A refusal should help the user move forward safely. It should identify the boundary, state what information is missing, and offer an allowed next step when one exists.

Escalation needs a destination. Name the person, queue, or process that receives the case. Define what context can be transferred and what should remain private.

Test polite, urgent, hostile, misleading, and indirect attempts to cross the boundary.

Build examples and blind tests

Examples should cover routine success, ambiguity, missing evidence, conflict, edge cases, out-of-scope requests, and failure recovery.

Keep a separate blind test set that is not included in the assistant's configuration. Otherwise, the team may only prove that the model can echo the examples it already saw.

Episode 28 captured this loop in a small way. Curio produced flat lists, so Dalton changed the instruction toward storytelling and tried again. The important move was naming a visible failure.

Use [[How to Write Conversation Examples That Test Behavior]] to turn that instinct into a versioned test set.

Assign ownership and change control

Record who owns the prompt, sources, evaluation, access, monitoring, incidents, and retirement.

Every meaningful change to the model, prompt, examples, sources, retrieval, tools, policy, audience, or consequence should trigger proportionate reevaluation.

The NIST Generative AI Profile frames generative AI risk across the lifecycle. OWASP's Top 10 for LLM Applications adds application-security concerns such as prompt injection and sensitive information disclosure.

Use a one-page contract

The contract should fit on one page before the build expands. It should contain the user, job, inputs, approved evidence, output, non-goals, authority, escalation, evaluation, owner, monitoring, and shutdown condition.

If the team cannot agree on that page, configuration is premature.

For a reusable specification, compare [[How to Design a Reusable AI Assistant]] from episode 33. E028 focuses on narrowing the job before the personality takes over.

This guide was developed with AI assistance from E028, NIST, OWASP, Google AI documentation, and the linked design contract. Dalton Anderson remains the author. Technical, safety, privacy, domain, accessibility, source, and founder review are required before publication or deployment. Publication and deployment are not authorized.