Why context graphs are the missing layer for AI

I invited Jamin Ball (Altimeter) and Animesh Koratana (PlayerZero) on the pod to discuss.

What’s missing as AI agents move into production?

It’s not intelligence - for most use cases, existing models are more than "good enough.” The main bottleneck is context.

Agents can read data and take action, but they don't capture the reasoning behind decisions. Why was this incident escalated? Why did this customer get an exception? Why was this fix prioritized over another?

That reasoning - what my partner Jaya and I call decision traces - is scattered across tools like Slack, email, and support tickets, or never recorded at all. It almost never makes it into a system of record.

Our belief is that the companies that can capture these decision traces and structure them into context graphs will own the most valuable layer in enterprise AI.

In this episode, I talk through this idea with two people who come at it from different directions.

Jamin Ball, a partner at Altimeter, kicked off this conversation with an edition of his Substack called “Long Live Systems of Record.” His argument is that agents aren’t replacing systems of record - they’re raising the bar for what a good one looks like. The familiar SaaS “front door” will matter less as agent-native interfaces emerge on top, but the need for canonical data will only grow.

Jaya and I agreed with parts of that thesis and pushed back on others - so I invited Jamin on the pod to debate it. Animesh Koratana, founder of our portfolio company PlayerZero, joined as well and shared what he’s seeing as he ships agents inside real customer workflows.

What we cover:

• What decision traces are, and why traditional systems of record aren’t designed to capture them

• Why agents “unravel quickly” when they read and write across systems in parallel

• The Amadeus/Booking.com analogy: what the travel industry tells us about where value will accrue

• Why getting humans to explicitly train agents is so difficult

• How PlayerZero wedged into support engineering to capture decision traces across SRE, QA, and dev

• The trust problem: why enterprise buyers need observability before they’ll grant autonomy

• Whether context graphs will be verticalized by workflow or universal like a data warehouse

• The bear case: could context graphs fail the same way semantic layers did?

• What happens to Snowflake and Databricks in a context-graph world?

• 2026 predictions: AI IPOs, world models, and which point solutions won’t survive

Read the transcript:

Ashu: Thank you, Jamin. Thank you, Animesh, for being on the pod. Jamin, you’re the first investor ever on my podcast.

Jamin: Wow. I’m very honored.

Ashu: But you created such a stir with your systems of record post, and I felt so compelled to respond. So maybe we should let you kick it off by talking a little bit about your thesis.

Jamin: Of course. And the good news is you did bring a CEO, so there is someone smart on the call who will actually share insightful takes!

Animesh: Oh, the pressure is on.

Jamin: The origins of the post were basically a lot of conversations I have been having - I’m sure both of you have as well - with different folks who are productionizing AI workflows and applications, and a little bit of this letdown of like, “Oh, they’re just not as good,” or “they’re not as impactful yet as I would’ve hoped.”

And then there was some triaging into: well, what are the issues?

And I think what I found in having a lot of these conversations was: agents are great, but when you have a lot of them running around in a very disorganized fashion, things start to unravel quickly. And it unravels because these agents are inherently read-and-write. They’re reading context from somewhere, but also updating state somewhere else. And when that’s happening in parallel across systems all the time, systems are getting updated. What you end up losing is ground truth.

And I saw a lot of posts about SaaS is dead, software is dead. And it all kind of felt like one way or another of saying systems of record are dead, and the Salesforces of the world and the ServiceNows of the world are going to be totally disrupted by some AI-native equivalent.

And I think my own point of view was: that’s a little too black and white. What agents still need is a source of truth.

Animesh: I mean, we think about this in very similar ways. The companies that are able to actually capture what we’re, I think colloquially right now, calling a context graph are going to be best positioned to actually own the work that happens on top of it, right?

And at PlayerZero, we often think about production engineering and what is the work that actually needs to happen in order to run and operate production.

And I think, from a builder standpoint, the way this has evolved - let’s say from a market segmentation or category creation - what is the bottleneck and how has that shifted over the life of agent companies that have evolved over the last two years, with constraints moving around and models getting…

A lot of what we have to think about when we’re building agents is: what are the priors that the agents have to have in order to be effective in any organization?

And I think one of the most universal shifts that have happened, especially over the last six to eight months as models have gotten really, really good, is that all of a sudden we’re now seeing them actually be truly agentic, right? To actually have agency, to actually have authority, and to own the work as opposed to being auxiliary or additive to somebody else’s work.

