The bug in most meeting agendas is an item with no owner and no decision
I used to write agendas as a list of topics. 'Q3 roadmap', 'hiring update', 'infra costs'. Every one of those lines has the same defect: it names a subject but not what happens to it. An hour later the meeting ends, the
I used to write agendas as a list of topics. 'Q3 roadmap', 'hiring update', 'infra costs'. Every one of those lines has the same defect: it names a subject but not what happens to it. An hour later the meeting ends, the topic was talked about, and nobody can say what changed.
That's not a facilitation problem. It's a data-shape problem. A well-formed agenda item has three fields - a time box, an owner, and the decision the item must produce. Missing any one of them and the item can drift indefinitely. I built MeetingAgenda around that observation.
The three fields
'Time-boxed items' is the first constraint. A topic without a duration expands to fill whatever is left. Assigning a number of minutes per item is a small thing, but it turns an open-ended discussion into a bounded one and makes the total length visible before anyone accepts the invite.
'Owner per item' is the second. If a line has no single name attached, the room assumes someone else is driving it. One owner doesn't mean one person does all the talking; it means one person is accountable for moving that item to its outcome.
'Decision per item' is the one that changes the meeting most. Most status meetings don't need a decision for every line, and I'm not claiming they do. But when I forced myself to write what each item should produce - a yes/no, a chosen option, an assigned next step - about half my topics turned out not to be meeting topics at all. They were FYI updates that belonged in a doc. The 'Decision per item' feature is really a filter: if you can't name the decision, you probably don't need the slot.
Pre-reads as a dependency, not a nicety
The 'Pre-reads suggested' feature came from watching meetings burn their first ten minutes with people reading a doc live. If an item depends on a dashboard or a spec, that's a dependency that should be resolved before the call, not during it. Suggesting pre-reads is cheap and it moves the reading out of the expensive room.
The input to all of this is deliberately small: a fuzzy meeting purpose and a list of attendees. You don't fill out a template with twenty fields. You say what the meeting is roughly for and who's coming, and you get a tight agenda with time boxes, owners, and decisions. I wanted the friction low enough that people would actually use it before a call rather than after.
Where a rigid agenda is the wrong tool
I'll be honest about the mismatch. A structured agenda with a decision on every line is bad for some meetings. A creative brainstorm, a one-on-one, a sensitive conversation - forcing those into time boxes and decisions makes them worse, not better. The tool generates a draft for a meeting that has a purpose and an outcome. It doesn't know your meeting is a venting session, and I wouldn't want it to guess.
The other limit is that a generated agenda is a hypothesis. I've taken outputs from the generator and rewritten half the time boxes because I know my team reads slower than the default assumes. The owners are suggestions. The decisions are a prompt to think, not a verdict. It's decision-support for planning a meeting, not a facilitator that runs it.
What it does and doesn't do
MeetingAgenda turns a fuzzy purpose and an attendee list into a draft agenda: time-boxed items, an owner per item, a decision per item, and suggested pre-reads. That's the declared scope. It doesn't schedule the meeting, send invites, track whether decisions were kept, or run the call. If you want a tool that manages the whole meeting lifecycle, this isn't it. If you want to stop writing 'discuss X' and start writing 'decide X, owned by Y, in ten minutes', it does that one thing.
FAQ
What do I need to provide?
A fuzzy meeting purpose and a list of attendees. You get back a tight agenda with time boxes, owners, and the decision each item should produce.
Does every meeting need a decision per item?
No. Some meetings are brainstorms or one-on-ones where that structure hurts. The decision field is useful for meetings meant to produce an outcome.
Does it schedule or send the agenda?
No. It generates a draft agenda. Scheduling, invites, and follow-up tracking are outside what it does.
Should I use the output unchanged?
Treat it as a draft. I rewrite time boxes and owners to fit my team before the call.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.