by MeetingAgenda (LX AI)
MeetingAgenda — An agenda people actually follow Use it as decision-support: demo mode works without a live key; live runs require configuration. No fabricated metrics, and no claims for SSO/CSV/Slack unless that surface is actually shipped.
Decision-support only — confirm before you publish or act.
I built MeetingAgenda to turn a vague meeting intent and a list of participants into a concrete plan that drives decisions. The process starts when you type a short purpose statement and add the names of people who will attend. The system then runs a language model in demo mode or with your configured API key to generate a draft agenda. Each draft item includes a start time, an end time, an owner, and a clear decision that the owner must produce by the end of the slot. The model also suggests pre‑reads that help participants come prepared. After the draft appears you can adjust any field, reorder items, or delete ones that do not fit. The final output is a simple list you can copy into a calendar invite, a shared doc, or a meeting note.
To see how the model handles risk, I consulted the OWASP LLM Top 10 guide at https://owasp.org/www-project-top-10-for-large-language-model-applications and the NIST AI Risk Management Framework at https://www.nist.gov/itl/ai-risk-management-framework. Those documents helped me shape the prompts so the model avoids hallucinating decisions and stays focused on concrete outcomes.
Write a single sentence that states why the meeting exists. Avoid vague phrases like “discuss project” and instead say “decide on the vendor for the new analytics tool”. A clear purpose gives the model a firm anchor for generating relevant items.
Enter the name and role of each person who will be in the meeting. If someone is only needed for a specific topic, note that in a comment; the model can use that to assign ownership later. Keep the list to the people who truly need to be present; extra names increase noise without adding value.
If you have a hard limit on total meeting length, type it in the constraints field. You can also note any items that must appear at the start or end, such as a status update or a next‑steps recap. The model respects these bounds when it allocates time boxes.
When you press “Generate”, the system sends your purpose, attendee list, and constraints to the language model. The model returns a JSON array where each object contains:
The model tries to balance coverage of the purpose with equal time distribution, but it will shift length to accommodate complex topics that need more discussion.
| Start | End | Title | Owner | Decision | Pre‑reads |
|---|---|---|---|---|---|
| 0 | 10 | Review project goals | Alex (Product Lead) | Confirm the three success metrics for Q4 | Goals doc |
| 10 | 25 | Vendor shortlist evaluation | Sam (Procurement) | Select two vendors for deep dive | Vendor sheet |
| 25 | 35 | Deep dive presentation Vendor A | Lee (Tech Lead) | Identify any deal‑breaker technical gaps | |
| 35 | 45 | Deep dive presentation Vendor B | Lee (Tech Lead) | Identify any deal‑breaker technical gaps | |
| 45 | 50 | Decision and next steps | Alex (Product Lead) | Choose vendor and assign contract lead | Contract template |
You can copy the table into a spreadsheet or keep it as plain text. The times are relative; when you paste into a calendar tool you add the meeting start time to each offset.
Read each row and verify that the allocated minutes feel realistic for the topic. If a item seems too short, drag the end time later and shorten a neighboring block. Keep the total length within the constraint you set earlier.
Make sure the person named as owner is actually attending and has the authority to make the decision. If not, replace the name with a suitable attendee or mark the item as “needs owner”.
Each decision should be a concrete action that can be verified after the meeting. Phrases like “agree on approach” are too vague; rewrite them to something like “choose the API version for the integration” or “approve the budget of $12,000”.
If the model suggested a link that is not accessible, replace it with a working URL or delete the line. If you know a useful document that the model missed, paste the URL in the pre_reads field.
Read the whole agenda from start to finish as if you were sitting in the meeting. Imagine each owner speaking, making the decision, and moving on. If anything feels off, adjust now rather than during the live session.
Select the rows, paste into a spreadsheet, then use the spreadsheet’s mail merge feature to create calendar invites. Each invite gets the title, start and end times, and the owner’s name in the description.
If you use a shared notes tool like Notion or a simple markdown file, paste the plain‑text list. Add a checkbox before each item so attendees can tick off completed decisions during the call.
Collect all unique URLs from the pre_reads column, deduplicate them, and send a short email with the list attached. Ask reviewers to skim the materials at least 30 minutes before the meeting starts.
Save the final agenda as a PDF in your meeting folder. Name it with the date and a short keyword, for example “2026-09-24-vendor‑selection.pdf”. This gives you a traceable record of what was planned versus what actually happened.
MeetingAgenda does not guarantee that every meeting will produce a decision. The output is a suggestion; you must review it and confirm that the proposed decisions are realistic and actionable.
It is not a substitute for a skilled facilitator. If the group struggles with conflict or needs extensive brainstorming, you still need a person to guide the conversation.
It does not provide SSO, Slack notifications, or bulk CSV export unless those features have been shipped in this specific build. Do not assume they exist based on marketing language from other products.
It is not a fully autonomous agent that runs meetings without human oversight. The model only drafts; you remain responsible for the final call.
It does not promise 100% accuracy in time estimates. Some topics may run longer or shorter than the model predicts, and you should build in buffer time.
I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.
| Signal | What to record | Stop-ship? |
|---|---|---|
| Unexpected write or send | Tool name, args, identity | Yes until gated |
| Missing confirmation on destructive action | Call path and bypass | Yes |
| Untrusted text treated as instruction | Source surface and resulting action | Yes for agent reach |
| Scanner clean, judgment open | Deferred items + owner | Only if core path safe |
meeting-agenda helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.
When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.
If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.
An agenda people actually follow
Operators and builders who need a fast first draft or checklist from MeetingAgenda.
Yes in explicit Demo mode. Live AI requires a configured key.
No. Outputs are decision-support; you still review before publishing or acting.
Only if those features are implemented in this product build — do not assume them from marketing copy.
Runs may be stored locally under the product's .data/ boundary; treat demos as ephemeral.