How we turn each meeting into notes and action items
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.
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
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.
More use cases
How we answer GDPR data-subject requests before the deadline
Our Machine agent checks each GDPR access or deletion request, finds the person's data across our product database, builds the report well within the SLA and hands it to legal before anything is sent.
How we keep our docs matching what the code does
Once a day a Machine agent reads every commit merged since its last pass, finds the doc pages those changes made wrong, rewrites them and sends you one pull request to review.
How we test every pull request without lifting a finger
Our Machine QA agent works with GitHub and our test environment. For each pull request it checks out the branch, runs the tests, tries the change for real, and posts what it found.
Put your first agentto work today.
- SSO
- RBAC
- Governed agents
- Full audit trail