The last 90 days: why recent AI chat history is your team's highest-value undocumented asset

There's a counterintuitive property of decision documentation that most teams discover at the worst possible moment: the decisions that are hardest to reconstruct are not the ones from three years ago. They're the ones from three months ago.

Three-year-old decisions are usually findable. They left artifacts — code, configuration, architecture diagrams, product specs. Someone wrote something down because the decision felt significant enough to document. The documentation may be incomplete or wrong in retrospect, but there's a record of some kind. The constraint that drove the choice, even if imperfectly captured, is there.

Three-month-old decisions are a different problem. They don't feel significant yet — they're too recent to seem like history. They weren't written down because everyone who made them is still on the team, still remembers (they think) what was decided, and plans to document them eventually when there's time. The AI chat sessions where the deliberation happened are still in everyone's sidebar, technically accessible if anyone bothered to search. Nobody is worried about losing them because they haven't realized they're already losing them.

Then the sprint planning meeting happens. Two engineers have different assumptions about a technical constraint that was evaluated six weeks ago. Neither is wrong — they each remember part of the deliberation, the part that was most relevant to their own work. The complete picture is distributed across four AI chat sessions that were never consolidated into a single record. The team spends forty minutes reconstructing a decision that took twenty minutes to make.

That's the team knowledge gap. And it lives in the 90-day window.

Why recent context degrades faster than old context

Decision context doesn't fade at a constant rate. The degradation curve is steepest in the first 90 days after a decision is made, then levels off. Understanding why reveals something important about when documentation matters most.

When a decision is made, three kinds of context exist simultaneously. First, there's the explicit reasoning — the stated constraint, the alternatives evaluated, the conclusion reached. This is what a decision record captures, and it's what the WhyChose extractor identifies in AI chat sessions. Second, there's implicit context — background knowledge that was so obvious at the time that nobody stated it, but which shaped the framing of the question. Third, there's interpersonal context — who was in the room, what their priorities were, which constraints came from which stakeholder.

Explicit reasoning is the most durable. If someone wrote it down — even in a Slack message, even in a code comment — it survives indefinitely. The problem is that most deliberation never gets written down explicitly. The AI chat session captures it, but the session is private, and no one pulls it out.

Implicit context degrades fastest. It lives in the team's shared mental model of the codebase, the product, and the users. That model shifts continuously as the team learns more, ships features, and responds to user behavior. A constraint that was obviously true in March ("we can't add a second database until we've resolved the connection pool issues") becomes invisible by June when the pool issues are fixed — not because anyone forgot the constraint, but because the background condition that made it salient is no longer present. A decision record that captured the constraint before the condition changed remains interpretable. A memory of the decision does not.

Interpersonal context has an intermediate degradation rate. It survives well while the same team members are working closely together, then drops sharply when someone's role changes, they go on leave, or they join a different team. The 90-day window is the period when interpersonal context is fully available — everyone remembers who said what, which team had which priority. After 90 days, that shared context starts fracturing into individual recollections that diverge without anyone noticing.

This is the core argument for the 90-day window: it's the last period during which all three types of context are recoverable. The explicit reasoning is still in AI chat sessions that haven't been buried by months of subsequent conversations. The implicit context is still legible against the current state of the codebase and product. The interpersonal context is still intact. Run the extraction pass now, and you can produce a complete record. Wait another 90 days, and you'll have a partial one.

The team knowledge gap in practice

The team knowledge gap isn't about not knowing what was decided. Most teams know the outcome — the decision is visible in the code, the product, the process. The gap is in the reasoning: why was this the choice, what was the constraint that made alternatives infeasible, what conditions would make it worth revisiting?

The gap is also distributed unevenly. Different team members were present for different parts of the deliberation. The engineer who implemented the decision participated in the technical evaluation. The PM who scoped the feature participated in the user research discussion. The EM who approved the approach participated in the cross-team negotiation about dependencies. In an AI-assisted team, each person ran part of the deliberation through their own chat interface, independently. The engineering decision, the product decision, and the planning decision were three separate conversations that produced a single outcome — and no single person has the complete picture.

When the decision is questioned three months later ("why did we build it this way?"), each team member answers from their piece of the deliberation. The engineer says the constraint was technical. The PM says the constraint was user research. The EM says the constraint was a cross-team dependency. All three are correct. None of them is the complete answer. The team has to reconstruct a whole that no one person holds.

