Latent Space: The AI Engineer Podcast
Original podcast
Watch the full show on YouTube: https://www.youtube.com/watch?v=zP8P7hJXwE0
6,350 words · 3 speakers
All right, we are starting with the Lane Space Pod in a remote studio. Welcome to Jay Gupta and Ashok Garg from Foundation Capital.
Thank you for having us.
Thanks for having us.
Jay, we apparently met three years ago at the Langchain Hackathon where a factory was born. Were you also actively thinking about context stuff back then? Or what was the vibe three years ago?
Yeah, I think three years ago was probably like the first AI hackathon. And I cannot say I was thinking about context things at that time. I was just thinking about like, and I think it was actually like before even agents took off. Like it was like literally right after ChatGPT. And I think the only things that really existed were Langchain, Llama Index and like Perplexity. Were like sort of the three companies that came out right after. And so anything that they were doing, I think all the AI builders were going and running there. And going into like whether it was like Notions office, I'm pretty sure had a hackathon. But definitely it was not context back then. It was even pre-agents. And so it's like crazy to see where we've come in just a short amount of time.
Yeah, I mean abstractly, I guess like Langchain, Llama Index and to some extent Perplexity also. They funnel context into LLMs. And we weren't working on agents back then, but you know, obviously at some point we would start. Like even back then, there was discussion already. Ashu, what's your, what's your sort of AI story as well? Like I'd love to introduce the audience.
Yeah, sort of very short version. You know, I used to run a machine learning team at Microsoft in 2006. We were doing ad targeting. And after you've done ad targeting for a few years, you want to do something that's better for the soul. So I left a little variety of ideas. I bumped into a guy called Jan Stoica at Conviva, which was my first portfolio company. And they were doing applied AI at the time, but they ran into a bunch of data infrastructure problems. And that led to, you know, data bricks and any scale. And then a whole series of other applied AI companies. So I'm lucky enough to hang out with Jay and Jan and other smart people. That's, that's my plan to fit.
Well, you guys work on really, really smart things. And congrats again on having the early hit of 2026. I would say, so I'm going to bring this up on screen right now, which is the context grasp discussion, which is what we're here to have. So
Jai actually tweeted basically like the article version of this, but obviously there was the actual formal blog post. I'm just kind of curious what the origin story of this is. Like, were you sitting in a room and you were talking like, "Hey, we need a name for this thing. We see an opportunity." What was going on in December that you started working on this?
Go for it, Jair.
It's a good question. So, you know, I think, you know, we sort of throughout December, and I would say more broadly, like the last six to 12 months, like, you know, we, you know, Foundation Capital, like, we spent a lot of time with our companies very up close. And so, you know, one of the things that Ashu and I kept continuously talking about, like, and what we were thinking about is like, what is actually missing as AI agents move into production? Like, if you think back, like, everyone said 2025 would be the year of agents. And in some ways, it was, you know, we got Claude Code, we got like Devon, we got all these customer support agents, Sierra, Decagon. And I think, you know, at the same time, the models also got dramatically more capable. But I think, you know, when you think deeply about like what is missing, you kind of realize like, you know,
that they still can't reliably do enterprise work, some of these agents. And so, you know, we started thinking about it and like it kind of struck us that, you know, one of the reasons is that because they don't actually capture like why we do certain things, like, and the human reasoning behind decisions. And so, like specifically, what do we mean? Like, why exceptions are granted, how conflicts are resolved, what precedents are applied? And that's sort of kind of what the thinking was over the last six months. And I think in December, we got to writing about it and published sort of last thing right before the year ended.
Yeah, I think the thing I would add to that is, you know, the subtext, at least for us, and I think for a lot of other people over the last year has been that as so much of the IP is captured in the model itself, what is the role of applied AI companies broadly? Systems of Agents companies, Systems of Record? And what is the defensible mode? And I think we've been debating that with Animesh at Player Zero, with Ishan at Olive, with Kabir at Tassara and so many of our founders. And they were all talking about the same thing, but using different languages or different words. And so I think it was that series of conversations that gave us this insight that there is an intermediate abstraction, which we call context graphs, which is the accumulation
of decision traces. And this intermediate abstraction, in our opinion, will be the one that will matter the most over the next decade. It's the enduring layer for the most successful application companies or systems of agents companies. And we also believe, and we'll talk about it more, that it's it's unique and new and it's not well suited for incumbents.
That is actually very key because obviously incumbents could also capitalize on it if they see the opportunity. You did you did name drop Animesh. I did have him categorized in our Discord. We have a Discord where we discuss all these like trends and stuff. And so, yeah, I didn't know he was your portfolio company.
Yeah, no, he's been a part of coming over the thesis along with a bunch of other founders like, you know, Kabir, as I said it to Sarah and Ishan at Olive, but Animesh is definitely a brilliant technical founder who's helped push our thinking.
Okay. How about let's let's do like a very crisp, like you, we have a deck that you guys kindly sort of put together. I think definitions always help motivate a discussion. So let's let's just go right into how do we define a context graph and and all the other related concepts.
Yeah, go for it.
You go for it. Go for definitions.
Yeah, okay, I think I think we can, we can, we can describe the, it's a concept and you can describe it in a variety of ways. But at its essence, a context graph is the institutional memory of all the why behind the set of decisions. And we think of that core unit as a decision trace. When when when an agent or a system of agents executes a business process, it goes through a dozen, maybe multiple dozen steps. It may have humans in the loop once or many times. And the tracking, these exceptions, these overrides, this cross-system context, which
sits in both structured and unstructured systems, and very often in people's heads, and that's where the human in the loop comes in, capturing that as a decision trace. And when you aggregate decision traces in a way that you can then Learn from them as an agent and you can use them to make the agent better. That's that fabric or becomes what we call the decision graph.
Uh, sorry, decision graph or decision trace?
Sorry, that's uh, my apologies, that that that layer becomes a context graph, my mistake, the context graph.
So context graph is made up of a lot of decision traces.
It's made up of a lot of decision traces and it's also, you know, when you implement that art, you will have to implement it in a way that you can actually extract insight from this and you can make it machine usable by the agents themselves.
And then one thing I, you know, I want to get clear off front, like, this is kind of like a conceptual thing, right? Like, the, do we, has anyone claimed to like have this working yet? Uh, cause it seems like very, very big.
What do you think, Ja? You talked to a lot of people.
I do talk to a lot of people. I would say that if you look at Twitter today and you look at LinkedIn, thousands of people claim to have it working. I've had like maybe thirty.
There's this guy. And he mentions like how to build a context graph, so he's, he's very confident.
Yes, he is, he's, I think Player Zero is actually one of the examples that, you know, that, you know, that actually has some version of this working. I think that what's interesting about this is that you, there's going to be a lot of different implementations of it. And so I think you have like, you have companies like Glean that have come out and say that, you know, we're the ones that are building this. You have companies like Atland, like data cataloging companies has have said that we're going to own this. You have application companies that have put out their version of this. I think Harvey, not, not Harvey, but Rocks put out approach, actively put out approach. There's companies across the app layer that have also, you know, said that they're building this. And so I think you will see infra companies, application companies, security companies, Okta put out something as well.
And so, but in terms of like seeing like this actually deployed at scale, like I think there are very few examples today. And some of that is because it's a very, you know, new concept.
So I think the only thing I would add to that is don't think of context graphs as a technology architecture. Think of it as a framework and there will be multiple technology implementations and those will evolve over time. And and different companies will use different components, different databases, different data fabrics in order to build that context graph. And it'll depend on the on the use case and the situation. What we are seeing from our portfolio, at least, is that the common theme across these systems of ancient companies that we think are doing revolutionary stuff is they are building a context graph. They're early, but we're seeing it. We we we see that at Player Zero, we see that at Tera, we see that at Olive,
we see that at Andal logic in the security context. Now, there are varying degrees of sophistication because it's a concept as against a specific product.
And so this very sort of flexible concept. Is there like a an ideal data structure, I guess, for a context graph? Like, is it is it just, you know, like the sort of triplet entities of a knowledge graph or anything like that?
Go for it, Jeff.
I think no, and I think that's because it's more of a framework for now. I think that you will see, you know, I would say it's like the concept of decision traces especially, like I think that is going to be implemented by like many different types of companies. And there will be also many different types of companies that will emerge because of this. Like thinking about like security governance. I think you'll see companies that pop up there and we're already starting to see a few pitches there. Or we're going to see like companies that are going to reimagine different sorts of applications. So I think with this logic, you could reimagine, how do you build Sierra today versus, you know, a lot of these application companies started three years ago. And so if you were to rebuild them starting today, I think that's also what we're seeing.
And I think as well as on infra, like we're going to see, we've already started to see like different people like imagine, you know, how do you think of, you know, data catalogs in the future, databases in the future? I think those are approaches are quite early. I think you also see like a lot of the graph database people come out of the woodworks and and say that, you know, this is us as well, so.
We've been doing this the whole time.
We've been doing this for the last ten years. I think most of my notifications when I get tagged and I press in, it's like, this is a great, this is what I've been trying to articulate for the last ten years, like, and here it is.
At the same time, there are some common themes of people who are building context graphs. And you know, the underlying infrastructure or technology implementation will vary depending on your starting point and your scale. But they tend to be cross-functional. They tend to be cross-process. They tend to sort of, these decision traces are stitching together data that goes across multiple existing systems of record. Uh, they tend to be in the right path, which is you're actually, you're executing a decision. And it's not an analytical, it's not analytical decision, it's the actual operational decisions you're making. You know, existing systems of agents, products actually have a very unique advantage because they're not bound by a business process.
They're not bound by an existing uh data store, they're in the orchestration path. And being in the orchestration path for automation of a business process positions you uniquely to capture decision traces and therefore build a context graph.
Yeah, you have that in this, in this slide here. Uh, and also I guess in your, in your post where you talked a little bit about the uh, why the incumbents uh, don't do it. I, I think like one of the interesting things, uh, I want to sort of double click on, first of all, systems of agents, I've heard this uh terminology, is that widely adopted? Cause uh, I would say that you're the first in recent months that I've, that I've heard actually use this term. What is a system of agents startup?
Well, I guess out of curiosity, what term have you heard um, you know, to describe systems of agents?
Don't know, I mean, I think that's, that's also like off for interpretation as to like what, what exactly it means. I do think like people have like system of record, you know, as like a baseline of like, okay, we all agree what a system of record is. Beyond that, like people try to modify it in some way, system of context, whatever. System agents, like, sure, you have like, I guess, a group of agents, I guess, and they all do different things. But I don't know if this is like a deeper origin or community around this term yet.
So you know, the way I would think about it is, and look, these terms are all collided. And it's a little bit like, you know, a cloud of words. The notion of a system of agent is a company that has a collection of agents that are automating a process or a set of processes. It was initially, we came up with that last year to differentiate from, you know, more basic chatbot-like systems. So, you know, a lot of, a lot of systems, a lot of AI companies are single-player mode, more like a chatbot. And to the extent that you're starting to build something that's multi-agent, multiplayer mode, has humans in the loop and is driving decisions across a business process,
we want to distinguish that with this notion of a system of agent. The underlying mode that these systems of agents are building is a context graph. And the way they build the context graph is by capturing the decision traces that they inherently sort of, you know, execute. So it is a mouthful and any, any advice on how to simplify would be appreciated.
The term that I've been working on is mostly just Agent Lab, the company that produces agents. But I think those are, those are like slightly different things in any way as well. So it's, it's hard to describe. I think I just, I just wanted to like, like double click on a few of these things so that people can get a sense of like what you mean when you say those things. I think the other thing that's also super interesting is being in the read path, not the write path. Obviously with your backup with Databricks, you understand the read path very, very well. I think the write path is also interesting, like context is mostly a read job. Write mostly just like introduces a higher.
Demand for uptime and lower latency and all those things. But I'm also curious, like basically, you know, the way that this creates a waterfall in my mind of exceptions, override precedents, cross-system context. Also, I put here approval chains, which you had in your original document.
It feels more like IAM, like AWS IAM, like some authorization, sort of logic system, these cascades down. And you know, hopefully you like derive some kind of formal logic reasoning that you can that you can sort of inspect and version control, maybe. Because like, I think the worst thing is like, when you capture all decision traces and you look at all the overrides and all the precedents. It looks like Swiss cheese, like people contradict themselves all the time. And you're like, okay, well, what's the truth of it? And L M is going to be completely confused, reasonably so.
Look, I think it's a great point. And I think when you think about read versus write, you know, it can mean a very different thing when you're very, very, if you're being precise and technical. I think when we think about the read versus write path is analytical systems, which are in the read path are ultimately. And you ultimately have to write to an analytical system. So there are some write path in that sense. That's why technically it means something very different. But analytical systems like data warehouses and even systems of record capture the endpoint of a decision.
They know what happened, so they may know what the revenue of a company is. They may know what the deal size was. They may know what the discount offered was. They may know sort of what was the patch applied in the case of a bug fix. What they don't know, so that's because that's ultimately stored in some analytical system, whatever that system might be. And to that extent, systems of records are more analytical in nature than they are in the right path where agentic systems or systems of agents actually capture the sequence of steps. What did you do? So if you're using Player Zero, there's a support ticket that comes in. That support ticket, then, you know, someone picks it up, some agent, not even a human being first. It does some analysis. It starts to run some queries. All of that is stitched together. It then.
At some point pulls a human being into the loop. That human being is then doing a bunch of queries themselves. Because they look at what the agents have presented to them and they start to query the system. All of those queries then ultimately lead to some decision or some hypothesis around what the root cause of the problem is and therefore what the bug fixes. That whole, starting with a ticket as an example, through auto triaging, to hypothesis generation, to sort of bug fixes, to ultimately then then translates into a piece of code. That code that gets pushed into production and it either works or it doesn't. You complete that loop. That loop is the right path, the way we think about right path.
Yeah, I see.
As against the narrowly defined read write path in a database, which is I think where you're coming from.
Yes, because, you know, I.
Which is technically more precise.
Yeah, but here you're you're you're writing code. So, you know, it's still still the right path, but it's different. Yeah, and I think I think my question there would be like, you know, do people want to use a separate platform for it or should it just be inside of GitHub and Slack? And, you know, those things will still continue to win or, you know, basically, obviously, people want to prefer their defaults, the things that they're used to. Is there a case to be made for putting these onto like a new thing, like whether it's Play Zero or something else?
Why don't I get Stab J and then use a jump in as well? So I absolutely think it'll be a new thing. Now, the key is that these new platforms, whether it's Player Zero or or Olive or Tessa or pick pick your favorite one, they will have to coexist with existing systems. And so the system of engagement may end up being slack. You may communicate with Player Zero through Slack. You may communicate with it through other systems you have, because you're not going to replace those, at least not overnight. But these existing systems don't actually orchestrate across an entire business process.
To some extent, systems of record do. But even in systems of record, what you see is systems of record were very historically all designed for structured data. So even if you're running a deal process through Salesforce, as an example, very quickly you find the data is not in Salesforce, it's in Slack in part, it's in email. Actually, the number one system of record for most organizational data is email.
Is email, yeah.
And Slack. So, but email and Slack just captures data. I mean, as a blob, and again, technically not as a blob. I mean, if you get into sort of data structures, but, but the, but the data is, is dark data in a sense in Slack and in email. And an agentic system that has a real context graph will capture this, the pieces of data that are appropriate across email, across Salesforce, across your account management system, across a conversation and across a Zoom call.
All of these have data, some structured, some unstructured, and most of the values actually in the unstructured data. And this is part of why just context graphs are so hard to build, that you have to figure out how to parse the unstructured data in a way that you capture value and insight.
Because if you started uploading every Zoom call you have in a sales situation, you'd have like a million Zoom calls of only noise. And so where the unstructured data is such a large part of it and conversation data is such a large part, most likely the context graph will actually consist of small models. The context graph itself is a model layer, like you use that data to train a set of models with them to become part of your context graph. In the case of Player Zero, actually, the data set is much more semi-structured. It's, it's less Zoom calls and more code and tickets and observability, which all has some level of structure, very large data sets, but with more implied structure. And so the way you would implement a context graph is very different. It's more of a traditional graph structure, maybe it's a relational database with a graph layer on top.
Yeah, Jay, I don't know if you have any notes to add on that?
Yeah, I don't think anymore to add.
Got it. One thing I wanted to move on to also is obviously there's a huge amount of community discussion. You also dedicated a slide to just the pushbacks. I actually wouldn't say pushbacks, but feel free to just capture pushbacks. Like, let's, let's go directly and address the elephants in the room.
Yeah, so I can take this one. So I think, you know, um, a lot of the, you know, I don't know if it's pushback, but like a lot of the people that are, you know, maybe taking other opinions and sides, which I love, uh, cause it pushes our thinking too, is that, you know, one of the things that we keep hearing is like, well, you actually can't capture the real why and like, you can, and you can only capture the how. Um, and the true, you know, intent is actually like really internal to the human. And the only thing you can actually capture is a sequence of actions and interactions. I think Lean actually uses those exact words, and they say that you can capture the how. You know, I think that some of that is, like,
in some cases, you know, that's true, but I also think that there's a way to get to like, you know, I think Unimage talks about in his blog post, but like the partial why and start to be able to reconstruct the why. And, and I think that, you know, the reason that is, is because like, you know, I think before AI agents, well, humans are making these decisions and, you know, now that agents are going to do the work, they sort of need some sort of access to that sort of memory. And then two, I think LLMs also made some of this capture more feasible. You know, pre LLMs, you kind of needed humans to maybe manually, uh, structure sort of every decision and no one wants to do that. Like, I think they sort of, it takes a lot
of work to write down why I did something. That's why sometimes like, you go through Salesforce and you look at like the, there was a bunch of text boxes about like, you know, notes and like, notes are probably always empty, is my guess.
Yeah, yeah. Someday we'll, we'll force all employees to wear a BCI device, uh, so we can read their thoughts and capture everything.
Exactly.
I will not name the company, but I have a portfolio CEO that does that. He and everyone in his team, you know, just, they have this watch thing that they wear that captures and it auto, it auto connects the data back to their calendar.
Yeah, yeah, yeah. Auto, auto transcribing, I think is, is actually honestly like a reasonable thing. Privacy has to be like worked out, but honestly, you know, it's no different than like, an employer owning all the Slack conversations and all that.
Totally, yeah.
You talk, you refer to privacy and I would say, one of the, one of the really critical things, which is both, there's some pushback, but I also think, you know, we, we acknowledge right in the original post, is going to be critical, is you've got to manage, there's data governance issues. You know, there's, there's, there's, there's
is a sensitive data that is organization specific. So in order to effectively capture these decision traces and then operationalize them in the form of context graph, there's a lot of work that companies will have to do around data governance and data management. And, you know, we have a company that's Skyflow, that Jay and I worked with, that does a lot of work in PII and sensitive data management.
Yeah.
Again, it's Skyflow.
Yeah, yeah.
Yes. So, you know, again, they're pioneering an approach to addressing this issue. There's still a lot to be figured out, but key to success in building a context graph will be data management, data security.
And then I think the, the second point that is interesting as well, related to that is, you know, a lot of people kind of like said, uh, said, hey, this is like, you know, metadata 3.0 and this is like, I forgot what someone used. It was very funny language, but I think it's like, you know, metadata, this is metadata 3.0 is like the new sparkling water of France or something. I don't know what Gen Z praise is going on.
But what was interesting, I think, about that and, you know, what a lot of people responded to it, well, hey, the same objection was raised about, you know, CRMs, about observability and about data warehouses as well. And so new categories, I think they emerge when there's a new unit of value worth, you know, storing. And I think the difference here is that decision traces are sort of captured as part of the execution path and not sort of defined upfront in all these like workshops and reconstructed after the fact via ETL. And they're more like emerging as a byproduct of agents doing work, which I think is architecturally like a little bit different than metadata layers. And I think
The second point there is like, the difference is also when and how it's sort of captured. Like, I think with um with metadata and, you know, this also goes to ontologies. I think that's like another point that's coming up is that, you know, there's a lot of like pre upfront tax of like, hey, I need to go model a bunch of stuff out with like, you know, a bunch of consultants, a bunch of stakeholders, um, and do a bunch of workshops where I think this is a little bit different.
I think that's, that all makes sense. Uh, I'm entertained to see this mentioned as data mesh again. I wonder if the data mesh discussion is, is like, um, like a bad comparison or like actually a pretty good one. Uh, because in a large enough enterprise company and this piece was very focused on enterprise, you do have silos that emerge and sometimes for a good reason. And sometimes they should not be joined.
I don't know.
So, so you're, you're on to something that Dan and I talk about a lot, which is, and you know, the last slide just references this a little bit. You know, the word data mesh can mean whatever you want it to mean. And so arguably, a context graph is one form of a data mesh. But typically, when people have talked about data meshes, they have this notion of one universal data mesh across a large enterprise.
Yes.
And we don't actually believe that that will be the case. We think context graphs, because they have to emerge from the automation of a specific set of tasks or business processes. Like, no one's going to do or can do the work to say, let me capture all the decision traces in an organization and put them in one universal context graph. Sounds a little bit like solving world hunger. And it's a good idea, but very hard to implement.
Our core thesis is these context graphs will emerge organically. And they'll emerge organically because just as, as, as processes get automated and human beings are incentivized to be humans in the loop. Because really, they are providing a lot of the training data. The why is coming from the actions that human beings take as part of a decision in an existing business process automation. And so Player Zero is doing that for the whole process of code from going into, you know, testing all the way to code in production. And there's an entire workflow. Once you generate code and they touch every part of that workflow. Similarly, Olive does the same thing for sales.
And those are just two different workflows, the business processes in a company. Like, there's no reason why companies would want to put both data sets or both context graph in one universal context graph. And mature companies or people who are selling context graphs can sell to both of these companies. But ultimately, no one's gonna, no company's gonna wake up one day and say, I want to build a universal context graph. And then if you look at some of the things that Arvind from Blean is saying, and Blean's an amazing company, and I have a lot of respect for Arvind. But it's so horizontal. Like, it's a very powerful chatbot, and it allows people to build some agentic applications or systems of agents on top of them.
But really, the deep cross-functional, cross-process automation problems are going to be solved, I think, by companies that are dedicated to solving that problem.
You know, you can call it vertical-specific and horizontal. You know, my partner, Joanne, the J and I work with, has a company called Tenor. Tenor is solving the process of automating, uh, you know, the intake process for patients in specialized healthcare situations, specialized clinics, whether it's sleep clinics, specialized testing processes. So again, they're capturing very similar workflow. It's almost like, I mean, the old world, we call it CRM for specialized healthcare clinics. But it's so much more today. And they're capturing those decision traces, and they'll build the context graph for that. And what Jen and I think about all day, every day is,
how do we, how do we identify which use cases, business processes, verticals, have, will have the deepest mopes over the next decade? We can, we can build, the way we're going to build the universal context graph is by having a hundred portfolio companies that have context graphs. And the winning ones are hopefully, hopefully the winning context graphs. Yeah.
Yeah, yeah, yeah. Okay, I think I think a very useful concept. We're we're coming up on time and I just want to make sure that we've like sort of adequately addressed or encapsulated everything that we know or like the community is excited about. There's there's a lot of like discussions and I think people are going to build out different versions of this. You know, what is what is uh do you have any predictions on what we're going to see by year end? That are falsifiable, that has a chance of being wrong, you know, like I I think that these are my ways of trying to test, have we have we sort of progressed in our understanding of what is what we need to build?
I think that's the alpha. I feel like that's the alpha. Can we give it away?
That's yeah.
It's the alpha. I don't know if we can give that away.
Okay.
I'm kidding.
You know, I would say some things are easy to, you know, there's a lot that we're talking about what's next. And so so, you know, as as Jay said, there's a lot of alpha there. But uh look, we believe that a year from now, you will actually have hundreds of context graphs in production at scale.
Yeah, you said that, yeah.
So so that's belief number one. Two, I think the the enabling infrastructure stack for context graphs will be well defined. And and there will be variations and flavors. But, you know, I totally anticipate that this time next year, we'll be writing, okay, here's here's the way, here's the best practice stack, just like once upon a time there was the modern data stack. There'll be the context graph stack and it will be ten times more important and ten times more valuable. And and lastly, I would say, you know, the debate about what is a context graph and what a decision tracer, what they why they matter will go away. And the question will be, how do we extract value from context graphs? But we're merely scratching the surface. Once you have a context graph, it's a little bit my context graph versus yours.
And and different people will do different things to extract value and drive further automation. Because automation is always a staircase. Like, the more value you can extract from the context graph, the more you can automate and the more you automate, the more the more decision traces you capture, the more, you know, you will capture in your context graph. So the best companies will be debating how to sort of accelerate that flywheel twelve months from now.
That's a good uh challenge to folks. Uh, you know, sometimes I also use these as kind of a call to action, like, you know, if if people are working on these problems, they resonate with it, they should reach out to you, obviously. But I'm sure you have a lot of people reaching out, reaching out as well.
Well, Jay and I are open for business 24/7, definitely holidays, so give us a shout.
Yeah, we're recording on a holiday for those listening later. No, thank you so much for joining and congrats on like basically creating this category. I'm excited to see what you do with it. I think it's early days still. I think we'll still be checking back on this, you know, six months, 12 months from now. And we'll hope to see like a lot more people building out what they see as context for us within their organizations. So, thank you.
Thank you so much. Take care.
Page updated October 24, 2026 · transcript and summary are machine-generated
