How to automatically update project tasks from meeting decisions (DIY)

Works withJiraLinearAsanaClickUpMonday

By Jack Galbusera · Co-founder & COO, Sumnote · Published 6 October 2026

This page will guide you through three possible ways to build an automation that creates or updates tasks inside your project management system, directly from your meetings. Part 1 is about using the AI built into your project tool. Part 2 covers the three ways: your notetaker’s own integration, an automation in Zapier, Make or n8n, and an assistant connected to your project tool. The last two can find and update existing work, not just create new tasks. Finally, after the DIY guide, we introduce Sumnote: the system we built to run the whole loop natively.

Your meeting

where decisions are made

Three ways to automate it

Route AYour notetaker’s integrationcreates new tasksRoute BAn automation: Zapier, Make, n8ncreates, or finds and updatesRoute CAn AI assistant with connectorsupdates, and asks when unsure

Your project board

tasks, owners, due dates

On this page

If you are reading this guide you likely already use both halves you want to connect: a notetaker that produces action items, and a project management tool where your tasks live. Connecting them is not the hard part; most tools in both categories support that, some in one click. The hard part is what comes out the other end, and whether you can 100% trust your project board afterwards.

These are prototype recipes: enough detail to build a first version, with setup time that depends on your permissions, your tools and your experience. Part 3 covers what to check during the first two weeks of testing your new pipeline.

The hint is that not everything a meeting produces is an isolated decision. Meetings also change work that already exists: a date moves, an owner changes, scope gets cut. That second kind of output is what this guide is about.

Illustrative example. The useful output of that sentence is two changed fields on a task that already exists, not a new task next to it.

Part 1. The AI already inside your project tool

Most project tools now have something in this direction. ClickUp’s AI Notetaker records the meeting and turns action items into assigned tasks inside ClickUp. Notion’s AI Meeting Notes produce a transcript, a summary and a list of action items; turning those into tasks in a Notion database is a further step. Atlassian publishes a ready-made skill for assistants that extracts action items from meeting notes, looks up Jira users, asks you to resolve ambiguous names and creates the tasks after confirmation, which is the assistant-based approach described in Route C below, with a vendor-written prompt.

In the meeting-to-task examples just described, these features share one verb with the notetaker integrations and the simple automation build you will meet in Part 2: ‘create’. That is not a flaw in any of them. It is the natural shape of the problem as it was first stated: get the action items out of the meeting and into the board. Two of the builds in Part 2 can update instead, with some caveats. This guide is about what happens when a meeting changes work that already exists.

A test you can run this week

Take the transcript of your last project meeting and sort every actionable commitment or agreed change into two piles: new work, and changes to work already on the board (a date moved, an owner changed, scope cut, something blocked, something dropped). Write down what the board should look like afterwards. Then run the transcript through whatever workflow you have, native or built, and compare what appeared with what should have.

Part 2. Three ways to build the pipe

What you need before you start

What each route needs

Route A

Nothing extra: your notetaker’s own integrations page.

Route B

A Zapier plan with multi-step Zaps and Paths, an API key with billing for the model app you pick, and a transcription service if you start from recordings.

Route C

Claude with connectors, or ChatGPT developer mode on a plan with write actions. Claude Code or the Codex CLI for the command-line version.

Route A. The native integration: your notetaker’s own

Fireflies, Fellow, Read.ai and other notetakers ship native integrations that turn detected action items into tasks in Asana, Jira, ClickUp, Monday, Trello or Linear (see Fireflies’ and Fellow’s).

SetupSet up your notetaker’s integration

In your notetaker, open ‘Integrations’ (in some tools ‘Apps’) and connect your project tool with your own account. Pick one destination project, a test project if you have one. Setup and export behaviour vary by integration: some need an administrator to install them in both tools, some push action items on their own after every meeting, others create a task only when you click one. Check how the integration maps speakers to users and what it does with fields the project tool requires. Then run one meeting that contains one clearly new task and one change to an existing task, and look at both results on the board.

What it does well: little setup, no prompt to write, less workflow code to maintain.

Where it stops:

  • The usual output is a new task created from an action item; how its title, assignee and date get populated depends on the integration, its configuration and any confirmation form it shows you.
  • Fellow’s Jira integration also lets you pull existing issues into the meeting agenda and keep titles, assignees and due dates in sync both ways, which is useful; that link is made when a person explicitly selects the issue, not automatically found from your project’s context.
  • What these integrations do not establish is automatic matching of each spoken change to an existing item using the project’s context: a name in the transcript is not a recognised user, and a change said in passing is not yet linked to the item it concerns.

