Extracting summaries, decisions and action items from meetings: how we designed the AI analysis

Turning a meeting recording into text is only half the job. The transcript of a one-hour meeting runs to thousands of words and nobody reads it from start to finish; what people actually want are answers to three questions: What was discussed? What was decided? Who will do what, and by when? The analysis layer of Transify AI exists to answer those three questions. This article explains how we designed that layer and what to watch out for in a similar solution.

#Why a transcript isn't enough

Even a perfect transcript carries the natural messiness of a meeting: unfinished sentences, digressions, the same decision stated three times in different words. A decision is rarely one sentence; more often it arrives at the end of a five-minute discussion as “fine, let's do that”. So analysis is not keyword search but following the flow of a conversation, which is exactly what large language models are good at.

#Designing the output as a structure, not free text

The most important design decision was this: the result of the analysis should not be a paragraph but a data structure with defined fields. Transify's analysis output looks like this:

{
  "summary": "The Q2 marketing budget was discussed...",
  "decisions": [
    "Launch date set for 15 June",
    "30% budget increase for digital channels approved"
  ],
  "actionItems": [
    { "owner": "Ayşe", "task": "Share the launch timeline", "deadline": "22 May" }
  ],
  "keyTopics": ["marketing", "launch", "budget", "Q2"],
  "sentiment": "positive"
}

The structure has three practical benefits:

• It can be passed to other systems: Action items can go to a task manager, decisions to project documentation and the summary to email, each separately. Picking those out of a paragraph would be a second job.
• It looks the same in every format: PDF, DOCX and email are generated from the same fields, so headings and order are always consistent.
• It can be queried: Questions like “how many decisions came out of this meeting, and how many tasks have an owner?” can only be asked of structured data.

#A decision is not an action item

The distinction matters because the two have different readers: decisions are read by people who weren't in the meeting, while action items concern their owners first. Making an action item three-part (who, what, when) is deliberate too; a task with no owner or date is the easiest thing to lose after a meeting.

#Analysis is a separate stage from transcription

In Transify, speech recognition and analysis are not one step but two consecutive stages of the job pipeline. Whisper handles speech recognition and a MiniMax model handles analysis. What the separation brings:

• It is optional: Users who only want a transcript don't wait for analysis; the scope is chosen when the job is started.
• It works on text too: If you already have a transcript you don't need to upload audio; the API's summarise endpoint takes text directly and returns the same structure.
• It can evolve independently: Changing the analysis layer doesn't touch speech recognition, and vice versa.

#What makes Turkish meetings hard

Language is not a detail in meeting analysis. Transify was built Turkish-first, and Turkish business meetings regularly include:

• Mixed language: Sentences that blend Turkish and English terms such as “deadline” or “sprint”.
• Forms of address: “Ayşe Hanım”, “Mehmet Bey”, “our colleague in accounting”: who owns a task is often said indirectly.
• Relative dates: “Tuesday next week”, “by the end of the month”, “after the holiday”: the date only makes sense relative to the day of the meeting.
• Proper names and abbreviations: Product, client and project names and in-house abbreviations are words a general model doesn't know.

That is why analysis runs in Turkish by default and the source language is detected automatically when not specified. Even so, the cases above are the reason the result should be reviewed by a person, whatever tool is used. The same challenges exist, in different forms, in every language.

#How far can you trust AI output?

The honest answer: as far as a good draft. Whether designing or using an analysis layer, keep these limits in mind:

• What wasn't said can't be extracted: If a task wasn't clearly assigned or no date was mentioned, the model can't know it. An action item with no clear owner is a gap in the meeting, not in the analysis.
• Recording quality matters: With poor audio or people talking over each other, names and numbers can be transcribed wrongly; check important figures against the transcript.
• You know the context: The model doesn't know what “last time” refers to in “let's do it like last time”.

#Connecting the output to your work

Structured output opens the way to automating what happens after a meeting. Once the webhook notification arrives the result is fetched from the API; action items can be written to your task tool, the summary to the relevant customer record and decisions to the team channel. For people using the interface, the same content is prepared as TXT, PDF and DOCX, and as SRT subtitles for video.

#Building a similar solution on your own data

The same approach isn't limited to meetings: extracting requests and complaints from call-centre conversations, pulling dates and obligations out of contracts, classifying support emails all follow the same pattern: take unstructured text, turn it into a structure with defined fields, connect that structure to a workflow. We build solutions like these as part of our AI solutions service. For the customer-facing side, see chatbots for small businesses; for the product itself, the Transify AI case study. Where recordings are processed is covered in on-premises AI and data protection.