This walkthrough builds an AI meeting assistant for a programme management office: it turns consented, transcribed steering and engineering meetings into structured minutes, proposes Jira tasks and answers "what did we decide about X?" with citations. An AI meeting assistant earns trust when every decision and action item it reports points to a timestamped line in the transcript, nothing lands in Jira until the named owner confirms it, and only the people who were entitled to hear a meeting can read its summary. The scenario is illustrative. Jira write patterns are covered in the Jira AI agent project and the chat channel in the Teams AI assistant project, so this article stays on transcripts, extraction, evidence and governance.
Business problem
Illustrative scenario. Consider a global capability centre (GCC) in Hyderabad running a multi-year platform migration for its parent company. The programme management office (PMO) runs weekly steering committees, daily engineering stand-ups, architecture reviews and vendor calls. Decisions are made in all of them, and most are lost within a fortnight.
Minutes are late and uneven. Action items are spoken ("Priya will check the licence position by Friday") but never become tickets. Weeks later, two teams remember the same decision differently, and when leadership asks "did we agree to move the cutover?" the honest answer is "let me ask around".
The customer wants decisions that stay decided and actions that get tracked, not "AI meeting notes". Getting there means sitting with the PMO, the collaboration platform admins, legal, HR and security, which is the Forward Deployed Engineer's job.
Requirements
Discovery with the PMO, collaboration admins, the data protection officer and HR produces this scope.
Functional
- Ingest transcripts of meetings that were recorded and transcribed on the meeting platform with notice and consent.
- Summarise into a fixed structure: decisions, action items (owner, due date), risks, open questions, each with transcript evidence.
- Link tickets mentioned by key ("PLAT-412") or by unambiguous description.
- Propose Jira tasks for action items; the named owner confirms or edits before anything is created.
- Post the summary to the meeting's channel after the organiser approves it.
- Answer questions across past meetings ("what did we decide about the DR region?") with citations to meeting and timestamp.
Non-functional
- Sensitive meetings (HR, legal, disciplinary, commercial negotiations) are never processed.
- Summaries and search results are visible only to attendees and explicitly permitted groups.
- Transcripts and summaries follow a written retention schedule, including deletion.
Success metrics
| Metric | Definition | Owner |
|---|---|---|
| Decision recall | Decisions in human-written minutes that the assistant also captured | PMO |
| Unsupported item rate | Reported items with no valid transcript evidence; target near zero | Engineering |
| Action conversion | Proposed actions confirmed by owners and tracked to closure | PMO |
| Access violations | Summary or answer shown to someone not entitled; target zero | Security |
| Organiser edit effort | How much the organiser changes before approving | PMO |
Architecture
The assistant is event-driven. A meeting ending is the trigger; a human approval is the gate before anything leaves the system.
Meeting platform (recorded + transcribed)
| transcript-ready event
v
Ingest worker
|-- policy gate (opt-out labels)
|-- fetch transcript + attendees
v
Extraction pipeline (LangGraph)
|-- clean + segment
|-- extract items + evidence
|-- verify evidence, link tickets
v
Draft minutes --> organiser review
| |
| approve / edit
v v
Store (Postgres + pgvector, ACLs)
|-- post summary to channel
|-- Jira proposals -> owner confirms
'-- Q&A over decisions (cited)Keep platform code in a thin adapter. Meeting platforms expose transcripts through their own APIs, webhooks, permissions and licensing conditions; check the current docs for your customer's platform rather than assuming a feature exists. Downstream code uses a normalised transcript format, so a new platform costs an adapter.
Data
The raw material is messier than it looks in a demo.
- Transcripts: utterances with speaker label, start and end time and text. Speaker labels come from the platform's diarisation and identity mapping, and they are sometimes wrong.
- Meeting metadata: title, organiser, attendees, invited groups, channel, sensitivity label and recurrence series. Metadata drives both access control and opt-out.
- Directory and Jira data: attendee aliases to resolve "Priya" to one person; ticket data read live, never copied.
- Human-written minutes from past meetings, which become the evaluation set.
Speaker attribution errors
Diarisation fails predictably: a room of people on one microphone appears as one speaker, cross-talk merges, a dial-in shows as a phone number. Treat speaker labels as evidence, not truth:
- Room-device speakers are marked "room" and never become an action owner without a name spoken in the text.
- Owners are inferred from what was said ("Priya, can you take this?" "Yes, I'll do it"); the label is one signal.
- When owner evidence conflicts with the label, the item is flagged "owner unclear" for the organiser instead of guessed.
Accents, Hinglish phrases and jargon ("DR drill", "CAB", vendor product names) also hurt transcription. Use a custom vocabulary where the platform supports it; the first finding is usually that transcript quality, not the model, limits the output.
LLM
A capable model handles extraction, because decisions are often implied ("okay, let's go with option B then"); a smaller, faster model handles cleaning, segmentation and query routing. Use structured outputs so every item has a type, text, owner, due date and evidence spans. Amazon Bedrock, Azure OpenAI or Gemini all fit; keep the provider behind one interface, log the model ID per summary and choose by your evaluation set. Long meetings are extracted per topic segment, then merged.
RAG
Retrieval appears twice: during extraction, to fetch recent decisions from the same programme so the draft can say "this updates the decision of 12 August"; and for "what did we decide about X?", over approved decisions, actions and open questions, each with meeting ID, timestamp and ACL.
Two domain rules matter more than chunk size. Supersession: decisions change, so each stored decision can be marked superseded by a later one, and answers lead with the latest decision while listing earlier ones as history. Approved first: answers prefer organiser-approved minutes over raw transcript segments, and say so when they fall back to unapproved text. Generic chunking, hybrid search and reranking are covered in the RAG knowledge assistant project.
Agent
Extraction is a fixed LangGraph pipeline, not a free-roaming agent, because the same transcript should produce the same minutes; Q&A is a small router.
transcript
v
policy gate --sensitive--> skip + log
v
segment by topic
v
extract candidates (per segment)
v
evidence check --no span--> drop
v
resolve owners, dates, tickets
v
merge + detect supersession
v
draft --> organiser interruptHallucinated action items: require transcript evidence
The worst failure for a meeting summary AI is an invented commitment: "Ravi to deliver the cost model by Monday" when Ravi said nothing of the sort. Trust collapses fast. The defence is structural, not a prompt instruction:
- Every item must cite one or more utterance IDs. The verifier checks the IDs exist and that the cited text actually supports the item (a quote-match plus an entailment check by a second model call).
- Items without valid evidence are dropped, not softened; the draft shows each evidence quote.
- Owner and due date each need their own evidence. "By Friday" is resolved relative to the meeting date and the attendee's time zone, shown as a concrete date, and flagged if the phrase was vague ("soon", "next sprint").
- Suggestions ("we could maybe look at caching") are classified as open questions or ideas, not actions, unless someone accepted them.
Why models produce confident, unsupported text and how to measure it is covered in LLM hallucinations explained.
Organiser review
The graph pauses until the organiser approves, edits or rejects the draft; edits become labelled corrections for evaluation. Making this approval fast rather than a rubber stamp is covered in human-in-the-loop AI.
If you want guided practice building evidence-checked, approval-gated AI workflows like this, the AI Forward Deployed Engineer course (FDE PRO) covers RAG, LangGraph, MCP, evaluation and deployment over 12 weeks, with Jira in the taught stack. The meeting assistant itself is not one of its five named projects; it applies the same patterns as the Enterprise Knowledge Assistant and the ServiceNow AI Agent via MCP.
Tools
| Tool | Type | Guardrail |
|---|---|---|
| get_transcript(meeting_id) | Read | Only after policy gate passes |
| get_attendees(meeting_id) | Read | Includes invited groups for ACL |
| resolve_person(name, meeting_id) | Read | Searches attendees first, not the whole directory |
| lookup_ticket(key) | Read | Runs as the viewer; hidden if they lack access |
| propose_jira_task(item) | Draft | Creates a proposal record, not a ticket |
| create_jira_task(proposal_id) | Write | Only after the owner confirms |
| post_summary(meeting_id, channel) | Write | Only after organiser approval; channel must match meeting |
Ticket linking and Jira proposals
Explicit keys are matched by pattern and validated against Jira; a missing key is shown as unverified. Described tickets ("the SSO timeout bug") are only suggested as candidate links. For each approved action, the owner receives a proposal with summary, due date, evidence quote and suggested project, and can accept, edit, reassign or reject it. The proposal checks for an existing linked ticket first, so an action about PLAT-412 becomes a comment or sub-task rather than a duplicate. Allow-listed fields, idempotency keys and duplicate detection are covered in the Jira AI agent project.
MCP/API
The meeting platform, Jira and chat posting are exposed through MCP servers, so the extraction service and the Q&A assistant share one tool layer with one permission model. Under the stateless 2026-07-28 specification, each request carries its own protocol version and capabilities, which suits a queue-driven worker that processes meetings independently; see MCP's 2026 spec changes. Webhook ingestion stays a plain authenticated endpoint feeding a queue; MCP is for the tools the pipeline calls.
Security
Consent, notice and opt-out
The assistant processes only meetings that the platform recorded and transcribed with its standard notice to participants, and only for meeting types the customer's policy has approved. Write the policy with legal, HR and the data protection officer before the first pilot:
- The invite and meeting start tell participants that an AI meeting assistant summarises it, and who sees the output.
- HR, legal, disciplinary, health, investigation and commercial-negotiation meetings are opted out by sensitivity label or calendar category, and organisers can opt out any meeting. The gate fails closed: no label on a meeting from an excluded group means skip.
- External participants (vendors, clients) trigger a stricter path: either skip or require the organiser's explicit confirmation that consent covers them.
- Participants can request corrections or removal of their contribution, through a process with a named owner.
Transcripts contain personal data and opinions about colleagues; notice, purpose limitation and rights under India's data protection law are covered in DPDP Act for AI applications.
Access control
A summary inherits the meeting's audience: attendees, invited groups and groups the organiser explicitly permits. ACLs are stored on every decision, action and transcript chunk, and the Q&A path filters by them in the database query before retrieval results reach the model, so a prompt cannot talk its way into another meeting. Ticket titles in summaries are fetched as the viewer. Service identities and delegated tokens are covered in identity and access for AI agents.
Retention
| Artefact | Retention | Notes |
|---|---|---|
| Raw transcript copy | [policy: short window] | Deleted after approval plus a review window |
| Approved minutes and decisions | [policy: records schedule] | Business records of the programme |
| Embeddings and index chunks | Same as their source | Deleted with the source, not left orphaned |
| Traces and logs | [policy: ops window] | Redacted; no full transcript text |
| Legal hold | Overrides deletion | Set only by legal |
Test deletion like a feature: delete a meeting and confirm transcript, chunks, embeddings and cached answers are gone.
Cloud
On AWS: API Gateway for the webhook, a queue, workers on EKS, PostgreSQL with pgvector, Bedrock, Secrets Manager and customer-managed keys, all in the approved region. On Azure, the same shape uses Azure OpenAI, AKS and Azure Database for PostgreSQL. Infrastructure is Terraform. Meetings cluster at the top of the hour, so autoscale workers on queue depth rather than CPU.
Observability
Trace each meeting end to end with OpenTelemetry and Langfuse or LangSmith: policy decision, extraction calls, evidence checks, drops, organiser edits and Jira outcomes. Dashboard items dropped for missing evidence (a spike usually means transcript quality fell), "owner unclear" rate, organiser edits by category (missed decision, wrong owner, wrong date, invented item), proposal acceptance and policy-gate skips with reason, so opt-out coverage is auditable.
Never log full transcript text to the tracing tool; log utterance IDs and hashes.
Evaluation
Against human-written minutes
With permission, collect past meetings that have both a transcript and good human minutes, and have a programme manager label each decision, action (owner, due date), risk and open question with its timestamp.
| Metric | How it is measured |
|---|---|
| Decision recall and precision | Match assistant decisions to reference decisions (judge plus human spot check) |
| Action field accuracy | Owner and due date correct for matched actions |
| Evidence validity | Cited spans exist and support the item; release blocker if it regresses |
| Unsupported items | Items with no reference match and no valid evidence |
| Supersession accuracy | Updated decisions linked to the decision they replace |
| Q&A correctness | Answers cite the right meeting and the latest decision; ACL tests pass |
Human minutes miss things too: when the assistant finds a decision the human missed and the transcript confirms it, update the reference. Agreement between two human minute-takers on a sample sets a realistic ceiling. Add adversarial cases: sarcasm ("sure, let's ship it on Diwali"), hypotheticals, rejected proposals, injected instructions in the transcript and an unlabelled HR meeting the gate must skip.
Deployment
CI runs unit and tool contract tests, the ACL and deletion suites, the opt-out policy suite and the evaluation thresholds; prompts and schemas are versioned behind the same gate. Roll out in stages: PMO-internal meetings with drafts visible only to the organiser; one programme's meetings with organiser approval; Jira proposals; then cross-meeting Q&A once enough approved minutes exist. Meetings with external participants come last.
ROI
All inputs below are hypothetical placeholders, not results. The wider method is in enterprise AI ROI.
| Input | Placeholder | Source |
|---|---|---|
| Meetings processed per month (N) | [placeholder: N] | Ingest logs |
| Minutes saved per meeting writing and circulating notes (W) | [placeholder: W] | Timed sample, before vs after, including review time |
| "What did we decide?" searches answered per month (Q) | [placeholder: Q] | Q&A logs, cited answers only |
| Minutes saved per answered search (S) | [placeholder: S] | PMO survey plus sampled timing |
| Loaded cost per hour (C) | [customer figure] | Finance |
| Monthly run cost (K) | [from billing] | Cloud, model usage, support |
Monthly value = ((N Γ W) + (Q Γ S)) Γ· 60 Γ C. Net value = monthly value β K β amortised build cost. Report action follow-through (confirmed actions closed by their due date, against a baseline period) separately; leadership often cares most about it, but do not convert it to rupees without a defensible method.
Build it yourself
Use synthetic transcripts you write or record yourself with friends who consent, a free Jira Cloud site and a test chat workspace, never real meetings from an employer.
| Milestone | Deliverable |
|---|---|
| 1. Transcript format | Normalised schema, three synthetic meetings with deliberate speaker errors |
| 2. Extraction | Structured output with evidence IDs; verifier that drops unsupported items |
| 3. Review | Organiser approval interrupt; edits stored as labels |
| 4. Jira | Ticket linking with validation; owner-confirmed task creation |
| 5. Q&A | Cited answers with supersession and ACL filtering |
| 6. Governance | Opt-out gate, retention and deletion tests, evaluation against your own minutes, ROI one-pager |
Interviewers will ask how you stop invented action items, handle a wrong speaker label and keep an HR meeting out; keep a one-page answer to each in the repo.
Frequently asked questions
What does an AI meeting assistant do in an enterprise?
It turns transcripts of consented, recorded meetings into structured minutes: decisions, action items with owner and due date, risks and open questions, each backed by transcript evidence. It also links tickets, proposes tasks for owners to confirm and answers questions across past meetings with citations.
How do you stop a meeting summary AI from inventing action items?
Require every item to cite utterances in the transcript, verify that the cited text supports the item, and drop anything without valid evidence. Owner and due date need their own evidence, and the organiser reviews the draft with the quotes shown before anything is shared.
Can it create Jira tickets automatically from meetings?
In this design it only proposes them. The named owner confirms, edits, reassigns or rejects each proposal before a ticket is created, and the assistant checks for an existing linked ticket first to avoid duplicates.
How are sensitive meetings handled?
HR, legal, disciplinary, investigation and commercial-negotiation meetings are opted out by sensitivity label or calendar category, and any organiser can opt out a meeting. The policy gate fails closed, so an unlabelled meeting from an excluded group is skipped.
Who can see the meeting minutes and answers?
Only attendees, invited groups and groups the organiser explicitly permits. Access lists are stored on every item and chunk and enforced in the database query before retrieval, so the assistant cannot quote a meeting the person asking was not entitled to see.
How do you evaluate AI meeting minutes?
Compare them with human-written minutes labelled by a programme manager: decision recall and precision, owner and due date accuracy, evidence validity and unsupported items. Treat human minutes as imperfect, review disagreements against the transcript, and measure agreement between two human minute-takers to set a realistic ceiling.
A meeting assistant that a PMO and legal team will sign off depends less on the summary prompt than on consent, evidence checks, access control and honest evaluation. Cloudsoft FDE PRO trains that end-to-end engineering over 12 weeks with 60+ labs, five enterprise projects, the GlobalBank capstone and placement support until you're placed. Join in the classroom in Ameerpet, beside Ameerpet Metro, or live online; call +91 96660 19191 for a free demo.