And I think what’s been really fundamental in that shift is: now all of a sudden they’re the ones that are actually owning the decision-making and the actual outcome, as opposed to someone else owning the outcome and them being auxiliary to it.

And with it has come this huge new set of possibilities to actually build around, because the richness of how these decisions are actually navigating organizational boundaries - why should this incident be resolved in this particular way? Or why is this drug being prescribed to this particular person? That reasoning is now being captured and encapsulated in a way that we really never actually had visibility into.

And what I think it implies is that, Jamin - going back to your initial point - the bar for systems of record is increasing, right? They’re just going higher and higher.

I think that’s actually what a lot of agent builders have been reflecting on. We’re sitting on top of this extremely rich set of trajectories that represent really interesting decision-making in organizations that otherwise could never even be observed. And now all of a sudden there’s an opportunity to build something greater.

And it doesn’t look exactly like the systems of record of the past. It’s something different. It’s represented differently, it’s queried differently, and it also creates a different sense of leverage for what the future of work actually might be.

Jamin: And I think you said something super interesting. When I boil down what’s fundamentally changing - put aside the technology - and if I had to boil it down to something super simple, it’s this: you have software and systems of record that are built and designed for people versus agentic systems that are built and designed for agents.

And I look back to the early days of the internet, specifically the travel industry. Before the internet, you booked travel through a travel agent, or you called directly. You had to call each individual airline. There wasn’t an aggregation point.

And for travel agents, they used something called a GDS system, a global distribution system, which was Amadeus, Sabre. And what did those platforms do? They went out to every single airline, all the hotels, and they aggregated the inventory: the flight data, the departure time, the arrival time, the open seats, the price per seat.

So as a travel agent, you had a desktop app - some terminal app - on your computer that had a direct data link to an Amadeus server. You could go to one single place to look at all available inventory. And so Amadeus and Sabre - the GDSs of the world - those were the systems of record, and they also owned the UX, the front door.

Well, then what happened? The internet was invented, and all of a sudden you saw the rise of OTAs - online travel agencies - your Booking.com, your Priceline, your Kayak. Now, as an end consumer, you could go direct to the OTAs.

The OTAs on the backend might integrate with the GDS systems because, in the early days, if you’re Priceline or Booking or Kayak, you don’t necessarily want to go build direct links to every single airline yourself. You might just go to the single place that aggregated, because all that work has been done - the GDS.

And so, if we fast forward, we have the benefit of hindsight. What happened to that industry? Did the GDS industry go away? Did it go to zero? No. Amadeus is still a $30 billion company. However, Booking.com, Expedia, Priceline, Kayak - there’s been a lot of mergers there - but the market cap of the OTAs is now hundreds of billions. And the market cap of the GDS - the old historical systems of record - is, I don’t know, $20-30 billion.

So it didn’t go to zero, but there was an order-of-magnitude larger opportunity that was created with a different interface. And it unlocked a different end user. Now consumers can go direct.

I think the same thing’s happening: a lot of systems of record will -

Ashu: - become 10x more valuable. The GDS was unable to capture the interface opportunity. So, would you have rather been an investor, if you went back to 1999, in Booking.com or Amadeus?

Jamin: Yeah. Exactly. And there are so many parallels there because even today you have Salesforce, ServiceNow, Workday - you have all these systems - and the reality is so many workflows span multiple systems of record.

Ashu: That’s the core insight for decision traces. The challenge with systems of record is because they grew up organically. Systems of record are owned by individual functions - individual chains of command - but decisions cut across functions and chains of command. Animesh, you should give the example in your case, but in most cases they flow through multiple functional organizations in a company who work off different systems of record.

Animesh: So at PlayerZero, we think about production engineering as a superset category. And what we think about is: there’s all of these partitioned functions that operate production systems. This could be SRE, this could be support, this could be QA, right? Or this could even be a faction of your developers that are independently building a certain view of how your production system actually works.

And they operate between all of these different systems of record, which are your ticketing system if you’re a support engineer - this could be Jira or Zendesk. It could be Datadog if you’re an SRE. Or it could be your codebase if you’re a developer.

And there are so many decisions that are being strung across all of these different systems of record, but the organizational dynamics of how a ticket is ultimately escalated, remediated, and then resolved back to the customer, back to the user, is never truly captured.