This is precisely the dynamic that the new-CTO onboarding problem describes at an organizational scale — but it doesn't require a leadership transition to trigger it. It happens in ordinary sprint planning, in ordinary code review, in ordinary design discussions, whenever a decision made six weeks ago becomes relevant to a decision being made today. The team knowledge gap is not a crisis event. It's a tax on every subsequent decision that touches the undocumented one.

What the 90-day window contains

The decisions in a team's 90-day AI chat window are distinctive. They differ from both older decisions (which produced durable artifacts) and from current work-in-progress (which hasn't reached a conclusion yet). Understanding what's in the window helps identify the extraction pass's highest-value targets.

Scope decisions made under time pressure

Sprint planning and roadmap discussions produce more undocumented decisions per hour than almost any other team activity. Features get cut, requirements get narrowed, timelines get adjusted. The reasoning for each cut is specific and contextual — this feature was deferred because of a dependency that's being resolved next quarter; this requirement was narrowed because the user research showed the full scope was solving a problem the ICP didn't have.

Scope decisions feel administrative rather than architectural. They don't generate ADRs. They often don't generate Jira tickets for the deferred work, because the team doesn't want to clutter the backlog with things that aren't in the near-term plan. They live in the PM's ChatGPT session where the roadmap reasoning was worked out, in the EM's Claude session where the sprint capacity was modeled, and in the Slack thread that referenced both without capturing either.

Three months later, someone asks why a feature was cut from Q1. "I think it was a capacity call" is the best available answer. The actual reasoning — that the feature was deferred specifically because the third-party API it depended on was in beta, and the plan was to revisit in Q2 when the API stabilized — is in a chat session that nobody is searching because nobody remembers that the API dependency was the constraint.

Technical approach decisions made during implementation

Engineers make implementation decisions continuously, most of them in AI chat sessions. The decision to use an event-driven pattern rather than polling. The decision to add an abstraction layer rather than calling the API directly. The decision to handle a particular edge case with a fallback rather than a proper fix.

Implementation decisions are often accompanied by explicit reasoning in the AI chat because the engineer is literally asking the AI to help evaluate options. "Should I use polling or websockets here given the constraints X, Y, Z?" produces a session that contains the alternatives, the constraints, and the conclusion. This is exactly what the extractor identifies as a decision record.

The problem is that implementation decisions are treated as implementation details — below the level of documentation. They don't go in the ADR. They go in the code, where the reasoning is expressed as structure rather than as words. When a later engineer reads the code and asks "why is this implemented this way?", the answer is in a chat session from six weeks ago that the original engineer forgot to copy into a comment or a commit message.

The documentation gap between implementation detail and architectural decision is well-understood in teams that practice ADR writing. What's less understood is that AI-assisted development is filling that gap with chat sessions — and those sessions contain better decision reasoning than most ADRs, because the deliberation is happening in real time against the actual constraints, not being documented after the fact when the reasoning has already simplified in memory.

Constraint decisions made when requirements changed

External constraints are the category where AI chat history most commonly contains something that no other source has. A stakeholder changed a requirement. A third-party service added a rate limit. A regulatory consideration surfaced that ruled out an approach that was otherwise optimal. The team adapted — the engineer discussed the constraint with Claude, modeled the options, chose an approach.

The constraint decision is not in the code (which reflects the adapted approach, not the constraint that required it). It's not in the ticket (which may not even mention the external change). It's in the AI chat session where the adaptation was worked out.

Constraint decisions are particularly valuable to document because they age poorly. The constraint itself may change — the rate limit may be lifted, the regulatory requirement may clarify, the stakeholder may revise the requirement. When the constraint changes, the team needs to revisit the decision. But if the decision record doesn't exist, the team doesn't know which implementation choices were driven by the constraint and which were made for other reasons. The constraint change may require a deeper rethink than it actually does, because the team can't tell which parts of the implementation were necessary responses to the constraint and which were independent choices.

Deferral decisions with implicit conditions

The most valuable and most commonly lost decision type in the 90-day window is the deferral with an implicit condition. "We're not building this now" is a decision. "We're not building this now because the user research doesn't yet support the investment, and we'll revisit when we have 50 users in the segment" is a decision record. The latter is in an AI chat session. The former is what survives in everyone's memory.

The deferral with an implicit condition is the decision that benefits most from the 90-day extraction pass because the condition is still legible. Three months after the deferral, the team remembers that there was a condition — "something about user research" or "something about the API being ready." Six months after the deferral, the condition has faded to "I think we were waiting for something." A year after the deferral, it's "I don't know why we didn't build this; it seems important now." The condition is gone, and the deferral looks like inertia rather than deliberate choice.

