How to Turn a Meeting Recording Into Lark Action Items

The reliable way to turn a meeting recording into action items is to separate the workflow into four stages: transcribe the audio, extract structured decisions and tasks, review uncertain fields, and then create the approved tasks in Lark. That review boundary matters. A transcript can contain “I can do that next week” without identifying the right Lark user or an exact due date.

This guide builds that workflow with an AI coding agent and Aident Loadout. The example uses Gladia for transcription and Lark for the meeting record and tasks, but the same structure works with another transcription provider or task system.

What You Will Build

The finished workflow accepts a meeting recording at a durable HTTPS URL and produces:

• a Lark document containing the meeting summary, decisions, full transcript, and source link;

• a review table with each proposed task, owner, due date, supporting quote, and confidence;

• one Lark task for each approved action item; and

• a stable idempotency key for every write, so rerunning the workflow does not create duplicate tasks.

The important design choice is that transcription and task creation are not one opaque step:

recording URL
  -> transcript
  -> structured action-item draft
  -> human review and identity matching
  -> Lark document and tasks
  -> read-back verification

Prerequisites

Before starting, prepare:

1. A meeting recording that you are allowed to process. Confirm consent and retention requirements for every participant.

2. A durable HTTPS download URL for the audio. A local path such as /Users/me/meeting.mp3 is not available to a remotely hosted action.

3. A Lark account with permission to create documents and tasks.

4. Claude Code, Codex, or another agent that can use Aident Loadout.

Install Aident Loadout by giving your agent this exact instruction:

Follow https://aident.ai/SETUP.md

Then confirm the CLI and connected accounts:

aident account auth status
aident vault vault --action status

If Gladia or Lark is not connected, ask the agent to connect it through Aident Vault. Keep provider credentials out of prompts, transcripts, source control, and shell history.

Step 1: Find the Transcription and Lark Actions

Ask your agent to find actions by intent instead of hard-coding an internal integration identifier:

Use Aident Loadout to find:
1. an action that transcribes an audio file from an HTTPS URL;
2. a Lark action that creates a document; and
3. a Lark action that creates a task.

Inspect each input schema before executing anything. Do not create a
document or task yet

At the time of writing, the connected catalog exposes Gladia Generate Transcription, Lark Create Document, and Lark Create Task actions. Catalogs evolve, so schema inspection is safer than copying an old payload from a tutorial.

The transcription action requires an audioUrl. The Lark document action accepts document content. The task action supports a summary, description, assignee, due date, task list, and idempotency key. Your available fields may differ by catalog version.

Step 2: Transcribe the Recording

Give the agent the recording URL and ask it to transcribe without writing to Lark:

Transcribe this meeting recording with the available transcription action:
https://files.example.com/meetings/2026-07-23-product-review.mp3

Return the provider result and preserve timestamps and speaker labels when
they are available. Do not infer speaker identities from voices. Do not
create any Lark documents or tasks

Replace the example URL with your own short-lived, access-controlled URL. The transcription request is asynchronous in Gladia: it returns an identifier, processes the audio, and then exposes the result. A hosted action may handle that polling for you.

Before continuing, check three things:

• Coverage: The transcript starts and ends at the expected times.

• Speaker separation: Speaker labels are present when the provider returned them. A label such as SPEAKER_01 is not a verified identity.

• Language quality: Product names, acronyms, and code terms are spelled correctly. For multilingual meetings, use a transcription setup that supports code switching.

If the transcript is incomplete or badly segmented, stop and correct transcription first. Better prompting cannot recover words that are missing from the source transcript.

Step 3: Extract a Reviewable Action-Item Draft

Next, convert the transcript into a strict intermediate format. This prevents prose summaries from silently becoming tasks.

Use this prompt:

Extract decisions and action items from the transcript.

For each action item, return:
- task: a concrete verb-first summary;
- ownerMention: the exact owner wording from the transcript, or null;
- ownerLarkId: null;
- dueDateMention: the exact due-date wording, or null;
- dueAt: an ISO 8601 timestamp only when the date is unambiguous, otherwise null;
- evidence: the shortest supporting transcript quote;
- timestamp: the supporting timestamp when available;
- confidence: high, medium, or low;
- needsReview: true if owner, deadline, scope, or evidence is uncertain.

Rules:
- Do not invent an owner or deadline.
- Do not turn ideas, questions, or rejected proposals into tasks.
- Keep decisions separate from action items.
- Merge duplicate mentions of the same commitment.
- Do not write to Lark

A useful draft looks like this:

{
  "task": "Send the revised launch checklist",
  "ownerMention": "Mina",
  "ownerLarkId": null,
  "dueDateMention": "by Friday",
  "dueAt": null,
  "evidence": "Mina, can you send the revised launch checklist by Friday?",
  "timestamp": "00:18:42",
  "confidence": "medium",
  "needsReview": true
}

