<!-- canonical: https://klappy.dev/page/writings/decisions-get-lost -->
<!-- content: klappy/klappy.dev@b750d7d3aa85a3e5ed6d1e2b24d63471f3df4bac -->

# Decisions Get Lost in Meetings, Chat, and Handoffs — They Don't Have To

> The most important decisions happen in meetings and chat threads. That's also where they go to die. Someone says "let's go with approach B" and everyone nods. A week later, nobody can agree on what approach B was, or why it won over approach A, or who's responsible for the next step. The decision existed for thirty seconds as spoken words, and now it's gone. Three capabilities fix this without changing how your team communicates: durable journal entries that capture decisions in a sentence as they happen, a team chat assistant that follows conversations and offers to record what matters, and a meeting listener that turns verbal decisions into structured records your whole team can find.

---

## Summary — Capture Knowledge Where It Happens, Not Where It's Convenient

Most knowledge management systems ask you to leave the place where knowledge gets created and go somewhere else to document it. Write it in the wiki. Update the ticket. Fill out the template. The result is predictable: nobody does it consistently, the documentation drifts from reality, and the most important context lives in one person's head.

AI memory features are getting better — Claude and ChatGPT both remember your past conversations and carry context forward. But they capture *everything* with equal weight. A casual mention and a firm decision look the same in memory. A brainstorm that went nowhere and a constraint that must be honored are stored identically. When you're trying to find "what did we actually decide about authentication?" the AI gives you everything you ever said about authentication, with no way to filter signal from noise. And whatever it does capture is locked inside that provider's ecosystem — if your meeting decisions live in ChatGPT's memory and your engineer works in Claude Code, the knowledge doesn't travel.

The three capabilities described here solve both problems. Instead of asking people to go somewhere to document, they bring structured capture to where people already are — in conversation. Instead of flat memory that treats every utterance the same, they classify what kind of thing was said: observation, learning, decision, constraint, handoff. And because everything enters a knowledge base in your repo, any AI tool can read it — not just the one that captured it. A sentence during a chat thread. A verbal confirmation in a meeting. A quick note before a handoff. Each one becomes a *typed*, *portable* record that the whole team's tooling can find.

---

## The Journal — A Sentence in Conversation, a Durable Record in the Knowledge Base

The simplest and most powerful of the three. Any team member, in any AI-enabled tool, can encode a durable record by saying what happened.

"We discovered the auth timeout was caused by a race condition in the token refresh — encode that as a learning."

"The client confirmed Q3 launch is firm but wants a demo by March 15 — encode the decision and the constraint."

"The CSV import breaks on files over 10MB because of the streaming buffer — encode this observation."

"Sarah is picking up the payment integration next week, here's where I left off — encode this handoff."

In each case, oddkit structures the entry and persists it to the knowledge base. The next person or session that touches the relevant area finds it automatically. Nothing evaporates between sessions.

The journal captures four things that matter most for project continuity: **observations** (what someone noticed), **learnings** (what someone figured out), **decisions** (what was chosen and why), and **handoffs** (what someone else needs to know to pick up the thread).

This is the smallest, most frequent unit of knowledge capture. It requires no ceremony — just a sentence in conversation. It works on every surface: Claude Code, Claude Chat, voice agents, team chat. The knowledge base only grows if knowledge actually enters it. Journal entries are how most knowledge enters.

For a deeper treatment of the journal practice, see [The Project Journal](https://klappy.dev/page/writings/the-project-journal).

---

## The Team Chat Assistant — A Sharp Colleague Who Never Forgets

Not a bot you invoke with `@oddkit`. A lurking participant that follows conversations the way a sharp colleague would.

It has already read every prior decision, every constraint, every definition of done in the knowledge base. When the architect says "We're going with JWT tokens for auth," the assistant chimes in: "Looks like you just made an architectural decision. Want me to draft a decision record with the rationale from this thread?" When a developer asks "Does anyone know why we chose Postgres over Mongo?" the assistant responds before a human needs to — because the answer is in the knowledge base. When someone proposes an approach that contradicts an existing constraint, the assistant flags it gently.

The team just talks. The assistant does the structured knowledge work. Decisions stop getting lost in threads. Constraints stop getting violated because someone didn't check. The knowledge base grows from natural conversation, not from documentation sprints.

The assistant also captures journal entries from chat — when someone shares an observation, learning, or decision in a thread, the assistant offers to encode it. The channel becomes a source of durable knowledge, not just ephemeral discussion.

---

## The Meeting Listener — Where Decisions Happen and Knowledge Dies

Meetings are the surface where the most important decisions happen and the most knowledge gets lost.

Meeting audio streams to an oddkit-powered assistant — not a transcription service, a participant. The same assistant that lurks in Slack, with the same knowledge base, the same context. As the meeting unfolds, the assistant listens with awareness of every prior decision and active constraint.

After the meeting, it presents its draft: "Three decisions were made. Two constraints were articulated. One observation contradicts assumption A from planning spec X. Four action items were assigned." Each item is already structured as a journal entry. The team reviews. Approved items enter the knowledge base. Meetings stop being where knowledge goes to die.

Capture the speech, structure it after. People think and decide in conversation. The documentation should follow the speech, not precede it. Asking someone to "write it up" after a meeting is asking them to re-create context that was alive five minutes ago and is already fading. The listener captures it while it's alive.

---

## All Three Share One Infrastructure

Every capability described here connects to the same knowledge base, the same rules, the same tools. The only difference is *where* the conversation happens: a terminal, a chat window, a browser, a Slack channel, a conference room.

The journal is `encode` — structure the knowledge. The write path persists it. The search surfaces it later. The surfaces are many. The infrastructure is one.

This means something practical: a decision made in a meeting on Tuesday is visible to the engineer's Claude Code session on Wednesday. An observation encoded from a chat thread on Monday is available to the PM's planning session on Friday. The knowledge doesn't live in the tool where it was created. It lives in the shared knowledge base that every tool reads.

---

## The Deeper Pattern

Knowledge gets created in conversation. It gets lost at every boundary — between meetings, between tools, between sessions, between people. The [most expensive problem](https://klappy.dev/page/writings/the-most-expensive-problem) is always the same: how do you transfer what one person knows into a form that someone else can act on?

The answer, it turns out, is not better documentation practices. It's lower friction. When capturing a decision costs a sentence instead of a form, people capture decisions. When an AI assistant offers to record what just happened instead of waiting to be asked, the team's knowledge base grows as a natural byproduct of working — not as a separate chore.

These three capabilities don't replace meetings, chat, or handoffs. They make the knowledge created in those moments durable. The conversations stay human. The knowledge stops being ephemeral.

*For the team infrastructure that makes this possible, see [Every Handoff Drops Context](https://klappy.dev/page/writings/every-handoff-drops-context). For the individual starting point, see [The Journey from AI Tasks to AI-Augmented Workflows](https://klappy.dev/page/writings/the-journey-from-ai-tasks-to-ai-augmented-workflows).*
