Custom autonomous systems · Mock demo

Keep Jira up to date from your meetings and Slack: Logbook

Teams say their updates out loud, in standups, syncs and threads, and the board falls behind. Logbook reads the meeting transcript, updates the tickets people talked about, marks blockers, and asks before changing anyone's commitments. From the blockers it builds a map of which work waits on what, and points out the biggest bottleneck.

The metric at the centre: tickets out of date. Active tickets whose status, owner or dates contradict what the team actually said. Logbook works it down to zero and reads the board back to prove it.

Building this yourself? Our guide to updating Jira from meeting transcripts without wrong updates covers the options, what goes wrong and the design behind this demo.

Mock demo · fictional company and data

Tickets out of date

Of 34 active tickets, 11 contradict what the team said this week.

Target: 0 by end of day

Press Restart, then Next (or →). The run stops when it needs your approval: you play the human.

#platform-team Tidewater Software (fictional) in Slack

Tuesday · 10:30

🎙️

Google Meettranscript10:30

Transcript ready: "Platform sprint sync"

28 min · 6 speakers · 10:00–10:28

📒

Logbookagent10:32

9 tickets

Heard updates on 9 tickets: 5 applied, 3 need the team lead, 1 new

only things said explicitly are applied · every update links back to the transcript

Applied (routine, stated outright)

✓Status, links, decisions and blockers5 tickets▸

PLAT-412In Progress → In Review, linked PR #882 · Dan 04:12 "the PR is up, needs a reviewer"

PLAT-405→ Done · Ana 07:40 "shipped yesterday" · checked: PR merged, deployed 16:02

PLAT-398decision comment: SQS FIFO, not Kafka · Lena 11:02

PLAT-421Blocked by PLAT-366 · Kai 15:31 "can't start the cutover until the staging DB migration is done"

PLAT-424Blocked by PLAT-366 · Ana 15:50 "same for the load tests"

Every change is in Jira history· undo is one click· nothing closed or deleted without a person

📒

Logbookagent10:32

Needs approval

3 changes to commitments

reassignments, dates and new work are never applied without a person

1Reassign PLAT-377 from Dan to AnaOwner▸

heardLena 13:20 "Ana can take the migration script" (said by Lena, not by Dan or Ana)

2Move PLAT-430 due date from Friday to next WednesdayDate▸

heardMarco 19:05 "we'll slip a few days, probably Wednesday"

3Create ticket "Rotate staging DB credentials"New▸

heardAna 18:20 "someone needs to rotate those staging creds" · no existing ticket found

You're the team leadReview one by one

📒

Logbookagent10:41

Done: PLAT-377 reassigned to Ana, PLAT-430 due next Wednesday, PLAT-441 "Rotate staging DB credentials" created for Ana (your approval is recorded on each). I've told Dan, Ana and Marco in a thread. Next I'm checking the tickets nobody mentioned.

📒

Logbookagent11:05

Bottleneck

PLAT-366 is holding up 7 tickets, and nobody mentioned it

ticket map built from blocker links, including the 2 marked today

Ticket map

PLAT-366  Migrate staging DB to Aurora   Marco · In Progress · no update in 9 days
├─ PLAT-421  Cutover rehearsal            Kai · blocked today
│  └─ PLAT-433  Production cutover plan   Lena
│     └─ PLAT-437  Decommission old RDS   Dan
├─ PLAT-424  Load tests on Aurora         Ana · blocked today
├─ PLAT-415  New backup policy            Kai
└─ PLAT-418  Update staging runbooks      Marco
   └─ PLAT-439  On-call training: Aurora  Lena

Evidence

jiralast status change 9 days ago; not mentioned in the last 3 syncs

githubbranch migrate-staging-aurora: last commit 8 days ago

sprint7 of 12 remaining sprint tickets sit downstream of it

Done so far

Asked Marco privately what's blocking PLAT-366.
Nudged the owners of PLAT-359 and PLAT-371 (no update in 6 days).
Added PLAT-366 to the top of tomorrow's standup agenda.

Marco B.engineer11:20

Ugh, yes. I've been waiting on DBA access to the staging cluster since last Tuesday and forgot to raise it. Can someone grant rds-admin on staging?

📒

Logbookagent11:24

PLAT-366 is marked Blocked by access request IT-5521, which I filed with Marco's words and linked both ways. PLAT-359 and PLAT-371 are updated from their owners' replies. All 34 active tickets now match what the team has said.

📒Daily board digest: Tuesday sent to #platform-team at 17:00 · every change links to its source

Changed today

10:325 updates from the sprint sync (status, PR link, decision, 2 blockers). 10:413 approved by the team lead (reassignment, date, new ticket). 11:24PLAT-366 blocked by IT-5521; 2 stale tickets refreshed by their owners.

Biggest bottleneck

IT-5521 (staging DB access) → PLAT-366 → 7 tickets. Unblocking it frees most of the sprint.

Watch

PLAT-430 has moved its date twice in two sprints.

Why it matters

11 → 0

tickets out of date, by lunchtime, without anyone updating Jira after the meeting

9 days

a blocker sat unnoticed, found in 30 minutes once the work was mapped

Every

change traceable to who said it, and when

This is a mock scenario. The figures are design targets, not measured results.

What it solves