And this was the core insight behind how and why we built what we built.

But I think the really interesting thing that Ashu, you mentioned there is: in a world where these decision traces truly become centrally represented - you truly have a context graph - then the entire shape of the organization actually changes as well.

These functions that were built based on labor constraints - for example, we have SREs because SRE requires a specific skillset that is different than the skillset of a QA, and that’s different than the skillset of a developer - these functional groups of people that we built because we have certain labor constraints and certain systems of record that those pools of labor understand can start flattening.

And I think we’ve seen parallels to this in past iterations of software. I mean, Clay with the go-to-market engineer, or Databricks with the data engineer and stuff like that - this is not exactly the same where there’s some centralized system of record. But if you flatten the tooling and the access to priors to be able to do great work, then I think the functions themselves start collapsing in a really interesting way to redefine what the shape of the organization looks like.

And I’m curious, Jamin: as systems of record evolve, how does the organization evolve?

Jamin: Yeah. I think it’s fascinating. I go back - one thing I loved about the context graph post is this concept of the decision trace.

And what I’m looking for - my wife was in software sales forever - so I’m going to make an analogy and I’ll connect it full circle at the end. If there’s one thing I know about her workflow, it’s what she hated more than anything: data entry. “I talked to this person - let me put the notes in the CRM.” “How many people are at the org?” “What are they looking to buy?” “What kind of discount are they looking for?” It was all of that, and it sat in her head, and she knew it because she knew her clients and she knew her prospects. But manually entering the data was just super hard.

And you kind of had this 80/20 where 80% wasn’t good enough. Like, you either had all of it or you didn’t.

And when I look at what I think is going to be most interesting in this whole concept of a decision trace is: well, how do you capture that?

And I love that you made a very clear analogy in your initial post about this concept of: “Hey, we only offer a 10% discount at renewal. That’s standard. We can go higher than that only if there’s been some sort of incident or outage or a bad experience.”

How do you go get that? Okay, well, I’m going to go to the ticketing system or the Datadog system. I’m going to look for outages and I’m going to look for this, I’m going to look for that.

And what’s interesting is I might do that in my normal workflow. What systems are going to naturally capture that so that I don’t have to enter it? “Well, I gave that discount because of this.” Because I’m just not confident in an organization’s entropy to be able to do that - to enter that data - and it’s kind of like the old UiPath analogy where it’s like: hey, you can just watch someone complete a workflow and then automate it, or you can describe it and build it with some GUI.

I think that’s what it is: either organizationally we’re going to need to train people to enter why you did things, or you’re going to need systems to capture it. And I’m pretty confident we’ll get to the latter. It’s just a question of how. How do we get there? Do we need new systems to do that? Is it new agents that monitor that?

That’s what’s most on my mind: organizationally, how do we get from A to B?

Ashu: Jamin, I think you’re spot on. There will be exceptions. I don’t want to generalize but for the large part, getting human beings to explicitly train agents is as difficult, or arguably more difficult, than getting your wife to give clean data to the CRM. No great sales rep ever wants to do that. That’s just not in their DNA. And I think the same is true if you ask human beings to explicitly train agents. So I think most of this data capture will be implicit.

It’ll be a staircase that you have to deliver enough value in v1 of the product, where the value the user gets far outweighs the training they’re providing by being the human in the loop. And then that gives you an opportunity to go to step two.

The early movers who move in 2026 and begin to capture these decision traces, translate them into a context graph, will create this flywheel that then becomes the moat.

I’d love to get your take on how you think this plays out for systems of record. Are they all equally at risk, Jamin, or do you think certain categories are more at risk than others?

Jamin: I think you will see the relative profit pool decline for the classic systems of record, at the benefit of modern startups. I think most are at risk.

Amadeus wasn’t the only one. Sabre was a huge GDS. It was acquired for $5 billion by I think maybe private equity, went public, and now it’s got a market cap of less than a billion dollars. So it’s treading water.

What industries, what types of systems - I don’t know if I have a point of view yet on what’s more at risk. I just think most are going to be at risk and will start a slow and steady decline, and a few will remain.

Animesh: In that vein, do you think that these systems of record are eventually going to converge into a warehouse itself, and then you have different UX layers that operate on top of this?

