Elicitation With an AI Note Taker: The Agenda, the Question Bank, and the Diff

An AI note taker is worth almost nothing on its own. It becomes valuable when it sits between two other steps: a question bank generated from your real artifacts before the workshop, and a diff of the transcript against the current requirements file afterwards. The recording is the cheap part. The preparation and the diff are where the requirements actually come from.

Most teams adopted an AI note taker the same way: someone turned on Teams transcription, the meeting produced a summary, everyone agreed it was quite good, and nothing else changed. The summary went into a channel and the requirements were still written from memory the following week.

That is a waste of the best elicitation instrument you will get this decade. A model can read your entire current specification, your API contract, and ninety minutes of conversation at once, which no human in the room can do. This article is how to use that, as stage one of the requirements to UAT pipeline. The mechanics of transcript extraction in detail are in from an AI note taker to real artifacts; this article is the wider elicitation practice around it. If you want the workshop agendas and interview guides in ready form, they are in The BA Deliverables Template Pack.

Why do most elicitation workshops produce thin requirements?

Because the agenda was written from the analyst’s memory of what is unclear, and memory is a poor index of a system with four hundred fields in it.

Watch what actually happens. The analyst books ninety minutes called “Payments scope workshop”, writes five bullet points, and opens the meeting. Two stakeholders talk about the thing they care about, which is the thing they already understand. The genuinely unspecified behaviour, what happens when a payment is cancelled after acceptance but before settlement, never comes up, because nobody in the room was looking at the state machine.

The fix is not a better facilitator. It is a better agenda, generated from the artifacts rather than from recall.

Generating the agenda and the question bank from artifacts

Before the workshop, hand a model everything that already exists and ask it what is missing. This is the highest value prompt in elicitation and it takes four minutes.

You are preparing a requirements workshop. Attached:
- context/system.md      our system, actors, and vocabulary
- requirements/business.yaml   the requirements agreed so far
- artifacts/openapi.yaml       the current API contract
- artifacts/state-machine.md   the payment lifecycle
- elicitation/2026-09-08-kickoff.md   the last meeting summary

Produce three sections. Quote the artifact for every item.

1. UNSPECIFIED: behaviour visible in the artifacts that no requirement
   covers. For each, name the artifact and the line.
2. CONTRADICTIONS: places where two artifacts disagree. Quote both.
3. QUESTION BANK: up to 25 questions, ranked by the cost of getting
   the answer wrong. For each question give: the question as you would
   ask a business stakeholder, why it matters, and what a good answer
   looks like. Do not ask anything already answered in business.yaml.

Ask nothing generic. Every question must be traceable to something
in the attached artifacts.

The output is qualitatively different from a template checklist. A real run against a payments contract produced these near the top of the ranking:

• “The POST /payments endpoint has no cancel path and the state machine has an ACCP state with no exit to cancelled. If a customer calls at 14:02 about a payment accepted at 14:01, what can the operations team actually do?”
• “business.yaml REQ-007 says rejections are returned within 5 seconds. The contract returns 202 Accepted and a webhook. Does the 5 seconds apply to the webhook, the API response, or the customer notification?”
• “The daily limit is per customer in REQ-014 and per account in the state machine note. Which is it, and what happens to a customer with three accounts?”

Every one of those is a requirement gap that would otherwise have been found in UAT. None of them appear on a generic elicitation checklist, because they only exist in the collision between your specific documents. This is the same discipline as reading an API contract against requirements, applied before the meeting rather than after it.

Take the top twelve questions into the room. Leave the rest for the follow-up email.

Consent, retention, and the meetings you do not record

Say this before the decision to record, not after.

• Announce it. “I am turning on transcription so I do not have to type. It goes to the project Confluence space and is deleted after ninety days. Say so if you would rather I did not.”
• Know your retention. If you cannot answer “how long is this kept and who can read it”, you are not ready to record.
• Do not record three kinds of meeting. Anything about a person’s performance. Any supplier or contract negotiation. Any incident review with live customer data on screen. The value of a transcript never outweighs the exposure in those rooms.
• Redact before the transcript goes into a prompt. Names, account numbers, customer identifiers. A script that replaces them with tokens takes an hour to write and removes the entire class of problem. The full judgement call is in AI guardrails for analysts.

One more practical point: transcription changes behaviour. Some stakeholders speak more carefully when recorded, which is occasionally useful and occasionally the reason you do not get the real answer. If a conversation matters more than the record of it, turn the recorder off and say so.

The extraction prompt, and the instruction that makes it trustworthy

After the meeting, run one extraction. Four outputs, and a hard ban on inference.

Here is a workshop transcript and our current requirements file.

Extract exactly four sections. For every single item, quote the
transcript line that supports it, with the speaker and timestamp.