If ADRs go stale after 60 days, deferral decisions go stale even faster because they were never written down to begin with. The 90-day extraction pass is the only mechanism that captures them before the condition becomes irrecoverable.

The divergence problem: when team members remember different decisions

There's a specific failure mode that the 90-day window produces that's worth describing in detail because it's so common and so difficult to diagnose. Two engineers or a PM and an engineer will disagree about what a decision was, and both will be certain they're right. The disagreement isn't about the outcome — both agree on what was built. It's about the reasoning and the constraints.

This happens because AI-assisted deliberation is individual. Each team member runs their part of the reasoning through their own chat interface, privately. There's no whiteboard session where everyone's understanding of the constraint is visible simultaneously. There's no architecture meeting transcript. There's a Slack message saying "going with option B" and four private chat sessions where option B was evaluated from different angles.

The engineer evaluated option B against technical feasibility and performance. The PM evaluated it against user impact and timeline. The EM evaluated it against team capacity and dependency risk. All three concluded that option B was right. But they each have a different reason for why — a reason that traces back to the part of the deliberation they personally ran.

When option B needs to be revisited — because a constraint changed, because a new team member needs to understand why, because a similar decision is coming up and the team wants to reason from precedent — the divergent recollections surface. Not as conflict, usually, but as confusion. "I thought we chose B because of the performance profile." "I thought it was because the user research showed they didn't care about the alternative feature." Both are true. Neither is the complete picture.

The engineering manager's role in documenting decisions is partly about resolving exactly this divergence — pulling the distributed deliberation from individual AI chat sessions into a shared record that gives the complete picture. The 90-day extraction pass is the mechanism for doing that before the divergence becomes entrenched. Once each team member has rehearsed their version of the reasoning for six months, the divergence is harder to correct because it's now embedded in how they explain subsequent decisions to new team members.

Why teams focus on the wrong end of the timeline

Given that recent decisions are higher-value extraction targets than old ones, why do teams consistently direct documentation effort at the past rather than the present?

The most common reason is that the past feels more clearly documented as a problem. "We have two years of undocumented decisions" is a legible deficit — there's a large gap, it's easy to point to, it feels like something that needs to be fixed. "We have ninety days of decisions where the context is starting to fade but hasn't faded yet" feels less urgent because the degradation isn't visible yet. The team can still answer most questions about recent decisions. The knowledge gap isn't obvious until it manifests as a disagreement or a reconstruction exercise.

The second reason is that the past feels more appropriate for documentation effort. Recent decisions are live work. Documenting them feels like slowing down to write about something you're still in the middle of. Historical decisions feel like material that belongs in the archive — something you compile when you have a moment to reflect.

The third reason is that recent decisions feel less important. The team made a scope call last week that felt minor at the time. It doesn't seem like the kind of decision that warrants an ADR. It will seem more important in six months when it's actively constraining the roadmap, but by then the reasoning will be gone.

The practical consequence of focusing on the past is that documentation efforts often target decisions that have already produced durable artifacts — the architectural decisions that were big enough to generate design documents, the pivots that were significant enough to be remembered in detail. The decisions that fell between those landmarks — the scope calls, the implementation choices, the deferral conditions — remain undocumented because they were too small to merit a formal document and too recent to feel urgent.

Running the 90-day extraction pass

The 90-day extraction pass is a structured process for capturing the decisions in your team's recent AI chat history before the context degrades. Here's how to run it effectively.

Export each team member's recent history. Each person exports their ChatGPT and Claude conversations for the past 90 days. The ChatGPT export is in Settings → Data Controls → Export Data. The Claude export is in Settings → Account → Export Data. Scope the export to the last three months — most services let you filter by date range, or you filter during extraction. For a 5-person team, you're working with 5 × 2 exports = 10 conversation files.

Run the extractor on each file. The WhyChose extractor identifies sessions that contain decision structure: alternatives evaluated, constraints identified, conclusions reached. For a 90-day export, expect each team member's files to produce 8–15 extracted decision records. The extraction pass filters out the non-decision sessions — the drafting, the debugging, the research — and surfaces the deliberation. At the end of this step, you have 50–100 candidate records across the team.