I think there’s something interesting to be said about the combination of the UX layer plus the database - how we could actually overfit to a -

Jamin: I mean, those used to be, but the front door is changing. Look, we’re kind of coming full circle to what Satya made as a comment a while ago about: all these SaaS apps are just a dumb CRUD database, right? That’s kind of what we’re arguing.

Do these systems of record get reduced to a dumb CRUD database that can do basic operations, but there’s something else on top of the CRUD database that is orchestrating, handling the workflow, executing the workflow?

And that’s the big challenge for the classic systems of record. Do you slowly get reduced to a dumb database where someone else captures all the value? Or are you able to innovate yourself and capture that new front door, capture that new profit pool?

Where the challenges are: you’re going to have to build solutions that are cross-functional. And if you’re selling to salespeople, you might not understand the workflow of the finance team. You might not speak the language of the accounting team. And those are different buyers with different personas, and it’s hard to sell to both. And I think there are a lot of challenges, let alone some of the innovator’s dilemma that all these players are facing.

Ashu: That’s why startups exist. Lots of fun opportunities.

Jamin: We’re in the business of venture capital. We’ve got to believe that startups can pose a risk.

Ashu: When I think about it, the two functions that come to mind - or two business processes - I think about this as: what business processes will get reinvented by agents, and therefore what are the underlying systems of record?

I think the go-to-market process - the business process of growing from a lead to customers that are paying and renewing - is a huge opportunity for automation and agents, in part because that process is done in high-cost economies. It’s a very communication-intensive process. And if there’s one thing we’ve learned about LLMs, it’s they’re incredibly good at both generating and processing communication.

Jamin: A hundred percent.

Ashu: The other process where that’s equally a challenge is the entire development process - from spec to managing code in production. So many different systems in that process, and people have historically built applications to help you do product definition, applications to help you manage code - code repos like GitHub, ticket databases like Zendesk, observability tools, you can go on and on. And I think, Animesh, you should definitely comment on that - those two business processes are hugely at risk.

On the other end of the spectrum, I think processes that are more tightly within the organization - potentially finance, procurement.. and by the way, there’s nothing that’s not cross-functional. That’s the big “aha.” They’re also cross-functional, but they have less cross-functional implications.

I think the underlying systems of record probably have a better chance, but I want to open it up to both of you. What do you guys think? How would you segment the market? Your firm picks some stocks too, Jamin.

Jamin: Animesh, you should definitely take the code example. Let me go back to my wife, right? Like 15 years ago, this was her workflow. She’s a hyper-competitive person. She would get up in the middle of the night to look at the inbound leads, because how her company operated was: the day before, there would be a set of inbound leads who hit the “Contact Us” button, who booked a demo on the website, who went to the company blog and downloaded the Gartner Magic Quadrant that was gated by “enter your email,” right?

There are all these different forms of inbound leads. I think they had some sort of scoring system or some basic data augmentation that would add in: how big is this company? How big of a contract could they be? Maybe some predictive stuff around how likely they were to convert.

And it was basically like a race: how can I put as many in my name that I can go after?

And you’re like, that’s crazy.

Ashu: It happens at firms too.

Jamin: It does! But it was kind of one of these: okay, well, let’s look at an agentic future. I hit “book a demo.” Why shouldn’t - instead of “book a demo” - why shouldn’t I be able to just hit a button that says “get a demo,” and pop up an AI avatar that can describe the product, that can answer questions about the product, that can give me a demo?

And guess what? I’m ready to learn at that moment. Maybe my boss just yelled at me because I don’t have some solution for this, and I’m feeling the pressure now, and I’m ready to buy now, or I’m ready to learn more now.

Instead of: I hit “book demo” and maybe someone reaches out to me in two hours, but maybe I’ve moved on. Maybe I’m not thinking about it anymore. Or maybe it’s not till the next day, right?

So often in the go-to-market world, there’s so much urgency that’s required because there are options. If I want to procure a piece of software, it’s not like there’s just one vendor that’s going to do it for me. There’s maybe five, right?

I think the extreme example here is a plumber. When I’m calling a plumber, I probably need that plumber ASAP. My dishwasher just broke, my toilet’s overflowing. I’m getting on the phone and I’m calling the plumber. And if they don’t answer, I’m hanging up and I’m calling the next one right away. And so that’s lost revenue for the first plumber that I called that didn’t answer.

