How I built RetainIQ: an AI early-warning system for the knowledge your team is about to lose

One of the teams testing RetainIQ had a four-hour production outage. The engineer who owned their payment gateway had resigned three weeks earlier and walked out with all the context that was only in his head. RetainIQ had flagged that exact topic with a fragility score of 91, six weeks before he left. Nobody acted on the alert in time.

That story is the whole reason the product exists.

Every company has a person like that. The senior engineer who built the payment integration and is the only one who remembers why the compliance path has that weird fallback. The one paralegal who knows how a key account is actually onboarded. The single person who can unbreak the deploy pipeline at 2 AM. It is not a people problem. It is a memory problem. Organizations forget what they know, and they forget it invisibly until it costs them.

RetainIQ is an observability layer for that risk. It scores knowledge concentration from 0 to 100 for every critical topic in an organization, and it generates a concrete intervention before the person holding that knowledge leaves. Think Datadog, but for the human layer of a company. The one rule that shaped every design decision: it requires zero documentation effort from the team. RetainIQ listens to work that is already happening and builds the map itself.

This is how it works under the hood, and what I got wrong before it worked.

The problem, in numbers

Knowledge concentration is a measurable cost, not a vibe. The average knowledge worker spends about 2.5 hours a day just looking for information (IDC). Roughly 42 percent of what an organization knows is never written down anywhere. When a critical person leaves, their replacement takes 6 to 12 months to reach full productivity. None of that shows up on a dashboard, so nobody manages it.

Most teams answer this with Confluence or Notion. Those tools answer one question: where should we write this down? For most teams most of the time, the honest answer is "we won't, and we'll forget." RetainIQ answers a different question: what is fragile right now, based on signals you are already producing?

How it works

RetainIQ is a serverless application on AWS, live at retainiq.cloud. The pipeline is event-driven end to end.

Signal upload (S3)
      |
      v
Lambda trigger  ->  Amazon Bedrock (Nova Pro): entity extraction
      |
      v
DynamoDB: knowledge graph
      |
      v
Fragility scoring  (concentration + repetition + dependency)
      |
      v
Amazon Bedrock (Nova Pro): intervention generation
      |
      v
Dashboard: dependency graph, scores, ranked tasks

Signal ingestion. Teams drag and drop the work they already have: JSON exports from their tools, plain-text notes, and VTT meeting transcripts. No connectors to configure, no documentation sessions, no change to how anyone works. The product observes the work; it does not ask for more of it.

Redaction, before anything hits a model. Every signal passes through a redaction stage first. It can mask names, emails, and other identifiers, and it can discard the original signal content once analysis is done. Both are admin toggles, so each customer sets their own privacy posture instead of trusting mine.

Analysis with Amazon Nova Pro. Lambda functions call Nova Pro through Amazon Bedrock to pull out knowledge entities: who owns what, which systems depend on which, and where the single points of failure are. The extracted entities land in DynamoDB as a knowledge graph. Two surfaces read from it: an interactive force-directed dependency graph where a node turns red when a topic has no backup expert, and a dashboard of per-topic fragility scores.

Scoring: what makes a topic fragile. The score combines three signals. Concentration measures how centralized the knowledge is. Repetition measures whether there is any backup coverage. Dependency measures how many critical paths run through it. A topic that one person owns, nobody else has touched, and everything else depends on, scores near the top.

Interventions, not just alerts. This is the part that mattered most. When the score crosses a threshold, RetainIQ does not just raise a flag. It uses Nova Pro to generate a concrete intervention: a plain-language summary of the risk, plus a ranked task list a manager can actually assign. Real examples it generated: "document the payment gateway integration and its security considerations," and "schedule a knowledge-sharing session for this topic." When the work is done, an impact summary shows how far the fragility score dropped.

The rest of the stack is deliberately boring: Cognito for auth with tenant isolation per organization, S3 for signal storage and static hosting, CloudFront for delivery, and the whole backend defined as one AWS SAM stack so a clean account goes from zero to running with a single deploy. The frontend is React and TypeScript, with D3.js for the graph and Recharts for the trend views.

The hard part was not the AI

Nova Pro is good at extracting entities. The hard part was deciding what not to surface.

The first version alerted on everything and drowned the user in noise. The rewrite only ships an intervention when three things are true at once: the concentration is high enough, the topic is actually business-critical, and the recent activity says the risk is live right now. Almost every design decision in v2 was subtractive. Cutting alerts, not adding them, is what made the product usable.

What I got wrong the first time

The first version was called OMDA. It reached the semifinals of Amazon's AIdeaS 2026 competition, and the judges' feedback was blunt. It was the most useful product review I have ever had.

Two comments rebuilt the product. The first was that I sounded like another knowledge-management tool. My instinct was to argue. Then I accepted the perception was the problem and rewrote the positioning from scratch: RetainIQ does not store knowledge, it measures the health of knowledge you already have, with zero writing required. That single commitment changed what the product does.

The second was that I had talked about privacy without building it. That stung because it was true. So privacy became a first-class, visible part of the product: the PII redaction toggle, the option to delete raw content after analysis, an explicit security page. "We take privacy seriously" is not a feature. Specific, visible architecture is.

I rebuilt the whole thing end to end using a spec-driven workflow with Kiro, where every module starts as a spec, the agent generates the implementation, and I review at spec boundaries instead of line by line. That is the only reason a full rewrite was even on the table given the time I had.

The rebuilt version, RetainIQ, went on to win the Innovation category at Amazon AIdeaS 2026.

The results

These are early numbers from a private beta, so I hold them loosely, but the direction is clear. Across completed intervention cycles, the average fragility score drops by about 31 points. Each intervention saves an estimated 12 to 18 hours of future incident and ramp time. Time from signal upload to first insight is under three minutes.

What I would do differently

I built v1 for the wrong buyer. I assumed CTOs wanted a company-wide audit. The person who got the most value was an engineering manager heading into a reorg who just wanted to know which of her reports could safely take on more without dropping something critical. Smaller problem, more urgent, more willing to pay. If I had talked to her before writing a line of code, I would have skipped most of v1.

Takeaway

The interesting work in applied AI is rarely the model call. It is the judgment around it: what to ingest, what to ignore, and what to put in front of a human so they act in time. RetainIQ lives or dies on that judgment, not on the model.

If your team has a Raj, a Sarah, or a Tom, you already have this risk. You just cannot see it yet.

Live demo: retainiq.cloud. The full write-up is on the AWS Builder Center. If you are just getting here, start with why I write this blog.