From monologue to list: how AI extracts tasks from a transcript

Transcribing audio to text is a solved problem. The interesting part starts afterwards: turning a paragraph nobody would ever write into a list of actions you can actually use. This article opens the black box of that step.

The starting point is worse than you think

When you talk without thinking about how it sounds, here's what actually comes out:

"Okay, so, I need to… the client thing, write to them about the quote, it's been two weeks now, uh… and then look into the October invoice, I don't think I sent it, or maybe I did, I don't know, check that. Oh, and the domain needs renewing before it expires, that one's urgent."

A perfect transcript of that audio is exactly that paragraph, with its "so", its "uh" and its half-finished doubts. Nobody wants that in their task manager. What you want is:

• Write to the client about the quote — high
• Check whether the October invoice was sent — medium
• Renew the domain before it expires — high

Between one and the other there are four distinct jobs.

The four jobs of extraction

1. Segmenting

Deciding how many tasks there are. It's less obvious than it looks: "write to them about the quote, it's been two weeks" is one task with context, not two. And "look into the invoice… or maybe I did, I don't know, check that" is a single task said twice with a wobble in the middle.

Connectors ("and then", "oh, and") help, but they aren't reliable: plenty of people string a single idea together with three "and"s. This is where an LLM clearly beats any hand-written rule, because the decision is semantic, not syntactic.

2. Normalizing

Turning each fragment into something shaped like an action. Verb at the front, no filler, self-contained. "The client thing, write to them about the quote" becomes "Write to the client about the quote". The key is that the task has to make sense three weeks from now and out of context, when you no longer remember the audio.

3. Inferring metadata

• Priority. "That one's urgent" and "it's been two weeks" are explicit signals. "Whenever I get a chance" says the opposite.
• Dates. "Before Friday" or "at the end of the month" has to resolve to a real date, and for that the model needs to know what today's date is and which time zone you're in. Without that information it will make something up.
• Certainty. "I don't think I sent it" means the task is to check, not to do.

4. Discarding

A good share of what you say out loud isn't a task. Reflections, context, doubts resolved within the audio itself. An extractor that turns everything into a task generates noise, and noise is what makes you stop looking at the list.

Why strict JSON is required

The model doesn't return prose. It's required to emit an object with a specific shape:

{
  "tasks": [
    { "title": "Write to the client about the quote", "priority": "high" },
    { "title": "Check whether the October invoice was sent", "priority": "medium" }
  ]
}

Two reasons. The first is obvious: this has to be written into a database, and "first you'd call the client and then…" isn't insertable anywhere.

The second is subtler: asking for structure improves reasoning. A model forced to emit a list of objects separates ideas better than one allowed to write freely, because the format makes it decide where one task ends and the next begins.

And if the model returns something that isn't valid JSON —it happens— the system has to fail explicitly and tell the user, never half-guess and insert junk.

Context: what separates decent extraction from good extraction

The same audio should produce different results for different people. If you're a developer and you say "need to look at the deploy thing", that means something specific. If you're a lawyer, "review the brief" does too.

That's why the system lets the user give the model two things:

Business context. A paragraph describing what you do, what your clients and projects are called, what jargon you use. It's the single biggest improvement in extraction quality, and the one fewest people bother to fill in. If your client is called "Robles Meats" and the model doesn't know that, it will transcribe and classify every mention worse.

Formatting rules. Output language, tone, default priority, whether you want short or descriptive titles, free-form instructions along the lines of "never create tasks longer than eight words" or "if I mention someone, put them at the end in brackets". In MicTask this is the Brain: a set of settings that becomes part of the model's instructions on every run.

The difference between using the Brain and not using it is the difference between a generic assistant and one that knows your work.

The classic failure modes of an LLM extracting tasks

None of these are hypothetical; they're what shows up the moment you put it in front of real users.

Over-segmenting. Turning every clause into a task. "Call Marta and confirm the time" ends up as two tasks. You fix it with explicit instructions to group actions performed at the same moment.

Inventing details. Adding a date you never said, or a "high" priority because the tone sounded tense. An extractor should leave fields empty rather than fill them in by eye: a fake date is worse than no date.

Turning context into a task. If you say "I was talking to Marta and she told me about the contract", that's information, not an action. It shows up as a task "Talk to Marta" — and you already did.

Carrying transcription hallucinations through. If the audio was silence and the transcriber returned "Subscribe to the channel" —Whisper's classic failure mode, which we cover in transcribing voice notes to text with AI— the extractor will dutifully generate an absurd task. That's why the hallucination filter runs before the LLM, not after.

Switching languages. A multilingual model with no fixed output language can hand you back in one language what you said in another. You pin it explicitly in the instructions.

What a human still does better

It's worth being honest about the current ceiling:

• Dependencies between tasks. That task B can't start until A is finished is something the model almost never captures.
• Irony and implicit discarding. "Sure, and while I'm at it I'll fix the world" shouldn't generate a task, and sometimes it does.
• Real priority. The model reads the signals you say out loud. It doesn't know that this particular client accounts for 40% of your revenue.

The practical conclusion is that automatic extraction has to let you review and edit. Its value isn't replacing your judgment: it's that things reach the system without you having to type them. Tidying up ten already-written tasks takes a minute; writing them from scratch takes fifteen and, more to the point, you almost never do it.

In summary

Between your voice and your list there's a pipeline with more parts than it looks: filtering out speechless audio, transcribing, segmenting, normalizing, inferring, discarding and writing structured output. Each part has its own failure mode, and all of them have to fail visibly rather than silently, because one invented task erodes trust in the system faster than one lost task.

When it works, the effect is the one you were after all along: you talk for thirty seconds and your task manager is up to date.

Try it and send your first voice note.