dueAt remains null because “Friday” needs a timezone and an anchor date. ownerLarkId remains null because a spoken first name is not a Lark identity.

Step 4: Review Owners, Dates, and Scope

Ask the agent to render all proposed tasks as a compact table, then review it with the meeting owner. Resolve:

• whether the sentence is a real commitment;

• the canonical Lark assignee;

• the due date and timezone;

• whether two transcript mentions describe one task; and

• whether confidential transcript evidence belongs in the task description.

Do not let the agent guess a Lark user from a display name. Match each approved owner to a verified Lark member identifier. Leave the task unassigned if the identity is not certain.

For a recurring workflow, define a durable meeting key such as:

2026-07-23-product-review

Then derive a unique write key for each task:

meeting-action:2026-07-23-product-review:send-revised-launch-checklist

The Lark task action exposes an idempotency key. Reuse the same key if the agent has to retry the write.

Step 5: Create the Lark Meeting Record

After review, create one Lark document before creating tasks. The document should contain:

1. meeting date, participants, and recording URL;

2. a concise summary;

3. confirmed decisions;

4. the approved action-item table;

5. unresolved questions; and

6. the transcript with timestamps when retention policy permits.

Ask the agent:

Create one Lark document from the approved meeting record. Include the source
recording URL and preserve the reviewed task table. Return the document URL.
Do not create tasks yet

Open the returned document and confirm that the title, decisions, action items, and source link are present. This document becomes the evidence trail for the task writes.

Step 6: Create Approved Lark Tasks

Only now should the agent create tasks:

Create one Lark task for each approved action item.

For every task:
- use the reviewed verb-first summary;
- assign only the verified Lark member identifier;
- set the reviewed due date and timezone;
- link the meeting document in the description;
- include the supporting timestamp, but omit sensitive transcript text;
- use the approved idempotency key;
- return the created task identifier and URL.

Stop on the first write failure. Do not retry with a different idempotency key

The expected result is a one-to-one mapping between approved rows and returned Lark task identifiers. If five rows were approved, the agent should return five successful writes, not “tasks created” without a count.

Step 7: Verify the Result

Read every created task back from Lark or open each returned URL. Confirm:

• the number of tasks equals the number of approved rows;

• each summary, assignee, and due date matches the review table;

• every task links to the correct meeting document;

• no idempotency key produced a duplicate; and

• no unapproved item was written.

Keep the review table and returned task identifiers in the meeting document. On a retry, compare against that record before making another write.

Common Failure Modes

The Transcription Action Cannot Download the Recording

An authenticated browser link, local path, or expired signed URL may not be reachable from the hosted action. Use a durable HTTPS URL that the action can fetch, limit its lifetime, and test the download from a separate environment before transcribing.

The Transcript Has No Speaker Names

Speaker diarization groups voices; it does not establish real identities. Preserve anonymous speaker labels and have a participant map them during review. Never assign tasks based only on voice order.

The Agent Invents Owners or Due Dates

Make null an allowed value and require an evidence quote. Any ambiguous relative date or owner mention should set needsReview: true. This is a data-contract problem, not a prompt-polish problem.

The Workflow Creates Duplicate Tasks

Generate each idempotency key from a stable meeting key and normalized task identity. Store the key with the approved row, and reuse it on retries. Do not include the current time in the key.

Lark Rejects the Write

Inspect the current action schema and verify the connected account's document, task, member, and task-list permissions. Resolve member identities before executing the task action. Fail fast instead of dropping the assignee or deadline silently.

Long or Multilingual Audio Produces Weak Results

Check the provider's supported formats, duration limits, diarization, and code-switching options. Split audio only when the provider requires it, and preserve absolute timestamps across chunks so evidence remains traceable.

Why This Workflow Is More Reliable

The workflow treats a transcript as evidence, not as a task list. Structured extraction makes missing fields visible. Human review resolves identities and dates. Idempotent writes make retries safe. Read-back verification proves that the external system matches the approved plan.

That separation also makes the workflow portable. You can change the transcription provider or task system without rewriting the rules for evidence, review, identity matching, deduplication, and verification.

Run the Workflow With Your Agent

Aident Loadout gives Claude Code, Codex, and other agents a searchable action catalog and connected-account access without placing provider credentials in every prompt. Start with one consented meeting, review every proposed task, and measure the percentage of approved tasks that arrive in Lark with the correct owner and due date.

Connect Gladia and Lark with Aident Loadout, then ask your agent to build the review-first workflow above. For the broader integration model, see How to Connect Claude Code and Codex to Real-World Tools.

Sources

• Gladia: Pre-recorded transcription quickstart

• Gladia: Initiate a pre-recorded transcription

• Gladia: Retrieve a pre-recorded transcription

• Gladia: Speaker diarization

• Gladia: Code switching

• Lark Open Platform: Task v2 overview

• Lark Open Platform: Docx overview