Triage by type and relevance. Not every extracted record is a team decision — some are personal choices, some are still in progress, some have already been superseded. Triage the pool into four buckets: (1) architectural and technical decisions that constrain the codebase; (2) scope decisions that constrain the roadmap; (3) process decisions that affect how the team works; (4) external dependency decisions that may need revisiting when the external constraint changes. Discard records that are no longer live. You'll typically keep 15–30 of the 50–100 candidates.

Check for divergent recollections before writing. Before writing each record, check it against other team members' recollections and exports. If two people's chat sessions describe the same decision with different reasoning, surface the divergence in the record rather than resolving it by picking one. "The constraint was identified as technical performance by the implementing engineer; the PM's deliberation records the constraint as user impact on the alternative approach" is more useful than a synthesis that papers over the divergence. The divergence is information.

Write records using the standard format. Use the decision log template for each record: decision title, context (what question was being answered), options considered, constraints that drove the choice, conclusion, and — critically — the conditions under which the decision would be worth revisiting. The conditions field is the one most commonly left blank, and it's the one most worth filling in for recent decisions where the deliberation is still fresh enough to reconstruct what "revisit this when X" meant.

Run the pass quarterly, not once. The 90-day extraction pass is most valuable as a rhythm rather than a project. A one-time pass recovers the immediate window. A quarterly pass maintains the window — every three months, the team captures the decisions from the period before context fully degrades. The quarterly pass takes 2–3 hours for a 5-person team and produces a rolling decision log that's always current. The decisions that fall off the 90-day window into the next quarter are already documented, so the team's knowledge gap is at most 90 days rather than unlimited.

What the extraction pass reveals about your team's decision-making

Beyond the individual records, the 90-day extraction pass produces something teams rarely have access to: a clear view of where decisions are being made and by whom.

In most teams, the assumption is that consequential decisions happen in meetings — sprint planning, architecture reviews, design critiques. The AI chat history tells a different story. The deliberation happens before the meeting — in the PM's chat session where they worked out the recommendation, in the engineer's chat session where they evaluated the technical approach, in the EM's chat session where they thought through the dependency risk. By the time the meeting happens, the decisions are largely made. The meeting is ratification, not deliberation.

This isn't a failure. It's how AI-assisted work actually happens — the AI chat interface is a thinking tool, and people use it before they're ready to bring a recommendation to the group. But it means the deliberation that should be documented is happening privately, before any shared surface exists to capture it. The extraction pass makes that pre-meeting deliberation visible for the first time.

The pass also reveals which decisions aren't being deliberated at all — implementation choices that were made intuitively, scope calls that were made based on gut feel rather than structured evaluation. These show up as gaps in the extraction output: the decision record for a period where a significant architectural choice was made, with no AI chat session that contains the evaluation. The gap is information. It suggests the team may benefit from making AI-assisted deliberation a norm for certain decision types — not to document decisions retrospectively, but to produce a deliberation record at the time the decision is made.

The compounding effect of capturing decisions while they're fresh

A team that runs the 90-day extraction pass quarterly for a year ends up with something different from a team that tries to document decisions retrospectively. The difference isn't just completeness — it's the quality of the conditions attached to each record.

When a decision is documented immediately after it's made, the condition for revisiting is fresh. "Revisit this when the third-party API exits beta" is a specific, actionable condition. Six months later, the condition survives in the record. The team reviews it against the current state — the API exited beta in February, the condition is met, the decision is worth revisiting. Without the record, the decision would need to be reconstructed from scratch: what was the constraint, why did we choose this approach, is the constraint still valid?

The compounding effect is that a team with a current decision log makes better subsequent decisions. Not because the team is smarter, but because the team is reasoning from a complete set of constraints rather than from the subset that's survived in memory. The decision that was made three months ago, under constraints that are now explicitly recorded, informs the decision being made today in ways that implicit memory cannot.

The solo-founder retrospective is the most extreme case of what happens when decisions aren't documented as they're made — a founder who extracts a year of founding decisions finds that the most consequential ones were made in the first three months, before anyone thought to document them, and the reasoning for those decisions now has to be reconstructed rather than recalled. The team knowledge gap is the same dynamic at a smaller scale and a shorter time horizon. The 90-day window is where the difference between capture-as-you-go and reconstruct-later is smallest — and it's the last moment when the difference is still recoverable.

The decisions that define what you're building now were made in the last 90 days. They're in your team's AI chat sessions. The reasoning is still there. The implicit context is still legible. The conditions for revisiting are still accessible from memory.

Run the extraction pass this quarter. The window is open. In 90 days it will be narrower, and in 180 days it will be closed.