Where did that decision actually go?
The meeting ends. Someone typed notes into a personal document, or nobody typed anything at all. Three weeks later, a new team member asks why a feature was scoped a certain way, and the honest answer is "someone remembers, ask around." The decision existed — briefly, in one person's notes — and then it stopped existing anywhere anyone else could find it.
This is the real cost of meeting notes that don't get published anywhere durable: not that the meeting was wasted, but that everything decided in it has to be re-decided the next time someone doesn't remember it happened.
Symptoms and the real cost
| Symptom | Cost |
|---|---|
| Notes live in someone's personal doc or inbox | Nobody else can search for the decision later |
| The PM finds out about a decision after the fact | Plans built on stale information |
| An AI assistant summarizes from memory, not the record | Answers that sound confident and aren't grounded in anything |
| "Why did we decide this?" has no citable answer | The same debate happens again next quarter |
A framework for publishing meeting notes properly
1. Capture decisions during the meeting, not after. Notes written from memory an hour later are already a reconstruction. Write down what was decided, who owns the follow-up, and why — while it's still happening.
2. Publish to the wiki, not to a chat thread. A decision posted in Slack scrolls away. The same decision on a wiki page stays findable by search six months later.
3. Turn action items into tasks immediately. An action item that lives only as a bullet point in the notes is a task nobody is tracking. Link it to a real task the moment the meeting ends, not at the next standup.
4. Link the wiki page back to the project and the tasks it affects. A meeting note floating with no connection to the work it discusses is hard to find later, even if it technically exists somewhere.
5. Keep a five-minute weekly review of what got published. Not every meeting needs a wiki page — only the ones where something was actually decided. The review catches meetings that should have been documented and weren't.
Common mistakes
Notes without a decision. A page that summarizes what was discussed but doesn't say what was decided is a transcript, not a record — it doesn't answer "so what do we do now?"
No owner on the action item. "We'll look into this" without a name attached means nobody actually will.
Publishing after the context is gone. A meeting note written days later, from memory, tends to smooth over the actual disagreement that led to the decision — which is often the most useful part to have on record.
How WKFGo supports this
publish_meeting_wiki(MCP) — takes the meeting's agenda, decisions, and action items and publishes them as a structured wiki page linked to the relevant project, instead of leaving that step to whoever remembers to do it.get_meeting— pulls a meeting's record programmatically, useful for an AI assistant summarizing status without guessing.- Action items become tasks — linked back to the wiki page that explains why they exist, so a task doesn't lose its "why" the moment the meeting ends.
- Task-linked wiki — the decision behind a piece of work lives next to the work itself, not in a separate archive nobody checks.
FAQ
Does every meeting need published notes?
No — only the ones where something was decided or an action item was created. A status sync that changed nothing doesn't need a wiki page.
Who's responsible for publishing?
Whoever ran the meeting, ideally in the meeting itself or within the hour. Waiting until end of day is when details start getting lost.
What about meetings that don't reach a decision?
Still worth a short note if the discussion narrows down options for a future decision — but keep it brief. The goal is a record people will actually read, not a full transcript.
Does AI replace the person taking notes?
It can draft a first pass from what's discussed, but someone who was in the room should confirm the decision was captured accurately before it's published as the record.
Summary
A meeting's real output isn't the conversation — it's the decisions and action items that survive it. Publishing those to a searchable, task-linked wiki page is what makes a meeting worth having instead of a conversation that has to happen again.