A User Story for Your AI Assistant

Most AI assistant projects begin with a feature list: summarize meetings, answer questions, draft emails, update records, create reports.

That is backwards.

A feature tells you what the technology can do. A useful assistant needs a person to serve, a recurring job to support, sources it may trust, evidence it must leave, and a boundary it cannot cross.

Start with one user story that makes those decisions visible.

Copy this AI assistant user story

As a [role], I want an AI assistant to help me [bounded task] using [approved sources], so that I can [observable progress]. The assistant may [allowed actions] and must leave [required evidence]. It must stop or escalate when [condition]. [Human owner] remains accountable for [decision or consequence].

This is not a technical specification. It is an operating agreement that a business owner, builder, reviewer, and user can inspect together.

Fill the worksheet for one recurring job

• The user is:
• The progress they need is:
• The bounded task is:
• The approved sources are:
• When sources conflict, this source governs:
• The assistant may:
• The assistant may not:
• The evidence it must retain is:
• The accountable human is:
• It must escalate when:
• It must stop when:
• We will review the design on:

If those prompts cannot be answered, the project is not ready for more features. It is still missing an agreed job.

A completed example

Imagine an operations leader who spends every Monday gathering updates from project notes, dashboards, and team messages.

The weak requirement is: “Build an AI assistant that prepares my weekly report.” It leaves the sources, authority, and definition of done unresolved.

The stronger user story is:

As the operations leader, I want an AI assistant to prepare a first-draft weekly review from the approved project board, current KPI table, and named exception log, so that I can focus my review on decisions and unresolved risks. The assistant may summarize, compare, and flag gaps. It must cite the governing source for each material status, preserve conflicts, and escalate missing or stale evidence. I approve the final report and remain accountable for any decision communicated from it.

Now the team can test something concrete:

• Did it use only the approved sources?
• Did it preserve conflicting evidence instead of smoothing it over?
• Can the reviewer trace every material status?
• Did it stop when evidence was stale or missing?
• Did the human retain the final decision?

The seven decisions behind the worksheet

1. Who is the user?

Name the role the assistant supports. “The business” is too broad. A workflow owner, operator, reviewer, or customer-facing role has a clearer job and consequence.

2. What progress matters?

Describe what becomes easier to decide or complete. “Save time” is not enough. Better examples include reaching a first reviewable draft, identifying exceptions before a meeting, or reducing repeated source reconstruction.

3. What is the smallest useful task?

Specify the smallest recurring job the assistant should perform. Avoid starting with an all-purpose assistant.

4. Which sources govern?

Name what the assistant may use, which source governs when records conflict, and how freshness is determined.

5. What may it do?

Separate reading, summarizing, drafting, recommending, updating, communicating, approving, and committing. Each action carries a different consequence.

6. What evidence must remain?

Define what the assistant must leave behind: citations, changed fields, unresolved questions, confidence labels, reviewer notes, or a decision record.

7. Who decides, and when must it stop?

Name who approves the consequential result and when the assistant must stop, escalate, expire, or surrender the task.

Test the story before you build

Give the completed story to someone who did not write it. Ask them to reconstruct the workflow.

Can they tell:

• who the assistant serves;
• what progress matters;
• which sources are allowed;
• what the assistant may do;
• who owns the decision;
• what evidence remains;
• what triggers escalation or stop?

If they have to guess, revise the story before adding technology. Ambiguity in the worksheet becomes hidden review burden in the workflow.

Measure burden honestly

The assistant may produce a draft faster while increasing correction, approval, or exception work. Track both the time to the first reviewable artifact and the time to decision-ready evidence.

One well-formed user story will teach you more than a long feature list. It gives the assistant a job, the human an authority boundary, and the organization something concrete to test.

If your source boundary is still unclear, start with Better AI Starts Upstream. For a deeper preflight checklist, read What Should an Agent Know Before It Helps?. If you want help turning the worksheet into a governed operating design, explore AI Operating Architecture and Workflow Design.