Context
A UK AI fintech working in financial advice. Advisers meet their clients, and every meeting has to end in written documentation the firm can rely on.
The client’s product records in-person, hybrid and remote advice meetings and turns them into transcripts, meeting summaries, updates to the firm’s CRM, and documents such as suitability reports, annual reviews and client letters, each tied back to the meeting it came from. Summaries and documents follow each firm’s own templates and terminology. By default nothing goes into the CRM until the adviser has reviewed it.
Problem
Writing that documentation by hand takes the adviser’s time after every meeting, and every firm documents a little differently.
A change to one firm’s output took hours: a developer’s time, a code review and a deploy before it went live. Now the firm edits its template itself and sees the change straight away.
Architecture
Twenty steps in four stages: capture the meeting, understand it, generate the outputs the firm asked for, then deliver them through adviser review into the firm’s systems.
01 · Capture
Capture the meeting: a recording becomes a transcript and a queued job.
- 01 Sources Meeting bots join video calls, a mobile app records in-person meetings, and advisers can upload a recording from the browser.
- 02 Transcription A speech-to-text service with a custom vocabulary for financial terms, so product names and fund names come through spelled correctly.
- 03 Event bus “Recording ready” events arrive on an event bus, decoupled from the services that produced them.
- 04 Per-firm queue A FIFO queue grouped per firm keeps one firm’s backlog from reordering another’s.
- 05 Job queue A job table with capacity lanes: a global concurrency cap, a per-firm cap, and separate lanes for reprocessing and priority work, so a bulk re-run never starves live meetings.
- 01 · Capture Capture the meeting: a recording becomes a transcript and a queued job.
- 01 Sources Meeting bots join video calls, a mobile app records in-person meetings, and advisers can upload a recording from the browser.
- 02 Transcription A speech-to-text service with a custom vocabulary for financial terms, so product names and fund names come through spelled correctly.
- 03 Event bus “Recording ready” events arrive on an event bus, decoupled from the services that produced them.
- 04 Per-firm queue A FIFO queue grouped per firm keeps one firm’s backlog from reordering another’s.
- 05 Job queue A job table with capacity lanes: a global concurrency cap, a per-firm cap, and separate lanes for reprocessing and priority work, so a bulk re-run never starves live meetings.
- 02 · Understand Understand it: who said what, and what the firm wants from it.
- 06 Speaker identification An agent works out which speaker is the adviser and which is the client, so outputs can say “the client wants…” rather than “Speaker 2”.
- 07 Meeting narrative The transcript is condensed once into a narrative that every later step reads, instead of each step re-reading the raw transcript.
- 08 Template selection The firm’s published template is picked by meeting type, then adviser, then team, with a firm-wide default as fallback.
- 09 Template → execution graph The template becomes a typed graph of steps. Independent steps run in parallel; shared steps run once and are reused.
- 10 Context assembly For documents, case facts from the meeting, uploaded files and CRM data are assembled into a working knowledge page for the document being written.
- 03 · Generate Generate the outputs the firm asked for: summaries, tables and documents.
- 11 Model gateway One client for every model call: multi-region failover, retries with backoff, and model choice per step.
- 12 Response cache Identical requests are answered from a cache, so a retried job only pays for the steps that had not finished.
- 13 Section summaries Each section of the firm’s template becomes one generation step with its own questions, format and level of detail.
- 14 Typed tables Fact tables with typed columns (text, number, date, currency, choice), extracted and coerced into rows a CRM can take.
- 15 Document generation Report templates are turned into a plan of what each part needs, the gaps become clarification questions for the adviser, and the answers fill a Word document.
- 04 · Deliver Deliver them through adviser review into the firm’s systems.
- 16 Output checks Structured outputs are validated against schemas; tables parsed from model output are checked before they are saved.
- 17 Artifact store Every output and its trace is stored per meeting, with progress shown to the adviser while the job runs.
- 18 Adviser review The adviser edits summaries, answers clarification questions and accepts or rejects document changes.
- 19 CRM delivery Facts and documents are pushed to the firm’s CRM when the adviser chooses to; a firm can opt in to automatic upload.
- 20 Retention Recordings, outputs and caches expire on retention rules, and a firm’s data can be deleted as a whole.
- 05 · Observe & evaluate What runs alongside the pipeline: tracing, evals, cost, rollout and monitoring.
- 21 Tracing OpenTelemetry spans per pipeline run, sent to an LLM observability tool
- 22 Evals golden datasets and LLM judges for summaries and document generation
- 23 Cost token usage recorded per job and per firm
- 24 Rollout feature flags per firm, plus shadow runs of new summary engines next to the live one
- 25 Monitoring alarms on failed jobs and on CRM integration errors and rate limiting
Decisions & trade-offs
-
One graph per meeting, not a queue per step
A meeting is one job. Inside it, the template runs as an in-process graph: independent sections run in parallel, and shared work, such as the narrative, runs once.
TRADE-OFF There is no step-level retry. When a job fails, the whole job is retried, and it has to fit in one serverless invocation (15 minutes). Retries live at the model-call level instead, which is where almost all failures are.
-
Cache whole model responses
Every model response is stored, keyed by a hash of the request. A retried or reprocessed job answers the steps that already ran from the cache and only pays for the rest.
TRADE-OFF The cache matches exact requests only: change one word of a prompt or switch a model and every step misses. It also holds client meeting content, so entries expire after 14 days, which caps how long re-runs stay cheap.
-
Typed output only where a machine reads it
Document generation and fact tables use strict schemas, because a CRM or a Word template consumes them. Meeting summaries stay prose, because advisers read and edit them.
TRADE-OFF Prose sections need parsing and checking code instead of a schema guarantee, and anything that later needs to become a CRM field has to be moved into a typed table first.
-
An adviser in the loop by default
Summaries and documents are drafts until the adviser edits or accepts them, and pushing to the CRM is the adviser’s action.
TRADE-OFF Adviser time on every meeting is the price. It is a default rather than a rule: a firm that trusts its outputs can switch on automatic upload, which moves the responsibility to the firm’s own checks.
-
Outputs non-engineers can define
A firm’s admin defines what the pipeline produces for each meeting type in a no-code template editor: sections, their questions, format and order, and who the template applies to. Templates are drafted, published as immutable versions, and can be rolled back.
TRADE-OFF A template is an ordered list of sections, not a free graph, so admins cannot break a pipeline, but a new kind of step still needs an engineer. Coded per-firm pipelines did not disappear: they run alongside templates, so two things now decide what a meeting produces.
Case study: No-code template editor
Results
- Since 2024in production, ongoing
- 1,000+meetings processed per day
- 20steps from a recording to a reviewed output
Stack
- Node.js
- TypeScript
- AWS Lambda
- EventBridge
- SQS
- DynamoDB
- S3
- Zod
- OpenTelemetry
- LLMs
- Speech-to-text