An architecture walkthrough, an early look at an internal tool actually being built, and some of the most experienced builders in agentic memory in one room. San Francisco, October 13.

Memory is the dessert everyone in AI wants right now. Episode 1 of The Cognitive Layer makes the case for eating your vegetables first, the data foundation underneath it. Himanshu Singh (Netflix) on why entity resolution is a systems problem, not a prompt problem, and what happens when you skip straight to "memory": agents don't just make mistakes, they hallucinate in sync.

The data platform pain is real, and so is the choice sitting right in front of you. Stitch together five systems and hope, or build on something that already works. Our customers keep picking the second path, and it's why they can focus on outcomes instead of infrastructure.

Understanding multimodal data isn't just about storing it. It's about being able to pull out the one paragraph, bounding box, or clip that matters, without paying for the whole blob every time. We explored array-based formats early on. The problem wasn't storage itself, it was that the overhead negated the exact benefit you'd expect from fast partial access. You'd gain on retrieval logic and lose it right back to bloat (loss of caching). The deeper issue: images, video, and documents don't need to come back in entirety most of the time. A user wants a bounding box, not the whole image. A clip, not the whole video. A paragraph, not the whole document. That requires a format built around a one-to-many relationship, one asset, many meaningful parts, with fast access to just the part that matters. That's what pushed us toward the graph. Two things fell out of that decision: • Clips, bounding boxes, and paragraph spans live as metadata and relationships, not duplicated bytes. No re-encoded copies of the same video for every clip someone wants. • We can embed the relevant part directly, not just the whole asset, because the whole often loses the detail a specific query actually needs. Native multimodal support also means real processing, chunking, resizing, format conversion, happens at the point of retrieval, not as a separate pipeline someone has to build and maintain. That's the actual bet behind multimodal native: not storing more data types, but understanding what's inside them well enough to hand back only the part someone needs!

A team came to us mid-migration, moving off a stitched-together stack because every quarter their query latency got a little worse and nobody could tell them why. Turned out the problem wasn't any single piece. It was three: a vector store, a graph store, and the glue code holding them together, each optimized on its own, none of them designed to talk to each other under real production load. Nobody could tell them why because debugging meant tracing a query across three systems that each told a slightly different story. We rebuilt their retrieval path on ApertureDB: one engine, embeddings, graph, and multimodal data together, no format conversion between systems, no glue code translating one store's output into another's input. In our benchmarks: 65K+ nodes/second ingestion, 1M+ QPS retrieval. That's the part that actually matters. Fast writes vs. fast reads vs. scale isn't a law of nature, it's usually a tax you pay for plumbing: converting formats, reconciling three systems that were never designed to agree. Remove the forced plumbing, and the tradeoff you thought you had to make mostly wasn't real to begin with. Debugging and maintenance stopped being their growing pains. That's the part worth paying attention to.

Built from the start, not bolted on after. Here's why that distinction matters for agent memory at scale.

Our founder Vishakha on why memory that only stores what isn't enough. Relationships and provenance are the parts most systems skip.