Notes from Episode 1 of The Cognitive Layer, with Himanshu Singh

Listen or watch the full conversation: Spotify · YouTube

Everyone building agents or AI forward versions of their product is racing right now to give their AI, memory. Only a few people are asking the harder question first: what is that memory actually built on?

That question is the spine of the first episode of The Cognitive Layer. My guest was Himanshu Singh, whose career has been spent turning scattered, low-quality information into connected, trustworthy data assets, at eBay, at Microsoft, and today as an engineering manager at Netflix, where he leads engineering on their entertainment knowledge graph.

We opened with a simple icebreaker: coffee, cocktail, or dessert. Himanshu picked dessert, then used it to hand me the thesis for the entire conversation before I asked a real question.

"Memory is the dessert that everyone is trying to reach for right now, and the whole message is that to have that dessert, you have to eat your vegetables first, and those vegetables are the data foundation. If you skip them, the dessert will make you sick."

Data Quality at Ingestion: A Merging Error, During an Election

Himanshu's conviction on this isn't theoretical. Early in his career, working on Bing's Knowledge Graph, he owned the politics segment, ingesting voting records, opinions, and quotes for public figures. During an election, data for one particularly prominent, trending politician turned out to be sparse, thin on the metadata needed to distinguish it clearly from other entities. When that data got merged with information from other sources, two different politicians with similar names collapsed into one entity, producing a view of the record that simply wasn't true.

Caught before it caused real damage, but barely, and squarely during the period when it would have mattered most.

"If the bad data fails quietly, it never stays put. The impact will compound downstream. You validate at the point of ingestion, and that is the cheapest place on earth to do it. After that, if you do it, you really end up paying a lot of costs."

Graph Model vs. Graph Database vs. Knowledge Graph vs. Context Graph

Before a team writes a line of code, Himanshu argues the first question isn't how to build the system. It's whether they need a graph at all: are relationships the actual product of the system? Are there evolving multi-hop connections? Is the same entity being resolved across many sources? Only once those answers point toward "yes" does the graph conversation actually start, and even then, most teams blur four distinct layers together.

A graph model is a modeling choice, nothing more. What are the entities, how are relationships between them defined. It doesn't require any particular technology underneath it.

A graph database is a storage engine tuned for efficient traversal. Useful, but in Himanshu's view, often a skippable question in early stages. A graph model can run on infrastructure a team already has.

A knowledge graph is where governance actually enters the picture: the ontology, how entities are merged and resolved, how a "canonical entity" gets defined so that meaning from multiple sources becomes something shared and standardized across different users and use cases.

A context graph is a knowledge graph put to work, specifically as the grounding and memory layer for AI: real-time context that agents read from and write into as they operate. It's the same layer we've written about as the missing piece between human judgment and machine agency, and it maps closely to what we call Knowledge, Memory, and Context in our own framework.

"These are essentially a stack, and not a menu. Everyone wants to start at the top, the memory layer. But if you're not thinking about the layers underneath it, entities, how they're resolved, how they're governed, you're just decorating the top without building the foundation."

Entity Resolution Is a Systems Problem, Not a Prompt

Multi-agent systems raise the stakes on all of this considerably. In a single dashboard, a bad entity match is an embarrassing number. In a system where dozens of agents are reading, writing, and reasoning off the same shared layer simultaneously, one bad match cascades: every agent that touches it inherits the error, and they hallucinate in sync, agreeing confidently with each other on something false.

Himanshu's position is direct: don't hand entity resolution to an LLM at runtime. That approach is non-deterministic, unauditable, and prone to drifting from one run to the next, none of which builds the confidence a system needs to pass downstream.

Instead, he described a tiered architecture: offline algorithms doing the bulk of merging and deduplication, so even a system that needs to operate online can fall back on an audit trail that's mostly deterministic. The process begins with blocking and pruning to narrow millions of candidate entities down to a manageable set. Deterministic rules and machine learning models earn their place in that pipeline, while a human reviewer serves as the final tier for the entities that matter most from a business standpoint. All of this sits behind a shared entity-resolution service, effectively an intelligent router, that decides which tier a given entity needs.

The output of that whole system is a canonical identity, the contract that keeps a fleet of agents from confidently agreeing on the wrong thing. It's the same pattern our own audit of 20+ memory frameworks found missing almost everywhere: governance and consolidation are treated as afterthoughts rather than architecture. More on what that study found in our landscape deep dive.

Provenance and Explainability: Every Fact Needs a Receipt

The second half of that trust problem is explainability. Every fact, in Himanshu's framing, should carry its provenance: where it came from, which tier of the resolution system decided to merge it, the confidence score, a timestamp, and whatever other metadata a system would need to reason about whether to trust it. Not just for a human debugging the system later, but for the agents themselves. A well-built agent encountering a fact from a low-confidence source should go looking for a second one.

One distinction he was emphatic about: ground truth has to stay separate from agent-generated facts. A fact an agent observed and a fact an agent inferred are not the same category, and an inferred fact shouldn't get promoted to the same status as an observed one without the same quality bar.

"Provenance and lineage is what's stopping you from laundering fiction into facts, and then stopping agents from merging fiction with facts."

Centralized or Federated? The Open Question in Enterprise AI Memory

We closed on something Himanshu was candid about not having a settled answer to: should enterprise memory be one shared, horizontal substrate, or should every domain own its own vertical implementation?

A pure horizontal system, he argued, tends to fail the way horizontal infrastructure always fails, too generic to serve any one domain's real needs around freshness, schema, or latency. A pure vertical approach means every team re-implements entity resolution, provenance, and governance from scratch, and the system loses any ability to reason across domains.

His bet lands in the middle: centralize the hard, universal primitives, identity and entity resolution, how provenance and lineage flow through the system, access control, a shared semantic registry, retrieval APIs, observability, and federate the actual business context and domain memory out to the teams who own it. He drew the comparison to human memory directly: the mechanics of how a neuron fires are the same across every person, but what gets stored, and what it means, is entirely individual. A well-designed horizontal layer, in his view, doesn't just hold the shared substrate. It also defines clean hooks so each vertical can write into it without friction (this philosophy aligns very closely with Aperture Nexus).

The Biggest Mistake in Building AI Agent Memory

Asked what he'd want an engineering leader building agent memory today to hold onto above everything else, Himanshu didn't hedge:

"The number one mistake is building the memory and agent layer before you know your data foundation is trustworthy. If your entities aren't resolved, if your facts don't have that explainability receipt, adding memory on top just automates the confusion faster, and makes you more efficient at being wrong."

His advice: resist buying a vector database, calling it memory, and moving on. Earn a small, governed slice of truth first. Define what the canonical identities are, what provenance means for your system, what memory actually is for your use case, how it expires, how you know the facts inside it are still current rather than silently stale. Understand all of that before the system exists. Then prove it works, to yourself and to another human, because if a person can't explain why the data coming out of a system is trustworthy, the agents consuming it won't do any better.

It's the same conclusion we landed on building Aperture Nexus: lineage, permissions, and trust in the reasoning itself all have to hold up together, or none of them mean much on their own.

This is the first episode of The Cognitive Layer. Full conversation available on Spotify and YouTube.