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

Works withJiraLinearAsanaClickUpMonday

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

This guide shows three ways to turn your meetings into tasks in your project tool. You can use your notetaker’s own integration, an automation tool like Zapier, or an AI assistant. The last two can also update tasks that already exist. Part 1 first looks at the AI already built into project tools. At the end, we show Sumnote, the tool we built to run the whole loop, from meeting to updated board.

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

You probably already use both halves you want to connect: a notetaker that lists action items, and a project tool where your tasks live. Connecting them is not the hard part. Most tools in both categories support it, some in one click. The hard part is what comes out the other end, and whether you can 100% trust your project board afterwards.

The recipes in this guide are prototypes. They give you enough detail to build a first version. Setup time depends on your permissions, your tools and your experience. Part 3 covers what to check in the first two weeks of testing your new pipe.

One thing to keep in mind: a meeting doesn’t only create new work. It also changes 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. That sentence should change two fields on a task that already exists, not create a new task next to it.

Part 1. The AI already inside your project tool

Most project tools now have AI that helps turn meetings into tasks. ClickUp’s AI Notetaker records the meeting and turns action items into assigned tasks. Notion’s AI Meeting Notes give you a transcript, a summary and a list of action items; turning those into tasks in a Notion database is a separate step. Atlassian publishes a ready-made skill for AI assistants. It pulls action items from meeting notes, looks up Jira users, asks you to resolve unclear names, and creates the tasks after you confirm. That is the assistant approach in Route C below, with a prompt written by the vendor.

In the examples above, these features share one verb with the notetaker integrations and the simple automation build in Part 2: ‘create’. That is not a flaw in any of them. It fits 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.

A test you can run this week

Take the transcript of your last project meeting. Sort every commitment and 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 pipe 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. These are ongoing costs.

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 have native integrations. They turn the action items they detect 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 project to send tasks to, a test project if you have one. Each integration works a little differently. Some need an admin to install them in both tools. Some send action items on their own after every meeting. Others create a task only when you click one. Check how the integration matches speakers to users, and what it does with fields your project tool requires. Then run one meeting with one clearly new task and one change to an existing task. Look at both results on the board.

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

Where it stops:

  • It usually creates a new task from each action item. How the title, assignee and date get filled in depends on the integration, how you set it up, and any confirmation form it shows you.
  • Fellow’s Jira integration can also pull existing issues into the meeting agenda and keep titles, assignees and due dates in sync both ways. That’s useful. But the link exists because a person picked the issue, not because the integration found it from your project’s context.
  • As far as their documentation shows, these integrations don’t use your project’s context to match each spoken change to the existing item it’s about. A name in the transcript is not a recognized user. 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 have the transcript (), send it automatically to an AI model, like Claude Sonnet 5.5, with a prompt that returns structured data (JSON).

What it adds over Route A: you own the schema, meaning you decide which fields come back. You can ask for the title, owner, due date and the sentence in the transcript that produced the item, and route each item to its project.

You also decide what the pipe does with the result. It can only create new action items. Or it can search your project first and update what’s already there. Those are two different builds, so here are both. The full build is written for Jira, with notes on adapting it.

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:

B1. The simple build: create only

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

    Trigger. In Zapier, choose your notetaker’s app (Fireflies, Otter, tl;dv, Fathom and others publish one). Pick its new-transcript event (in Otter it’s called New Recording), so the Zap starts each time a meeting is transcribed. Also map the meeting date, the time zone and the meeting ID from the trigger; later steps need them.

  2. 2

    Model. Add an action with the Anthropic (Claude) or OpenAI (ChatGPT) app. 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 add the transcript text, the meeting date, the time zone and the participants.

    Here is a prompt you can use for this 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 show you how much of what it’s about to create is really a change to something you already have. The label is the model’s judgment, so check 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 can process one item at a time. When a Code step returns a list, Zapier runs every step after it 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. Below is an example of the model’s output, before the Code step adds its helper fields. It’s for a meeting on Monday 21 September 2026, Toronto time, with Jack, Maya and Priya. (Copy it from the page, where each string is on 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 holds both changes Jack asked for, on one item. The second is flagged for clarification. The deadline ‘before we see them again’ can’t be resolved 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 that lets through only items where needs_clarification is false and type is new_work or change_to_existing.

  5. 5

    Create. Add your project tool’s create action (Create Issue in Jira, Create Task in Asana). Map title to Summary (Jira’s name for the task title) and due_date_value to the due date. Put source_quote, speaker and the meeting date in 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). 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 doesn’t say 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 can’t tell you who said ‘I’ll take that’. AssemblyAI can label speakers as Speaker A and B, but 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. A lookup can find nobody, or more than one person. Test once with a name that isn’t in your workspace and once with a name two people share, then check the assignee on the tasks it creates. Handling this fully (checking how many people came back, branching, projects that require an assignee) is its own rabbit hole, and beyond this guide. It’s one of the problems we built Sumnote to solve. Sumnote identifies speakers by voice, and asks you which person when a name could mean two.
  • Rejected records. Records the Code step rejects are extraction problems to report, not tasks to create.

