Organizational Memory: A Two-Agent Workflow That Keeps Decisions Retrievable

Engineering managers in a 2024 survey reported losing roughly four hours per week to meetings that relitigate decisions already made. Ten percent of a forty-hour week, spent re-arguing settled ground because the original reasoning never made it into a form anyone could find.

Every org makes hundreds of decisions a quarter. Strategy pivots, vendor selections, hiring freezes, architecture choices, budget calls. They happen in a meeting. They get captured in notes. They vanish into a Notion graveyard nobody searches.

Three months later someone asks why you picked Vendor X over Vendor Y. The answer lives in a Tuesday standup transcript nobody tagged. The person who made the call left the company. The rationale is gone.

IDC put a number on it: Fortune 500 companies lose roughly $31.5 billion a year by failing to share knowledge.^[9] That figure covers re-work, re-explanation, and decisions made blind — without knowing what was already settled and why. For a 200-person engineering org, the math is less dramatic but still real: when institutional knowledge leaves with each departing engineer, it costs up to 213% of that person's annual salary to rebuild at equivalent proficiency.^[10]

This is the org-memory failure mode. Teams re-litigate settled questions. They reverse decisions without knowing the originals existed. They build on assumptions that were explicitly rejected six months earlier.

The fix is not another documentation initiative — your team already has documentation fatigue. The fix is an agent workflow that processes transcripts on a cadence, extracts decisions into a structured schema, and attaches review triggers that tell a separate scanning agent when to surface them again. Capture is one job. Re-surfacing is a different job. Both have to ship.

Most knowledge management systems treat decisions as a documentation problem. Write it down. Put it somewhere. Hope someone finds it. Documentation alone has three failure modes that compound:

Capture failure. Nobody writes the decision down. The meeting ends, the next thing starts. Action items get tracked because somebody assigns them. The reasoning behind the action — the part that ages well — does not.

Retrieval failure. The decision was documented but lives in a format that resists search. Buried in paragraph seven of February twelfth's notes, tagged only with the meeting series name. Nobody thinks to look there when the question resurfaces.

Staleness failure. The decision was correct when made. Conditions changed. The vendor you rejected raised a round and dropped pricing forty percent. The constraint that drove the architecture call got removed. No mechanism flagged it for review.

A structured record solves all three. Automated extraction handles capture. Indexed schema handles retrieval. A review-trigger field — the piece nearly every system misses — handles staleness.

Knowledge workers already spend an average of 1.8–2.5 hours per day searching for information they need to do their jobs.^[11] Decision records don't eliminate that search tax — but they shrink the worst version of it: the search for institutional reasoning that left the building with a former colleague.

The schema borrows from Architectural Decision Records (ADRs) but extends the concept past software architecture into general organizational decisions.^[1] ADRs have been battle-tested at companies from startups to enterprises — AWS documents the practice across teams of varying sizes.^[2] The load-bearing insight from ADR practice: recording alternatives considered and rationale matters more than recording the decision itself.^[3] The decision is the easy part. The reasoning is what disappears.

Recent LLM research on automated ADR generation confirms the same field hierarchy. Structured context strategies that capture rationale and constraints outperform those that capture only the decision outcome — the model produces more complete, accurate records when it has access to the deliberation, not just the conclusion.^[12]

The workflow runs weekly, processing every transcript generated since the last run. Two agents, two distinct responsibilities:

Agent 1: Decision Extractor. Takes raw transcript text. Identifies segments where decisions actually happened. Outputs structured records that conform to the schema above.^[6] During the first eight weeks, those records route through a human review step before reaching active status.

Agent 2: Review Scanner. Runs daily. Reads all existing records. Evaluates each review trigger against current conditions. Flags any record where the world has moved.

Keep them separate. The extractor needs strong language understanding and reliable structured output. The scanner needs to query external systems and reason about whether a condition fires. Different skills, different prompts, different evals. Merge them into one agent and both jobs degrade.

The human-in-the-loop step in the diagram is not optional in early weeks. It is what builds the ground truth your eval depends on.

Extraction is the hard part. Transcripts are messy. Decisions are usually implicit. Someone says "okay, let's go with option B then" — that is a decision. There is no formal announcement. No gavel. No declaration.

The prompt has to handle several categories of decision language:

