A Field Guide to the Agentic Data Stack

Three dozen tools that claim to sit between your data and your agents — mapped by lifecycle stage and ownership layer into five neighborhoods, with a build-or-buy verdict on each.

We've all watched the same thing happen to a phrase. Two years ago nobody said "context layer." Now it's on every vendor's homepage — context graphs, context engines, memory layers, agent substrates, knowledge fabrics — all promising the same thing in slightly different words, and all sounding vaguely like each other. I got tired of not being able to tell them apart. So I spent a few weeks mapping it: every tool I could find that claims to sit between your data and your agents. Three dozen of them. Here's the terrain — and where I think the ground is actually moving.

The agentic data stack — three dozen tools by lifecycle stage (→) and ownership layer (↓), with open protocols and my own stack plotted alongside for context. The interactive version is clickable.

The map has two axes, and they're the two questions I actually care about when a new tool shows up.

Left to right is the lifecycle — the path a piece of context takes from the moment it's created to the moment an agent uses it and learns from the result. It gets specified, indexed, stored, recalled, composed, delivered, executed, observed, fed back. Most tools touch only two or three of those stages, even when the homepage implies all nine.

Top to bottom is ownership — who actually holds the thing. Open protocols at the top, then open-source implementations, then vendor SaaS, then your own stack, then domain-specific analogs, and finally the incumbents, banded across the whole bottom because they're trying to span every column at once. Nine stages. Most tools cover three.

That second axis turns out to matter more than the first. More on that below.

Five neighborhoods

Don't read the map by axis, though. Read it by neighborhood — by what job a tool is trying to do. There are five, plus the incumbents looming over all of them, and they cut across the ownership axis rather than running along it.

Substrate — where context lives. This is the biggest neighborhood and the one I care most about, because it's where structured, producer-maintained context actually sits. CocoIndex is the standout: Apache-2.0, a Rust core, and an incremental indexing model — Target = F(Source) — that fingerprints your inputs and reprocesses only what changed. It's the freshness primitive a real substrate needs, and you can self-host it. Kaelio's ktx is newer — Apache-2.0, barely a month old, already past a thousand stars — and the most analytics-native thing in the row: it defines a context layer as two committed file types — schema-validated YAML that compiles to SQL, and Markdown wiki pages that cross-link to it — and reconciles both against your live stack, with query-history evidence deciding when a piece of context has gone stale. dltHub is coming at the same row from upstream: its new Transformations runtime carries one structured metadata graph from ingestion through transformation, though the business context riding on it is still prose. On the other end sits Glean, an enterprise search platform pivoting to "context graph," whose whole bet is that they ingest your corpus and infer the why from process traces over many cycles. Interesting thesis. Very different risk profile — they hold your whole corpus.

Memory — what gets retained and recalled. This neighborhood almost didn't make it onto my map as its own thing. I'd smeared it across storage and retrieval, treated it as background plumbing. Then I sent the taxonomy out for a hard critical review, and the feedback was blunt: memory is a first-class competitive surface, not a footnote. It was right. Mem0, Letta (the MemGPT successor), and Zep all live here — a vector store, an explicit memory-tier state machine, and a temporal knowledge graph, respectively — and the differences between them are real architecture, not marketing. Corrections, prior decisions, the hard-won intuition about what's normal and what isn't: that's a different problem than storage, and it earned its own column.

Composition — how context gets assembled. Less of a market than I expected, because Claude Code's own task system is quietly eating it. Tasks survive a restart, enforce dependency order structurally with a blockedBy field instead of trusting the model to remember, and hand each parallel agent a fresh, isolated context window. When the runtime ships the composition primitive for free, the standalone tools have a hard time. Most of what's here — Agent Relay, Agno, the Ralph bash-loop pattern — is worth reading for the patterns, not buying for the product.

Delivery — how context reaches the agent. This one has a clear winner, and it's a standard, not a product: MCP. Build on it, not instead of it. The pattern I keep coming back to is Notion's — the tool description tells the agent to fetch the current spec at runtime, from the resource, at the moment of need, instead of pre-loading two hundred pages of documentation and hoping the right one is in the window. Just-in-time context. It's a small idea that quietly changes how much you have to stuff into a prompt.

Runtime — how agents use context, and how you watch them. Observability for agent decisions. Arize is the most serious player here — think Datadog for what an agent decided and why — and OpenTelemetry now has real semantic conventions for LLM calls and tool-call spans, which means the trace of why an agent did something is queryable with tooling you may already run. This is the neighborhood the analytics world has thought about least and is going to need most.

And the incumbents, across the bottom. Snowflake Cortex, Databricks AgentBricks, Salesforce Agentforce. The data-gravity play: AI where your data already lives. The map makes their strategy legible — they're not trying to win any single column, they're trying to band the whole bottom row so you never have a reason to leave. Watch one signal in particular: the day Cortex ships context cards for its metrics — discrete, evaluable fields instead of just SQL generation — the substrate neighborhood gets a lot more crowded.

What the map made obvious

Two things jumped out once everything was on one page.

The first: most of these are not products you buy. They're patterns you lift. When I tagged each tool with a verdict — buy, adopt, evaluate, monitor, pattern-only, or avoid — the pile skewed hard toward "evaluate" and "pattern-only." The genuinely buy-it-today entries are almost all standards — MCP, OpenTelemetry, the task system — plus a few pieces I'd already built myself. The rest are good ideas wearing a logo, and you can usually take the idea and leave the logo.

The second is a single line that predicts the verdict better than any feature list: can the vendor see your context? A tool that runs locally and never touches your corpus is safe to prototype with on a Tuesday; a tool that ingests your definitions, your corrections, your hard-won domain knowledge is accumulating the exact thing that would make your own agents valuable. That's the first thing I check now, before features, before pricing. And for the tools that clear that bar and actually sit in your stack, the next question is what they encode — whether they tell an agent anything beyond a metric's name and its joins. That's the subject of the companion field guide on the context layer, where I read eleven schemas field by field against the five rungs a business user actually climbs.

The interactive version of this map — all three dozen tools, clickable, with my notes and a build/buy verdict on each — lives at data-centered.com/landscape. This is part of an ongoing series on context engineering for enterprise data: practical notes from building analytics pipelines with AI agents. Follow along, and tell me what I missed. I know I missed something.