sanju writings thoughts tools

Capture the Why

Dec 26, 2025

·

3 min read

tl;dr: We capture what happened everywhere. But ask 'why did we do that?' six months later and everyone's scrambling. The solution is embarrassingly simple.

There’s a lot of noise right now about “decision traces” and “context graphs.” Fancy words for a simple problem we’ve been ignoring for years.

We don’t need new infrastructure. We’ve just been lazy.

Activity Log
• Sanju opened feature-x.ts 3:12pm
• Sanju edited feature-x.ts 3:18pm
• Sanju opened config.json 3:24pm
• Sanju deleted feature-x.ts 3:31pm
• Sanju edited config.json 3:35pm
• Sanju ran tests 3:38pm
• Sanju removed feature X 3:42pm
• Sanju pushed to main 3:44pm

Lots of what. Zero why.

Decision Trace
• Removed feature X
• 2% usage across all users
• 10hrs/week maintenance drain
• Team voted 4-1 to remove
• CEO approved in Monday sync
• 12 affected users migrated

Now you actually know why.

The problem is embarrassingly simple

Every tool we use captures what happened. Activity logs, audit trails, version history. We’re swimming in “what” data.

But ask “why the hell did we do that?” six months later and everyone’s scrambling through Slack threads, pinging people who’ve left the company, reconstructing context from memory.

The data was there. At the moment of decision, someone knew:

  • Why this approach won
  • What other options got shot down
  • Who said yes
  • What past decision made this okay

We just didn’t save it. Not because we couldn’t. Because no one asked us to.

We already solved this for code

Engineers figured this out 20 years ago.

Git commit + PR description + linked issue = decision trace for code.

commit message
sanju sanju committed 3 hours ago
Fixed bug
1 file changed +2 -1

6 months later: "Why did we change this?"

Good luck figuring that out.

commit message
sanju sanju committed 3 hours ago

fix(auth): increase session timeout to 60min

Users on slow connections were getting dropped at 30min.
Support tickets up 23% this month from timeout issues.

Discussed with security team - low risk given we
already have refresh token rotation.

Closes #234

1 file changed +2 -1

6 months later: "Why did we change this?"

You already know.

Engineers who’ve been burned treat commit messages like documentation. Not because anyone forces them to. Because they’ve asked “wait, why did we write it this way?” one too many times.

The code doesn’t change. The context around it does.

Now apply that thinking everywhere else

Click cards to flip

Sales

Gave 20% discount

tap to see the why
Sales

Gave 20% discount. Customer had 3 unresolved critical tickets, similar deal got exception last quarter, VP approved citing churn risk

tap to flip back
Design

Changed button color to blue

tap to see the why
Design

Changed to blue. A/B test showed 12% higher clicks, client approved in Figma comment, aligns with new brand guidelines v2

tap to flip back
Hiring

Rejected candidate

tap to see the why
Hiring

Rejected. Strong technical skills but culture fit concerns raised by 2 of 3 interviewers, similar profile didn't work out last quarter

tap to flip back
Product

Removed feature X

tap to see the why
Product

Removed feature X. 2% usage, 10hrs/week maintenance cost, team voted 4-1, CEO approved, migrated 12 affected users to workaround

tap to flip back

Same pattern. Just applied beyond code.

So why hasn’t this happened?

Two reasons.

Friction. In the moment, no one wants to fill out a “reason” field. They’re busy. They’ll do it later. They never do.

Incentives. Activity logs are easy to build. Check a compliance box, ship it. Decision traces take effort. You actually have to think.

What changes now

AI agents fix both problems.

AI Agent
Processing discount request...

Checking customer history...

Found: Enterprise account, 2 years, $48k ARR

Checking open tickets...

Found: 3 critical tickets unresolved (14 days avg)

Searching precedent...

Found: Similar deal Q3 got 20% exception (policy v2.1 §4)

Routing for approval...

VP Sales approved (churn risk flag triggered)

Saving decision trace...

Done. Full context logged automatically.

Decision trace captured with zero extra effort.

The agent already had the context. It just saved it.

No more friction. The agent is already doing the work. It pulled data from 5 places, weighed options, got approval. Writing down why? That’s just one more line. Zero extra effort.

Incentives finally align. AI agents need past decisions to get smarter. If you never saved why exceptions were made, the agent can’t learn when to make them. Bad data in, bad decisions out.

If you’re building AI agents, you have a choice. Capture the why from day one, or end up with another pile of useless logs.

The moat isn’t the graph. It’s the discipline.

You don’t need fancy infrastructure to start. Just capture three things with every action:

  • What happened
  • Why
  • Who approved

Try it yourself

Your decision trace

Save this somewhere. You'll thank yourself in 6 months.

A text field works. A simple schema works. The value isn’t in the architecture. It’s in having the data at all.

Six months from now, when someone asks “why did we decide this?”, you’ll either have an answer or you won’t.

Want the trillion-dollar insight?

Just give a shit
about capturing the why.

That's it. That's the whole thing.