An agent writes requirements and notes with confidence, and guesses in them look like facts. The way out is to demand a link, the model’s assumptions and a “fact or not a fact” status for every item. Major and minor edits and the work with use cases follow from these marks. The basis of the approach is in the MCP for an AI agent article.
What to demand from the agent
An agent retells meeting notes and documents smoothly, and you cannot see where the fact ends and the guess begins. So for every item in requirements and notes we ask for three things.
LinkA link to a document or a quote from the meeting record with a timestamp.
AssumptionWhat the agent filled in on its own is written on a separate line.
StatusFact, not a fact, or a question for a person.
Takeaway
In this exampleEvery item has a source, a separate line for the guess and a status.
In generalAn item without a source gets the status “not a fact”, and a person checks it before relying on it. This continues the idea of the section on hallucinations in the MCP article.
What to doAdd the three marks to your template for requirements and meeting notes.
How to ask in notes and requirements
Tell the agent
Parse the meeting record and write a list of requirements. For every item give the source (quote and time), your assumptions on a separate line and a status: fact, not a fact or question. If there is no source, mark it “not a fact”.
Template of one item
Requirement: Card payment
Source: meeting of 12 Oct, 14:32, “the customer pays by card at checkout”
Assumption: payment in one currency only
Status: fact | not a fact | question
Confirmed by: —Takeaway
In this exampleThe meeting record becomes requirements where every line is marked.
In generalA quote with a timestamp makes checking take seconds, and the assumptions line shows where the model filled gaps.
What to doRun one of your meetings through this prompt and compare it with what you remember.
Major and minor changes
The marks show how serious an edit is. A minor one leaves system behavior as is, a major one changes it.
Guess confirmedThe status becomes “fact”, the text stays: a minor edit.
Guess refutedThe item’s text changes: a major edit.
A fact changedIf the new version of the source changes behavior, the edit is major.
WordingA typo or a clearer wording with the same meaning goes to the change history.
Takeaway
In this exampleA minor edit goes to the history, a major one needs approval and a new version.
In generalBy the marks the agent separates edits that can go in at once from those to show the requirement owner.
What to doAgree who confirms major edits and write it into the template.
Use cases
One requirement has several use cases: the normal path, an error, a repeat. An edit affects different cases differently.
Case: normal pathCase: errorCase: repeat
Takeaway
In this exampleThe “Card payment” requirement splits into three cases, and an edit about repeat payment touches only the third.
In generalOn a major edit the agent lists the affected cases, and on a minor one it confirms the cases did not change.
What to doAfter each edit ask the agent to list the affected cases and their tests.
Where to start
Takeaway
In this exampleThree steps: template, prompt, rule.
In generalStart with one meeting and one document: the result is visible within an hour.
What to doToday, parse one meeting record with the template.