And that’s an extreme example, but it’s kind of similar in a lot of software sales: when I’m ready to get information, if I have to wait for it, odds are I’m going to go find a different vendor.

So you have such an opportunity in the go-to-market world to shrink that time from intent to information delivered to software purchased, because you don’t have to wait for people.

Ashu: Historically, the way this has evolved - and that’s where the systems of record have evolved - is they’ve chosen niches and then kept adding capability and functionality. And I think that’s a very plausible path, and time will tell.

I think the other path, though, is that it’s entirely possible people will build cross-functional workflows, but do it for a narrow segment of customers. That segment could be an industry vertical, it could be a size segment, it could be a geography segment. And they start stitching together - not everything - but stitching together multiple functions, because that’s how you capture the decision traces. But you do it for some customer segment where you don’t have to solve world hunger in terms of features and capabilities.

Jamin: Right. Exactly.

Ashu: Animesh, you are doing this in real life, Jamin, and I just..

Jamin: ..just pontificate about it!

Animesh: Yeah, I have to sell it at the end of the day.

Thematically, I think the best places - or the greatest opportunities - to build this are in places where there’s enough urgency and incentive to ultimately give agents authority to actually make these decisions.

And we talked about this earlier: these agents are now able to operate across all these different systems of record. I have to give the agents agency, or I have to give them authority to actually go do this and make decisions in order to be able to capture the decision trace.

And this has been really interesting for us, where Jamin, you mentioned they ultimately start as point solutions. And I think choosing that wedge is incredibly important.

For example, for us, our wedge tends to be support-engineering. And the reason support engineering is a really interesting wedge for us is because it is laterally available to all of the different functions that are adjacent to it.

So it’s available to SRE, it’s available to QA, it’s available to developers. And the types of systems of record that support engineers need to interoperate between include the ticketing system, the observability system, and the code.

They have to interoperate between all of these things to be extremely effective. And by wedging there - even though it sometimes looks a little different, sometimes smaller, sometimes bigger than SRE - it becomes this really interesting vantage point to start building this entire context graph.

And the other thing we see a lot is: ultimately, we have to sell this. And how do you sell something that’s cross-functional, that’s going to change the way you work?

I think the real alpha here is that you can do each one of these individual functions better because you’re doing all of them, as opposed to doing any one of them in isolation.

An example of that - similar to the go-to-market example you gave - in the coding space is: if you understand the intent of how the software is built, you can debug it better. That sounds obvious in hindsight, but that’s not obvious when you’re thinking about an SRE’s workflow in isolation.

Going the other way, when you think about the SDLC and you’re trying to prevent bad things from going into production, understanding how things have broken in the past becomes an obvious prior to pull on to say: “Hey, you’re changing this area of the code - here’s what might break in the future.”

So when you create a cohesive pitch and say, “I can do each of these point functions better, and the advantage is that I’m doing this in a centralized, universal way,” you end up being greater than the individual parts. One plus one equals three.

Jamin: You said something interesting too. Working with a lot of these agent companies - whether it’s a sales agent, a marketing agent, a voice agent - what I’ve found is, what people really want to buy is observability.

They want to know: why did it do this? When did it fail? Where did it fail? Why did it fail? They want to be able to debug it.

Maybe it’s a voice agent and they want a transcript. Maybe it’s a marketing agent and they want to know when you sent something and why you sent this proposal.

So much of it comes down to trust.

And I wrote a post last week about authority as the bottleneck. Right now, it still feels like we’re in phase one. AI drafts the email, but you review it and you click send. AI flags an alert, but a human reviews it and says, “I’m going to remediate it.”

I think we’re in the trust-building phase, similar to the early days of the cloud. It took time for people to trust it - was it going to be secure, was it going to scale?

We need to build trust with these AI agents and systems, with a human in the loop. The human in the loop can help provide the context and the decision traces, and that will ultimately be the bridge to fully agentic and autonomous systems.

Ashu: I think you’re right. It’s changing very quickly. What I’ve been pleasantly surprised by is how quickly business users are willing to hand off trust to an agent to complete tasks.

In many cases, people still want a human in the loop, but I think 2026 is the year that changes.

Jamin: Yeah. And the irony is that uptake is happening so quickly because the ROI is so painfully obvious so early on.