Route B. The automation route: Zapier, Make or n8n

Once you get the transcript, you can automatically send the text to a model with a prompt that returns structured JSON (). Then, you can run extraction with an LLM, like Claude Sonnet 5.5.

What it adds over Route A: you own the schema. You can ask for title, owner, due date and the sentence in the transcript that produced the item, and route by project. And you decide what the pipe does with the result: only create new action items, or search the ones already in your project and update them first. Those are two different builds, so here are both (the full build is written for Jira, with notes on adapting it).

Note: you will need a Zapier plan that allows multi-step Zaps and Paths, an API key with billing for the model app you pick, and, if you transcribe inside the Zap, a transcription service; those are running costs alongside the meetings themselves.

Is this a bit too technical? Jump to the end to see the solution that works out of the box.

If you have never used Zapier:

Route B1. The simple build: create only

5 stepsBuild the workflow that creates tasks from a transcript
  1. 1

    Trigger. Choose your notetaker’s app in Zapier (Fireflies, Otter, tl;dv, Fathom and others publish one) and pick its new-transcript event (in Otter it is called ‘New Recording’), so the Zap starts each time a meeting has been transcribed. Map the meeting date, the time zone and the meeting ID from the trigger as well; later steps need them.

  2. 2

    Model. Add an action with the Anthropic (Claude) or OpenAI (ChatGPT) app and pick the action that sends a message and returns the reply (‘Send Message’ in Anthropic’s, ‘Conversation’ in OpenAI’s). Paste the prompt below into the message field, then use Zapier’s insert-data menu to drop in the transcript text, the meeting date, the time zone and the participants.

    A possible prompt for the extraction step; the full build reuses it unchanged:

    Prompt
    Read this transcript. The meeting date is [date], time zone
[zone], participants [list].
Return a JSON array with one object per work item that the
meeting created or changed, with these fields:
  title, type, existing_item_hint, changes, source_quote,
  speaker, needs_clarification
type is one of: new_work | change_to_existing | unclear
Use unclear for a task or change that cannot yet be resolved.
changes is a list of {field, new_value} objects, one per field
the speakers set (due_date, owner, status, title, description).
Mark change_to_existing whenever the speakers refer to work
already underway, and put the words they used in
existing_item_hint.
Use null for anything not said. Do not invent people, dates
or task IDs. Resolve relative dates ("next Friday") only when
the meeting date makes them certain; otherwise set
needs_clarification to true. Also set it to true when a
change is conditional ("if the client approves") or when the
speakers ask to remove a value, such as a deadline.
Return valid JSON only, no commentary.

    The field called ‘type’ is the point of this whole guide. On its first run, even a pipe that only creates will tell you how much of what it is about to create is really a change to something you already have. The label is the model’s judgment, so read a few against the transcript before you trust the count.

  3. 3

    Parse. The model’s reply is one block of text holding a JSON list of the work items it found. Add a ‘Code by Zapier’ action (JavaScript) that turns it into a list Zapier processes one item at a time: when a Code step returns a list, Zapier runs every following step once per item. Ask your AI to write it, with this request:

    Request for your AI
    Write a Code by Zapier JavaScript step that takes
inputData.reply, parses the JSON array inside it, and for
each object returns it with its original fields plus:
- search_text: existing_item_hint for change_to_existing,
  title for new_work;
- for each of due_date, owner, status, title, description:
  a has_<field> true/false flag and a <field>_value;
- the search_text with quotes, backslashes, control
  characters, JQL operators and grouping characters removed
  or escaped, for use inside a JQL text search.