A board nobody trusts. When tickets lag reality, people stop reading them and status lives in meetings and DMs.
Admin after every meeting. Engineers say the update once. Logbook writes it down, with the source.
Blockers that stay quiet. The ticket holding up half the sprint is often the one nobody mentions. The map makes it obvious.
Decisions lost in transcripts. "We chose SQS over Kafka" ends up on the ticket it belongs to, not in a recording nobody rewatches.

Key features

Reads transcripts from Google Meet, Microsoft Teams or Zoom, plus Slack threads
Updates Jira (or Linear): status, links, comments, decisions and blockers
Applies only what was said explicitly, quoting the speaker and timestamp
Reassignments, dates and new tickets go to the team lead for approval
Ticket map from blocker links, with the biggest bottleneck called out
Finds stale tickets nobody mentioned and asks their owners
Daily digest of what changed and why

Buy or build?

Try what already exists first. Each option below was checked against the vendor's own documentation in October 2026, and each is enough for some teams.

Loom + Rovo in Jira

Rovo reads a Loom meeting's transcript and suggests work item updates (status, priority, assignee, description, comments) that the meeting owner accepts or discards. Needs Jira Standard, Premium or Enterprise with Rovo, and Loom AI. Enough when your meetings are already in Loom. Docs

Note-takers: Fireflies, Spinach

Fireflies creates Jira issues from meeting action items. Spinach says it proposes tickets at the end of a call and links existing ones when they're mentioned, on Zoom, Meet, Teams and more. Enough when the gap is action items that never become tickets. Fireflies · Spinach

Troopr

Watches Jira, GitHub and Slack and DMs each person a proposed update that waits for a yes. Enough when work is discussed in threads and commits more than in meetings. Docs

Jira Automation and plan dependencies

No AI needed for the mechanical part: a Pull request merged trigger can transition the ticket. Jira Premium and Enterprise plans include a dependencies view that draws blocker links. Enough when most drift is tickets not moving after code merges. Triggers · Dependencies

When a custom build makes sense

Your own approval policy. You want to decide exactly what changes without asking, who approves the rest, and that every change carries a quote and timestamp.
Several sources in one place. Meetings on Meet or Teams plus Slack threads, feeding one tracker, with Done checked against your repos and deploys.
The bottleneck, not just the board. Blockers turned into links, then ranked by how much work each one holds up.
Data constraints. Transcripts can't go to another SaaS vendor, so the system runs in your cloud or on-prem with the model you choose.
Your tracker and workflow. Custom fields, unusual workflows, Jira Data Center or Linear.

To build it in-house, our step-by-step guide has the pipeline. To have it built for you, see custom autonomous systems.

Questions

Can AI update Jira tickets automatically from meetings?

Yes, with limits worth setting deliberately. A model can read a transcript and propose status changes, comments and blocker links, but it will also misread hedges, pick the wrong ticket or invent commitments. Logbook applies only routine changes someone stated outright, with the quote attached, and sends the rest to the team lead. Our guide to updating Jira from meeting transcripts explains the failure modes in detail.

What does Logbook change without asking?

Status moves within work in progress, links to pull requests, decision comments and "is blocked by" links, when the ticket's owner said so explicitly. Each change carries the speaker, timestamp and quote, and Jira history makes it reversible. Reassignments, dates, priority and new tickets wait for the team lead, and nothing is closed or deleted without a person.

How does it know a ticket is really done?

It doesn't take "shipped" on trust. Before moving a ticket to Done it checks for a merged pull request, and a deployment if your definition of done includes one. If the check fails, the ticket stays where it is and the owner gets a question instead.

How does Logbook find the bottleneck?

It turns blocker links into a graph and counts how many unresolved tickets each one holds up, directly or through a chain. The ticket with the largest count, especially one nobody has mentioned or touched recently, is called out with the list of work waiting on it. In the demo, one unmentioned migration ticket is holding up seven others. The guide includes the JQL and a short script to do this yourself.

Which meeting tools and trackers does it work with?

The design reads transcripts from Google Meet, Microsoft Teams or Zoom, which all expose transcripts with speakers and timestamps through their APIs, plus Slack threads. It writes to Jira, or Linear if that's your tracker. Because each Logbook is built for one team, the sources are whichever ones that team actually uses.

Is Logbook a product I can sign up for?

No. This is a mock demo with a fictional company and data, showing a system we build to order. Each build is shaped around your tracker, your meetings and your rules for what may change without asking, and can run in your own environment if transcripts can't leave it. See custom autonomous systems.

How it stays safe

Logbook updates a ticket on its own only when someone said it outright, and each update carries the quote and timestamp, so it can be checked. Jira history makes every change reversible. It never closes, deletes, reassigns or re-dates work without a person, and it checks what it can, such as a "Done" against a merged and deployed PR. The same verifiable, reversible, contained rule as the rest of our systems.

Want a Logbook for your team?

We build it around your meetings, your tracker and your rules for what may change without asking. Tell us how far your board drifts in a week.

Book an engineering consultation Custom autonomous systems

More demos

First Mate →Incident companion: investigates every alert, fixes what you approve, drafts the post-mortem. Metric: time to restore. Lookout →Alert triage: groups the noise, runs approved runbooks, retires noisy rules. Metric: alerts that reach a human. Quartermaster →Joiner and leaver access across every system, with approvals. Metric: access gaps.