If a step is unclear, paste this section into your AI assistant with the names of your tools. 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.

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

This build is written for Jira. Its Zapier app has every piece the recipe needs: a search that can return several candidates, a user lookup, an update and a comment. Notes for 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 pipe 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 it to return up to five results, and use 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 already 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. It reads the item and the candidates, and answers in one line. Use 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 write it) that splits 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, from step 2, every item is already either New or Change:

    • 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. 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 stays on the item.

  6. 6

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

Good to know

  • Labeling 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 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 unlabeled tasks in the results.
  • Search settings. Return all results as line items. 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 after it 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 characters JQL would read as part of the query. 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 it was given fit, 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. An empty input should leave the field unchanged, so test it. A status change goes through the action’s Status input when your Jira workflow allows that transition; otherwise it becomes a Check: task. A description change also becomes a Check: task, since this recipe doesn’t rewrite descriptions.
  • Matching by meaning. If a match is missed, first check whether the right task was in the candidate list at all. A task missing from the list and a task in the list but not chosen are different failures, and a wider query helps only with the first. The query already searches titles, descriptions and other text fields. To widen it, try other terms, adjust the project or status scope, or pull candidates by owner and recent activity. The bigger upgrade is embedding-based search, which finds records by similarity in a vector index (services such as Pinecone offer it, including as a Zapier step). It finds tasks described in different words. It’s 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 that returns 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. For Linear or ClickUp, you need a different way to get candidates, because 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, pull the tasks from the right list or folder, page by page, and pick candidates from them. Either way, the call goes through a request step your connector supports, or an HTTP action set up for your tool’s API. Test it before you reuse the matching and routing steps. The routing, matching and comment steps stay the same; the search and the field mapping change per tool.

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

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. Both platforms can keep state between runs. What the recipe as written doesn’t do yet:

  • It keeps no structured history of pending proposals across meetings. The same item discussed twice means two separate runs, each leaving a comment, 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.
  • 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. A model with search access can read the board before it writes to it. Here’s how it works: your project tool publishes a small server (an MCP server) that lists the actions it allows, such as search issues, read one issue’s details, update a field, or add a comment. An assistant connected to it can run those actions with your login. That’s what Route A and the simple build of Route B don’t have: something that reads the board before deciding.

C1. In a chat app, for anyone

5 stepsConnect Claude or ChatGPT to your project tool

How to set it up in Claude, with no code. Connectors are available on Claude plans, with different limits per plan. 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. Monday admins can also limit who may use it.

  2. 2

    Set permissions. In the connector’s tool settings, set every tool that can change anything to ask before running. That means create, update, transition and comment, and on Atlassian’s server also its general write tool. 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 waits 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 their own MCP server. 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 yours before building around it. On workspace plans, an admin may need to allow custom apps first.

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. 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). Atlassian’s older v1 addresses still work, but new setups should use v2. In the Codex desktop app, you’ll find the same option under Settings, MCP servers, Add server.

    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 for each client. Follow Asana’s coding-client guide.

  3. 3

    Save the prompt below as a command that takes a transcript file. In Claude Code, create a file .claude/commands/meeting.md with the prompt in it, and put $ARGUMENTS where the file path goes. 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 and start an interactive session with codex. Ask it to read meeting.md and the transcript file, and to 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 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. Don’t rely on a default for that. You can set permissions tool by tool in each app: in Claude Code through its permission rules, and in Codex through its MCP server settings, which have an approval mode for each tool (separate from its shell and file permissions). Set every write tool to require approval. Then confirm it in a test project before the first real meeting, with one read and one small write. A prompt that asks the agent to wait is not the same as the client refusing to write. This way, you check the proposals, then approve the changes.

  5. 5

    The unattended version. This runs 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). For that, 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 won’t work here, because it tells the agent to wait, to ask about ambiguity, and to ask again if the board changed. Use this separate prompt instead. It’s 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.

    Before you turn on the unattended run, name and set up the external review log and the review owner. The review owner is a person you designate in advance, not a guess at who owns the work. The prompt uses Jira’s meeting-review label to mark review items. For another tool, set up a marker or a separate review destination that the connected tools can both write and read back (a tag column in Monday, a tag or custom field in Asana). Use it the same way in steps 2 and 5, and check that both the exclusion and the review lookup work in that setup. If those operations aren’t available there, send review items to the external log.

    The comment helps catch a change that was already made, but it doesn’t fully guarantee safe retries. A write can succeed before its comment is saved. Two runs started at the same time can both check before either leaves a mark. After a partial or uncertain failure, check the item and the run report before you retry that operation. A production version keeps a lasting record of each 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 isn’t your thing, stop at Route C1; it does the same job in a chat window. If you’d rather write code, you can reach the same servers from the Claude API (the Messages API takes MCP servers as a parameter) and from 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
    Use Asana’s v2 server; the old v1 server has been shut down.
  • 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.