Skip any object whose type is not one of the three allowed
values, whose needs_clarification is not true or false,
whose changes entries are malformed, or that sets the same
field twice with different values, and log each rejected
record with its index and the reason.

    Map the model’s reply to ‘inputData.reply’ and test the step. Here is an example of the model’s output, before the Code step adds its helper fields, for a meeting held on Monday 21 September 2026, Toronto time, with Jack, Maya and Priya (copy from the page, where each string is one line):

    Example output
    [
 {"title": "Homepage review",
  "type": "change_to_existing",
  "existing_item_hint": "the homepage review",
  "changes": [{"field": "due_date", "new_value": "2026-09-25"}, {"field": "owner", "new_value": "Maya"}],
  "source_quote": "Let’s push the homepage review to Friday and give it to Maya.",
  "speaker": "Jack",
  "needs_clarification": false},
 {"title": "Draft the client onboarding checklist",
  "type": "new_work",
  "existing_item_hint": null,
  "changes": [{"field": "owner", "new_value": "Priya"}],
  "source_quote": "Priya, can you draft the onboarding checklist before we see them again?",
  "speaker": "Jack",
  "needs_clarification": true}
]

    The first object carries both changes Jack asked for, on one item. The second is flagged as needing a clarification, because ‘before we see them again’ is a deadline nobody can resolve without knowing the next meeting date, so the next step keeps it out of automatic creation.

  4. 4

    Filter. Add a ‘Filter by Zapier’ step so that only items with ‘needs_clarification’ false and ‘type’ equal to ‘new_work’ or ‘change_to_existing’ continue.

  5. 5

    Create. Add your project tool’s create action (‘Create Issue’ in Jira, ‘Create Task’ in Asana). Map ‘title’ to the summary, ‘due_date_value’ to the due date, and ‘source_quote’, ‘speaker’ and the meeting date into the description; Jira also needs the project and the issue type. For the assignee, add a ‘Find User’ step (Jira has one), set it to continue when nothing is found, and map the user it returns. Test with one meeting, then turn the Zap on.

Good to know

  • No notetaker? Use Google Drive as the trigger (‘New File in Folder’) and add a transcription action before the model: the OpenAI app’s ‘Create Transcription’ (Whisper, files up to 25 MB) or AssemblyAI’s app (turn on ‘Wait for Completion’ so the next step gets text, not a job ID). A file in a folder says nothing about when the meeting happened, so take the date from the meeting’s metadata; without it, relative deadlines stay unresolved.
  • Speakers. If the transcript has no speaker labels, the speaker stays unknown: a participant list alone cannot tell who said ‘I’ll take that’. AssemblyAI can label speakers as Speaker A and B; a label is still not a name.
  • Flagged items. The filter drops what it rejects. To keep flagged items somewhere, add a ‘Paths by Zapier’ step before the filter and send them to a Google Sheet.
  • Names. A name in a transcript is not an account, and a lookup can find nobody, or more than one person. Handling that fully (checking how many people came back, branching, projects that require an assignee) is possible but beyond the scope of this guide. Test once with an absent name and once with a shared one, and check the assignee on the tasks it creates.
  • Rejected records from the Code step are extraction problems to report, not tasks to create.

If any step is unclear, paste this section into your AI assistant with the names of your tools and ask it to walk you through it screen by screen. It can also write the Code step for you.

That is Route A with your own schema and your own prompt. It creates. On its first run, the ‘type’ field in the prompt will tell you how much of what it created was really a change to something you already had.

Route B2. The full build: find first, then update an existing task or create a new one

This build is written for Jira, because its Zapier app has the pieces the recipe needs: a search that can return several candidates, a user lookup, an update and a comment. Notes for the other tools are at the end.

The full build, simplified. Every ‘Check:’ task carries the same label, so the search never returns one as a candidate.
6 stepsBuild the workflow that finds and updates existing tasks (Jira)
  1. 1

    Start with steps 1 to 3 of the simple build, including its prompt.

  2. 2

    Route by type. Add a ‘Paths by Zapier’ step with three paths:

    • Check, when ‘type’ is ‘unclear’ or ‘needs_clarification’ is true: create one task titled ‘Check:’ followed by the title, and nothing else.
    • Change, when ‘type’ is ‘change_to_existing’ and ‘needs_clarification’ is false: go to the search.
    • New, when ‘type’ is ‘new_work’ and ‘needs_clarification’ is false: go to the same search, so work already on the board is not created twice.
  3. 3

    Search. On the Change and New paths, add Jira’s ‘Find Issues (Via JQL)’ action, set to return up to five results, with this query: project = KEY AND statuscategory != Done AND text ~ "{{search_text}}" AND (labels IS EMPTY OR labels NOT IN ("meeting-review")). The Code step has prepared ‘search_text’: the item hint for a change, the title for new work.

  4. 4

    Match. A search result is a candidate, not a confirmed target. Add one more model step that reads the candidates and the item and answers with one line, using this prompt:

    Prompt
    Here is one item from a meeting, a proposed change or a
