# How we turn each meeting into notes and action items

Our meeting agent on Machine works from Google Calendar, the call transcript and Linear. When a call wraps, it writes tidy notes and files each action item as a Linear ticket for the person who owns it.

Canonical page: https://themachine.myapps.ai/use-cases/meeting-notes

You leave a call with three clear next steps. By tomorrow morning, two of them
have evaporated. Notes depend on whoever happened to type them, the to-dos sit
in people's heads, and nothing turns into real work unless somebody sits down
afterwards and writes the tasks up. That somebody is usually already late for
the next call.

Our fix was to give the calendar an agent. Once a meeting finishes, it writes
up proper notes and opens a ticket for each action item, assigned to the
person who took it on. Below is how we set that up on Machine: what it
connects to, how each run goes, and the limits we put on it.

- **Team:** Machine
- **Connected systems:** Google Calendar · Transcript · Linear
- **Trigger:** A meeting finishes
- **Mode:** Fires on each call · tickets go to the named owner

## The problem

Writing up a meeting properly takes effort, and it falls to whoever has the
most slack once the call ends. On a small team, nobody has any slack.
Choices are made and people even volunteer by name, then everyone hangs up
and none of it is captured. Seven days on, the thing you all agreed to still
hasn't begun, simply because it never became a task.

Recording helps with memory but not with action. Nobody scrubs through sixty
minutes of video hunting for the three promises that matter. What's missing
is the hop from transcript to tickets, and doing that hop by hand is precisely
the job that never quite gets done.

## What we built

We hooked our **Google Calendar** up to an agent on Machine. As soon as a call
is over, the agent gets its own fresh cloud computer, or sandbox, with access
limited to the meeting event, the transcript and Linear. From there it writes
notes in our format, picks out every action item, and opens a ticket for each
one under the name of the person who owns it.

## How it works

### Let the calendar start each run

We point a signed webhook from Google Calendar at the project. It goes off when
a meeting finishes, and Machine starts a new **session**: a clean sandbox for
that call alone, preloaded with the event details and the transcript. Every
meeting gets its own throwaway computer. Nothing is shared between sessions, so
two calls that end at once are simply handled side by side.

### Teach it how we write things up

Our house style is stored as **skills** and **memory**, the playbook the agent
opens at the start of every session. It covers how our notes are laid out, how
we word an action item, who looks after which area, and what earlier meetings
covered. The agent follows that style instead of making up its own, and the
memory keeps up as projects change hands.

### Decide what it may touch

Access runs through **connectors**: narrow links to each tool, with the keys
held on our servers so the model never sees a raw token. Through them the
agent can:

- **Pull the event and the transcript.** It sees who attended, what was on the
agenda and everything that was said.
- **Produce notes in our format.** Decisions, discussion and next steps, saved
where the team already goes to read them.
- **Open Linear tickets.** Every action item becomes a ticket with its owner
assigned and a link back to the meeting.

### Set the limits

The agent adds notes and new tickets, and that's it. Closing tickets,
reassigning them or editing work that already exists is off limits. If it
isn't sure who an action item belongs to, it flags it for a person instead of
guessing. Credentials are stored encrypted in the **Secrets Manager** and only
handed to the agents you grant them to.

### Then just have your meetings

From then on, a call ends and, before the next one starts, there's a page of
notes and a short stack of tickets. Someone says "Sarah will handle the
migration" and Sarah finds a ticket waiting. Someone says "we ship Friday" and
it's written down in the notes. Follow-up shows up as real tasks, not a vague
recollection.

> **The pattern**
> A **trigger** on meeting end starts the run. Limited **connectors** reach the
> transcript, the notes and Linear. Our note-taking habits live as **skills**
> and **memory**, and every action item goes to the person who owns it.

## Guardrails

Letting software open tickets and hand out work comes down to trust. Here is
what Machine puts in place:

- **Isolation.** One sandbox per meeting. It can read the transcript and the
  context it needs, and the only things that leave it are the notes and
  tickets it creates.
- **Scoped secrets.** The Calendar and Linear keys are stored encrypted in the
  **Secrets Manager** and only handed to the agents you grant them to, when the
  sandbox starts.
- **Human approval gate.** Any action item without a clear owner goes to a
  person to assign. The agent never guesses.
- **Everything is code.** The agent's persona, skills and permissions are files
  in the repo. Changing them takes a reviewed **change request**, not a toggle
  in a settings page.

## The outcome

- **Every call:** Gets written notes and filed action items
- **Assigned:** Each ticket lands with the person who owns the task
- **3 systems:** Calendar, transcript and Linear, handled by one agent

Follow-up used to rely on somebody's memory. Now notes and tickets turn up a
few minutes after hanging up. People skim a tidy summary and find their own
tasks already sitting in Linear, rather than trying to piece the meeting back
together a week later.

Four things make it work: a separate sandbox for each meeting, the Secrets
Manager holding the Calendar and Linear keys, a flag whenever the owner of an
action item is unclear, and memory that carries context from one meeting into
the next.