A large language model is just a piece of software that runs on a computer or many computers. It is a statistical model. You give it tokens. It uses the weights created by its training data to create a probability distribution for subsequent tokens, and selects which token to provide to you based on its “temperature” and other factors. Tokens are the independent variables. Tokens are the dependent variables.
LLMs feel like magic because they model text using vectors in high-dimensional space, which allows them to traffic in semantics in a way that early information systems (including earlier machine learning models) never could. What does this mean?
Context is existential: Bad independent variables create a useless regression. Bad context creates boring, incorrect or ridiculous results. Agents may call agents that call other agents, but at the start of the chain something running on a carbon rather than a silicon substrate orchestrates an initial set of independent variables. In this system, you are the unmoved mover.
Ontology matters: How do you communicate with a new member of the team? You take care to define your terms. What is the objective? What is the bar? Who is the customer or the client? You don’t want a recent graduate guessing about what you mean. Nor do you want an LLM guessing about what you mean when you provide it context. Structured input outperforms unstructured input.
Relationships define: How would you answer the question “Who is James Kaplan?” You might say: He is married to Amy and father to Adam and Matthew. He works for McKinsey. He hangs out in Greats of Craft and writes Prosaic Times and the Tech and AI Update. We define things (or people) via relationship to other things (or people). A graph captures relationships, articulates ontology and therefore provides context — at scale.
Output is input: Agentic processes are recursive. The output from one LLM call (perhaps combined with human input) serves as the input for the next LLM call. So ontology matters just as much for LLM output as LLM input.
Player Zero CEO Animesh Koratana and I discussed how to use graphs to make agentic systems effective in large complicated institutions.
A context graph, in Koratana’s telling, captures the tacit judgment models still lack — the work that happens in the gaps between systems of record, not the outcomes those systems store. We use software development as the test case: what actually counts as a system of record, whether a context graph rests on some deeper epistemological substrate, and how it raises the waterline for what judgment a machine can take on. His closing case is blunt: model the work itself, not just the trail it leaves behind.
Previous Prosaic Times interviews on context and graphs
Ashwin Gopinath and I worked through the uncertainty-principle problem with measuring organizational context in the first place.
Harrison Touati made the case that legacy code is already a map of the business, encoded in a form nobody fully reads anymore.
Philip Rathle argued for graphs, not tables, as the right primitive for anything where relationships carry the meaning.
Jaya Gupta explained what a context graph captures that a system of record never did.
An operating system for software work?
In this section:
PlayerZero is an operating system for software work, built to centralize context across the software development lifecycle.
Before founding PlayerZero, the background was model compression and inference research, including early work on the technology that came to power GitHub Copilot.
The two connected through a prior podcast appearance; this is a follow-up conversation, picking up where that one left off.
James Kaplan: Hello there. This is James Kaplan with another Prosaic Times video podcast. And I have with me Animesh Koratana, the CEO of PlayerZero. Animesh, thanks for joining. Tell us very briefly a bit about yourself.
Animesh Koratana: Thanks for having me, James. I’m excited to do part two here to get together.
James: You had me on your podcast a few months ago. We had a great time.
Animesh: This is gonna be really exciting. A lot of interesting topics to talk about here around context and knowledge graphs and all the cool things that we’re seeing out there in the AI world. My name is Animesh — for all the listeners out there — and I’m the founder and CEO of Player Zero.
We’re an operating system for software work. We do a lot of cool things around figuring out how to centralize the context around the entire software development lifecycle. That’s actually where you and I connected a few months ago. Been a lively conversation ever since.
James: Terrific. And what did you do before Player Zero?
Animesh: Before that I was in research. Specifically I was interested in model compression and inference. It was an interesting time — this is back before ChatGPT, where the biggest neural network was something in the 50 to 100 million parameter range, and we were trying to figure out how to make inference on these neural networks a lot faster. And I was first introduced to LLMs around 2019, 2020 time.
When OpenAI had just trained GPT2, and there was a variant of GPT2 called Codex [1] that later became the stuff that powered GitHub Copilot and all the autocomplete models there, and so I got to work in some very small part on some of the technology that powers inference for GPT 2, GPT 3. It was awesome.
What is a context graph?
In this section:
The term traces to a late-2025 realization: models had gained enormous expertise but no experience — the tacit, learned-by-doing knowledge that lives in the work between systems of record, not inside them.
A knowledge graph models outcomes stored in systems of record; a context graph models the work — the decisions, debates, judgment calls — that happens in the gaps between those systems.
Agent-hype gets pushback: cruise control is technically an agent too. The real question isn’t a model’s intelligence, it’s whether it’s getting the right inputs.
James: Alright, sounds great.
You and I started talking about context graphs, and I still think this is a little bit of a murky topic. I think everyone agrees context is important. Increasingly everyone — or many people — agree graphs are important. What is a context graph? Is it different from a knowledge graph? Help us understand that a bit.
Animesh: So a little bit of the etymology of the term, so to speak: it was late last year, and we were sitting down thinking about everything that unfolded over 2025. 2025 is supposed to be the year of agents — it was supposed to be the year where agents took over all of knowledge work, all white collar labor was supposed to look different. We were sitting there in December and it feels very different.
Some cool things have happened, but it clearly wasn’t everything that we expected. I think what had happened was the intelligence of these models had increased a ton, and what we’d done is we’d essentially scaled the expertise of these models — there were PhD-level intelligence that was metered on tap. And what was really clear, sitting especially in December, January, coming into this year, was that the models, while they had a lot of expertise, didn’t have experience. And experience — another word for that is institutional knowledge or tribal knowledge, the things that intuitively we as knowledge workers learn by just doing work.
I think for a long time when we thought about knowledge graphs, we thought about taking systems of record and then being able to model out the outcomes that often are stored within them. And I think the key realization that we had was that there’s actually the most interesting and insightful context that actually lives in between the systems of record. That lives in the work that happens between the nodes in a knowledge graph.
And so speaking in an abstract way here, the difference between a knowledge graph and a context graph is the work that happens.
James: So this is — let me see if I can play this back. I like to joke that for most systems of record there’s a lot of work that gets done in email, spreadsheets, word processing documents, spiral notebooks, in between one system of record and another. And you’re saying that a context graph includes at least some of that information in a structured way.
“These models are somehow getting smarter still, but I don’t know if people actually know the difference between Opus four eight and Opus five.”
— Animesh Koratana
Let me ask you this. Sometimes I worry that the discourse has become overly focused on agents — that agents are nice and agents are important, but at the end of the day, the cruise control in your car is an agent. It has a goal — it seeks a goal to keep your car at sixty-five miles per hour or seventy-five miles per hour. But what’s really interesting is the interaction with the model.
And then I wonder — is intelligence of the model the right way to think about it? Or at the end of the day are we talking about an extraordinarily good statistical model that is very good at predicting a set of outputs based on a set of inputs?
And the question becomes, to your point about context — are we giving it the right inputs?
Animesh: Exactly. And I think we’re starting to feel this in some really tactical or pithy way these days, where these models are somehow getting smarter still, but I don’t know if people actually know the difference between Opus four eight and Opus five. It still feels the same, even though the intelligence is supposedly increasing.
And I think that’s probably just an indication of the property that you just described, where context actually is an important factor in figuring out what are the right questions to ask — or in other words, what are the right inputs into these models in order to actually get some scalable, repeatable, economical, and good output.
James: Well, if you have a new joiner — a new engineer or a new business analyst on your team — you just have to say, all right, let me explain the business we’re in, let me explain the problem we’re trying to solve. Is it like that?
Animesh: Yeah, I think the way we think about this is the lineage of work. Maybe a better way to actually frame this would be thinking about what is a system of record. Historically, what has it actually been? A system of record stores the output of work — if I’ve had to really distill it down: transactions
James: Right. Transactions happened.
Animesh: happened, exactly, and the output. And the most prototypical example of this might be Salesforce.
So Salesforce stores the output of sometimes months of work between different sales reps, between SEs, the support person, support tickets — all these different things. And once all that is said and done, what we store in Salesforce is: this customer is paying us this much over this contract period, and here’s the different people. And often the most important context ends up being the work that happened before we got there.
Which is — why did we negotiate that particular price? Or why is this particular person dedicated to this particular account? These are the things that actually are operationally useful for decision making in the future when we’re talking about the renewal of the account, or expansions, or whatever it might be. And so as we’ve started trying to model — or, I think a different view, democratize — work: making it accessible not only to the new intern who joins, but also to the thousands of agents. And I agree that I think we’re overly rotated on agents, but I think that’s the thing that’s changed. There’s now this capacity for thousands of different agents to actually go and do work on your behalf. The natural question that has kind of arisen is: how do we get these agents to have the same judgment, and the same kind of insight about the why behind the decision making of the organization, as opposed to just the what — because the what is, I can go and integrate into Salesforce and all those kinds of things. And so I think that actually is the thing that mirrors this transition in the public vernacular from knowledge graphs to context graphs — there’s a slightly different nuance to what we’re really trying to model here. And what we’re really trying to model is the work. We’re trying to model the decision making in the organization, because I think that’s what we found is the most leveraged piece.
James: So let’s play with that a little bit.
And the degree of ambiguity varies greatly by business domain.
A-to-C markets often don’t have a lot of ambiguity, because if you’re dealing with millions of customers, you can’t afford ambiguity. If you’re running a credit card business — if you have this type of credit score, you get X percent interest rate, and you have that type of credit score, you get Y percent interest rate — there’s not a lot of one-off judgment involved. On the other hand, if you’re negotiating — large software contracts, hedge fund services, what have you — it’s all judgment.
Animesh: Yeah, it’s all ambiguity.
James: A fifty-million-dollar enterprise deal of some set ultimately goes to somebody senior — or a group of senior people — and it’s: yeah, we’ll go to this price and not that price. And all that information — not only is it not written down somewhere, but someone probably couldn’t even tell you what the decision rules he or she used were. How do you extract that? How do you get at that?
Animesh: There’s this whole topic these days around continual learning and improvement. Continual learning, in the most widely accepted case, is usually figuring out how to take feedback from actions that a model has taken, and figure out how to imbue that back into the weights of the model, so that it creates a better output next time that is more consistent with the rule set or the operating procedure of that business. I think what we’ve seen, especially as we now think about the ecosystem around the model — the harness and the memory and the context and the inputs and all of these other pieces — the way I think about this is: a lot of the intelligence and the context that makes a model mine — or my organization’s — ends up coming from thinking about how do we tune the ecosystem around the model, or the set of models that we have available, in order to better mirror the patterns and ways of working that we observe in an organization.
And so instead of actually thinking about an individual model and training loops within the weights of the model itself, I think we actually need to think about the agent system as a machine that produces work, and think about how we optimize that entire stack in order to actually be able to hill-climb towards some optima that mimics a particular organization’s rule set and stuff like that. Is that kind of getting at what you’re talking about?
James: Are you familiar with type 1 versus type 2 processing [2]?
Animesh: No, tell me more.
James: I hope I’m not reversing them here. Type 1 is instinctive. Someone asks you, do we go with a long deck or a short deck for this meeting — you don’t actually think about it, you just subconsciously process fifty different things and say, it’s a short deck.
Or someone asks you, how long is it gonna take to implement that feature, and just instinctively you say, this is one sprint. It’s all based on experience. And then type two processing is when you really sit down and decompose it — and we’re pretty good, I think, at least in some cases, at getting computers to do type two processing, because there’s logic then we can articulate.
But a lot of what you’re describing — the work between the work, the work between the systems of record — I’d suggest to you is type one processing. It’s people debating their instincts, in some respects. And I’m trying to figure out — one of the things I’ve been thinking about a lot is: how do we try and turn type one into type two, or articulate type one processing, so we understand our subconscious processes. So I was trying to think through how you think about that.
And let me stop talking and see what your take is.
Animesh: That’s probably the trillion-dollar question, at the end of the day. How to model type one work in type two is the bedrock of, I think, all of enterprise transformation. It is the bedrock of all automation in the enterprise. It’s a huge, huge problem, and I think it addresses all of what we see as white collar labor in the world.
I don’t think there’s actually a silver bullet for this answer, because at the end of the day, it’s a pure judgment game, and there’s compounding errors in every single direction that you look, where judgment —
“Agents are essentially your brain in a jar.”
— Animesh Koratana
James: If only there were a silver bullet.
Animesh: No — but let’s take a look at what are the tools that we have available in order to think about this problem differently today than we had a year or two ago. At the risk of sounding like I’m beating a dead horse, I think the single most useful tool that we have today that we didn’t two years ago is agents.
What do agents do? Agents are essentially your brain in a jar — and if we give them the right set of tools, they can interact with different systems of record, they can reason and take action in the world and see what the consequences of their actions are in order to actually orient and take the next best action.
So they’re embodied in the organization by just being able to interact with different systems of record.
Building a context graph for software engineering
In this section:
Using software as the test case: what actually counts as a system of record? Jira and Salesforce, yes; a Slack thread or email chain, more like a shared spiral notebook that stores context but never a resolved decision.
A support ticket’s real path — Salesforce to Jira to a GitHub PR to Datadog — covers four or five systems of record for one unit of work.
The pitch: instead of asking the one person who understands a given database every time, an agent with the context graph can infer what he’d likely say and act on it directly.
James: Well, let’s take software development as an example.
Because software is maybe the easiest use case in the fuzzy world, for a couple of reasons.
It’s a much more instrumented process than some other creative processes. We have tickets, we have requests, we have PRs, we have GitHub. We have requirements, we have use cases. And software engineers tend to be a little more explicit than other people, and we’ll have a thousand-message Slack argument over an architectural issue.
Animesh: Yeah, sure.
James: So explain to me a little bit — okay, we’ve got email threads, we’ve got Slack threads, we have Jira tickets, we have architecture documents, we have use cases and what have you. How does that get turned into a context graph, and what do you use it for?
Animesh: That’s a good question. To bring these two topics together: in the software development lifecycle, there’s a bunch of different systems of record that developers and people adjacent to the SDLC actually use. We have requirements, we have tickets,
James: We have requirements. We have tickets.
Animesh: we have Slack channels, we also have Datadog, and we have —
James: Well, Slack channel’s not a system of record, I would suggest.
Animesh: I don’t know — I think there’s decisions and outcomes that are actually kind of recorded there, usually in some sort of a —
James: Yeah, but it’s recorded. Let me challenge that a bit. I agree Jira is a system of record for software engineering. There is a ticket, the ticket was dispositioned, what have you. A messaging app or email — that’s a shared spiral notebook.
People debate stuff. No one ever says — people may say informally, we’ve agreed on this, but at no point is there a piece of structured data that says this issue has been resolved.
Animesh: Yeah. So maybe it blends the line a little bit, because it’s not storing an outcome, or some sort of central record about the organization.
James: I would argue it’s storing context.
Animesh: It is storing context. It’s often storing where the work is actually happening and the path to actually getting there. But to pull this up a level — when we think about how do we build a context graph for software development — what we think about are all of the different trajectories and lineages of work that happen in order to truly solve one problem. And one specific problem that’s particularly interesting is around support, or SRE. On one extreme, we get a ticket. That ticket might be created in Salesforce, and then we have an L1 support engineer taking a look at that ticket and saying, okay, well, this isn’t a user problem — this might actually be an engineering problem.
And they go and escalate it to L2, and now it’s a Jira ticket — and that Salesforce ticket turned into a Jira ticket somewhere with a little more context and a little more work done. And that L2 ticket is then triaged and reproduced, and then it goes to an engineer. And that Jira ticket is now moved stages. And that engineer goes and takes that Jira ticket, maybe takes some set of code changes that actually might fix that particular problem. And now it ends up as a PR that’s in GitHub, which is now a third system of record.
And ultimately that code change is deployed, and now the changes are actually being observed in Datadog, or some sort of telemetry or observability system. So, very simply, there’s four or five different systems of record that we traverse through for one unit of work.
“Instead of having to go and try a whole bunch of different things, and instead of having to go and ask the same people the same dumb question again, I’m now able to go learn from the past.”
— Animesh Koratana
James: We’ve gone from user makes a complaint all the way to code is working in production.
Animesh: Exactly. And it traversed three or four different functions, and in the process three or four different systems of record, all in order to get to one particular outcome that was useful to the business. And
James: And I would argue between each system of record you often have multiple emails, multiple Slack messages, multiple meetings, whatever, as people align on decisions in order to solution the next phase in the chain.
Animesh: Exactly. And that’s historically how we’ve worked — we get people together on war rooms, and there’s Zoom chats, and then there’s Slack and email, and all of these decisions that are made to essentially progress — move the puck forward. And I think the single most useful tool that we have available that we didn’t two years ago is now agents, where agents can actually be the things instead of humans to actually own the decision authority and the progression of that arc between these different systems of record. Now, for a second, let’s suspend
James: So —
Animesh: the belief as to whether they make the right decision or not.
James: Okay, let’s put that aside. But what is the decision that the agent makes? Does it design the solution? Does it review the solution and say it’s ready to go into production? What is, in that chain — if you have a context graph, what does the agent do that it would not have been able to do otherwise?
Animesh: So this context graph is actually a record of all of the decisions in the past that got us from one record to another. And with a context graph, this agent is able to make —
James: Right. Let me just illustrate that for a second. We required two sprints here and one sprint there. We required synchronous communication for this thing, and we’re able to go with asynchronous for this other thing. We used a relational database for this problem and a graph database for that problem. That’s it, okay.
Animesh: Exactly. Those kinds of decisions. And in the support analogy that we were just taking, the equivalent would be: whenever we get this type of problem, we go talk to James, and James tends to be the one who understands everything about this particular table schema. So whenever there’s problems with login authentication — James is the one who built this particular database, and he tends to understand the indexes, the performance of it really well. And so the next time I get a ticket like that, I am able to essentially short-circuit my thinking. Instead of having to go and try a whole bunch of different things, and instead of having to go and ask the same people the same dumb question again, I’m now able to go learn from the past — able to learn from this implicit decision making that we just observe over how we handle tickets that look like this, in order to go to you directly, or infer what you might have said about this particular category of problem, so that I could go and look in the right places to push further.
James: Okay, let me play with this a little bit. Let’s take graph database versus vector search, which is sometimes — I can imagine twenty different projects or events where various people have had debates over whether we should use vector search, or cipher, or something like that for this particular problem, or any other architectural decision. And I could imagine interrogating the email, or video transcripts, or whatever other set of communications, and decompose those into a set of claims that support or don’t support other claims.
And from that I wonder if I might be able to derive signal. Is that some of what you mean by a context graph? Because I would argue that’s some of the most important context in our decision making. Animesh argued this, James argued that, somebody else argued the other thing, and ultimately we went with Animesh’s solution for these three reasons — but if something else were true, we might have gone with a different solution.
Animesh: Yeah, absolutely. And the way to teach agents to do work and decision making in the same way that we would, they essentially have to be in the room — and when I mean in the room, I mean they need to be a part of that Slack conversation, or they need to be a part of the decision making. And what’s really interesting is this becomes a bit of a UX problem — just how do you actually create
James: A what problem? A UX problem?
Animesh: Yeah, a UX problem — which is essentially, how do we create the room where the agent can actually participate alongside all of the other humans that are necessary to make a particular decision, so that we can actually capture the right — what we call — decision trace, for how we got from one particular input to one particular decision or action on the other end. And what this context graph becomes is basically a web of a bunch of different decision traces that were observed as the agent participated in the rooms where the work was actually being done. And what we see is over time these agents
James: And yes.
Animesh: can actually start inheriting more and more of that.
James: And is it fair to say a decision trace might be a claim or a fact? You have a hypothesis which supports another, which supports another hypothesis, which is grounded in a fact — or not grounded in a fact.
Animesh: Yeah, it’s actually a chain of hypotheses — a chain of a bunch of these different things.
James: Yeah, well, that’s okay. And then hopefully someplace you hit a fact. One hopes.
Animesh: Yeah, exactly. A fact is in another record — the facts are essentially ultimately stored in some system of record.
James: Yeah, yeah, yeah. A fact is a proven hypothesis, right — or a proven claim, within certain limitations, or within a certain scope. So creating the structure is a challenge. Surfacing the structure, or deriving insight from the structure, is a challenge.
The other thing is populating the structure is a challenge. I’m curious about this a little bit. As you’d expect, I get into — not arguments, but debates — with people all the time. And sometimes they’ll say things like, yeah, that’ll totally work. How good do you think the models are at interpreting the ironic, imperfect, sometimes highly colloquial language that people use as they debate things.
Animesh: That’s a good question.
I think there’s a simple answer and a more complicated answer. The simple answer is I think LLMs have proven to be pretty good at reading between the lines and operating in ambiguity.
James: Perhaps better than humans are, because half the time people — sometimes I’ll use sarcasm and people will totally not get it.
Animesh: No, for sure. And I think the other part of this is — maybe the bigger question you might be getting at is this framework that I think you and I talked about one or two conversations ago, which is: is the context graph, in contrast to a knowledge graph or a system of record, a kind of high-entropy, high-dimensional sort of thing, or is it — is the job of a context graph to essentially reduce entropy down to something that is very specific and understandable — a fact? Where, in the spectrum, does a context graph actually live?
I think that’s actually maybe the bigger question you’re getting at within this, which is: there’s a lot of nuance, obviously, in what a decision trace actually represents, and how does it actually get represented — is it a series of facts? Is it a high-dimensional thing? Or is it ultimately a system of record — a very structured, ontology-esque store? My answer for this, and I think this is an open debate, is that right now it’s highly dependent on the category of work. And more importantly, I think the consequences of bad outcomes in that work. A good example of this, again, is software — where the consequences of bad work is I have to roll back, or fix a bug, and I have a lot of support volume — in a large majority of software. Now, there’s a different set of software organizations where they’re handling payments, or they’re handling EHR records, and there the consequences of bad software are way worse — regulatory problems.
James: And then think about embedded software in, say, the control panel for a nuclear reactor or a submarine or something like that.
Animesh: Yeah, exactly. And there’s grades of this. And I think if you look at the way organizations work in each of these different consequences, their process and their speed are largely vastly different. A nuclear reactor’s software is probably not being deployed eight times a day, but a consumer app that’s helping you order your food might be deployed fifty times a day. So there’s two kinds of extremes here, and the processes and the way people work have actually been adapted for it. And so, to a large degree, I think the way these context graphs need to evolve is actually very domain-specific. And I think the commercial opportunity here is: how do we take intelligence and pair it with context and a representation of the world that is specific to each one of the organizations that this intelligence is actually being deployed into. And I think that’s actually where the problem of how to make agents productive in the enterprise is going to be solved.
James: Let me not entirely, but partially, challenge that. Maybe not — I’m not sure.
Animesh: Please.
The epistemology underneath the graph
In this section:
Does a context graph rest on some underlying logic — classical, inductive, Bayesian — or is that the wrong question entirely?
A context graph as world model raises a further question: does it compile down to fixed primitives, or live as something more continuous, like an embedding space?
Landing point: gut-driven judgment is itself a world model humans can’t fully articulate — the same way a language model’s internal representations encode patterns nobody explicitly designed in.
James: Is it possible that a context graph rests on an epistemological substrate? We could have classical logic — statement, implication — but there’s other epistemological substrates.
We could rest it on inductive logic. We could rest it on Bayesian logic — if you go to anyone who runs money at a hedge fund, everything is Bayesian logic. Are there — I understand there’s different domain-specific things, but is there some sort of epistemological substrate, or set of assumptions, that would sit at the bottom of a context graph — some view about what reality is and how you think about reality.
I’ve broken the podcast here.
Animesh: I gotta think about this — let me think out loud here for a second.
A context graph, in its truest form, is a world model. It is a model of —
James: I would argue any system is a model. A general ledger is a model of a set of financial transactions. A CRM is a model of a set of customer relationships. Any system is an imperfect model of the world. And so a context graph is a more nuanced model of the world than, for example, a traditional customer relationship management system.
Animesh: Yeah, so the question here is: is that world model compiled down to specific primitives, or specific types of relationships that we think are general enough to represent all of this particular domain.
James: And what are the primitives? With a large language model, you could argue the primitive is language.
I don’t know if there’s some primitive someplace in the stack that’s logic. And for a physics model, you’d argue the primitive is ultimately, I suppose, a set of physical laws.
Animesh: Physics. Yeah.
So, just so I understand this framework fully — how do you think about embedding spaces? Is there
James: What?
Animesh: an embedding space — or some sort of vector space?
James: Here’s how I think about embedding. It is just a way of managing entropy — which is to say, Python is a formal language. It can mean only one thing. I’m sure that’s not a hundred percent true, but I bet it’s ninety-nine and a half percent true.
English is the opposite — it can mean just about anything, but it can mean many things. Any given sentence could mean several things, and you could say any given thing multiple ways. Let’s say Esperanto is somewhere in the middle.
And embedding, to me, is a way of capturing the fact that natural language is indeterminate. It allows us to say a desk is proximate to a table, is proximate to a work surface, even though the letters are very different from one another. It’s allowing us to say that —
Animesh: It allows us to compare discrete things in a continuous space.
James: Yes — that, it’s, in effect, applying numerical values to semantics.
Animesh: But to your question — is an embedding space underpinned by some set of laws or primitives that govern the entire embedding space? Or is it just an embedding space?
James: I don’t know. What do you think?
“These models have somehow internally derived certain laws of the universe, or laws of language and cognition, that we haven’t fully been able to rederive, but these models are fully exercising.”
— Animesh Koratana
That’s an interesting question — you could argue, is there some — I mean, we’re truly probably getting far afield from software development processes, but is there some conceptual model that underpins language? One of my personal hypotheses is: my god, we’re gonna learn a lot more about linguistics over the next decade as a result of large language models than anyone ever thought about.
Animesh: Yeah, so I think yes — there is some physics that governs it, and I’m using the physics word as a broader term here, but
James: Yeah. Maybe neurology, or neuroscience, is a better term than physics.
Animesh: There’s something that I think governs embedding spaces, and more broadly the representation spaces in these models. I think it is
James: Mm-hmm. So you could argue how much of it is culture versus how much of it is neuroscience, because different languages have different numbers of words for any given concept. There’s some languages that have a zillion words for one thing and few words for another thing, and a language that evolved in a different culture, in a different place, might have the reverse be true. Please continue.
Animesh: No, exactly. And so the answer is, I think, that there is a worldview — it is just far more nuanced than our minds can comprehend, or than our minds really can or need to model. And this is actually where the whole field of interpretability research, I think, really comes from — these models have somehow internally derived certain laws of the universe, or laws of language and cognition, that we haven’t fully been able to rederive, but these models are fully exercising.
And I think there’s an equivalent for that in the way that we work — it’s highly nuanced, it’s why great salespeople are paid so much — because they have this highly nuanced view of the world, and view of their customer, and view of the problem and the market, and they’re able to navigate all these things in a problem-dependent, time-sensitive sort of way.
James: And let me push on that a little bit, or add to that point: they’re doing an optimization problem in their head with a zillion variables, all of which are continuous, all of which are interconnected, and many of which are latent. And if you ask them how they do it, they’d look at you blankly.
Animesh: Exactly. It’s a model that lives in their head somewhere.
James: Right? We made X, not Y. We have this meeting, not that meeting. Why do we have it? Because we do.
Animesh: Yep, exactly. It’s often led by gut. And I think the ones that are even better are the ones who can explain a little bit of it, but regardless, there’s a lot of —
James: Even great software engineers are like that too. When I used to code thirty years ago, I’d sometimes head in a direction — I have no idea. Not that I was a great software engineer, I was a mediocre one. But why do you head in this direction? I’m not sure, but I’m pretty sure I’m right.
I think many architects start to investigate a direction not entirely knowing why they’re investigating it.
Animesh: Yeah, a hundred percent. And so, bringing it to the context piece here — at the end of the day, there is some world model that’s underpinning people’s intuition, or gut. And I think the world of context is actually a way of trying to create some sort of learning machine, or learning layer, that essentially connects to a model and gives it this sort of experience or intuition about how to operate and do work in the organization — to give it that same level of intuition that a human might accrue over doing that work over a long period of time.
James: I wonder if there’s two models. There’s a human model, which a large language model is an incredibly simplistic exposition of, and then there’s a physics world model. And I suppose there’s certain people who would say that ultimately neuroscience is physics, so therefore your human world model should derive from your physics world model. I’m not smart enough to fully understand that, but there is some part of me that thinks that’s at least a distinction between things that are cultural, psychological, and intellectual versus things that are mechanical and physical. Does that make sense at all?
Animesh: I think so, yeah.
From judgment to a rising waterline
In this section:
Coding agents have already pushed the UX from line-by-line autocomplete to “express your intent” — the next shift is expressing the business outcome, not just the code.
Any decision can be called judgment, but a context graph raises the “waterline” — pulling enough signal from how a team handled similar cases before to turn instinct into a heuristic an agent can use.
Landing analogy: an agent with the context graph is like the intern on a trading desk who’s watched the trader long enough to know why she zigs one way and not another.
James: Alright, so take this back to software engineering. What does this mean? How do we use any of this to write better software?
Animesh: So I think the software paradigm, and the software work, is a very interesting moment. A lot of folks are in this moment where they’re six, eight, twelve months into starting to use coding agents.
And the amount of code that we’re able to write has clearly increased by one, maybe two orders of magnitude.
“How do I know any of that is good? We’re producing a whole lot of new software.”
— Animesh Koratana
James: Though I will say I hope for a coding large language model which is trained on the tiny fraction of code that’s any good, as opposed to —
Animesh: Yeah. I think you’re actually getting at the bigger problem, which is: how do I know any of that is good? We’re producing a whole lot of new software.
James: Yeah — and that gets — well, to me that’s a bit more mechanical than contextual, which is: okay, we know that hard-coding things is bad, and we can hopefully create hooks around that. That’s a very different issue from — okay, when do we design a user workflow that’s sequential versus parallel? Because sometimes it does have to be sequential, and sometimes you can make it parallel. That’s not “don’t hard-code things” — that is entirely context-dependent.
Animesh: No, exactly. And so I think the opportunity ahead with context layers broadly is basically leveling up the conversation that we have with agents. Instead of being, hey, can you go and write this line of code — task delegation — you can actually start thinking about what the business outcome is that we actually want to drive towards, and what we want to optimize our stack of agents towards being able to produce. And good here is measured by the outcome, as opposed to lines produced, in the unit economics, and all these other dimensions that we’re starting to understand matter a lot more.
James: What is the line between what the agent does and what the human does? Human creates the spec, human defines the outcome. What does the human do, and
Animesh: What?
James: what does the agent do — to your thinking? Think two years in the future, not today.
Animesh: I think where the world is headed right now is that the human needs to be brought in for any moments of judgment, and everything else needs to essentially be compiled away. If we think about what’s happened with coding agents already — coding agents aren’t asking us for every fifth or tenth line that they’re writing. The UX shifted from autocomplete to “express your intent, and then I’ll go and execute a couple of turns,” and then execute on that intent on your behalf. And I think now we need to level that up one more time — which is: what is the business outcome that we’re ultimately trying to express? What is the operating procedure? What is our way of working? And being able to express that, and then essentially having agents be able to repeatedly do that in a way that actually creates the operational efficiency that we were looking for in the enterprise.
James: Let me see if I can pull a couple of things together. Tell me if you agree with this.
We can frame anything as judgment — or many, many things as judgment. I write a line of code this way or that way. Judgment.
What type of loop do I use? What type of loop construct do I use?
Animesh: Yeah. It’s like the threshold for what its leverage on the rest of the organization is — I think that threshold is increasing.
James: Let me push on this slightly. A context graph increases the waterline for what judgment we can engage in programmatically. There are a million decisions that might have been “do it this way” based on instinct — but if we can pull more signal out of history — the reason we did it in these twenty circumstances one way and those twenty circumstances another way — we’ve now derived some sort of heuristic that we can give to an agent, as opposed to going and asking Animesh what we’re doing.
And you could argue that’s not dissimilar from the intern sitting on a trading desk, watching the trader — he or she did it this way when this happened, and did it that way when that happened. Alright — closing thoughts.
Animesh: Exactly. You nailed it. It increases the watermark of where judgment is.
James: For people using context graphs in a technology environment, or in a software engineering environment —
Animesh: Can you repeat the question? I think you broke out there for a second. What advice?
Closing advice
In this section:
The biggest insight: think about the work that happens between the creation of a task and its outcome — not just retrieval across existing systems of record.
The bet is a continuous, representation-based approach over a prescribed ontology — though domains like trading, healthcare, and finance may need the opposite, where explainability is non-negotiable.
Work rarely gets solved by one person alone; capturing decision traces means being honest that most real outcomes span multiple people, not a single line of code.
James: What advice do you have as people think about getting value from context graphs?
Animesh: I think the biggest insight that helped us was basically thinking about what is truly the work that happens between the creation of the work and the outcome, between all of the different systems of record.
James: And how do you create the ontology around that work — I’d suggest, to your point about domain specificity?
Animesh: Yeah, I would also — I think the answer ultimately comes down to: what are the mechanisms that we have for the agents to learn from the work that they’re actually doing, so that watermark over time rises. For us, the answer ultimately was actually taking a more continuous, representation-based approach, as opposed to a prescribed-ontology sort of approach.
James: Interesting.
Animesh: But I think there are plenty of other domains — trading, healthcare, finance — where continuous, nuanced, unexplainable representations actually aren’t good enough, and we need —
“It’s not ‘write this line of code,’ it’s ‘solve this problem for my customer.’”
— Animesh Koratana
James: Okay, for a follow-up discussion, we’re gonna talk about two topics. I want to hear more about continuous representations, and then I want to have a discussion around whether more of knowledge work begins to look more like software engineering.
Animesh: I think yes. I think a lot of it will start collapsing in. But that is a much, much longer topic.
The advice I’d have here is: just think about the work. A lot of people think about it as a retrieval problem for agents to be able to interoperate between systems of record. You really have to think about how you model the work — and if you do that really well, you actually start capturing signal that helps you inform these decision traces that kick-start this flywheel. That’s probably the biggest insight. And second: often work doesn’t span only a single person — it spans multiple people. And so being honest with ourselves about what that work actually looks like in order to get to the outcome. It’s not “write this line of code,” it’s “solve this problem for my customer.” And that latter outcome often ends up becoming much more complex, but also has much higher opportunity, in my eyes.
James: In part because people have different mental models for thinking about work. Alright — thank you very much.
Animesh: Exactly. And that’s why we have different teams.
Thank you so much for having me, James. This is a lot of fun.
{A system of record tells you what happened. A context graph tries to preserve why it happened: the relationships, arguments, precedents and judgment that moved the organization from one state to another. That matters because in an agentic system, output becomes input recursively; every ambiguity or lost distinction can propagate downstream. The promise of a context graph is therefore not that it eliminates judgment, but that it raises the waterline for how much judgment a machine can exercise without asking a human to reconstruct the past. — Ed.}
Footnotes
[1]: OpenAI’s original Codex, released in 2021, was a version of GPT-3 fine-tuned on code — not a variant of GPT-2, per OpenAI’s own paper introducing it. Koratana’s spoken timeline compresses two separate model generations; the substance of the claim (Codex → early GitHub Copilot) holds regardless.
[2]: The “type 1 / type 2” terminology here tracks Keith Stanovich and Jonathan Evans’s dual-process framing more precisely than it does Daniel Kahneman’s better-known “System 1 / System 2” from Thinking, Fast and Slow (2011) — both describe the same basic split between fast, intuitive judgment and slow, deliberate reasoning.