proposed new task, and up to five candidate items from the
board. Answer on one line with the ID of the existing item
this proposed task or change refers to and a confidence
(high, medium, low); or NONE if no candidate fits; or
UNSURE if you cannot tell, because several candidates are
plausible or the context is too thin. Nothing else.

    Add a small Code step (your AI can easily write it) that turns that line into three values: outcome, candidate ID and confidence. Then add a second ‘Paths by Zapier’ step that decides what to do with the answer. Remember that every item is already either New or Change, from step 2:

    • One task, high confidence: update that task (step 5). This also catches ‘new’ work that turns out to be on the board already.
    • NONE, for a New item: nothing on the board matches, so the work really is new. Create the task as in the simple build.
    • NONE, for a Change item: the meeting changed a task the search couldn’t find. Don’t create a duplicate; create a ‘Check:’ task instead.
    • UNSURE, or medium or low confidence: create a ‘Check:’ task listing the candidates.
  5. 5

    Update. For a matched item, add ‘Update Issue’ with the issue key from the matcher, and map only the fields whose ‘has_<field>’ flag is true: ‘due_date_value’ to Due Date, ‘title_value’ to Summary (Jira’s name for the task title), and ‘owner_value’ to Assignee. For the assignee, add a ‘Find User’ step that looks up the person by that name, set it to continue when nothing is found, and map the user it returns. Then add ‘Add Comment’ with the quote, the speaker and the meeting date, so the reason is on the item.

  6. 6

    Turn it on. Test in a test project before real meetings, with these four cases:

Good to know

  • Labelling ‘Check:’ tasks. Give every ‘Check:’ task the label ‘meeting-review’, the meeting ID and the quote, plus the candidates when there are any. The end of the query uses that label to leave your own ‘Check:’ tasks out of the search: they contain the meeting’s words, so Jira would otherwise return them as candidates. The ‘labels IS EMPTY’ part keeps ordinary unlabelled tasks in the results.
  • Search settings. Return all results as line items, and check once that two known matches reach the matcher together, in one call. Set the step to continue when nothing is found, otherwise the steps that follow can stop. A search that failed with an error is not the same as one that found nothing; keep the two apart.
  • Empty or messy search text. If ‘search_text’ is empty, send the item down the Check path instead of running an empty search. The Code step already removes the characters JQL would interpret; test once with a title that contains punctuation.
  • Finished work. Drop ‘statuscategory != Done’ from the query if a conversation may reopen finished tasks.
  • Issue keys. If the transcript names an issue key, say PROJ-123, confirm it is in the project and use it as the target, without the matcher.
  • What the matcher can’t tell you. NONE means none of the candidates supplied fitted, not that no matching item exists. The confidence is the model’s own estimate, not a measured accuracy.
  • Fields the update leaves alone. Leave every other input empty; the intent is that an empty input leaves the field unchanged, so test it. A status change goes through the action’s Status input when the workflow allows that transition, otherwise to a ‘Check:’ task. A description change also becomes a ‘Check:’ task; this recipe does not rewrite descriptions.
  • Matching by meaning. If a match is missed, first check whether the intended task was in the candidate list at all: a task missing from the list and a task that was in the list but not chosen are different failures, and a wider query can help only with the first. The query already searches titles, descriptions and other text fields; to widen it, try alternative terms, adjust the project or status scope, or retrieve candidates by owner and recent activity. Embedding-based search, which finds records by similarity in a vector index (services such as Pinecone offer it, including as a Zapier step), is the bigger upgrade: it finds tasks described in different words. It is weaker on exact terms such as issue keys and names, which keyword search catches, so the strongest setup runs both. It also needs the records kept in sync, and its results still need the matching step.
More optionsOther project tools, and the n8n template

Adapting the search to other tools. Asana’s Zapier app has ‘Find Task in Project’ and ‘Find Tasks in Workspace’, the second is a text search returning several results, documented for premium plans. Monday’s ‘Find Items’ matches a value in one column of a board, so choose the column and the value. If your tool is Linear or ClickUp, you need a different candidate-retrieval step: their Zapier apps look tasks up by ID (ClickUp also has a most-recent-task search and an authenticated API request action). For Linear, query its API, which supports filtered issue queries; for ClickUp, retrieve a scoped, paginated set of tasks and select candidates from it. Either goes through a request step your connector supports or an HTTP action configured for your tool’s API, and either needs testing before you reuse the matching and routing steps. The routing, matching and comment steps are the same; the search and the field mapping are per tool.

If you prefer n8n, there is a published template that transcribes recordings with Whisper, extracts with Claude and creates tickets in Jira, ClickUp or Linear. Its description lists duplicate detection; test that with two meetings that discuss the same task before relying on it.