All the AI pundits ask, “Where’s the ROI?” But the ROI is visible in the uptake. Companies like Cursor are only able to scale that quickly because the ROI is so obvious that sales cycles are compressed to minutes, not days, weeks, or months.

You see this in many agent companies. As a buyer, you see it in 30 minutes. The ROI is obvious. You say, “I’m going to compress the time I spend doing this to basically zero.”

So not only is it removing monotonous time, it’s driving business value. And to me, you only get that speed of growth if the ROI is painfully obvious. So when people ask where the ROI is, it’s right in front of you.

Animesh: I think it’s so clear after the first time someone sees an incident resolved, or the first time someone sees a problem detected days before they would have thought about it, how quickly the rest of the sales process accelerates.

I think this is a universal feeling among AI agent companies.

Going back to the context graph piece, the question of why these systems are durable needs to be answered at the same time. Why is this agent going to stick around six months from now or a year from now, when there’s all this other noise in the market?

That’s where context graphs become interesting. They create stickiness.

And that takes me to a question we touched on earlier: are context graphs infrastructure, or are they the moral equivalent of intellectual property for each vertical solution?

Is there a different context graph for production engineering versus go-to-market, or is there a single universal context graph for every organization, like a data warehouse?

I don’t think there’s an answer yet. The companies that can capture decision traces are the ones that have the UX to run agents, evaluate outcomes, and take action in cooperation with humans.

That UX is why they’re best positioned to own the decision traces. And because of that, the best context graph companies will be verticalized. You won’t have a single universal context graph company, because to build one, you need to be embedded in a specific workflow.

Jamin: I think an analogy here might be the process mining world from the RPA space. Everyone knows UiPath, but a company like Celonis is less well known, even though they’re almost equally big.

Their pitch was: “We’re going to help you identify which processes can be automated in the first place.” That process mining step.

So is there an equivalent in the agent world that helps surface which workflows can be automated, and how to automate them - specifically through context graphs?

The challenge is creating an environment that can capture the telemetry data and the usage. That’s hard. Companies might not be instrumented in a way to do it.

You look at classic systems of record: many modern companies pitch that they have a flexible data model underneath their product. It’s not a rigid CRM with fixed fields where adding a new field requires a Salesforce admin.

A flexible data model allows you to capture this interaction, that interaction, this thing, that thing. But first you have to capture it. You need infrastructure that’s instrumented to automatically collect it.

You also need a human layer on top that can verify: yes, this was the reason we gave a larger-than-normal renewal discount.

I still think the biggest challenge is capturing that logic in an automated fashion. And it’s not just capturing it - it’s making sure the infrastructure is flexible enough to capture the full range of decision traces.

Ashu: I don’t think there is one architectural solution to a context graph. The way you build a context graph for software engineering or production engineering may be very different from the way you build a context graph for go-to-market.

Jamin: Yeah. And let me give a quick bear case - not against context graphs, but where they could go wrong.

It’s similar to semantic layers in databases. People have been trying to build semantic layers in data warehouses forever. A semantic layer says: “Here’s how we define ARR,” and that definition becomes the single source of truth.

The challenge isn’t technology. It’s people. Ashu and I might fundamentally disagree on how you calculate something or when you apply a rule. That disagreement isn’t technical - it’s human.

So the question is: how do you resolve those disagreements in a context graph? Do context graphs become like semantic layers - great in theory, but never fully realized in practice?

Ashu: That risk is real. The other risk I’d add is that even when two people agree, they agree today - and truth changes.

Any agreement is out of date minutes later. Truth isn’t static; it’s dynamic. Time is an important component, and often there are other dimensions as well.

Even when there is agreement, it depends on which part of the business you’re looking at. So that will have to be figured out.

What gives me confidence is that these graphs aren’t being explicitly defined the way semantic layers were. I remember workshops with 50 people spending weeks agreeing on definitions - and even then, they represented only a slice of the organization.

Here, the graphs are implicitly created by delivering value to customers. That staircase of value is critical. The teams that get that staircase right are the ones that will capture the data that compounds into a flywheel.

Before we wrap up, I want to change topics slightly. One thing Jamin mentioned in his original post was the role of data infrastructure companies like Snowflake and Databricks - and the CSPs like Google and Microsoft.

What do you think happens to Databricks and Snowflake?

