Extract Action Items From an AI Conversation
A long AI chat ends with a dozen suggestions — some you accepted, some you rejected, some already done — and "list the to-dos" turns all of them into pending tasks. Here's how to extract action items sorted by state, tied to evidence, with finished work kept out of the queue.
Build an Action-List PromptWhen "list the to-dos" resurrects the work you already did
You've been working with an AI assistant for an hour. It proposed a dozen things, you took some and waved off others, a couple of tasks it actually finished and reported back, and one you parked for later. At the end you type "list the to-dos from this chat" — and the model hands you all twelve as a to-do list. The work it already completed is back on the list as if it were pending. The suggestions you explicitly rejected are there too, phrased as next steps. The one idea that was pure brainstorming sits next to a real commitment with equal weight. It looks like a plan, and it would send you off to redo finished work and revive ideas you'd already killed.
That's the gap this guide closes. Pulling action items out of an AI conversation isn't summarizing it — a summary compresses what was said, and what you need is an execution list that separates what you agreed to do from what the assistant merely suggested, and what's already done from what's still open. The distinctions that matter here barely exist in a meeting: the assistant proposes and you dispose, some tasks get completed and reported inside the same chat, and a suggestion is not a commitment until you take it. NewPrompt helps you write the prompt that pulls that sorted list out; it doesn't read your chat history, connect to your AI account, or create anything in a task tracker. You paste the conversation into your own AI tool, and what comes back is a candidate list to check — not a verified account of what you decided, and not a to-do list wired into anything.
Why an AI conversation isn't a meeting transcript
A meeting is people making commitments to each other; an AI conversation is you steering an assistant that generates far more than you accept, so the extraction has to answer a different question — not "what did the group agree?" but "which of the assistant's proposals did I actually take, and which of those are still open?" Four things trip up a model told to just "list the tasks":
- It treats every suggestion as a task. The assistant offers ten ideas; you accept two. A model that doesn't check for your acceptance writes up all ten as things to do.
- It misses that you said no. "Let's not do that" and "skip those" are easy to overlook in a long thread, so a rejected option comes back as a recommendation.
- It re-lists completed work. When the assistant did a task and reported it done in the same chat, a plain extraction reads the task and not the completion, and puts finished work back in the queue.
- It flattens brainstorming into commitments. An idea you were only thinking out loud about lands in the same list as a task you committed to, with nothing marking which is which.
Step 1: Ask for a sorted execution list, not a summary
Give the output the shape that forces the distinctions, by asking the model to sort the conversation into states rather than recap it. A working set of buckets: accepted actions still to do, completed (already done in the chat), rejected or skipped, follow-ups parked for later, blocked or waiting on something, and idea-only (raised, never taken). Once "accepted" and "idea-only" are separate buckets, the model has to decide which one a line belongs in — and that decision is the whole point, because it's where a suggestion gets separated from a commitment instead of quietly promoted to one.
Because the result is a repeating shape — one row per item, the same fields each time — it reads best as a table you can scan and check. The Markdown Output Builder builds a prompt that holds it in a fixed structure — Action, Status, Owner, Evidence, Next Step — so each item arrives with its state and its source attached instead of as a flat bullet list. Under the hood this is field extraction, not compression: the Extraction Prompt Generator is the engine for pulling defined fields out of unstructured text with per-field rules and a missing-data policy, which is what keeps the model reading the conversation for what it states rather than paraphrasing it into prose. Both hand you a prompt you run in your own AI tool; the reading happens there, on a conversation you paste in.
Step 2: Separate what the assistant suggested from what you accepted
This is the distinction the whole extraction turns on, so state it as a rule: an item is a pending action only if you accepted it, not because the assistant proposed it. Tell the model that an assistant suggestion with no acceptance from you goes in "proposed, not accepted" — a record that it was offered, not a task you owe. An option you turned down goes in "rejected," explicitly, so it can't drift back as a next step. The default has to flip: in a meeting, a stated task is usually a real one; in an AI chat, a stated task is a proposal until your words take it.
The acceptance has to be traceable, which is why every accepted action needs an evidence quote — the line where you took it on. "Ok, do those," "yes, proceed," "let's go with the second option" are acceptances; the assistant's own "I suggest we…" is not. Requiring the quote is the guardrail: if the model marks something accepted but can't point to a line where you agreed, that's the signal it inferred your acceptance rather than found it, and you see the gap instead of trusting a confident "pending." The model can misread a polite "interesting" as a yes, so the quote is what lets you check its call against what you actually said.
Step 3: Read the completion states — don't requeue finished work
An AI conversation has something a meeting transcript rarely does: work that got done inside it. The assistant runs a task, reports "here's the result" or "delivery report: done, tests passed," and that task is now complete — not pending. Tell the model to treat an in-chat delivery or completion as "completed" and keep it out of the to-do list, capturing it as context rather than as work remaining. The line that matters: a task named earlier and reported done later is one item that ended completed, not two items where the first is still open.
Separating done from open is a discipline worth being explicit about, because the two travel differently — the finished work is context that explains where things stand, and the open work is the actual payload you carry forward. The Carry Forward Open Tasks resource is built on exactly that split: it keeps completed work in a current-state section and pending work in its own list, so a task you already finished doesn't get resumed after the boundary. Borrow that structure for the extraction — done in one bucket, open in another — and the finished work stops masquerading as a next step.
Step 4: Give each item fields, an evidence quote, and "not stated" for gaps
Turn each item into fields rather than a sentence, so the list is checkable at a glance: the action, its status, the owner (who's doing it), any dependency (what it's waiting on), the next step, and the source quote it rests on. The owner field matters more in an AI chat than it looks — a task might be one you'll do, one you're handing to the assistant next, or one for a teammate, and a flat list blurs them. And when the conversation doesn't state a field — no owner named, no due date given — the rule is the one that keeps extraction honest everywhere: write "not stated," never a guess. The Missing Data in AI Extraction resource lays out the handful of ways to mark an absent value around the single rule that survives all of them — never invent one.
The evidence quote does double duty here. It anchors the status — a line proving you accepted, rejected, or that the task completed — and it makes the whole list fast to verify, because you can read the quote instead of re-reading the conversation. Where the conversation genuinely conflicts with itself — you said do it, then later said hold off — the model shouldn't pick a winner silently; it should mark the item "needs_review" and quote both lines, so you resolve the contradiction rather than inherit whichever one the model happened to weight. A visible conflict you settle beats a confident guess you don't notice.
Step 5: Review the list, then carry it into your tracker yourself
The output looks like a finished plan, which is exactly why it needs a pass before you act on it. Read the high-stakes items against the conversation first — the accepted actions and anything marked completed, because those are the ones that decide what you do and don't redo. For each, the evidence quote makes the check quick: does the quoted line actually show you accepting it, or the task finishing? A useful last question is "what here would send me to redo something or revive something I killed?" — it catches the completed task marked pending and the rejected idea dressed as a next step, the two errors that cost the most.
Then move it by hand. The extraction is a candidate reading of the chat, not a verified list of your intentions — the model can miss an action buried in a long message, misjudge a soft "maybe" as an acceptance, or read a half-finished task as done. So confirm the list is right, assign the owners and real dates it doesn't have, and copy the actions into your own tracker or the next chat yourself. NewPrompt structures the extraction; it doesn't read your chat history, sync with a task tracker, open a Jira or Linear ticket, or set a reminder — the list becomes real work only when you enter it somewhere and stand behind it.
Common mistakes
The habits that turn a long chat into a wrong to-do list:
- Asking for a summary when you need an execution list. "Summarize the chat" optimizes for readable prose, not for what to do next — ask for a sorted list of states instead.
- Treating every suggestion as a task. The assistant proposes far more than you accept; mark an item pending only when a quote shows you took it on.
- Missing the rejections. "Skip that" and "let's not" are easy to lose in a long thread — give rejected options their own bucket so they can't come back as next steps.
- Requeuing completed work. A task the assistant did and reported in the chat is done; read the completion, not just the task, and keep it out of the pending list.
- Letting brainstorming become commitments. An idea raised out loud isn't a task; keep idea-only separate, and require a quote before anything counts as accepted.
- Treating the list as ready to execute. It's a candidate extraction to check against the chat and copy into your own tracker by hand — not a task list wired into anything.
A worked example: extracting the plan from a working chat
Watch a short working conversation get flattened into a wrong to-do list, then sorted into what actually remains.
"List the to-dos" revives completed and rejected items; a sorted extraction keeps accepted apart from suggested and done apart from pending, with a source quote for every statusTHE CONVERSATION (excerpt):
User: Let's create two guides from the backlog.
Assistant: I suggest Rank 45 and Rank 46.
User: Ok, proceed with those.
Assistant: Delivery report -- both guides created, tests passed.
User: Great. From now on, skip the warning candidates and only
produce the recommended ones.
Assistant: The next recommended after skipping warnings is Rank 50.
User: Ok, give me the last guide task, then we'll run a new analysis.
Assistant: We should produce "Extract Action Items From an AI Conversation,"
then create a fresh backlog analysis for the next 50.
THE "LIST THE TO-DOS" RESULT (looks like a plan, quietly wrong):
- Create Rank 45 and Rank 46 guides <- already DONE
- Consider the warning candidates <- user REJECTED this
- Produce Rank 50
- Run a new analysis
- Continue guide production <- vague, not a real item
A SORTED EXTRACTION PROMPT (pull states, with evidence):
Extract action items from this conversation. Sort into: pending
(accepted, not done) | completed | rejected/skipped | follow-up | idea-only.
Rules:
- Mark pending ONLY if the user accepted it and it isn't already done.
- An assistant suggestion the user didn't take -> proposed_not_accepted.
- A delivery report / "done" -> completed, never pending.
- Quote the source line for every item's status. If owner/date not
stated, write "not stated". Flag contradictions as needs_review.
THE SHAPE YOU WANT BACK:
PENDING (accepted, not done):
- action: Produce the guide "Extract Action Items From an AI Conversation"
status: accepted_action owner: the assistant next_step: one guide only
evidence: "Ok, give me the last guide task"
COMPLETED (context, not to-do):
- Rank 45 and Rank 46 guides
status: completed evidence: "Delivery report -- both guides created,
tests passed"
FOLLOW-UP (later):
- Create a fresh backlog analysis for the next 50 guides
status: follow_up_later dependency: finish the last guide first
evidence: "then we'll run a new analysis"
ACTIVE RULE:
- Skip warning candidates; produce only recommended ones
evidence: "skip the warning candidates and only produce the recommended"
REJECTED / SKIPPED:
- The warning candidates status: skipped_by_rule
evidence: the recommended-only rule above
NEEDS REVIEW: none stated.
NEXT: check each status against the conversation, then copy the ONE pending
item into your task list yourself -- the completed and rejected items stay
out of it. NewPrompt didn't create a task; you did.Where this fits in NewPrompt
Pulling a plan out of a conversation is one job in a small family, and knowing which one you need saves a wrong turn. The Markdown Output Builder holds the sorted list in a fixed shape; the Extraction Prompt Generator is the field-extraction engine underneath it; the Carry Forward Open Tasks resource is where the done-versus-open split comes from; and the Missing Data in AI Extraction resource is the "not stated" rule that keeps the model from inventing owners and dates. Each gives you a prompt you run in your own AI tool.
It's worth telling this apart from its neighbors, because the source is the same but the goal isn't. Pulling decisions and owners out of a meeting transcript is the human-commitment version — no assistant proposals to filter, no in-chat completions to net out. Distilling a messy chat into a reusable prompt keeps the wording that worked and throws away the rest; moving context between chats carries the whole state forward. This one is narrower than a handoff and different from a prompt: it pulls just the execution list — what you agreed to do, what's left, and what's already done — out of a conversation you're closing.
A finished AI chat is a pile, not a plan: the done, the dropped, the parked, and the still-to-do all sit in it looking alike, and the model will hand the whole pile back as "to-do" unless you make it sort. Sorting by state, tying each item to the line that proves it, and keeping finished work out of the queue is what turns the pile into a list you can act on — and even then it's a draft. The model reads the words fast; which of them you actually committed to, and which are already behind you, is the part you confirm before any of it becomes a task you own.