Where the full build stops: not at the tools. Zapier’s Jira app can search with JQL and update issues, n8n’s Jira node can get and update them, and both platforms can keep state between runs. What the recipe as written does not yet do: it keeps no structured history of pending proposals across meetings, so the same item discussed twice is two separate runs, each leaving a comment but neither aware of the other; it does not re-read the item between proposing a change and applying it, so a field edited in the meantime can be overwritten; and it has no place where a person sees the current value next to the proposed one before it lands. Each of those can be built with more state, more rules and more checks. Part 3 is about how to find out whether you need them.

Rather not build and maintain it?

See how Sumnote runs the whole loop

Route C. An assistant connected to your project tool

This is the one worth trying this week, because a model with search access can read the board before it writes to it. The mechanism is simple: your project tool publishes a small server (an MCP server) that lists the actions it allows: search issues, read the details of one issue, update a field, add a comment. An assistant connected to it can call those actions with your login. That is what Route A and the simple build of Route B do not have: something that reads the board before deciding.

Route C1. In a chat app, for anyone

5 stepsConnect Claude or ChatGPT to your project tool

How to set it up in Claude, no code. Connectors are available on Claude plans with different limits; check the connector guide for yours.

  1. 1

    In Claude, open ‘Customize’, then ‘Connectors’ (in some versions the path starts at ‘Settings’; menus move). Add ‘Atlassian’ (for Jira), ‘Linear’, ‘Asana’ or ‘monday.com’ from the directory; for ClickUp, choose ‘Add custom connector’ and paste https://mcp.clickup.com/mcp. Sign in when asked and review the access it requests. Some workspaces need an admin to allow the connection, and Monday admins can restrict who may use it.

  2. 2

    Set permissions. In the connector’s tool settings, set every tool that can modify anything (create, update, transition, comment, and on Atlassian’s server also its general write tool) so that it asks before running. Claude also offers an allow-always choice; don’t use it for write tools. Then test it: in a test project, ask for one read and one small write, and confirm the write pauses for you. This setting, not the prompt, is your safety net.

  3. 3

    Start a chat, open the tools menu and switch the connector on. Say which project, team or board it should work in, and use a test project the first time.

  4. 4

    Get the transcript in: paste it, upload the file, or export it from your notetaker (most export a ‘.txt’ or ‘.vtt’ file). Some notetakers publish an MCP server of their own; if yours does, connect it the same way and skip the export.

  5. 5

    Paste the prompt below. Save it as the instructions of a Claude Project so you don’t paste it every time.

If step 2 is not clear, ask your AI: what is an MCP connector, and how do I check a connector’s tool permissions in Claude?

In ChatGPT the usual way to add a custom MCP connection is developer mode; follow OpenAI’s developer mode guide for the current path, because it has moved more than once. Which plans get write actions is still changing, so check it for your plan before building around it; on workspace plans an administrator may need to allow custom apps first.

Route C2. From the command line, for professionals and for automation

5 stepsRun it from the command line or on a schedule