The full build of Route B also searches, updates and comments. What this route adds: the current value and the proposed one side by side in the conversation, a question back to you when the match isn’t sure, and a fresh read of the item before an approved change is applied. In the chat version, you check the proposals and approve them. Unattended, it applies its own matches under the rules above. Part 3 covers both.

Part 3. What to check after two weeks

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

The two-week checklist

DetailsWhat to look for in each check

These checks show whether the pipe 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 pipe has to handle once meetings start repeating.

  • Repeated discussion. Say 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 reason you can trace? If your pipe queues proposals before applying them, do the two changes arrive as one combined proposal? A create-only pipe gives you two items. One that updates depends on its search finding the same item twice. When the search misses, you get a duplicate, an unresolved review item, or a missed update.
  • Ambiguous references. Say you discussed something that could refer to two similar tasks (for example, two open items mention the homepage). Does the pipe ask, or does it pick? Watch for a wrong match that looked right and got 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 pipe notice the newer value before writing?
  • Where the ‘why’ lives. You open a task that changed and want to know why. If the reason lives in a chat nobody else can point to, the board shows a change with no way to tell where it came from.
  • Volume. Multiply the meetings in a week by the minutes each run takes. Then 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 typical meetings can show you a pattern. They won’t give you a measured accuracy rate for every future meeting.

If your current pipe handles these cases reliably, at a cost you’re happy with, it’s a good place to start.

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

Here is what we think a truly reliable solution needs:

  • Capture. Conversations can be recorded with any tool you like, or uploaded by hand and linked to the meeting.
  • Structured extraction. Tasks, subtasks, meetings, blockers, decisions and open questions are each kept as their own kind of item, with the fields they need, and each one is updated precisely.
  • Matching with context. Matching uses the project, the item’s current state, its recent history and what was decided the last time it came up, not just similar words. And the system is allowed to say it can’t tell, instead of forcing a 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 several times before anyone reviews the pending changes, the system combines them into a single review item showing the final state.
  • Source evidence. Every change carries the sentence it came from, with a link to the transcript.
  • Corrections. When a transcript or speaker label is corrected, or a transcript is transferred to a different project, and it’s processed again, the proposals waiting in review are rebuilt in the new context.

Running the whole loop continuously takes more than a prompt. It also needs integrations, stored state, review controls, and a way to handle failures and corrections. Putting those pieces together brings its own edge cases and ongoing 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 goes through an extraction engine. It finds the existing action item a decision is about, and proposes the change with 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’s 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

Each requirement from Part 4, and how Sumnote meets it.

Capture

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

Structured extraction

Each meeting becomes proposals: tasks and subtasks with owner, due date and priority, blockers between them, milestones, and follow-up meetings. Decisions and open questions are recorded separately in the project’s Insights. 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, next to the item’s current state. When a match isn’t certain, the proposal is marked ambiguous and asks you which item, or which person, it meant. It doesn’t guess.

Review

Every proposal waits in the project’s review queue, run by the project’s managers. Accept, edit, or reject. A proposal is saved in the queue from the moment it’s 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 doesn’t pile up as separate cards. When an item is discussed again before anyone reviews the first proposal, Sumnote combines the proposals into one chain that shows the item’s latest state. 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 as out of date. Run it again, 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 apply.

Join the beta