Meeting Transcripts → Delivery Documents
Turns a project's meetings into an Executive Summary, a High-Level Requirements Document, User Stories or a Timeline Matrix, in the same templated structure every time, through a one-call fast pipeline or a two-stage or chained one.
Workflow
From “A document request in chat, or a persona's guided questions” to result
- 1. Trigger
Document requested
Intent detection spots a document request in chat, or a persona flow collects the project, the document type and the time period.
- 2. Action
Gather the project's meetings
Chunks that mention the project are kept, and up to 30 of them are joined into one transcript.
- 3. Action
Unified extraction
One LLM call returns a single JSON with the requirements, users, decisions, actions, risks and timeline the four documents need.
- 4. Action
Format to the template
Deterministic code formats that JSON into the requested document: Executive Summary, HLRD, User Stories or Timeline Matrix.
- 5. Action
Render Markdown
A document formatter turns the structured result into Markdown for the chat.
- 6. Output
Document delivered
The document appears in chat, where it can be copied or exported as a branded PDF.
Problem
A project's decisions, needs and actions are spread across 90 to 120 days of meeting transcripts. Writing an executive summary or a requirements document meant digging through all of them by hand and writing the document from scratch, in a different shape each time. This automation extracts everything a project's meetings say and writes it into fixed document templates, so the same document always comes out in the same structure.
Architecture
The steps above are the fast mode, the default: one LLM call, then formatting in code. Two other modes share the same four document types and formatters. The two-stage mode makes two calls per document. Stage 1 runs an "extract everything, over-extract" prompt at temperature 0.2 with up to 4000 tokens; after a pause to respect rate limits, Stage 2 synthesises the structured document at temperature 0.25–0.3 with 6000–8000 tokens, and the JSON is parsed and repaired. The chained mode runs the documents in order: Executive Summary, then HLRD, then User Stories, then Timeline Matrix. The requested document decides how far the chain goes. Each stage produces a full output for display and a compressed chain output of about 800 tokens, at most 10 items per list and 20 words per item, which the next stage reads. HLRD results are cached for an hour. The prompt library is a set of JSON files, one per stage and document, each holding its stage, temperature and token settings, system prompt, extraction categories and user prompt template. For meeting summaries, a template selector scores keywords in the request: 8 or more points picks the detailed template, 4 or more the simplified one, and anything lower the minimal one. Five personas (Product Owner, Delivery Head, Business Analyst, Scrum Master and General User) wrap the pipeline in a guided flow, and each one leads to its own primary document.
Two-stage: extract first, then write
- 1. Input
Project transcript
- 2. AI
Stage 1: extract facts
Over-extract everything relevant
temp 0.2, max 4000 tokens - 3. Action
Pause
Respect rate limits
- 4. AI
Stage 2: write document
Structured synthesis prompt
temp 0.25–0.3, 6000–8000 tokens - 5. Action
Parse & repair JSON
- 6. Output
Templated document
The chained pipeline's hand-offs
- 1. AI
Executive Summary
- 2. AI
HLRD
Cached for 1 hour
- 3. AI
User Stories
Acceptance criteria, epics, points
- 4. Output
Timeline Matrix
Phases, owners, risks
Chained generation, explained
THE CONCEPT
Chained document generation
THINK OF IT LIKE
A relay race
Chained document generation is like A relay race
- Each document is one stageis like Each runner runs one leg
- The ≤800-token chain outputis like The baton: small and easy to pass
- The full output stays for displayis like The runner keeps their own race kit
- The requested document sets where the chain stopsis like The race can end after any leg
Input
A project name, a time range, and that project's meeting chunks from the search index.
A persona's guided questions
stateDiagram-v2 [*] --> detecting: persona trigger or choice detecting --> confirming: persona matched confirming --> collecting: user confirms confirming --> cancelled: user declines collecting --> collecting: ask or repeat question collecting --> ready: all answers recorded ready --> processing: map to pipeline processing --> completed: document returned completed --> [*] cancelled --> [*]
Output
A Markdown document in one of four fixed structures (Executive Summary, HLRD with IDs such as BG-001 and FR-001, User Stories in As a / I want / so that form with acceptance criteria, epics and story points, or a Timeline Matrix with phases, owners, dependencies and risks), ready to copy or export as a PDF.
Integrations
Limitations
On Groq, the multi-call modes ran into rate limits, which needed 15-second pauses between stages and single-stage fallbacks. The two-stage document services call Groq directly, so they don't get the Ollama fallback. Nothing reviews a stage's output before the next stage reads it, so a weak Executive Summary weakens everything after it in the chain. Three of the executive-summary prompt files are no longer loaded: the live prompts are inline copies. Persona sessions are shared across the process rather than kept per user.
Security Notes
Model API keys are read from git-ignored .env files. The API itself has no authentication yet; per-user access is part of the planned redesign.
Learnings
Rate limits, not model quality, drove the design. The one-call fast mode became the default because it is faster and avoids rate limits, and the richer two-stage mode is kept for when the extra depth is worth the extra calls. The two-stage design splits extraction from writing: the model lists every relevant fact first, then writes the document from that list. Templating each document completely is what keeps the output in the same structure every time.