The same connectors work in the coding agents, Claude Code and OpenAI’s Codex, and that matters for two reasons: the prompt becomes a saved command you run with one line, and it can run without a chat window, on a schedule or from your notetaker’s webhook.

  1. 1

    Install Claude Code or the Codex CLI (both have an install page; your AI can walk you through it), sign in, and open a folder to work in.

  2. 2

    Add the connector. In Claude Code: claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp, then type /mcp and choose ‘Authenticate’. In Codex: codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp, then codex mcp login atlassian. Same shape for Linear (https://mcp.linear.app/mcp), Monday (https://mcp.monday.com/mcp) and ClickUp (https://mcp.clickup.com/mcp).

    Asana is different: its v2 server (https://mcp.asana.com/v2/mcp) needs an OAuth app registered in Asana first, with a client ID, a client secret and a redirect URL per client; follow Asana’s coding-client guide. The Codex desktop app has the same under ‘Settings’, ‘MCP servers’, ‘Add server’. Atlassian’s older v1 addresses still work, but new setups should use the v2 one.

  3. 3

    Save the prompt below as a command that takes a transcript file. In Claude Code: a file .claude/commands/meeting.md containing the prompt with $ARGUMENTS where the file path goes; you then run /meeting path/to/transcript.txt (Claude Code now recommends skills for new reusable commands; the file works the same way).

    In Codex: keep the prompt in meeting.md, start an interactive session with codex, and ask it to read meeting.md and the transcript file and follow the instructions; AGENTS.md holds standing instructions for the folder, it does not create a command. The non-interactive codex exec is for the unattended version below, not for this one.

  4. 4

    The assisted version. After each meeting you do two things by hand: export the transcript, and run the command on it (one line, with the file’s path). From there the agent searches, drafts the proposals, and stops before each write to ask you. Do not rely on a default for that: both tools have permission settings per tool (Claude Code’s permission rules; in Codex, the MCP server settings with their per-tool approval modes, which are separate from its shell and file permissions), so set every write tool to require approval and confirm it in a test project before the first real meeting, with one read and one small write. The prompt asking the agent to wait is not the same thing as the client refusing to write. This supports an assisted workflow: inspect the proposals, then approve the changes.

  5. 5

    The unattended version. To run it without you (on a schedule, or from a small script triggered by the notetaker’s webhook: Claude Code’s -p flag and codex exec both run without a chat), you have to pre-approve the write tools in the agent’s settings, and from then on the agent applies its own matches. The assisted prompt cannot be used for that, because it tells the agent to wait, to ask about ambiguity and to ask again if the board changed. Use this separate prompt instead, complete, so nothing has to be reconciled by hand:

    Prompt
    You are running unattended on the transcript of a meeting
held on [date], time zone [zone], with [participants].
Meeting ID: [id] (the notetaker’s identifier; it stays the
same on a retry). Work in [project / team / board]. You may
write to the board only under the rules below.

1. List every agreed new task and every change to existing
   work (date, owner, status, scope, blocker). Use null
   where an owner or a date was not said.
2. For each item, search [project] by task ID if one was
   mentioned, then by the deliverable, keywords and the
   owner’s name. Exclude review placeholders (tasks
   labelled meeting-review) from these candidates; never
   update one as though it were the work item. Read the
   current values of every candidate.
3. Apply an update only when all of these hold: exactly one
   item matched with high confidence; every value you would
   write is unambiguous (one person for an owner, a certain
   date, a status the workflow allows); the change is not
   conditional; the item’s current value still equals what
   you read in step 2. Write only the fields the transcript
   changed.
4. Create a new task only when it is clearly agreed,
   unconditional new work; the search completed and found
   no plausible existing task; every value you will write is
   unambiguous; all required destination fields can be
   supplied; and no task titled "Check: <title>" exists for
   this meeting ID. Leave an unspecified optional owner or
   date empty where permitted. If a stated owner, date or
   required value is unresolved, use step 5. If the search
   failed or its result is uncertain, stop this item and
   report it.
5. Everything else that is a task or a change becomes a task
   titled "Check: <title>", labelled meeting-review, with the
   meeting ID, the candidates and the quote in its
   description, unless that task already exists for this
   meeting ID (search the label, not the text). Create it
   only if its required fields can be supplied from the
   configured review destination and review owner; never
   invent a person or a value. Otherwise record the meeting
   ID, the item, the quote and the unresolved fields in
   [external review log] and report that no task was created.
6. Before updating an existing item, check its comments for
   this meeting ID and the same intended change; skip a change
   already recorded. Before creating an item, complete the
   existence checks in steps 2, 4 and 5. After a successful
   update or creation, add the source comment to the item:
   meeting ID, quote, speaker, date. If a write or its
   comment fails, or the result is uncertain, stop processing
   that item and report the partial or uncertain outcome.
7. Report every applied, skipped, failed and uncertain write
   at the end.

    Name and configure the external review log and the review owner before enabling the unattended run; a designated review owner is not a guess at who owns the work. The prompt uses Jira’s ‘meeting-review’ label as the review marker; for another destination, configure a marker or a separate review destination that the connected tools can both write and retrieve (a tag column in Monday, a tag or custom field in Asana), use it consistently in steps 2 and 5, and verify the exclusion and the review lookup in that configuration; if those operations are not available there, send review items to the external log.

    The comment helps detect completed repeats; it is not a complete retry guarantee. A write can succeed before its comment is saved, and two runs started together can both check before either leaves a mark. After a partial or uncertain failure, inspect the item and the run report before retrying that operation; a production version keeps a durable record per operation, which is outside this guide. Creating ‘Check:’ tasks needs its own duplicate check, which step 5 does by title and meeting ID. Do any of this only after Part 3’s checks on the assisted version.

If the terminal is not your thing, stop at Route C1; it does the same job with a chat window. If you would rather write code, the same servers are reachable from the Claude API (the Messages API takes MCP servers as a parameter) and the OpenAI Responses API (its remote MCP tool). With credentials and access in place, an experienced builder can prototype that flow; running it unattended also needs authentication, scheduling and retry handling.

Copyable promptThe assisted prompt

The prompt, for C1 and C2 alike:

Prompt
Here is the transcript of a meeting held on [date], time zone
[zone], with [participants]. Work in [project / team / board].
Do not change anything yet.

1. List every agreed new task and every change to existing
   work (date, owner, status, scope, blocker).
   Keep tentative ideas and conditions explicit. Use null
   where an owner or a date was not said.
2. Before proposing anything new, search [project] for open
   items each change refers to: by task ID if one was
   mentioned, then by the deliverable, keywords and the
   owner’s name. Include done items if the conversation
   reopens work.
3. For every match, propose the update: the item’s ID and
   link, the field, its current value, the proposed value,
   the exact sentence that justifies it, and who said it.
4. If more than one item or person could match, do not pick.
   List the candidates and ask me. If a search fails or
   returns nothing, say so; a failed search is not proof
   the item does not exist.
5. Propose a new task only when the transcript supports new
   work and the search found no plausible match.
6. Show me the full list and wait. After I approve, re-read
   each target item first; if a value changed since the
   proposal, ask before applying. Apply only what I approved,
   one at a time, and report anything that failed.
7. On each item you change, add a comment with the sentence,
   the speaker and the meeting date, so the reason lives on
   the item.
ReferencePer-tool notes and official setup guides
  • Jira
    How to connect
    ‘Atlassian’ connector, from the directory
    What to search before writing
    Open issues in the project (JQL: project = X AND statuscategory != Done), then issue keys, deliverables and assignees
    Worth knowing
    Recommended address: mcp.atlassian.com/v2/mcp; the v1 addresses still work. OAuth 2.1 or an API token; some tools consume Rovo credits. Acts with your Jira permissions; status changes go through workflow transitions.
  • Linear
    How to connect
    ‘Linear’ connector, from the directory
    What to search before writing
    Open issues in the team or project, by keyword and assignee
    Worth knowing
    Also handles projects and milestones.
  • Asana
    How to connect
    ‘Asana’ connector, from the directory
    What to search before writing
    Incomplete tasks in the project, by keyword and assignee
    Worth knowing
    Custom setups should use Asana’s v2 server; v1 was scheduled to shut down in August 2026.
  • Monday
    How to connect
    ‘monday.com’ connector; the server is preinstalled on Monday accounts
    What to search before writing
    Items on the board whose status column is not done
    Worth knowing
    Read the board’s columns and labels before updating; not every board uses ‘Done’. Admins can restrict who may connect.
  • ClickUp
    How to connect
    Custom connector, URL https://mcp.clickup.com/mcp
    What to search before writing
    Open tasks in the list or folder
    Worth knowing
    Public beta. Check your plan’s MCP request limits before relying on it daily.

Official setup guides: Atlassian (v1 to v2 upgrade) · Linear · Asana · Monday · ClickUp. Addresses, plan access and menu paths last checked 20 September 2026.

What this route adds over the full build of Route B, which also searches, updates and comments: the current value and the proposed one side by side in the conversation, a question back to you when the match is not sure, and a fresh read of the item before an approved change is applied. In the chat version you inspect the proposals and approve them; unattended, it applies its own matches under the policy above. Part 3 is about both.

Part 3. What to check after two weeks

Run whichever workflow you built for two weeks, or on a handful of past meetings, and check these five things.

The two-week checklist

DetailsWhat to look for in each check

They help you see whether the workflow fits how your team works; some of what you find will be a prompt or a mapping to fix, some of it is what any workflow has to handle once meetings start repeating.

  • Repeated discussion. You discussed the same task in two meetings and changed its date in the second. After the second meeting, does that one task show the latest date, with no duplicate and a traceable reason? If your workflow queues proposals before applying them, do the two changes arrive as one consolidated proposal? A create-only workflow gives you two items. One that updates depends on its search finding the same item twice; when it misses, the result is a duplicate or otherwise an unresolved review item or a missed update.
  • Ambiguous references. You discussed something that could refer to two similar tasks (e.g. two open items mention the homepage). Does the pipe ask, or does it pick? The case to watch for is the plausible wrong match approved: it shows up on the board as a moved date with nothing to say it was a mismatch.
  • A changed board. After a proposal is prepared, edit the task on the board; when you approve the proposal, does the workflow notice the newer value before writing?
  • Where the ‘why’ lives. You open a task that changed and want to find out why. If the reason lives in a conversation nobody else can point at, the board shows a change without you knowing where it comes from.
  • Volume. Multiply the meetings in a week by the minutes each run takes, and check your connector’s request limits; ClickUp caps them on some plans.

Keep five counts while you do it: items created correctly, updates applied correctly, changes missed, wrong or duplicate changes, and minutes spent reviewing. A few representative meetings can reveal a pattern; they do not give you a measured accuracy rate for every future meeting.

If your current workflow handles these cases reliably, at a cost you are happy with, it’s a good solution to start with.

Part 4. What we want from a system that runs the loop continuously

Here is our own idea of the requirements for a truly reliable solution:

  • Capture. Conversations can be recorded with any tool you like or uploaded manually and linked to your meeting.
  • Structured extraction. Tasks, subtasks, meetings, blockers, decisions and open questions: each is a clearly distinct entity, with the fields it needs, each updated with precision.
  • Matching with context. Based on the project, the item’s current state, the recent history and what was decided the last time it came up, not just based on string similarity. And an explicit unresolved outcome the system is allowed to return, instead of a forced guess.
  • Review-gated. A review queue showing the current value next to the proposed update. Nothing on the board changes without a Project Manager approving it.
  • Continuity across meetings. When the same item is discussed multiple times before anyone has reviewed the edits in review, the system combines them in a unique review item with the final state.
  • Source evidence. Every change carries the sentence that originated it, together with a link to the transcript it comes from.
  • Corrections. When a transcript or a speaker label is corrected or transferred to a different project and processed again, extracted proposals in review are rebuilt within the new context.

Running the whole loop continuously takes more than a prompt. It also needs integrations, persistent state, review controls, and handling for failures and corrections, and putting those pieces together brings its own edge cases and operational work.

Sumnote. What we built

Sumnote is a project management tool that updates itself from the decisions in your meetings and chats, with a review queue in between. Every conversation runs through an extraction engine that finds the existing action item a decision is about, and proposes the change showing the evidence behind it; nothing on the board changes until a Project Manager accepts it. The work lives on Sumnote’s own boards, so it is for teams willing to run a project in it, not a plug-in for Jira.

A task on the board with its owner and date; the meeting decision; the proposed update with its source sentence; accept; the board changes. Then the same task discussed again before review, and the one chained proposal.

Our tool’s capabilities

Capture

Record in the browser, upload a file, or send Sumnote’s bot to Google Meet or Zoom; calendar meetings can join automatically. If your recordings already live in Fireflies, Sumnote reads them from there. Speakers are identified by voice, so ‘I’ll take that’ becomes an assignment.

Structured extraction

Each meeting becomes proposals: tasks and subtasks with owner, due date and priority; blockers between them; milestones; follow-up meetings. Decisions and open questions are recorded on their own into the project’s Insights, and an open question closes itself when a later decision answers it.

Matching with context

Before it proposes anything, the system looks through the existing items a meeting decision could refer to. An update shows exactly which fields change against the item’s current state. When a match is not certain, the proposal is marked ambiguous and asks you which item, or which person, it meant. It does not guess.

Review

Every proposal waits in the project’s review queue, run by the project’s managers. Accept, edit, or reject. A proposal exists as a record in the queue from the moment it is extracted; nothing reaches the board until someone accepts it, and a rejected proposal is removed.

Continuity across meetings

Leave the review queue alone for a while and the same item does not pile up as separate cards. When the same item is discussed again before anyone has reviewed the first proposal, Sumnote compacts the proposals into one chain that shows the item’s latest state, and one ‘accept’ applies the whole chain.

Source evidence

Every proposal carries the sentence from the transcript, who said it, the engine’s reasoning and a confidence level.

Corrections

Correct a line in the transcript, name a speaker or transfer the transcript to a new project, and Sumnote marks the extraction out of date. Re-run it and the pending proposals are rebuilt from the new reading.

And it is a project management tool

Boards with custom columns, lists, a timeline with dependencies and milestones, time tracking, comments and mentions, project chat, team dashboards, exports. Your existing tasks can be imported from ClickUp, Linear, Asana or Monday. It does what a capable project tool does, and all of it is built to update from the decisions you make in conversation.

Every decision lands.

Sumnote is in closed beta. If keeping your projects aligned with your meetings is a pain point for your team, you can submit your application.

Join the beta