An AI meeting agent is judged by what it files

Six meetings end on a Tuesday, and by Thursday nobody can say which three decisions came out of them. Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers. What separates a meeting agent from a recorder is where its notes and its action items end up.

The follow-up is the step that gets skipped

Turning a conversation into tasks is real work, and it lands on whoever is least busy when the call ends. On a small team that is nobody. Decisions get made, owners get named out loud, and the meeting closes. A week later the thing everyone agreed to has not started, because it was never a task. Recording the call fixes the record and leaves the follow-up where it was: nobody rewatches an hour of video to find the three things they agreed to do.

An AI meeting agent is software that attends a call, keeps a record of it, and then acts on that record. The acting is the part worth judging, since anyone with a recorder and a subscription has the transcript.

Getting into the room is the easy half

Being in a live call takes four things: a way to join, audio in both directions, speaker names, and a transcript the agent can read afterwards. Kortix shipped the room half of that in v0.15.0. The release notes say: "Voice: a Kortix agent joins a Google Meet with its voice, joins any web call, and speaks into and transcribes audio files" (read 8 November 2026).

The claim names Google Meet, web calls and audio files, and it stops there. Speaking in the room is what lets an agent read an owner back before the call ends, or ask which of two people is taking the pricing page. Transcribing is what gives the next step something to work from. Neither one files anything, which is why a capable voice stack still leaves the follow-up undone.

A transcript is not a ticket

Products sold as AI meeting agents fall into two groups. The note-takers own the record. Otter schedules its notetaker into Zoom, Microsoft Teams and Google Meet, says next steps are "automatically captured and assigned from every meeting", and syncs them to a CRM (otter.ai, read 8 November 2026). Noota produces "action items with an owner, a follow-up email ready to send", with a bot in the call or without one (noota.io, read 8 November 2026). MeetGeek triggers agents when a meeting ends and lists a skill that will "auto-create tickets in Jira or Linear" (meetgeek.ai, read 8 November 2026). tl;dv sells agentic workflows whose action item tracker extracts assigned tasks and deadlines (tldv.io, read 8 November 2026).

The second group puts an agent in the call and leaves the rest to you. Vexa is a meeting bot API under Apache 2.0 that runs on your own servers, at $12 per seat per month, with bot time sold by the hour on its API plan (vexa.ai, read 8 November 2026). AgentCall is a skill that lets a coding agent join Meet, Zoom or Teams with voice and a live transcript, with the meeting bot from $0.35 an hour (agentcall.dev, read 8 November 2026). joinly is MCP middleware that gives an agent the meeting controls, and its page lists tasks after the call "like writing follow-up mails or creating tickets" (joinly.ai, read 8 November 2026).

Both groups get the record right. The assignment rule is the part left over. Check whether a teammate can read the rule deciding who gets the ticket, and see a diff when it changes. A rule kept as a file can be reviewed in a diff before it goes live. For a sales team logging CRM fields, the setting is a fair trade. For a company whose follow-up now starts with an agent deciding who owns what, the rule is worth owning.

The meeting-notes setup, in three files

Kortix runs this on its own calendar, and the setup is published as a use case (read 8 November 2026). Three files carry it: an agent file that says what the meeting-notes agent is for, skills/meeting-recap/SKILL.md with the rules for the writing, and a trigger in kortix.yaml. The first two are text a teammate reads and edits like any other file in the repo.

A run starts on the schedule, finds every meeting that ended since the last check with a transcript attached, and writes notes in three parts: decisions, discussion, and next steps phrased as "[Owner] will [do X] by [when]". Each action item becomes a ticket assigned to the owner named in the transcript. The trigger is a cron line:

triggers:
  - slug: meeting-ended-check
    name: Meeting-ended check
    on:
      cron: "0 */15 * * * *"
    run:
      agent: meeting-notes
      prompt: Load the meeting-recap skill and write notes and tickets for every meeting that ended since the last check.

Fifteen minutes is the whole latency budget, so the notes arrive while the call is still fresh. To change the cadence, edit the cron line or open Triggers in the project. Either way the trigger ends up beside the agent it starts, in kortix.yaml.

Three connections make it work: the calendar that holds the events, the drive that holds the transcripts, and the ticket tracker. In the published setup those are Google Calendar, the transcript store and Linear. The sample run reads: "Wrote notes for 1 meeting with 2 decisions. Filed 5 tickets in Linear: 4 assigned to the owners named in the call, and 1 unassigned because nobody took the pricing page copy."

Who decides, and what the agent may change

An agent that files tickets makes an ownership decision for you, so the rules matter more than the model. This setup assigns a ticket only when the transcript names the owner or the ownership map in memory covers the topic. When neither holds, the ticket goes in unassigned with the ambiguity written into its description, for a person to sort out. That rule separates an agent that files work from one that guesses and is wrong quietly.

The second rule is narrower. The agent only creates tickets. It never closes, reassigns or edits a ticket that existed before the meeting, so the history in your tracker stays a record of what people did.

The agent's rules say what it may do; the platform enforces the rest. Every session gets one isolated sandbox with its own machine and branch. Session work reaches main through a change request, and merge is default-deny for agents. Approval gates stay off until you set them. The meeting-notes agent reaches the repo the way an agent editing a skill does: through a change a person reads before it lands.

Four questions before you buy one

Every demo looks the same, because every demo shows a summary. Ask these instead, of any meeting agent, this one included.

• Where the notes live. Where a note can be read from decides whether it outlives the contract. A file in your own repo is readable either way.
• Who can read the rule. A file can be read by the team and changed in a diff.
• What the agent may change without a person. Creating a ticket and rewriting a ticket are different permissions, and only one is safe to hand over on day one.
• What happens when ownership is unclear. A guess produces a ticket in the wrong queue, and the person who notices is the one who did not get it.

On Kortix the repo holding the agent, the skill and the schedule is yours. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

Two related reads: how a screen-recording agent turns a recording into a searchable timeline an agent can query (/blog/screen-recording-ai-agent), and why an agentic workflow ends at a change request (/blog/agentic-workflow-ends-at-a-change-request).

The setup takes one pasted prompt, a change request you review, and a calendar connection. Start on Kortix. Free to start, free to self-host.