Meeting-to-Action-Item Agent

The useful output is a short list of decisions with named owners and dates, confirmed by someone who was in the room, then tickets on the board the team already uses. A meeting recap is the wrong artifact. It reads well and still leaves the work in Slack.

Speed is the point: when steering runs long, nobody rebuilds the decision log from memory. The cost of that speed is junk on the board if you treat the model's first pass as a write. Extract. Stop. Confirm. Then push.

Transcripts arrive from tools in the Otter.ai, Fireflies, Gong, and Microsoft Copilot class. Use the transcript as the source file. Do not treat the recap as the action list. A recap will merge a decision, a parking-lot idea, and a joke into one tidy paragraph. That paragraph cannot own a ticket.

This is not interview synthesis. A diagnostic set of interviews belongs in a multi-stakeholder interview transcript analyzer. That job is contradictions across roles. This job is what this working session actually decided.

If you cannot record, this use case does not run. Write actions from notes. Do not paste a quiet recording into a model.

Client meetings often need more than a courtesy. Some clients prohibit recording. Some allow it only with named attendees. Some require a basis in the master agreement before a recorder joins. Get explicit consent, and say what happens to the recording afterward: who can see it, how long it is kept, whether a transcript leaves the client's tenancy.

A written record of every decision also changes the engagement's evidentiary position. Legal may have a view. Settle that before you put a bot in the calendar. Recording without consent is not a tooling miss. It is a breach.

Internal huddles are a different consent bar. Do not mix those files with client steering. An internal "we should push back on scope" is not a client decision, and it should not become a client-visible ticket.

Do not prompt "summarize this meeting and create Jira tickets." Prompt for structured fields, then hold the write until a human confirms.

From the transcript, extract only rows that look like this:

1. Decision: what was agreed, in one sentence, with a quote or timestamp when you can.
2. Owner: a named person who was on the call, or a named role that already maps to one person on the team. "We" and "the team" are not owners.
3. Date: the due date someone said, or the next named checkpoint (Friday standup, next steering). If nobody said a date, leave it blank. Do not invent Friday.

Ask the model to label each candidate as decided, parking lot, or new request. Parking-lot ideas stay off the board. New requests that sound like extra work go to the scope creep detector, not into a task.

Then a human who was in the room (engagement manager or workstream lead) marks each row: keep, edit, drop. Only keep rows may write to the existing project in Jira, Asana, or monday.com, with the same issue type, labels, and parent epic the team already uses. Do not create a parallel "AI actions" board. Tickets nobody looks at are worse than notes in a doc.

If the transcript still says Speaker 2, fix speaker labels before you extract. An unlabeled speaker cannot be an owner. "Write at meeting end unless someone objects" is a push before confirm, not a confirm step.

This is a worked example with made-up names, written to show the cuts, not a case study with results.

Sam is the engagement manager on a finance-process redesign at Harbor Logistics. Thursday steering runs 50 minutes: Priya (client PMO), Mei (controller), Tomas (consultant, data), Anders (consultant, process), and Sam. Otter.ai produces the transcript. A Microsoft Copilot recap lands in the chat. Fireflies huddle files and Gong recordings from the original sale stay out of this run.

The Copilot recap says the team aligned on the SKU-master mapping, vendor invoices, and extra sites.

The extractor, asked for decided / parking lot / new request, returns four rows:

• Decided: Tomas owns "finish SKU-master mapping for the pilot DC" by Friday's standup. Quote: Priya, "Tomas, can you close mapping for the pilot DC by Friday so Mei can run the parallel." Keep.
• Parking lot: "Stand up a vendor-invoice workstream." Tomas floated it. Mei said, "interesting, let's not decide today." The model still proposed Mei as owner. Drop. A parking-lot idea is not a decision.
• Invented owner: "Send a weekly status pack," owner "the team," due Friday. Nobody named a person. Nobody agreed a pack. Drop, or rewrite only if Sam names a real owner and a real date.
• New request: Priya, late call: "while you're in the data, can we add the other three sites to the diagnostic." That is a scope ask, not an action on the current SOW. Do not open three extra-site tickets.

If Sam had allowed an auto-push to Jira, Mei would own a vendor-invoice epic she declined, "the team" would own a ghost ticket, and three extra sites would look like committed delivery.

Sam confirms the mapping ticket, writes it into the existing Jira epic for data, and leaves the rest off. The Asana board the client PMO uses is not a second dump of the same rows unless Priya asked for that mirror.

Design for these four failure modes before the first auto-write.

Invented owners. Models fill the owner field because the schema requires one. They will pick the last person who spoke, the client sponsor, or a name from a previous meeting. "We should" is not assignment. If the owner was not on the call, or is a group, leave the field blank and make the human name someone, or drop the row.

Pushing before confirm. The speed fantasy is tickets at meeting end. That is also how a misheard date, a joke, and a declined idea become the plan of record. Jira, Asana, and monday.com tickets are commitments people staff against. A human who was in the room is the write gate. No confirm, no push.

Parking-lot ideas treated as decisions. Exploratory language ("we could," "maybe later," "interesting," "let's park that") is cheap for the model to promote into a decision because it looks like work. Force the three-way label. If the transcript never contains agreement, it is not decided.

Recording without consent. A bot that joins from the calendar will record people who never agreed. That is not fixed by a good prompt. It is fixed by not joining until consent and retention are explicit. If legal or the client says no, stop. Notes are slower. They are allowed.

A quieter fifth miss: treating tone in the transcript as a client satisfaction sentiment monitor score. This use case does not score the relationship. If Priya's replies got shorter, that is a different job, with a different consent bar for mailboxes.

The artifact the team should see is the same board as yesterday, with a few new tickets that look like their tickets. The artifact they should not see is a dump titled "AI actions from steering."

Match project, issue type, and parent. Put the quote or timestamp in the description so a skeptic can check the transcript. Leave story points and sprint assignment to the workstream lead. A model that estimates remaining work from a meeting will guess.

Unclosed tickets from this path are a delivery signal. They belong in the workstream delivery risk predictor the same way any other aging ticket does.

Discovery calls are not this path. If you are still shaping scope, use the SOW drafter from discovery transcript. Pushing "action items" from an unsold discovery call creates delivery on a contract you have not signed.

Trial this on one recurring steering meeting, in parallel with the current notes. Judge it on whether confirmed tickets match what the room decided, whether anyone had to close a ticket they never owned, and whether a parking-lot idea stayed off the board. If the output is a recap plus twenty tickets, you ran the wrong job.