1. DECISIONS: what was actually decided. Not discussed, decided.
2. ACTIONS: task, owner, due date. If the meeting did not name an
   owner, write OWNER NOT NAMED. If no date, write DATE NOT NAMED.
   Never infer either.
3. REQUIREMENT CANDIDATES: statements that should become or change a
   requirement. Mark each NEW, CHANGES REQ-xxx, or CONTRADICTS REQ-xxx.
4. CONTRADICTIONS: two things said in this meeting that cannot both
   be true, or something said that contradicts business.yaml. Quote both sides.

Rules: do not smooth anything. Do not resolve a disagreement that
was left open, list it as OPEN. If you cannot quote it, do not write it.

The OWNER NOT NAMED instruction sounds trivial and is the difference between a useful artifact and a tidy fiction. Without it, a model assigns every action to the most plausible attendee, the summary looks complete, and in three weeks two of those actions turn out to have been owned by nobody. With it, the follow-up email contains four lines reading OWNER NOT NAMED, which is uncomfortable and correct, and which gets owners assigned within the hour.

The contradiction section is the extraction humans genuinely cannot perform. In a ninety minute workshop, somebody says two incompatible things forty minutes apart, and nobody notices because nobody is holding both halves of the conversation in working memory. A model reading the whole transcript at once catches it every time. In my experience roughly one workshop in three contains at least one, and it is usually about a threshold, a timing, or who approves something.

The diff: the step almost nobody runs

This is the one that earns the recording. After the extraction, run a second pass whose only job is to compare the meeting against the requirements you already have.

Compare the attached transcript against requirements/business.yaml
and requirements/functional.yaml.

Output a table with one row per affected requirement:
| id | current statement | what the meeting said | classification | evidence quote |

Classification is one of:
  CONFIRMED   the meeting restated it as written
  CHANGED     the meeting changed a value, a threshold, or a scope
  CONTRADICTED the meeting stated something incompatible with it
  OPENED      the meeting raised a question the requirement does not answer
  NEW         the meeting introduced something no requirement covers

Then list every requirement in the files that the meeting did not
touch at all, under UNTOUCHED, with no commentary.

Two things fall out of this that hand-written minutes never produce.

The CHANGED rows are your real changelog. A meeting that moves a limit from 50,000 to 75,000 produces one line of conversation and, historically, a specification that still says 50,000 three sprints later. The diff catches it while everyone is still online.

The UNTOUCHED list tells you what to schedule next. After four workshops, the requirements that have never been discussed in any of them are the ones nobody owns. That list is the agenda for workshop five, and it is derived rather than remembered.

Publishing, within ninety minutes

Speed is what converts a transcript into agreement. The follow-up has three destinations and a script should do all three:

1. The meeting summary goes to elicitation/2026-09-15-pacs008-workshop.md in the repository, with the decisions, the actions, the open items, and the evidence quotes. It is the source cited by the source: field on every requirement it produces.
2. The diff goes in the same file, and the CHANGED rows become a pull request against business.yaml. A requirement change is now a reviewable commit with the transcript quote in the message, which is the cleanest audit trail an analyst can leave.
3. The email goes out with three sections and nothing else: decisions, actions with owners, open items needing an answer by a date. Under three hundred words. Anything longer does not get read, and an unread summary is an unconfirmed summary.

The Jira and Confluence side of that publish is a script, and the safe way to wire it is MCP with a scoped API token.

What the note taker cannot do

Four things, and they are the reason you are still in the room.

• Read the room. The transcript records that everyone agreed. It does not record that the operations lead agreed while looking unhappy, which is the agreement that gets reversed on Friday.
• Follow a surprise. When an answer opens a door nobody expected, a human leaves the agenda and walks through it. That is where the requirements worth having come from, and no prepared question bank produces it.
• Notice who is absent. The missing stakeholder generates no text, so no extraction can find them. Only you can look at the attendee list and realise nobody from reconciliation is on it.
• Judge whether an answer is true. A stakeholder confidently describing a process they have not performed in two years sounds exactly like a stakeholder describing it accurately. Verification is your job, usually by testing the system yourself.

The takeaway

Elicitation improves when you move the AI from the middle of the process to both ends of it. Before the meeting, generate the question bank from the artifacts so the agenda covers what is genuinely unspecified rather than what you happened to remember. During the meeting, transcribe with consent. After the meeting, extract with a ban on inference, then diff against the requirements you already have and publish within ninety minutes.

Do that and the workshop stops being a conversation you try to remember and becomes an input to a pipeline. The next stage is giving every candidate a permanent identifier, which is requirements as code. For the workshop agendas, interview guides, and stakeholder maps, see The BA Deliverables Template Pack, and for the prompt library, The Tech BA Prompt Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Requirements, AI, Elicitation, Workshops