AI coding agents read your code perfectly and understand your team not at all.

Here’s a pattern you’ve probably watched play out. An AI coding agent produces a diff that looks great, fewer lines, better names, tidier control flow, and in the process it quietly removes something that was there on purpose. A guard rail. An invariant. A workaround that exists because the team hit a problem once and swore never to repeat it.

The agent isn’t being careless. It literally cannot know. That step was added for a reason that lives in a Slack thread and in the heads of two engineers who may have since moved on. The code in front of the agent doesn’t explain itself, so the agent optimizes it away.

The code is usually correct. The context is what’s missing. And once you see that failure mode, you start seeing it everywhere.

The two layers of everything

Every engineering organization runs on two layers of knowledge.

The first is explicit: the code, the READMEs, the tickets, the commit history. It’s written down, and anyone can read it, human or AI.

The second is tacit. Why a design was chosen over the obvious alternative. What the team tried before and abandoned. Which invariants must never be violated. Which shortcut is quietly forbidden and why. Who to ask before touching the fragile part of the system. This layer isn’t written down anywhere clean. It’s scattered across Slack threads, buried in PR review comments, and stored, unreliably, in the memory of a few long-tenured engineers.

Here’s the uncomfortable part. A senior engineer’s real value isn’t that they type faster or know more algorithms. It’s that they carry that second layer around in their head. They begin a task already knowing that an approach deadlocked in production last year, that a pattern is banned for a security reason, and that you don’t touch payments code without a heads-up.

AI agents begin every task with none of that. They’re capable and tireless and completely amnesiac about your organization, so they write confident, plausible, context-blind code, and someone has to catch it.

We built Decispher to fix that at the source.

The mental model that made it click

>Git stores what changed. We wanted something that stores why it changed, what must not change, what was tried before, and what the next engineer should know before touching it.

That’s the whole product in one sentence. Everything else is engineering in service of it.

Step one: capture the memory without asking anyone to write it down

The graveyard of knowledge-management tools is full of systems that only worked if humans diligently maintained them. Humans never do. So the first rule was simple: capture has to be passive.

Slack bots listen in channels. GitHub webhooks watch pull requests and reviews. The Jira app reads ticket descriptions and comment threads. And inside coding sessions, a feature we call Branch Story records what actually happens.

Engineers keep working exactly as they do now. The durable signal gets extracted automatically and sorted into seven structured types: Decision, Convention, Constraint, Rationale, History, Ownership, Plan.

That structure isn’t bureaucratic tidiness, it’s functional. A constraint should block an agent’s action. A convention should shape the code it generates. History should stop it from walking into a dead end someone already explored. A wall of undifferentiated chat text can’t do any of that, but structured, typed memory can.

Step two: fuse the fragments into one truth

The same architectural rule tends to appear in five places, each worded slightly differently: a Slack message, a PR comment, a line in a Jira ticket. Store all five and you haven’t built memory, you’ve built noise.

Our Context Fusion Engine merges those fragments into a single canonical unit, using semantic similarity, explicit references, timing, and overlapping people and entities. Then it links units into a graph with real relationships. This decision confirms that one, extends another, supersedes an older one, or contradicts something still on the books. When two things can’t both be true, it surfaces the conflict instead of silently keeping both.

This graph turned out to be the closest thing we have to how a senior engineer actually reasons. They don’t remember isolated facts, they remember chains. An authentication choice constrains a deployment pattern, which affects caching, which touches compliance. The graph encodes exactly those chains.

Step three: serve the right context, not all of it

The lazy way to give an agent context is to shove a giant block of background into every single call. It’s expensive, and worse, it buries the one fact that mattered under a thousand that didn’t.

So we split it. A small, always-present spine lives committed in the repo. The deep detail stays in Decispher and is fetched live, on demand, when a specific task needs it.

The most important thing an agent can do with this is ask before it acts. It describes what it’s about to do and gets a verdict. Illustratively:

```

Agent: I’m going to simplify the session flow by removing the

token-rotation step.

Decispher: BLOCKED.

This violates a constraint: token rotation must not be removed

from the session flow. It was added deliberately after a past

security issue. Owner: the payments team.

Sources: the Slack thread and PR where the rule was set.

```

That’s the difference between catching the problem in code review, or in production, and never letting it happen at all.

Step four: enforce it at review time

Not everything gets caught before code is written. So Decispher Lens reads pull requests against the knowledge graph and flags the violations by analyzing intent, not by matching patterns. When it comments, it doesn’t just say a change is wrong. It says which decision the change violates and why that decision exists, which is the single hardest senior-engineer move to scale.

If you want the formal version of this idea, our open-source starting point, Decision Guardian, enforces Architectural Decision Records on pull requests. It’s the front door. The platform grows from there.

The part people underestimate: humans use the same memory

It would have been easy to build this only for AI. We didn’t, and I’d argue that’s the whole point. Engineers get the same searchable, cited memory the agents do, through search, a dashboard, Slack, and PR comments. Every answer cites its sources. The rule is no source, no claim.

Why insist on one shared memory? Because when a new hire asks why the team does auth a certain way, and an agent asks the identical question, they should get the identical, traceable answer. Two separate memory systems drift apart. One system of record keeps everyone, carbon and silicon, pointed at the same truth.

What I believe now

The mistake is to think of this as a better wiki. A wiki is a place you go to read. This is a system that reaches into the moment of work and says, “wait, not like that, and here’s why.”

AI didn’t invent the tacit-knowledge problem. It just made it impossible to keep ignoring, because we’ve handed our codebases to tireless collaborators with zero institutional memory. The answer was never going to be a smarter model. It’s giving the model, and the humans working beside it, the scars, the guardrails, and the reasoning that used to live in one person’s head and leave the moment they did.

The diff that quietly removes something load-bearing becomes a BLOCKED message with a citation. That’s the whole idea.

— -

*Decispher is a system of record for engineering decisions. The open-source Decision Guardian is the easiest place to start.* You can find smarter version at Decispher’s website. What is Decispher? https://www.youtube.com/watch?v=GDTYotlRNdM