Jamin: I think the bull case is they become the new transactional backdoor - the modern Salesforce or ServiceNow. In the same way Oracle bought NetSuite to own both the database and the application, these platforms could become the data app future.

The question is whether people build modern agents on top of Databricks and Snowflake. Can they be the aggregation point?

As your post pointed out, they’re generally in the read path, not the write path. But maybe they become the new OTAs - the layer on top of systems of record where most of the profit pool accumulates.

I think we’ll see AI-native applications built on top of these platforms, especially data apps like observability, where you’re sending logs and metrics and alerting on top.

No one wants to be reduced to a dumb data platform used only for reporting.

Animesh: I think it’s hard for Snowflake or Databricks to become critical in the write path. I think a different way to think about it is: what primitives are required to represent context graphs?

A lot of it comes down to probabilistic data structures - embeddings and similar approaches. There’s also an interesting connection to continual learning, where some learning is externalized into the context graph and some is internalized into model weights.

There’s an awkward truth here: some of the “database” lives in the model weights, and some lives in embedding stores.

Because data warehouses aren’t oriented around the write path, it makes it harder for them to be the storage layer for context graphs. But I do think the front door for CRMs and other systems of record will collapse into data warehouses.

I don’t see a reason why not.

Ashu: Fundamentally, this battle will come down to changes in technology that allow analytical and operational systems to collapse into one.

The infrastructure we have today exists because of past constraints. As those constraints change, the architecture will change too. My instinct is that data infrastructure companies are better positioned than systems-of-record companies because of cost economics and architecture.

Animesh: But the ergonomics of capturing judgment matter. A lot of what people pay for in Salesforce is the services and abstractions built to capture decisions and outcomes. Ashu, if I understand you correctly, you’re saying there could be a new category of commodity companies that build those abstractions on top of data infrastructure?

Ashu: Imagine a CRM app built on top of Databricks. Using Databricks’ infrastructure - combining structured, unstructured, operational, and analytical use cases - and building an application layer on top.

Animesh: Yep.

Jamin: Look at what both businesses have done. Databricks is moving into transactional systems with Lakebase and Neon. Snowflake bought Crunchy Data.

You’re seeing analytical databases move into the transactional world.

Ashu: And CSPs already have both - they just keep them siloed. They’ll likely combine them in more creative ways. In some ways, the database wars are back. Like the ’80s and ’90s with Sybase and Oracle.

If you both had to pick one prediction for 2026, what would it be?

Jamin: One hot take: I think we see a very large AI IPO - either one of the big labs like OpenAI or Anthropic, or a major application company like Cursor. A very fast founding-to-IPO cycle. At least one very large one.

Ashu: Just one?

Jamin: No no! At least one large one. I hope we see a lot.

Ashu: If it’s only one, a lot of growth stage investors would be unhappy.

Animesh: My bet is that the most slept-on opportunity in AI is world models. I think we’ll figure out how to define them beyond physics, and they’ll drive enterprise AI advancement, especially around continual learning.

Ashu: Perhaps at the risk of stating the obvious, I really think this is the year of enterprise agent adoption. A massive wave that benefits incumbents and startups alike.

Animesh: I thought we were doing hot takes.

Jamin: These are boring takes.

Ashu: I’ll leave the disagreement to the two of you.

Animesh: One more: I think many AI point solutions will die. Point solutions don’t externalize learning into context graphs or capture broader organizational dynamics. The durable part of enterprise AI comes from using point solutions to build a flywheel. If you’re not thinking about that, someone else will do it better.

Ashu: Anything to add, Jamin?

Jamin: One more take: political discourse around AI and job loss will hit a fever pitch. It’s already happening and will accelerate into elections.

Ashu: That’s why I think we’ll be better off on this side of the pond. There’ll be debate, but the U.S. will keep moving forward.

Jamin: You don’t want to limit potential, but you also need empathy for real people. Creative destruction should be handled carefully.

Animesh: As we adopt agents, there will be more work, not less. We already see it - Cursor hasn’t reduced code output; it’s increased it.

Jamin: I’ll always bet on the resilience of the American people and our ability to adapt.

Ashu: With that, thank you so much, Jamin and Animesh, for joining on short notice. What a fun conversation on context graphs. I think it’ll be a fun year. Thanks again for joining us.

Jamin: Thanks for having me. This was fun.

Animesh: Super excited. It’s going to be a good year.