• Explicit decisions: "We've decided to…" or "The decision is…"
• Implicit consensus: "Sounds like we're aligned on…" or "Let's move forward with…"
• Authority decisions: "I'm calling this — we'll go with…" or "As the owner here, I want to…"
• Negative decisions: "We're not doing X" or "Let's table that for now"

The prompt also has to distinguish decisions from opinions, preferences, and speculation. "I think we should use Postgres" is not a decision. "We're going with Postgres" is. The whole system fails if the extractor cannot tell those two apart.

One practical detail: transcripts from different sources have different quality profiles. Otter.ai and Fireflies produce speaker-attributed transcripts that let the agent assign the decider field reliably. Google Meet's built-in transcription is accurate but attribution is less consistent. The hard requirement is speaker attribution — without knowing who said what, the decider field becomes unreliable, and a record without a decider is half a record.

Strong review triggers share three properties. They are specific — they reference a measurable quantity or observable event. They are falsifiable — you can check whether the condition is true or false without subjective judgment. They are externally verifiable — the scanner can query monitoring dashboards, billing systems, surveys, or competitive intel feeds to evaluate them.

The trigger is what turns a record from a historical artifact into an active governance signal. Without it, you are building a better filing cabinet. With it, you are building an early warning system that pings you when your own assumptions stop holding.

When writing triggers at extraction time, the agent often produces vague ones by default. A post-processing step that evaluates each trigger against three questions — "Is this measurable? Can a machine check it? What system holds the data?" — catches the failures before they enter the registry.

Generic prompts against meeting transcripts run around 70% field-level accuracy on the first pass. Few-shot prompting with real examples from your org pushes that number to the 85–90% range — but the gain comes from the examples matching your culture, not from prompt cleverness.^[7] The model needs to see how decisions get expressed in your meeting cadences, with your jargon, by your people.

The research on this is consistent: few-shot improvements are not uniform across fields. The decision field is easiest — the model reliably identifies commitment language. The review_trigger field is hardest — it requires inferring what assumption underlies the decision, then specifying the condition that would invalidate it. Plan for the trigger field to need the most human correction in early weeks.

Field-level accuracy from LLM structured output benchmarks (2025) shows a similar pattern: high-frequency, well-structured fields (dates, names) hit 90%+ accuracy quickly; inferential fields (rationale, trigger) stabilize more slowly and benefit most from domain-specific examples.^[12]

This system earns its keep around 8–10 people. Below that, institutional memory lives in a few heads and informal communication is enough — you do not need a registry when the whole team fits in one Slack DM. Above 8–10, the combinatorial explosion of who-knows-what makes systematic capture worth building. For distributed orgs above 50, it is close to mandatory.

There are three situations where the system actively backfires:

High-trust, low-documentation cultures. Some orgs run on implicit authority and fast iteration. Introducing a formal registry slows the decision loop in ways that cost more than the re-litigation it prevents. Fit matters. A quarterly planning cadence benefits more than a sprint team shipping every week.

Orgs with weak transcript hygiene. The extractor is only as good as its input. If transcripts are incomplete, speaker-unattributed, or generated from meetings where key discussion happened off-channel, extraction quality degrades fast. Fix the transcript problem first.

When the registry becomes political. Decision records cited selectively to shut down legitimate reconsideration turn the system from memory into a veto mechanism. The healthy norm is: the review-trigger path is the legitimate route to revisiting a call. If that path gets blocked or ignored, the registry calcifies into bureaucratic lock-in — worse than the filing cabinet it replaced.

Two quarters in, the decision registry becomes a real asset. New hires search it during onboarding instead of asking "why do we do it this way?" in every meeting. Planning sessions reference specific records instead of leaning on collective memory. When a trigger fires, the team revisits the call with full context — original rationale, alternatives, and the specific condition that flipped.

The second-order shift is cultural. Once people know decisions are being captured and indexed, they articulate reasoning more clearly in the meeting itself. Once they know review triggers exist, they think harder about what conditions would invalidate the choice. The system makes the org more deliberate, not just better at remembering.^[8]

The registry does not prevent bad decisions. It prevents the specific failure mode where good decisions get reversed for bad reasons — or bad decisions never get revisited because no one remembers why they were made.