Where Context Actually Dies During a Normal Sprint

Follow one decision through a single sprint and it changes shape five separate times before it reaches the code, and it’s a little less itself each time. Nobody loses it on purpose. Each handoff is a reasonable, ordinary thing to do. By the end of the sprint, what shipped and what was actually decided don’t quite match, and there’s no single moment anyone would point to as the mistake.

Context typically dies in five specific handoffs during a sprint: planning to ticket, Slack thread to decision, meeting to spec, spec to code, and code review comment to follow-up. Each is a manual copy step with no link back to the original source. Naming all five in order, on one real decision followed start to finish, makes the pattern visible in a way that “documentation could be better” never quite does.

Where does context actually get lost during a normal sprint?

At five specific, ordinary handoffs, each one a manual copy from a richer conversation into a thinner written form, with nothing linking the copy back to where it came from. None of the five looks risky in the moment. Each is just how a normal sprint runs: something gets discussed, then someone writes down a version of it, then someone else works from that written version. The loss isn’t dramatic at any single step. It’s cumulative, and by the fifth hop, what’s left resembles the original decision only loosely.

One decision, followed through all five seams

Start with a real conversation in sprint planning: the team decides that a new rate-limiting feature should use a sliding window, not a fixed one, because a fixed window caused a customer-visible spike in a past incident everyone remembers. That’s a decision with real reasoning behind it, discussed for several minutes, understood clearly by everyone in the room.

Seam one, planning to ticket: someone writes the ticket. It says “Implement rate limiting using a sliding window.” The decision made it in. The reasoning, the past incident, the reason a fixed window was specifically rejected, didn’t, because a ticket field isn’t where reasoning lives, and nobody has time to write a paragraph of context into every line item from a planning session.

Seam two, Slack thread to decision: two days later, an engineer asks a clarifying question in Slack about window size. A sixty-message thread follows, debating five-minute versus fifteen-minute windows, with the actual final answer landing at message forty-seven: fifteen minutes, because the customer-facing API has a documented rate limit reset that lines up with that interval. That answer is real and correct. It’s also buried in message forty-seven of sixty, in a thread nobody’s going to reread once it scrolls past the top of the channel.

Seam three, meeting to spec: a spec gets written for the feature a few days after a follow-up meeting touches on implementation details. It’s written from memory, not from the Slack thread, because nobody’s cross-referencing a two-day-old sixty-message thread while drafting a spec. The spec says “rate limiting with a configurable window,” which is technically consistent with what was decided, but the specific fifteen-minute answer from message forty-seven doesn’t make it in, because the person writing the spec doesn’t remember that exact number days later.

Seam four, spec to code: an engineer, or an agent, picks up the spec to implement it. They read it as it exists the moment they open it, not as it might read after a later edit nobody’s made yet. The window ends up configurable, technically matching the spec, defaulted to five minutes because that was the first reasonable-sounding number that came up in the earlier Slack debate before message forty-seven settled it. Nothing about the code is wrong relative to the spec in front of it. It’s wrong relative to the actual decision, three hops upstream, that never made it this far.

Seam five, code review comment to follow-up: a reviewer catches the mismatch, sort of. They leave a comment: “should double check window size against the API’s rate limit reset, I think we discussed this somewhere.” The PR gets approved anyway, with a “let’s fix this later if it’s wrong” note. No ticket gets created from that comment. It’s not tracked as real work anywhere. It’s a sentence in a review thread that will scroll out of anyone’s view the moment the PR merges.

Five hops. One decision. By the end, the shipped feature uses a five-minute window instead of the fifteen-minute one the team actually settled on, and the only trace of the correct answer left anywhere is message forty-seven of a Slack thread nobody’s rereading and a review comment nobody turned into a ticket.

Why didn’t anyone do anything wrong at any individual step?

Because every single handoff was the reasonable, normal way to do that particular piece of work. Writing a concise ticket instead of a paragraph of meeting reasoning is correct ticket-writing practice. Debating window size in Slack instead of scheduling another meeting is efficient, not careless. Writing a spec from a general understanding of the feature, days after the detailed thread, is how specs normally get written when nobody’s cross-referencing every message from every related conversation. Implementing against the spec that’s actually in front of you, rather than a version that might exist in someone’s head, is exactly what a spec is for. And leaving a review comment instead of blocking the PR over an uncertain detail is a judgment call plenty of reviewers make reasonably, every day.

That’s the actual point worth sitting with: “be more careful” doesn’t fix any of this, because nobody was careless. Each seam is a technical gap, a copy step with no link back to its source, not a discipline problem a stricter process would solve. Asking people to be more careful at each individual handoff treats five structural gaps as one motivational problem, which is why that advice never actually closes the gap no matter how many times a team hears it after a postmortem.

What would a sourced, checked answer change at each of these seams?

At each hop, the thing that’s currently lost, the reasoning, the specific decided value, the correction that should have landed, stays attached and traceable instead of being re-typed from memory or buried in scrollback. A ticket connected to its planning discussion carries the reasoning behind it, not just the resulting line item. A decision made in message forty-seven of a Slack thread gets surfaced and linked directly to the work it affects, instead of requiring someone to reread sixty messages to rediscover it. A spec written with a live connection to the conversations that produced it reflects the actual decided value instead of whatever the writer remembers days later. Code gets built against the current version of a requirement, not a stale copy frozen at whatever moment it was opened. And a review comment that flags a real concern becomes a tracked piece of work instead of a sentence that evaporates the moment the PR merges.

That’s the practical shape of Thor’s living model of what’s true: not eliminating any of these five moments, which are all normal, ordinary parts of how a sprint runs, but keeping the actual content connected across them instead of re-derived from memory or lost in scrollback at each individual hop.

Documentation and knowledge decay in fast-moving teams is a well-recognized pattern outside any single company’s own experience: as velocity increases, the gap between what’s written down and what a team actually knows widens faster than anyone’s manually keeping the two in sync, and that gap compounds specifically at the same kind of handoff points this sprint just walked through. The context layer exists for exactly that reason: not to slow a team down with more process, but to keep the decision itself connected across every seam it has to pass through before it becomes shipped code.

FAQ

Is this really five separate problems, or one problem in five places?

One underlying problem: a manual copy with no link back to its source. It shows up in five distinct, ordinary spots during a sprint, which is why naming all five together makes the pattern visible instead of looking like five unrelated small mistakes.

Wouldn’t a stricter documentation policy fix this?

It would help at the margins, but a policy asking people to document more thoroughly doesn’t solve the actual gap: a written copy has no way to know when the thing it describes has changed somewhere else, no matter how thorough the copy was originally.

Which of the five seams is the most damaging?

It depends on the sprint, but seam three and four (meeting to spec, and spec to code) tend to be the most expensive to catch late, since by the time code exists, undoing a wrong assumption costs real rework, not just an edit.

Does this only happen on sprints that go badly?

No, this is what a completely normal, well-run sprint looks like by default. Nothing about this scenario required anyone to be behind schedule or under unusual pressure.

How would a team even notice this is happening?

Usually only after the fact, when a shipped feature doesn’t match what someone remembers deciding. That’s the same lagging-indicator problem this post describes: the gap is invisible until its result shows up.

See how your agents work from one checked answer instead of a stale ticket. Book a demo.