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.

That suspicion assumes models are all roughly alike — that the interesting variation happens around them, not inside them. Liquid AI’s research program bets the other way: not on scaling, but on what a neuron and a synapse actually do.

Liquid AI is a foundation model company, building a diverse portfolio that includes small, efficient models built to run locally, on a phone or a Raspberry Pi or inside a car, especially where network latency and bandwidth make backhaul to cloud impractical. They also train models on data that isn’t language at all — protein sequences, for example.

Liquid AI’s research started with a one-millimeter-long worm called C. elegans. It runs its entire nervous system on three hundred and two neurons [3] and still manages to forage and navigate a complicated world. Lechner’s team asked what those neurons and synapses were doing differently, and built liquid time-constant networks [4] — architectures where the connection between two neurons isn’t a fixed, linear weight but something that varies over time, the way a real synapse does.

The conversation opens with what Liquid actually ships, and the real trade-off between large and small models — not the trade-off people assume. Small models are mostly invisible, Lechner says — they run quietly in the background of products you already use. Maybe that’s why I haven’t thought much about small models?

From there we get into the liquid time-constant network itself, and then into memory — why a language model still needs something like a transformer’s perfect, growing memory even when a liquid architecture does more with less everywhere else. The KV cache discussion explains why memory, not compute, is the real constraint on model architecture.

Lechner also has a read on what separates enterprise leaders who are getting value from AI from those who aren’t: the ones who succeed understand they’re investing in a moving target, not a finished product. The conversation closes on whether we can build biology up from physics, or whether some phenomena only exist at a higher level of abstraction. Maybe that matters for how we model the world?

What Liquid AI Builds

In this section:

• Liquid AI is a foundation model company whose research began with C. elegans, a worm that runs its entire nervous system on 302 neurons.

• Foundation models are pre-trained by a company like Liquid AI, then customized by the customer through fine-tuning or prompting; large language models are only one type.

• Liquid AI builds a diverse portfolio, including large language models scaled down for edge deployment — able to run on a Raspberry Pi — and non-language models like protein-sequence generators.

James Kaplan: All right. Hi, it’s James Kaplan here with another Prosaic Times podcast. It’s a gorgeous day in New York, and I’m here with Mathias Lechner, the CTO of Liquid AI. Do you wanna introduce yourself and tell us a little about your journey and how you came to Liquid AI? And then we’ll get into it.

Mathias Lechner: Thanks for having me, James. My name is Mathias. I’m CTO and co-founder of Liquid AI. I come from a research background — our research was about looking into neuroscience and seeing where there are advantages if you bring some of these models into machine learning. It’s been a journey from research to now, at Liquid AI, the company.

James: What does Liquid AI do?

Mathias: We are a foundation model company. In machine learning, the classical approach was: you collect your dataset, you train a model from scratch on that data, and then deploy it. That’s changed a lot in the last ten years with foundation modeling, where somebody — some entity, in our case Liquid AI — pre-trains a model on a much larger set of data, crawled from the web, all types of images, text, and so on.

Then the customer fine-tunes this model for their use case, or customizes it in some way. Even prompting ChatGPT is still using a foundation model that’s not fine-tuned — it’s just prompted; there’s a conditioning layer there. So instead of training from scratch, foundation model means somebody else pre-trains it, and the customer customizes it either with fine-tuning or prompting.

James: But it’s not a large language model. What type of model is it?

Mathias: Exactly — the term foundation model is agnostic to any type of model. Large language models are just one type of foundation model. It could be image —

James: But the type of models you build — what type of models does Liquid AI build?

Mathias: We build a diverse set of models. Our most prominent ones are large language models, but at small scale, for edge deployment. We can run a large language model on a Raspberry Pi at around forty tokens per second [5] — that’s roughly what you get from some of the ChatGPT models. We can run a smaller, more efficient version on a Raspberry Pi, which enables a lot of edge use cases. We also train models not just on text — for instance, we have protein models. Think of a generative model, like an image-generation model that you prompt, but instead of an image it generates a protein sequence.

Large vs. Small Model Trade-offs

In this section:

• Large general-purpose models still win for productivity workflows like coding; small, specialized models win where sub-100-millisecond latency or limited bandwidth make cloud calls impractical.

• Small models are mostly invisible to users — they run quietly inside voice assistants and other embedded products rather than being something people deliberately choose.

• Enterprise adoption is uneven, with some companies fully AI-native and others just touching a few models; small-model use is driven as much by capability and bandwidth constraints as by token cost.

James: How do you guys think about the trade-offs between large language models versus small language models? How should people think about the trade-offs between a large general-purpose model and a more specialized model?

Mathias: That’s a good question. There’s always use cases for both. There are productivity workflows where you just want the best model out there — when we code, for instance, we want the latest model from Anthropic or OpenAI, irrespective of size. And then there are use cases — say, certain cloud e-commerce companies or automotive companies — that have latency requirements. End-to-end request-to-response needs to happen within about 100 milliseconds before the user experience degrades. You can’t run that with a large language model. You need a specialized small model for that.

James: You want it to be small. In many cases you want it to be local, so you don’t have to deal with network latency, correct?

Mathias: Exactly. We have an e-commerce company we deploy with where our portion of processing the request is tiny compared to the network latency. That’s very interesting.

James: And the large-language-model-versus-small-language-model debate — some people might be surprised that we haven’t seen more small language models evolve. If I think back a year or eighteen months, there was more assumption that we’d see more specialized models, and that hasn’t, at least in my experience, been the case.

So a couple of questions: are you surprised by that? Why do you think that’s happened? And how might that change in the future?

Mathias: That’s an interesting observation. Part of it is that a lot of these small or specialized models are actually running in the background, so people aren’t used to noticing them. When you have a voice assistant on your laptop — that’s a local model, and you don’t really notice it. Same with other companies we work with — a lot of that is hidden use cases: assistants, intelligence, getting deployed on all of these devices. It’s not that you go to a website or ask a certain tool — it’s more that it’s happening in the background, in hidden use cases.

James: Got it. Do you think people in the enterprise are using smaller models as thoroughly as they should? How do you see this evolving? There’s one world where most enterprises, broadly speaking, use large general-purpose models, and product companies use smaller language models for specific use cases — voice, whatever’s built into a product.

Do you think that bifurcation continues, or do you think enterprises will start using more smaller language models? How do you see things evolving?

Mathias: Looking at the customers and engagements we have, we see both gaining traction — companies adopting more of the large models, but also more of the small models rolling out.

In the three years since starting the company, I’ve observed a vast difference out there on adoption. There are some companies — I’d call them older companies — that are completely AI native, that have flipped their entire workflow upside down. And there are companies you’d assume are heavily using AI but are just getting started.

They’re just touching a few models here and there, which is quite interesting — the diversity I’ve seen in terms of AI adoption.

James: How does this intersect with concerns about token costs? Everybody in this category is now talking about token costs in the enterprise. Sometimes I think that’s a little early, because most places — even very large companies — are spending single digits of millions of dollars on tokens at this point. [6]

So I don’t think it’s a crisis yet, or will become one shortly, but certainly token costs have gotten people’s attention. Do you think small specialized models running locally, in conjunction with larger models running remotely, will be part of the answer for managing token costs?

Mathias: Yes, I’d say so. But it’s not only about cost — it’s also about capabilities.

We have some prototype applications with our own models — imagine an agent, a voice assistant, running twenty-four-seven on your — on your computer, that then communicates with the cloud models, the large language models, to send or pull certain results, to orchestrate together. We see much more orchestration of agents, and small agents will be part of that equation — because, as you said, token cost is one factor, but also just being able to run without transmitting everything to the cloud.

James: And latency, obviously, is a big issue, right? You’re saying it’s functionality as well as latency. Can you give an example? When you say functionality or capability, do you mean some combination of reducing hallucination, more precision, more relevance?

Can you give an example — in a use case, how does that play out, and technically speaking, why does that tend to be the case?

What’s the better answer you get, and why, if you’re using a specialized small language model as opposed to a general-purpose large language model? Do you get a better answer?

Mathias: I’d say it’s everything — token cost, infrastructure cost. Some companies want to deploy multimodal models — audio and voice — on their devices, and the bandwidth to transmit those to the cloud is prohibitive. It’s actually less about the token cost.

The token cost is another story, but it’s also about the connection — the bandwidth of, for instance, video, which is quite expensive. So there are advantages to running locally, and the token cost is part of the combination.

That’s why this agent is running twenty-four-seven, basically, on your laptop. We see more and more of those applications coming, where you need to be local — not just because of token cost, but connectivity and other factors.

The Liquid Time-Constant Network

In this section:

• Liquid AI’s research started with C. elegans, whose nervous system runs on 302 neurons and roughly 8,000 synapses yet still supports foraging and social behavior.

• The key difference from artificial neural networks isn’t the neuron — it’s the synapse: biological connections vary in neurotransmitter type, latency, and saturation, rather than acting as a fixed linear weight.

• Liquid time-constant networks bring that variability into machine learning, making a neuron’s time constant liquid rather than fixed, for more expressivity without more size.

James: Tell us what a liquid time-constant network is, or a model built using a liquid time-constant neural network. Tell us about the innovation and the benefit of it.

Mathias: Our research started, as I mentioned, from neuroscience — there’s a worm called C. elegans, about one millimeter long, with three hundred and two neurons. Every worm has almost the same nervous system, wired the same way, and yet it can forage for food and show social behavior. [7] That’s remarkable for a nervous system with only three hundred and two neurons and about eight thousand synapses, compared to artificial neural networks, which have thousands of neurons and do far simpler tasks.

When we studied how the worm’s nervous system handles these interactions, we found the neurons themselves are similar to the ones in artificial networks. What’s different is the connection between two neurons. In the worm, the synapse has different neurotransmitter types, latency, delay, and saturation — both at the neuron level and the synapse level. In an artificial neural network, a synapse is just a single connection: a linear, proportional element.

We brought that difference into machine learning as liquid time-constant networks. The idea is that the time constant — how a neuron behaves — isn’t fixed. It’s liquid. It varies over time, and the connection between two neurons isn’t statically wired. It has more complexity, more expressivity, in how two neurons communicate.

James: So — I’m going to oversimplify massively here — what you’ve said is that the size and density of the neural network isn’t always correlated with the level of capability provided. That’s the point of your neurological analysis with worms, I guess. And the implication is that there’s a certain level of capability you can achieve without the processing overhead of other types of models.

Is that correct?

Mathias: Yes, at least at a high level, that’s correct.

James: Not bad. I was a history major.

Mathias: Yes.

Memory, Context, and the KV Cache

In this section:

• Liquid networks excel where context is small and time-bound, as in robotics, where only recent state matters and old, irrelevant history can be filtered out.

• Language modeling is different: it still needs a transformer’s growing, perfect-memory KV cache, because some information must always be exactly retrievable rather than filtered.

• Liquid AI’s own language models pair that transformer memory with a short-term, convolution-based liquid component, letting attention specialize on the longer horizon and easing KV cache pressure.

James: How does this relate to memory and context window? As I’ve thought about model performance — let me back up. My long history in enterprise technology is: it’s never the compute, it’s always the memory.

That’s the bandwidth. And if you look at the history of large-model evolution — the GPU evolution — compute exceeds memory bandwidth, right?

Mathias: Yes.

James: And as a result, people who build these things have to use aggressively lossy compression around context windows, because you can only access so much context, and that’s where hallucination and imprecision come from. The question for you is: what’s the intersection between the type of models you build and the scale of the context window?

Can you use a bigger context window versus a smaller one? How do you think about context and what that means for model fidelity or precision? Does that make sense?

Mathias: To go back a bit — we started this research on liquid time-constant networks mostly looking at a robotics problem, because in a way it’s a biological robot. There, we observed really nice behavior, because there’s a temporal component — you need to remember, you need to filter out disturbances, but you don’t need to remember what action the robot took twenty minutes ago. So the context window, in a sense, is precious but typically very small. You need something time-bound.

James: What happens fifty milliseconds ago matters a lot more than what happened fifty years ago.

Mathias: Exactly. That’s the robotics case, and it’s exactly where the liquid time-constant network helps a lot. In language modeling we have a different problem. There we really need the transformer architecture — multi-head attention — because certain things need to always be perfectly remembered.

Instead of a fixed memory system, the transformer’s memory grows with each additional token. That’s a massive disadvantage for scalability — it becomes quadratic in compute, linear in memory size — but it has the advantage of perfect memory: it can always go back and look exactly at what happened.

When we tried applying our liquid networks to language modeling, we found we always need some of that component — the transformer’s growing KV cache — so the model always perfectly remembers what happened in the past. That’s always necessary, at least in language, but it can be enhanced with a short-term, liquid, gated component running alongside it.

James: And your KV cache has constraints, right? You can’t have an infinitely large KV cache, correct?

Mathias: Exactly. That becomes prohibitive for several reasons. But at least with the short-term interactions in our own model — the LFMs, the liquid foundation models we’ve published — our language models have an additional short-term time component in the form of convolutions. That lets the attention layers specialize more on the longer horizon, which again helps a bit with KV cache compression.

James: Mm-hmm. Good. What does this mean as we move from language models to world models? I’ll admit — having thought a lot about language, I sort of understand language models, or think I do. But world models are based on physics, fundamentally different, with a different set of dynamics.

How does that change the architectural trade-offs? How does it change the experience? How does it change the decisions between a large model and a small model?

Mathias: That’s a good question. In terms of world modeling, what we’ve observed that really benefits is cross-modality world models. If you train only a video model, a video-generation model, it’s quite tricky — if you have the scale, it will work. But for us, the most interesting component — that’s why we’re refocusing mostly on this part — is the cross-modality aspect.

Imagine you have a text input and generate audio for it, or the other way around — a video input, and how does the world then look in text space. This cross-modality, bridging the gap between modalities, is for us much more interesting than a world model that just predicts the next frame from previous frames. That’s where I think most of our own research is going.

Advice for Enterprise Technology Leaders

In this section:

• The enterprise leaders getting the most value understand model capability is a moving target, not a finished product — treating today’s model as the end state is the mistake that leaves companies behind.

• Lechner expects multimodality — audio, video, and image in and out — to become inherent to models rather than a special-case feature, paired with new NPU-equipped hardware from Qualcomm, Intel, and AMD.

• Liquid AI’s own research is shifting toward cross-modality — translating between text, audio, and video — over single-modality world models that just predict the next video frame.

James: Imagine you’re the CIO or CTO of an enterprise — not a technology company, but a bank, a pharma company, an insurance company, a consumer packaged goods company, a manufacturing company. What do you think people need to know more of, in terms of model choice? What do you think people get or understand, and what do you think they don’t?

Mathias: What very few people understand — but the ones who do, I have deep respect for — is that we don’t live in a static world. Model capabilities aren’t static. When we approach some of our customers or partners, some of them think of it in a static world.

This is the final product, the final model, nothing comes afterwards — this is it, the end of the game. And then there are others who really see, hey, this is just the current point in the evolution. It keeps going further —

with better data, better training algorithms, better hardware that’s available and feeds more data through the process — all working together, algorithmically, hardware, modeling, data, to improve the model. It’s interesting to talk with people who think about it very statically, versus enterprise leaders who really understand that the model is going up, and there’s enough evidence this will continue for at least the next couple of years.

James: What, how will the landscape be different two years from now? What predictions would you make about the mix of models people will use, and how they’ll use them?

Mathias: I can only speak with confidence about our own model-development roadmap. Even if you freeze compute and everything else, capabilities will keep increasing — better data, better algorithms, more research into different ways to model these components. One thing happening on the small-local-versus-large-model side is multimodality becoming an inherent part of it — audio, video input, the way we think of text right now — that’s just standard, it’s always supported. Same with output.

If your model speaks back to you, writes back to you, or sends back an image, that will be indiscriminate — there won’t be a difference in it being a special case triggering a special function; it will just be inherent within the model. And if you combine that with advancements in hardware — the new chip manufacturers, Qualcomm, Intel, AMD and so on, all shipping new chips with NPUs, neural processing units, packing a lot of flops at very low precision — and building models to leverage that, the combination of better hardware and better models will definitely lead us to more capable models. Where a cloud model was a year ago, we’ll have locally maybe next year.

James: Terrific. What did I neglect to ask about? What else should people know, or what else would you like to talk about before we wrap up?

Mathias: One area I’m most excited about is how it connects the large-language-model, multimodal domain with other data modalities. We’ve talked about text, audio, and vision. But there are many more modalities out there — time series, biological signals.

As I mentioned, we’re training protein models. I think that becomes very interesting — do you model this by mapping it into text, which seems to be what a lot of big companies are currently doing? They map every modality to text, process it with a large language model, and map it back. Or will there be something smarter out there that already models the data itself?

James: Let me ask this: some scientists say everything is physics — ultimately physics is the substrate, and I guess the math is under the physics. But if you build a world model that’s physics-based, does that imply everything else goes on top of that? Does that make sense at all?

That chemistry is physics, biology is physics, and so on.

Mathias: Yes and no. If you model —

James: I realize that’s something physicists say, which other people may not agree with, but —

Mathias: Yes — a lot of physicists say everything is —

James: They say that, right? They say everything is physics, correct?

Mathias: Physics, yeah. In some sense that’s correct. If you model everything with — if you train a world model with some quantum interactions, whatever — sure, it will work in a way. But the problem is the interesting interactions actually happen at a much higher abstraction scale. Even biology, I would argue, is very bit detached from physics in a way — how the immune system responds to certain things. It’s connected to physics and molecular chemistry, obviously, but it’s already so much detached that if you model it —

James: You could argue there are only two types of things in the world: physics and semantics. There’s language, video, and so on, which are sort of human-constructed artifacts. At some level you could argue the English language doesn’t describe physical reality — it’s not grounded in physical reality. And then you have everything else, which is physics. But as I said, that’s something physicists say.

Mathias: Yes —

James: And then, math describes them both, I suppose.

Mathias: Yes, in some way. And I think that’s totally fine, totally valid. But the question is whether it’s the right abstraction level to think about. If you model it with an ML model, isn’t it better to go one abstraction level higher — talk about chemical interactions, biological interactions, social stuff? At the moment, words have basically emerged as the standard unit — but you could also model language at the character level instead of words, and those aren’t that great.

James: Yeah.

Mathias: They really struggle. So again, character-level is too low-level — for some reason, at that resolution, it doesn’t work as well. Maybe in the future they’ll come, but at the moment character-level large language models aren’t at the same scale as word-level. Again, it’s about the abstraction level at which you model them.

James: I think your point about abstraction is a good one — tell me if I’m being naive. Inorganic chemistry isn’t that far abstracted from physics. But once you get to biology, you’re pretty separate from the underlying physics, and that would be hard.

We may not be able to draw a straight line from the underlying physics to the biological interaction, so we need to model biology separately, independently, rather than building it up from the physics. Does that make any sense?

Mathias: Exactly. At least I have a belief this might be the case, based on this tokens-versus-words-versus-character-levels point.

James: Mm-hmm.

Mathias: But again, there’s some dynamics — so much has changed, there’s a new approach coming out there. Maybe if you have enough data, this abstraction will emerge within the model. But yeah, that’s interesting, curious to watch what happens in machine learning going forward.

Physics, Language, and Epistemology

In this section:

• Lechner is skeptical that intelligence can be built up cleanly from physics: biology, like language modeling itself, seems to work better at a higher level of abstraction than the most granular one.

• The word-versus-character-level modeling gap is offered as evidence — character-level language models consistently underperform word-level ones, suggesting the right abstraction level matters more than raw resolution.

• James closes by proposing generative AI as a form of “entropy transformation,” a way to learn from the world’s raw entropy that deterministic systems never could — an idea Lechner doesn’t take a position on.

James: There is part of me that wonders if we as a civilization have fully grasped the epistemological change in front of us — that we can model things we never imagined we’d be able to model before. Things that were just too entropic to model, we can now model.

Is that too broad a statement, or do you think that’s a generally correct statement?

Mathias: I think it depends. There’s a lot of people who —

James: Don’t go out on a limb there.

Mathias: — yeah.

James: Depends on what? Talk to me.

Mathias: I think there’s some people who predicted this — that artificial intelligence emerges, whether it was through large language models or different paradigms, is more the nuance, the technical detail, that’s not relevant for them.

So that’s, in some sense, predictable — a lot of sci-fi —

James: Thank you.

Mathias: — turned out to be the case. There are probably a lot of people who were right that this was going to win out.

James: There’s a book I’ve been meaning to read for years called The Dreams Our Stuff Is Made Of, which I think makes the argument that science fiction has much more influence on technology innovation than we’ve ever been willing to admit to ourselves — that the people who do the technology innovation grew up reading science fiction, and it shaped how they think about...

It both raised their aspiration levels and shaped how they think about innovation. Now, I haven’t read the book yet, so I may not be describing it that well, but it’s on my list of things to read.

Mathias: Yeah, I think it’s to some extent probably true.

James: And I suppose the corollary, just as an aside, is: absent science fiction, we would have a much lower pace of technology innovation.

Mathias: Yes, probably. It sparks the imagination.

James: Yeah, it sparks the imagination. You were saying?

Mathias: Yes.

James: Okay. Now, one way I think about this, I’m curious if you agree with this: generative AI is a way of doing entropy transformation. Deterministic systems can’t process entropy — they need deterministic, non-entropic information.

And for the first time, we can ingest data about the world in all its entropy and start to learn from that. I was wondering if that resonates with you at all.

Mathias: I’m not sure.

James: Well, come back, think about it a little bit. When you come back for the follow-up at some point in the future, you could think about that, or you can shoot me an email. Tell me what you think. Hey, thanks so much.

This was a terrific discussion. I very much appreciate you coming on and talking to us.

Mathias: Thanks so much, James. It was great speaking to you, and thanks for the invitation.

James: All right, terrific. Thanks.

Mathias: Awesome.

Footnotes

[1]: Epoch AI’s analysis of SWE-bench Verified found the same model’s score moves purely on scaffold choice, holding the model fixed: Claude 3.7 Sonnet rose from 62.3% to 70.2% under a custom scaffold; GPT-4o rose from 23% (SWE-Agent scaffold) to 33.2% (Agentless scaffold); DeepSeek R1-0528 scored 33% under Epoch’s own tooling versus 57.6% reported by DeepSeek under the Agentless scaffold. Separately, Cursor’s engineering team reported taking the same underlying model from 46% to 80% on an identical benchmark, and from Top 30 to Top 5 on Terminal-Bench 2.0, by changing only the harness.

[2]: IBM Institute for Business Value, “AI in motion: Orchestrating AI at scale for sovereignty and resilience” (2026, with the Dubai Future Foundation, 1,000+ senior leaders across 20 countries) — organizations with an orchestration-led AI governance layer (coordinating retrieval, evaluation, and guardrails across the AI lifecycle) were roughly 13x more likely to scale AI successfully and reported significantly fewer losses tied to AI errors and misfires, versus peers without one.

[3]: White, J.G., Southgate, E., Thomson, J.N., & Brenner, S. (1986). “The Structure of the Nervous System of the Nematode Caenorhabditis elegans.” Philosophical Transactions of the Royal Society B. The original C. elegans connectome paper — source for the “three hundred and two neurons” figure.

[4]: Hasani, R., Lechner, M., Amini, A., Rus, D., & Grosu, R. (2021). “Liquid Time-constant Networks.” AAAI. The original LTC paper referenced in the C. elegans/liquid-time-constant-network discussion.

[5]: The “around forty tokens per second” Raspberry Pi figure is Mathias’s spoken claim. No published benchmark shows a genuinely large model hitting 40 tok/s on a Raspberry Pi 5 — independent testing (arXiv, “An Evaluation of LLMs Inference on Popular Single-board Computers,” 2025) puts 7B+ models at 1-3 tok/s, 3B models at 2-5 tok/s, and 1-1.5B models at 5-15 tok/s on that hardware, all memory-bandwidth-bound. The one figure that does land at “around forty” is Liquid AI’s own LFM2.5-230M — a 230-million-parameter model, not a large one by any standard measure — reported at 42 tok/s in under 1GB of RAM. Likely what Mathias means by “large language model” here is relative to what people expect an edge device to run at all, not large by parameter count.

[6]: The “single digits of millions of dollars” enterprise token-spend estimate is James’s spoken estimate. It sits at the low end of the 2026 range: CloudZero’s State of AI Costs 2025 report put average enterprise AI spend at roughly USD 1MM/year (USD 85,521/month), while Menlo Ventures’ 2025 Mid-Year LLM Market Update put average enterprise AI budgets at roughly USD 7MM/year — both consistent with “single digits of millions” as a typical figure at the time of recording. Agentic workloads are starting to push some companies past that band, though: one healthcare enterprise reportedly burned through more than USD 6MM in six months once agentic AI use took hold, per the FinOps Foundation’s State of FinOps 2026 report.

[7]: de Bono, M., & Bargmann, C.I. (1998). “Natural Variation in a Neuropeptide Y Receptor Homolog Modifies Social Behavior and Food Response in C. elegans.” Cell. Primary source for the social/solitary (npr-1) distinction underlying the “social behavior” reference. See also: de Bono lab et al. (2012), “A Modular Library of Small Molecule Signals Regulates Social Behaviors in Caenorhabditis elegans,” PLOS Biology, on the signaling mechanism.

Likewise corporate success in the AI age will require citizen development and traditional, at-scale enterprise technology to coexist. Yes, CIOs must build platforms citizen developers can use. But they also should inspire citizen developers to think, at least a little bit, like software engineers. That makes it more likely that citizen developers will build applications that the technology organizations can co-opt and scale.

Citizen development at Normandy

More than 900 officers and other ranks worked for General Eisenhower in COSSAC (Chief of Staff to the Supreme Allied Commander) coordinating thousands of other military and civilian personnel in planning Operation Overlord. Staff studied Normandy from aerial photographs and pre-war maps and yet, as John Keegan recounts in Six Armies in Normandy, they failed to plan for the 15-foot-tall earthen hedgerows that would stymie the advance of invasion forces. Staff knew about the hedgerows, but they so focused on getting onto and then past the beaches, they didn’t think enough about what would happen next.

Culin attached metal prongs to a tank so that it could breach the hedgerows. A demonstration of the Culin Rhino impressed Gen. Omar Bradley, who ordered the First Army Ordnance Section to produce it at scale. Decades later in Iraq, US soldiers innovated in similar fashion. When Humvees proved vulnerable to improvised explosive devices they found ways to augment them with improvised “hillbilly armor” in theater.

You can see the skeptics of big IT smiling at each example. Innovation happens at the front lines, they will say. Nobody in an enabling function will understand the business well enough to automate it. I’ve heard plenty of people say that citizen development will cause the IT shop to wither away, no less than Engels believed that the state would wither away under Communism. Neither has happened yet.

Citizen development and at-scale technology will coexist in large institutions

Sgt. Culin did not and could not have coordinated the 160,000 troops, 7,000 ships and landing craft and 12,000 airplanes deployed on just the first day of the invasion. Nor could troopers in a maintenance depot in Iraq have realized the Second Offset, which brought stealth platforms and precision-guided munitions into reality.

Citizen development and at-scale technology will coexist in large institutions. Citizen development will push and reshape enterprise technology no less than the desktop revolution did in the 1980s and 1990s. We graybeards remember that ambitious users -- often with equipment funded in departmental budgets -- pushed glass house IT to adopt new technologies and consider new types of applications. Sometimes companies deployed applications initially developed for a few users widely -- when I worked at Deloitte Consulting in the 1990s, everyone entered time and expenses into a database an associate had thrown together in Clipper and created charts using an Excel plug-in some BA had built.

No, the analyst on the front-lines will not vibe-code your next ERP platform, but he or she has local knowledge that many requirements processes will struggle to capture. How can enterprise technology unleash creative talent close to the front-line -- in a safe, scalable manner? Last week I talked about how vibe coding will require platforms to enforce architectural standards. But that’s not enough -- it will also require skills and, especially, mindsets on the part of vibe coders (or citizen developers).

Inspire citizen developers to understand the power they have

Yes, citizen developers will need to learn the protocols for the platforms they use, but skills have boundaries. Mindsets compound. Every developer learns syntax. Good ones combine curiosity with intellectual precision -- they have a desire to move past the fuzziness that dominates corporate life, understand how things work and how to make them better.

We want citizen developers to ask not only “How do I do X?” but also “What do I mean by X? Why can’t I do X now? And: What is the best way I might do X?” We want them to learn to think a little like software engineers.

Maybe not a small lift, but no important one is. Can CIOs and CTOs inspire citizen developers not only to do, but also to ask and to learn? If I were to write a letter to a vibe coder, here’s what it might say:

1. Automate what you understand. Years ago, someone asked, a great user of yellow pads, “What can a computer do?” I stand by my reply: only what you can do on a yellow legal pad, only much more quickly. If you can’t sketch it out on a whiteboard, graph paper, in a spiral notebook or on legal pad, you have no business writing a program about it.

2. Models aren’t magic. They just perform a statistical prediction of what tokens to use in response to the tokens you provide. A model is only as good as the context it receives. You have to figure out not only what type of context you can provide, but also how accurate an answer that context will yield.

3. Agents need to write things down, just as people do. We’ve all stared into a chat window and wondered why the machine can’t remember something. Context windows are limited and attention degrades. Almost every compute architecture faces memory bottlenecks. LLMs handle large inputs imperfectly, suffering from attention degradation over long context windows. Like a human colleague who forgets verbal directives, force your coding agents to write state and requirements down into explicit artifacts like Product Requirements Documents (PRDs).

4. Many things must be deterministic. The uncertainty and variety inherent in probabilistic execution make for great brainstorming, but can create unacceptable risk in business logic. Use models to write deterministic code (Python, SQL) that you can isolate, test, and run reliably, rather than relying on an LLM to interpret business logic on the fly.

5. Sometimes models are just as superficial as humans. Training creates incentives for a model to deliver an answer, not the best answer. Just as with a new joiner, you have to probe a coding agent: Did you consider all possible causes for a bug? Is this the most robust and flexible possible solution?

Don’t be afraid to co-opt what citizen developers build

For CIOs and CTOs watching an impending onslaught of citizen development: be ready to co-opt the best of it. Gen. Bradley didn’t penalize Culin for modifying armor; he ordered the Rhino cutter into scaled production. CIOs in the 1990s cherry-picked the best user-developed desktop databases and hardened them for the enterprise. Treat citizen development as a finely-tuned sensor array for organizational friction—and an opportunity to scale what works.

I sparked a controversy in one of the Technology Leadership Forum breakouts back in May. Which is good—how boring is a breakout session where participants compete to emphasize how much they agree with everyone else.

In discussing how building business applications might evolve in coming years, I suggested that we might need more of what they call “Strats” in capital markets, people who combine deep insight into a business domain with deep software engineering expertise. Nobody contested that point.

Then I noted that many Strats started out as software engineers who learned about securities markets and suggested that technologists might learn about many business domains more easily than business managers might learn how to build applications, even with coding agents. [1] This caused more contention. All the technologists in the room worried I might have taken too tech-centric a view.

The importance of a technology mindset

As always, I think it’s more complicated than that. Back in the 1990s, I was the chief technologist for a small company outside of Boston that created on-line training, demos and the like for technology and media companies. My brief tenure there highlighted the difference between a business mindset and a technology mindset when building software. Business people want to get things done. Fair. Good technologists learn to think in terms of abstraction: How is this task similar to or different from other tasks? Can I build a machine to execute the task rather than execute it myself? Can I add parameters to create a machine that performs similar activities in different contexts?

I had created libraries of reusable functions, one for Grasp and one for Visual Basic that turned, in some cases, weeks of work into hours. (I was very proud of this.) Not infrequently, a major new project required an expansion to one of our core libraries.

My colleagues had marketing and design backgrounds. When we received a new commission, they just wanted to get things done, and immediately wanted to start typing.

I would say “stop.” Sketch a user interface. Go for a walk. Take in a movie. Go square dancing. Give me 48 hours without typing.

I would spend 24 hours drawing boxes in a spiral notebook and determining the additional functions required for our core library. For Grasp, I would also sketch out the central control loop -- VB did a lot more of this for you. (Attached photo: a poor recreation of the indecipherable chicken scratch I used to create.)

Then I would spend 24 hours coding the additional core functions. Then I would encourage people to start typing. While I got some sleep.

Coding agents are empowering but lazy

Coding agents are empowering. They allow me to do things I would never have the time or patience to do otherwise, like construct the technology-economic model I have always wanted to build. [2] But coding agents are lazy—lazier than the most slovenly hack programmer you can find. They will hard-code anything. Separation of the presentation, application and data layers? Who needs it? [3] I suspect the frontier labs have trained their models on billions of lines of terrible code. What else is there?

Labs train models using reinforcement learning that rewards passing a test. The model finds the cheapest way to satisfy the exit criteria, and hardcoding is cheaper than abstraction in the short term. CodeRabbit’s audit of AI-generated pull requests found 1.75x more logic and correctness errors, 1.64x more maintainability defects, and 1.57x more security findings than human-written code—including 2.74x more cross-site-scripting vulnerabilities. At the same time, experienced engineers can also use coding tools to improve software quality. [4]

I assumed that I could use the system prompt to solve problems like this. Hah. As I wrote about in Turning relationships into files to vanquish the chaos muppets, I used junctions (simple markdown files with a noun, verb and an object) rather than wikilinks, YAML front matter or stems to define relationships between entities in my personal knowledge base. I put language in the system prompt about how I wanted the coding agent to use junctions. I might as well have written out a set of policies and procedures for a cat. Maybe amusing; not effective.

A system prompt is not code, even if context is the new code. Nothing type-checks it, nothing tests it. Two instructions pull in different directions, and the model resolves it silently—no error, no warning, just whichever rule it weighted more heavily that turn (a 2025 benchmark on LLM conflict handling found the same pattern: consistent detection, inconsistent safe resolution). My junctions instruction was one more rule in that pile, and it lost.

Using hooks rather than prompts

Eventually I discovered that hooks work better than additions to the system prompt. Classical if-then logic has power. Recently, I sought to extend and formalize that in a governance framework for Prosaic Graff, including both architectural principles and coding standards.

The mechanism exploits hooks in Claude Code’s event lifecycle—checks that fire automatically after every edit, not instructions I hope the model reads before it acts. There are three moving parts.

Rules as graph entities. The rules themselves live in the graph the same way everything else in this system does—as files connected by other files, not as configuration buried in a script. For example, I have junctions indicating what organization people I know work for. The rule below ensures that nobody can have more than one current, full time employer:

type: rule
rule_type: cardinality
applies_to: [Employed-by]
scope_field: tense
scope_value: present
scope_match_blank: true
scope_exclude_field: nature
scope_exclude_value: part-time
max: 1
message: "A person may have at most one full-time present Employed-by junction (part-time roles are exempt)"
scope: PostToolUse
tier: log

Rule taxonomy. Not every rule is enforced the same way, and the taxonomy matters more than I expected going in.

• Architectural principles, e.g. to mandate building extensions to the graph using junctions between entities rather than by YAML front matter or wikilinks

• Entity-schema rules, pure data contracts to ensure required fields and appropriate values in each field (e.g. employment cardinality example above)

• Heuristic rules, e.g. patterns for classifying calendar entries by project. These aren’t deterministic, but at least I know the model will look at all the heuristics when it junctions a calendar entry to a project.

Hooks. A handful of scripts run after every edit, write, and shell command, and check the change against whichever rules apply. I consolidated the mechanism—schema loading, tier dispatch, junction validation— into its own package, graff_governance, so the same engine can run against multiple projects.

Yes, it’s overhead but it’s automated overhead rather than overhead I have to remember. When I applied graff_governance to a model I built to measure entropy it found that it had been using stems and front matter when it should have used junctions—that’s why it took so much manual tweaking to run correctly.

I think the field has been converging on the same answer from a different direction.

• A Codesai engineer’s 2026 case for architecture tests over prompt-based “guidelines” makes the identical argument for a narrower target—code structure, not data structure—for the identical reason: a second LLM pass auditing the first is non-deterministic and doubles the token cost, so the rule has to become code, not another instruction.

• Speakeasy’s framing of agent hooks as an “AI control plane” describes the exact primitive this system runs on, arrived at independently. Where this system differs is the object being governed: everyone else is gating code—what compiles, what a linter flags, what a Terraform plan would deploy. This gates the integrity of the graph and the code together using the same mechanism[6]—detect after the fact, tier by severity, never prevent before the write.

Vendors seem to be working on the domain, though nobody has an end-to-end solution yet. Every piece exists somewhere; the combination doesn’t, but probably will soon. [5] [6]

Will this work for me? I think so, at least for me, although it has teething problems, especially in making the language in the rules both specific and broadly applicable.

What does this experiment say about citizen developers, especially those who want to build more than a simple report? We can imagine a world where enterprise technology provides platforms and citizen developers create applications that solve business problems. It might unleash innovation or create crippling technical debt. Making the model workable will require building tools to govern vibe coding or enhance citizen developer skill sets—or both.

Footnotes

[1] Obviously this varies by domain. Few software engineers will pick up large molecule pharma manufacturing quickly. Marketing or HR, on the other hand?

[2] Yes, I’m very popular at cocktail parties.

[3] I discovered this when I split my model into a front end and back end. Watching text scroll by on the screen, I saw the coding agent had jammed calculations into the front end. “No!” I shouted. When I asked one of the senior-most executives at the company that shipped the coding agent why I did that, he replied “Some people might want that.” Some people might want to put chocolate syrup on their brussels sprouts or wear brown shoes with a blue suit. Doesn’t make it right.

[4] Even though studies from technology vendors may have a predisposition, they also can provide useful signal.

[5] Some companies working in the space include

• Open Policy Agent’s Gatekeeper binds a policy to a resource type through an explicit link, the closest existing match to what Applies-to does, but nothing in its audit-controller design lets a policy’s own firing frequency promote or retire it.

• Guardrails AI’s on_fail taxonomy—hard-fail, auto-correct, suppress, log-only—is the best-documented tiered-severity model in the AI-guardrail space.

• LaunchDarkly’s stale-flag detection is the closest real-world analog for automated retirement, gated on evaluations run rather than violations triggered, so a rule that’s working perfectly doesn’t get mistaken for a dead one.

[6] Yes, SHACL and OWL have bound a rule to a type explicitly for two decades—that part of the claim isn’t new. What they don’t do is fire off a live edit, tier the resulting violation by severity, or use how often a rule fires to decide whether it survives. Static graph validation and a governance layer wired into an agent’s tool-call lifecycle are different animals wearing the same constraint-binding coat.

[6] The rule itself only ever inspects file shape—front matter block versus junction file—never the code that consumes it. But how you model a relationship is an architecture decision, and getting it wrong costs you in code, not just in data: the entropy model above needed manual tweaking precisely because its relationships were shaped wrong. The junctions rule, for example, draws that line from data into code.

There is no such thing as vibe coding, at least for anything important. Coding agents will hard code anything (maybe they are allergic to parameters?) and will always default to procedural over declarative language. Relying on a system prompt is like sending a policy memo to a toddler -- it might be amusing but doesn’t change behavior much. If you want to enforce an architectural standard, create a deterministically fired hook. And if I hadn’t wired up a skill to apply the five whys to root cause analysis, I might have gone batty.

What was I working on? How to think about GenAI and entropy.

From the outside building a system looks simple. You just need some data and some rules to act on that data:

• If a customer buys product x, charge her USD 20.00

• If a passenger is on the manifest let him on the plane

• If a user has rights to a document, let her open it

But we live on Planet Earth. Even before you start to deal with issues like scale, resiliency and security, the data and business rules prove much fuzzier than the simple examples we sketch out on a whiteboard.

Entropy makes enterprise technology expensive and frustrating

In many domains, who is the customer and what is the product can be uncertain; the data may be incomplete; the rules for applying discounts or granting access to resources may get dizzingly complex. A couple of weeks ago, I suggested:

• Information systems use a simplified model of an entropic world to derive analytic insights and automate business processes. The more entropic the domain the more expensive it is to build the system and/or the less faithfully it reflects the underlying reality.

• Much of the frustration we have with enterprise systems derives from the gap between entropic reality and the deterministic systems we use to model it — that’s why companies spend hundreds of millions of dollars paying to create intricate business rules for their ERP platforms and why account executives complain they hate using CRM applications.

• Naturally GenAI doesn’t make a messy world any less messy, but it reduces the cost of reflecting reality in formal information systems (e.g. by converting entropic user requirements to deterministic code or converting free text to structured data). This makes it economical to expand analytics and automation in a way that would not have been economical even a year ago.

• Many companies succeeded in automating low-entropy business processes a decade ago or more. Origination systems for consumer credit cards and underwriting systems for personal auto insurance tend to work pretty well. Systems to support provisioning treasury services for large enterprises work less well.

How to look for entropy

So in making decisions about funding and designing AI systems you want to understand where the entropy exists in your business system and how AI could help you ameliorate the challenges it creates -- so I wired up a methodology for assessing business domains for entropy. Again -- I just would not have gotten there without my 5-whys skill.

There are eight markers of entropy

• Data opacity: ambiguity, incompleteness, lack of structure and heterogeneity

• Rule/path complexity: discretion, rule volume/velocity, path variance, rule interdependency

You can use these markers to score domains — here I did it for governance, risk and compliance in cybersecurity, but the same markers can apply to any business domain.

Here’s the rationales for the scores for Security Governance:

• Ambiguity: Governance frameworks provide defined structure, but determining what “adequate governance” means for a given organization’s risk appetite and maturity level involves genuine interpretation — the data exists, but the correct read of it is contestable.

• Incompleteness & Unreliability: Governance functions operate on formal documentation — policies, board minutes, audit findings, program metrics. The evidence base is largely complete and verifiable; the bottleneck is not data gaps but the effort of assembly and analysis.

• Lack of Structure: The inputs to a governance assessment are almost entirely unstructured — board presentations, committee minutes, risk appetite statements, policy documents, external audit reports.

• Heterogeneity: Multiple frameworks coexist (NIST, ISO, CIS, COBIT, SOC 2), but they are generally reconcilable — different naming conventions, not fundamentally incompatible schemas. Moderate cross-system joins, not deep structural incompatibility.

• Discretion: Governance decisions — which risks to formally accept, how to rate program maturity, whether to grant policy exceptions — require professional judgment. The framework bounds that judgment but does not eliminate it; edge cases and proportionality calls are routine.

• Path Variance: Governance workflows vary sharply by industry, regulatory regime, board composition, and organizational structure -- and often include different paths for different types of issues or questions

• Rule Interdependency: Governance rules are densely interconnected — a change in risk appetite cascades to control selection, exception thresholds, audit scope, and reporting requirements. Policies reference standards that reference frameworks that reference regulations; downstream effects of any single rule change are hard to trace.

• Rule Volume & Velocity: The regulatory surface is expanding rapidly — SEC cyber disclosure rules, DORA, NIS2, state privacy laws, updated NIST CSF 2.0. Governance teams must continuously track a high and growing volume of requirements that change on timescales shorter than most policy review cycles.

These markers don’t just tell you where to spend — they tell you how to build.

• Ontic entropy needs tools that organize context for a human decision, not tools that try to make the decision instead; more automation doesn’t shrink a gap that has no single right answer.

• Epistemic and representational entropy point to a different design: instrumentation, ingestion, agentic conversion — the missing piece is data, not judgment, and GenAI’s job is to make structured data cheaper to produce.

• Rule-side entropy is a formalization problem, not a data problem: the rules already exist, scattered across policy documents, regulatory text, and precedent — GenAI’s job there is to ingest that material and derive deterministic rules from it, so path variance and rule interdependency get resolved once in code instead of re-litigated by hand every time a case comes up.

If you don’t understand the entropy you face, you might invest in the wrong place or you might build the wrong system — a judgment-support tool for a data problem, or an automation pipeline for a problem that was never going to reduce to a rule.

Appendix: Entropy markers

You can think of entropy in terms of three dimensions

• Source: What is the underlying reason for the uncertainty

• Degree of uncertainty: How much uncertainty remains after collection of all available facts

• Possible mitigation: How GenAI can help bridge the gap between messy reality and formal system

Data opacity

Ambiguity

• Description: There are multiple plausible interpretations — the world itself doesn’t have a single answer.

• Examples: What stage in the pipeline is this deal in? Who is the decision maker for a corporate customer?

• Source: Ontic — the uncertainty is real, not a data gap; more information may provide context, but won’t resolve the question definitively

• Degree of uncertainty: Persistent: uncertainty remains above zero even with all available evidence
  Possible mitigations: Use GenAI to collect and organize the data required for human judgement. You may not be able to mathematically derive what stage the deal is in, but at least you can know who has provided input on it

Incompleteness and unreliability

• Description: Data needed to answer the key question is missing, outdated, or contradicted by another source.

• Examples: Incomplete and out of date information about critical systems stored in CMDB

• Source: Epistemic — the missing data could in principle be found or the conflict resolved, but right now it isn’t there.

• Degree of uncertainty: Approaches maximum — the data that would resolve the question is absent or irreconcilably contradictory.

• Possible mitigations: Use GenAI to collect additional information (i.e. by instrumenting processes) or to address anomalies and flaws by inferring patterns

Lack of structure

• Description: Information exists but is encoded in formats a system cannot read — email, PDF, voice, handwritten notes.\

• Examples: Clinical treatments stored in free text notes. Business cases stored in spreadsheets or word processing documents.

• Source: Representational — the information exists and is possibly determinate, just historically expensive to access (i.e. would require an analyst to spend hours converting unstructured text to structured data)

• Degree of uncertainty: Artificially high — you can eliminate it entirely, though it has been historically expensive

• Possible mitigations: Use agentic data ingestion to convert unstructured text to machine-readable structured data that you can use to derive analytic insights from or transact against

Heterogeneity

• Description: Relevant data is split across systems with incompatible formats that cannot be automatically joined.

• Examples: Enterprise counterparty exposure spread across trading, lending, and derivatives systems with different identifiers; claims data split across billing, underwriting, and adjudication systems.\

• Source: Representational — the information exists and is possibly determinate, just historically expensive to reconcile

• Degree of uncertainty: Artificially high — you can eliminate it entirely, though it has been historically expensive

• Possible mitigations: Use GenAI to interrogate differences across data sets and create connections to a shared schema

Rule/path complexity

Discretion

• Description: The goal and the facts are known, but the correct action cannot be reduced to a rule — professional judgment fills the gap.

• Examples: There is no set of imaginable rules for addressing the concerns of an angry corporate customer — requires instinct and tact

• Source: Ontic — this is not an information problem; you can’t even define a specific set of actions to pick from

• Degree of uncertainty: Remains above zero even with complete information — two experienced practitioners given the same situation arrive at different but equally defensible answers.

• Possible mitigations: Use GenAI to capture information and provide humans with additional context required for exercising discretion

Path variance

• Description: Cases of the same type require materially different handling — different workflows, skills, or systems depending on the specifics.

• Examples: Trade settlement — handling varies by instrument type, counterparty jurisdiction, and settlement method; insurance claims — standard auto, total loss, disputed liability, and catastrophe each require different workflows.

• Source: Formalization — converting complicated rules to formal language is possible, but historically expensive

• Degree of uncertainty: Ultimately reducible, but historically expensive

• Possible mitigations: Use agentic software engineering, which changes tradeoffs about how many rules you can automate economically

Rule interdependency

• Description: Rules cannot be evaluated independently — the outcome of one governs which others apply, or multiple rules conflict for the same input.

• Examples: Union contracts with grandfathered provisions that modify base rules that themselves modify exception rules; tax deductions subject to phase-outs that interact with alternative minimum tax calculations.\

• Source: Formalization — sorting out the interactions among rules is possible but historically expensive

• Degree of uncertainty: Ultimately reducible, but historically expensive

• Possible mitigations: Use GenAI to reason across the full rule dependency graph; surface conflicts and identify the permissible path when rules interact.

Rule volume and velocity

• Description: The rule set is too large to manually search or too frequently updated to keep encoded guidance current.

• Examples: Thousands of new potential security rules requiring assessment against a specific asset inventory to determine whether it applies and how urgently; cloud security benchmarks updated quarterly as new services launch, meaning previously compliant configurations go stale without any change on the organization’s part

• Source: Formalization — a large rule set is expensive to capture; a fast-changing one means captured rules go stale before teams can update them.

• Degree of uncertainty: High because finding and applying the right rule is expensive — not because the answer itself is unclear.

• Possible mitigations: Semantic indexing of the full rule set; automated

The US military defines a weapon system as not just the hardware, but “a combination of one or more weapons with all related equipment, materials, services, personnel, and means of delivery and deployment required for self-sufficiency.” US Army rifles like the M-4 and M-16 assume disciplined, well-trained forces; Mikhail Kalashnikov designed the AK-47 for an indifferently trained, poorly-educated conscript army. [9]

No less true in automating (or applying AI to) business domains than in equipping infantry platoons. Somebody has to use the bloody system in some way, and they may not want to use it in the way you want them to. Salespeople may not want to enter all their relationship information. Service techs may want to spend more time fixing customer problems and less time entering data on what they did. Doctors may disregard recommendations from a clinical support system.

Business or technology transformation initiatives are simple on Planet Milton Friedman. We all do rigorous strategic, operational and technology analysis. We formulate a business case. And if it plausibly exceeds the hurdle rate, senior leaders adopt it and implement the material incentives for everyone in the organization to prosecute it ruthlessly.

Frustratingly and wonderfully, we live on Planet Earth, not Planet Milton Friedman. Managers have other objectives and constraints in addition to maximizing their bonuses. They have different risk tolerances. Measuring contribution is hard, especially for more strategic and transformative initiatives. So client executives who want to achieve big things must be savvy political operators as well as astute business strategists. In the technology context, I framed this as CIOs needing to be demon game theorists to achieve the cooperation they need for success.

Getting any complicated bill through the US Congress requires careful coalition management. Add this provision and you pick up a few votes tied to one lobby or another. And that provision you pick up a few more votes tied to a second lobby, but you might lose a few too because you have disadvantaged some regional interest or another. And, take care, add too many expensive provisions in hopes of picking up votes and you might lose deficit hawks who want to keep the total ticket under a certain number.

We’ve all gone through this in constructing business cases. Exempt one local market from consolidation to avoid a political fight and the benefits decline more than the investments. Accept more conservative savings assumptions to get operations on board and the ROI attenuates further. The CFO insists on smaller investments in the first year. Figuring out a value-creating direction is hard. Assembling a ROI-positive path through political realities to get there is brutal.

Very little of the information required to determine how humans and machines should interface or how to assemble a politically-viable, ROI-positive business case appears in any database. Even when written down it’s ambiguous and stored in dozens of different spreadsheets, email threads and chat streams and, now, videoconference transcripts.

Ashwin Gopinath, Co-founder and CEO of Sentra, [2] wants to make the information substrate that busineses need to make complicated, multi-dimesional decisions legible. AI won’t solve the problem for you, but it make make the required information legible enough so that you can. [3]

Remember: ProsaicTimes never endorses companies or technologies. But we find insight in talking directly to builders about the future they are trying to create.

A Polymath’s Unplanned Path

In this section:

• Ashwin describes his journey across physics, biology, and AI

• How following interesting problems rather than a career plan connected disparate fields

• Why the most interesting people rarely have a predetermined map

James Kaplan: Hi there, this is James Kaplan with another ProsaicTimes video podcast. With me I have Ashwin Gopinath — why don’t we start out with you introducing yourself a little bit, talking about your journey, and telling us how you came to Sentra?

Ashwin Gopinath: I started in one area and got pulled into working with biomolecules, because that was the only way I could get to the molecules I cared about. That opened two pathways at Caltech.

Then some personal moments led me to get interested in biology as a systems problem — something I could connect to a sense of social responsibility. That pulled me into a whole other set of work. And then I realized what was happening: I was chasing the unifying thread, not the discipline.

James: Well, the most interesting people never have a plan. Sometimes we create artificial divisions between knowledge domains. The physicists will say it’s all physics, and those of us who are history majors will say it’s all history.

Ashwin: You are only as good as your context. The way one person can connect things is remarkable. But the problem with teams is that people don’t know what they’re working on in aggregate. The collective has no privileged vantage point — each person knows only their slice. If you know 100 people, not all of them know what the others know.

James: Alan Kay [1] said that context is worth 20 IQ points, or context is worth 50 IQ points, depending on which version of the remark you’ve heard. History is context. And it is interesting to think about human context versus machine context, because all of us are operating in a professional environment, swimming in context and never quite able to manage it all. There are a zillion emails, a zillion chat messages, a zillion documents to read, and we can never quite assimilate it.

Ashwin: That’s precisely where the friction lives. The CEO, the C-suite — they believe they know what the organization knows, but they only know their slice of it. They may know their own knowledge, perhaps. But in practice, they don’t know what others know. That generates enormous friction.

James: Have you ever read anything by Peter Turchin? He overstates his point a little, but his theory is that asabiya — an Arabic term — is the discriminant between successful and unsuccessful societies. It means common purpose and willingness to sacrifice for that common purpose. But one definition I’ve seen is knowing what you’re supposed to do without being told — everyone has enough shared context that the next action becomes obvious, and everybody moves left or moves right without having to be directed.

Ashwin: Some of that gets called culture in any meaningful sense, or people describe it as a shared operating system. But the thing is, there are these ephemeral artifacts that some groups have — and the question I keep coming back to is: can we use AI to start building that? Can we get groups into that state faster?

James: You could argue that the humanistic aspects of AI are the most interesting ones. There’s an age-old question about how you generate what the military would call unit cohesion — without engendering groupthink. That is a tough issue. People have probably struggled with it from the beginning of time.

Ashwin: That is part of what led me to work on Sentra. The important problem — what Sentra is trying to do — is to be there and make sure everyone arrives at the same page. The question is how you sustain that as things move forward.

Context, Memory, and AI Alignment

In this section:

• The challenge of aligning human and machine context in organizations

• Human memory, utility functions, and lossy compression in AI context windows

• Why structure in memory aids both programmatic analysis and human recall

James: It’s not only a hard problem — different motivations make it harder or easier depending on the environment. On an old-fashioned equity trading floor, decades ago before electronic trading, you could align people because there was a P&L at the end of the day. You had clear risk parameters and a clear profit-and-loss statement on the book. If you made money, that was good; if you didn’t, that was bad. But most of business isn’t like that.

Even where you have quantitative metrics, you may have multiple conflicting ones — this went up, but that went down. Or metrics that are overdetermined: this happened because you did this and I did that. How much was you versus me? Or you may have things that are hard to measure, ambiguous data. If you’re in the consumer world, measuring customer satisfaction is easy, but in a corporate world where you may have 50 different stakeholders in a relationship, how do you measure satisfaction?

Ashwin: When people think about utility functions in AI, they’re making the point that you define the behavior — and if you define the behavior poorly, it gets defined for you. The whole behavioral-economics school of thought is bound up with this definitional challenge: what does the model think it is optimizing, and what are we actually asking it to do?

The biological approach, if you think of the utility function as a kind of lossy compression, is that you compress away what you don’t believe is important. But the interesting thing is, if you need everything, you’re not running the compression correctly — you’re just storing.

James: When you say memory, do you mean memory in the context window, or memory stored to a file — which may be a graph?

Ashwin: I mean both, but I lean toward the latter. I think the ability to go to 100 million tokens is meaningful, but what matters is whether you can actually reach what you need at inference time.

James: Here’s why I’m skeptical of the context window. Thirty years of hanging around data centers tell me the constraint is never the compute — it’s always the memory. And as I read the charts, the compute is improving in capability more quickly than the bus to the memory is.

The context window is constructed using lossy compression [5] — which is obviously not the same as anything you write to a file. Anything involving lossy compression is, at some level, going to be unreliable — the question is how unreliable. And the beautiful thing about system memory as opposed to human memory is you do have infinite long-term memory if you mediate it with structure. [4]

Capturing Meetings and Extracting Structure

In this section:

• How Sentra approaches capturing unstructured professional conversations

• Identifying primitives — decisions, risks, issues — from fast-moving dialogue

• The challenge of determining whether something is one decision or two

James: Now, I think you’re doing some really interesting stuff around capturing conversations. To me, this is one of those things that is incredibly difficult and deceptively important, because in a professional environment, we spend a lot of time in meetings — and then we walk out and say, my God, what just happened?

Ashwin: At the top level, you have the external artifacts — the Slack messages, the emails, the decks, the reports, the minutes. But underneath that, there’s a bunch of people having a discussion. And beneath that there’s something else: a set of primitives. Those primitives may be decisions, risks, issues, deliverables, questions, work streams — it will vary by business context.

What we’re trying to do is use the semantics available from the meeting itself, combined with the semantics you can get from the organizational graph — who are the visitors, the teams, the stakeholders — and pull out those primitives reliably. So the question we’re always asking is: what is the smallest meaningful unit of work or commitment that came out of this conversation?

James: That sounds like an object model. Do you have inheritance and polymorphism in there at all?

Ashwin: Yes — there is a hierarchical structure, and entities do carry properties inherited from their context. The graph structure lets you traverse those relationships.

James: The thing I always struggle with is: is one thing one thing, or is one thing two things? If you’re thinking about redesigning an IT organization — is the decision to consolidate across business units the same as the decision to optimize? You could argue they’re two discrete decisions. You could optimize in place without consolidating. But consolidating without optimizing seems pointless, and optimizing in place without consolidating gives you no scale effects. Theoretically, two decisions; practically, one. How do you think about that?

Ashwin: The way we handle it is probabilistic rather than deterministic. If the semantics of two threads are entangled — if resolving one consistently changes the frame of the other — we surface that dependency as a relationship in the graph rather than forcing a merge or a split. The human gets to see that these are linked and decide whether to treat them as one or two.

James: Ultimately a person or a group of people make a decision, sometimes very ambiguously. I tend to think of those as two separate and incredibly complicated problems. First, what is the set of decisions that have to be made? And second, what is the group of humans that have decision rights? Those rights can be very complicated — you might have negative control but not positive control. You can prevent an answer but not force one. Some people have influence only if three others also agree.

Ashwin: The act of making those dynamics legible changes them. The moment you surface who has influence over what, the political landscape shifts. That’s the observer effect applied to organizational behavior.

James: It’s Heisenberg’s uncertainty principle as applied to AI. [6]

Ashwin: And this is why I think the right model is the one you described — Team Cyborg. AI surfaces insights that inform human judgment; it doesn’t replace the judgment, because you can never capture information completely enough, and because the act of capturing it creates second-order effects.

James: Here is why it matters in a very practical sense. Every business case is a trade — at a big enough scale, it’s like getting something through Congress. I’ve been involved in multi-hundred-million-dollar business cases where there’s always a question: do we leave this country in or out of the consolidation? How aggressive do we estimate the savings here versus there? You’re always balancing the quality of the business case — what does the ROI look like? — against the quality of the political coalition. Smart senior executives do that calculation in their heads without thinking about it. Past a certain point, it gets hard to do in your head.

Ashwin: Political science has been mapping political dynamics for decades, if not centuries, and the models exist. [7] The challenge is applying them in real time to a specific organization with incomplete data. That’s where the second-order effects become dangerous — you don’t want to make the map so visible that people start playing to the map instead of doing the work.

James: This is why I’m on Team Cyborg, not Team Android — AI is a tool that provides insights to inform human decision-making, but we will never, or not in the foreseeable future, capture information perfectly enough to make instinct and judgment irrelevant. The act of capturing some information creates second-order effects.

AI Accuracy, Knowledge Work, and What Comes Next

In this section:

• What “95% accuracy” actually means in different professional contexts

• The distinction between being wrong at design time versus run time

• How AI will reshape the toil and grunt work embedded in knowledge work

James: Where does this all go? Give us your few-sentence expression of where this issue — capturing and transacting with ambiguous data — will be in the next two or three years.

Ashwin: I think everyone believes AI is going to automate everything. It’s not going to automate everything — but I do think people’s work will change. What I find interesting to say is: if AI is 95% accurate on 100 tasks, you’ll know the 5 it got wrong. But if AI is working on 10,000 tasks at even a lower accuracy, the net volume of errors grows — and you have to think very differently about where you put humans in the loop.

James: I would put it slightly differently. First — if you’re running a hedge fund and you’re right 95% of the time, you’re a multi-billionaire. If you’re running an institutional brokerage processing trades and you’re right 95% of the time, you’re either bankrupt or in court. So 95% means very different things in very different contexts.

Second, it’s very different to be wrong 5% of the time at design time versus run time. If you’re wrong 5% of the time at design time, fine: we have quality assurance processes, we can test, we can adjust. But depending on the application, being wrong even 5% of the time at run time can be completely unacceptable.

Ashwin: And I think what’s important — and often under-appreciated — is how much toil and grunt work is embedded in most knowledge work: writing things down, recording things, organizing things. [8] AI is very good at absorbing that toil. Not eliminating the work, but absorbing the mechanical overhead so that humans can do the judgment-intensive part.

The quality of what the agent produces is going to be bound by the quality of the context it’s given. The response from a large language model is only as good as the prompt, and the context is what constructs the prompt. Getting that context right — at an organizational level, not just a session level — is the whole game.

James: All right, Ashwin — context is the whole game. Thank you.

Ashwin: Thank you, James.

Organizational context is a brutal problem of structuring information — decisions that were made but never documented, commitments that live in someone’s memory, dependencies that exist because of a conversation nobody recorded. AI may help us capture and understand: who decided what, when, under what assumptions, with whose sign-off. Done well, this will empower human decision-makers exercising judgement rather than replace them.

Footnotes

[1] Alan Kay massively influenced the development of the Mac via his work at Xerox PARC, and later was an Apple Fellow, but was not on the original Mac team. The “context is worth 80 IQ points” formulation (the number varies across tellings) is widely attributed to Kay from his OOPSLA keynotes and ACM lectures.

[2] Sentra describes itself as a “unified memory layer for your company” — capturing decisions, commitments, and organizational context into a queryable graph accessible to both humans and AI agents across 200+ business tools. (The 200+ figure is per Sentra’s own marketing; no independent verification available at time of publication.)

[3] Ashwin’s Company Brain post argues that most organizations confuse having data with having memory — data without temporal and semantic structure doesn’t tell you what the organization actually decided, or why, or when it changed.

[4] Ashwin’s analysis of how LLMs and biological memory fail the same way makes the case that both systems apply lossy compression, discarding what they judge unimportant at encoding time. The implication: if precision matters at retrieval, you need a different storage path — structured external memory, not the compressed context window.

[5] The arithmetic illustrating why memory bandwidth, not compute, is the binding constraint for LLM inference at scale — is worked through in Why LLMs Will Never Remember Your Enterprise.

[6] The intuition that measuring a system changes the system has a long pedigree in social science. The classic example is the Hawthorne effect: people often change their behavior simply because they know they are being observed. The analogy to Heisenberg’s uncertainty principle is metaphorical rather than literal — in physics, the principle describes fundamental limits on measuring physical quantities; in organizations, the comparable insight is that observation itself can alter the behavior being measured. Management scholars have recently formalized this analogy: Shelef, Wuebker & Barney (Academy of Management Review, 2024) argue that business experiments do more than reveal information — they can change the value of the underlying idea by influencing competitors, customers, and other stakeholders. A companion commentary in the same journal explores both the strengths and limits of the Heisenberg metaphor.

[7] The academic research connected to this point: Gailmard & Patty’s survey of formal models of bureaucracy — covering hierarchy, delegation, and information asymmetry across decades of political science literature — establishes the toolkit Ashwin is referencing. A foundational result (Crawford & Sobel 1982) demonstrates that complete information-sharing between agents with divergent interests is mathematically impossible; the degree of distortion is a function of how far apart their preferences are. Annual Review of Political Science 15 (2012): 353–77.

[8] Knowledge work contains substantial coordination and administrative overhead. McKinsey estimates that knowledge workers spend more than one-quarter of their time searching for information rather than applying their expertise. Cohen & Birkinshaw argue in Harvard Business Review that knowledge workers could reclaim roughly one day per week by eliminating, delegating, or outsourcing low-value activities.

[9] C.J. Chivers covers the history and design philosophy of the AK-47 in depth — the rifle was deliberately engineered for soldiers with minimal training and limited mechanical aptitude. Reliability under adverse conditions, not precision, was the design priority. Helpful comparison to the M-16 here.

Processes are complex. They depend on thousands of interconnected rules for applying discounts or approving requests. Rules change based on business need and regulatory requirements. And there are exceptions — and exceptions to exceptions: send the invoice to this executive rather than that one in a local market; apply an off-book discount that someone agreed to years ago. Data is opaque. Information is inaccessible because it lives in email chains or spiral notebooks. It is incomplete, disconnected, and out of date.

Why do enterprise systems cost so much and perform so poorly? Because business is entropic. Why is system modernization so hard? Because legacy code reflects years of patches and hacks accumulated to capture the weird idiosyncrasies of our business processes. Sometimes this produces the dreaded second-system problem: a replacement system that degrades productivity because it fails to replicate some of the never-written-down, barely-understood functionality that made the first system work for users.

We will all spend considerable time in the coming years using GenAI tooling to understand legacy code. Where does it capture important process idiosyncrasies? Where does it assume an obsolete process that can be reimagined? Where does it contain years of accumulated, useless crud?

I had the chance to talk with Harrison Touati, CTO of Rhino AI, and discuss how he thinks about using GenAI tooling to interrogate legacy code — and what that means for modernizing systems and improving operational productivity. As always, Prosaic Times never endorses and company or technology, but we often find it interesting to hear from builders themselves! Here is what I took away.

1. Legacy systems are not technical artifacts — they are business records. A company’s processes contain more information than any one person can hold. Code is the accumulated record of how those processes evolved — including rules nobody wrote down, constraints nobody remembers creating, and idiosyncrasies that may or may not still matter. Modernization fails not because developers are slow but because nobody can comprehend the whole thing.

2. The right comparison is not AI versus deterministic code. Human engineers are already a stochastic process. The real question is which messy stochastic process produces cheaper outputs with a lower defect rate. Once you frame it that way, the trajectory becomes clearer.

3. Where you process entropy matters as much as whether you do. Enterprises can deploy AI agents at runtime to handle messy decisions as they arise, or at design time to clarify the rules and encode them in software. Design-time is almost always preferable — it lets you apply 30 years of software QA to the output. Most organizations are currently doing it backwards.

4. When code becomes cheap, what remains scarce is structure. Domain knowledge commoditizes. What doesn’t: the structured understanding of how a specific business actually operates — its ontology. The companies that will win are those that own the vertical model, not just the development capacity.

James Kaplan: Hi there, this is James Kaplan, joining from Rhode Island for another Prosaic Times video podcast. We have Harrison Touati, CTO of Rhino.ai, with us this morning. Harrison, welcome.

Harrison Touati: Hey, great to be here.

James: Why don’t you tell us a little bit about your journey to Rhino AI?

Harrison: I’ve always been interested. I remember even back in college, natural language, NLP.

Data science, stuff like that. And my early career was a bit of a pivot from there, but it all came back together when I worked at some low-code SaaS companies. I did a lot of what I learned was, wow, a lot of these processes are really painful and miserable. And the thought process was, okay, can we use AI to make understanding legacy systems and to make modernization a lot less painful?

And that’s what inspired the creation of the technology and the company and how I got to where I am currently.

1. The Low-Code Mirage: legacy systems are business records

• Low-code promised to eliminate developer dependency; in practice it reinvented programming complexity in proprietary form.

• The hard part was never syntax — it was understanding the problem.

James: Many people were convinced that low-code, no-code was going to take over the world. It didn’t. What was the promise, and what caused the gap?

Harrison: Low-code, no-code products — the promise was that business analysts could do the development. You wouldn’t need developers. And that never really manifested for two reasons.

One is a failure to actually be sufficiently no and low-code in the first place. And the other is that even if you were sufficiently such, you would still need developers anyway, because the hard part is understanding the problems. If you look at low-code products in particular, they end up reinventing the wheel. At first they’ll be like, oh, we have this really easy way to solve some problems.

But then they’ll ask: what if I need to iterate that across an array of issues? And all of a sudden they’re rebuilding for loops in their own way of doing that. You end up sometimes in a worse situation where not only are you not low-code, you’re basically in some invented programming paradigm that only your staff knows. And that sometimes makes things even worse.

So what you end up seeing is for the easy use cases, you do get savings. And then for the complex use cases, sometimes you’re like, man, it would have been easier to just run a Python script for this. The other thing is that the idea that if development was easy, that you wouldn’t necessarily want people with a developer mindset is not really true. A lot of business problems are hard and complicated and require a lot of thinking to solve.

If you’re going through and doing really complex ERP implementations and the rules are really hard, you need someone who can sit down and logically think through things. And so you end up just having developers working with weird proprietary tools, and I think that probably hurt the adoption of low-code.

James: It reminds me of the 1990s when people started coming out with visual development languages. I’m dating myself, and I remember people showing them to me and — great. So instead of typing three lines of code, I have to click and drag 40 things from a palette onto some sort of screen and then do a bunch more mouse clicks to connect those things with arrows and what have you. Why wouldn’t I just write the four lines of code or the 10 lines of code? Once you get past remembering some very simple syntax, it doesn’t buy you anything.

Harrison: Especially when you start getting into complex arithmetic calculations — you’re calculating interest rates or something like that — you end up back having to enter Excel-like formulas and then you end up with a programming language anyway. That’s the worst part — you drag and drop the boxes, you draw the arrows, you map the variables in the dropdowns, and then you end up still running some monstrosity of an Excel-like expression to close it all together and you’re like, this could have just been five lines.

James: Exactly. And in a programming language, you can just call up all the logic and look at it. Instead of having to click on 10 different things to see where the logic might be buried — which gets to an important underlying topic: the reason systems have been challenging is that there’s a lot of entropy, a lot of variation and uncertainty in business processes, and none of the low-code, no-code products either in the 1990s or more recently had any effective way of dealing with that.

Harrison: The complexity — when you think about most businesses, there are absolutely use cases, like you buy an ITSM system for ticket management, and okay, this really does just out of the box solve a lot of my problems, but mostly because ticket management is fairly consistent across many companies.

And businesses very rarely are building greenfield new applications. Even when they think they are, they run today and therefore whatever problem they need to solve, they have some way of solving it today, even if it’s not good. And that problem is often constrained by regulations, by economic realities, by human processes that nobody’s even aware of.

Whenever you try to automate these things with code — entropy is a really good framework for thinking about it. These are very high entropy, confusing, often poorly thought out processes, often emergent. They’re not an artifact of design. They evolved in the wild and you have to be able to capture these and it can be just so complex. And then what you end up having to do is taking that ITSM or whatever CRM ERP software and smashing it into some sort of monstrosity workflow engine to handle really complex use cases. It doesn’t work out very well usually.

James: And often the failure is in the understanding of the business. How does this actually work? Your point about emergent processes is a very good one — because we sit there and say, here, use the SaaS product and use the out-of-the-box workflow. That’s interesting because we don’t really know whether the emergent idiosyncrasy is accidental — just the way someone had to design it at some point — or, to use the example of Chesterton’s fence[5], did that idiosyncrasy evolve for an important business reason?

Was there some regulatory thing someplace or some set of customer requirements that nobody bothered to write down?

Harrison: That is the hard part. When modernization projects fail — and this is something I learned early in my career — it’s very rarely due to developers not being fast or smart enough. It’s almost always due to everyone — the client, the developers, the project managers — it’s not a one-person thing or one-role thing. It’s everybody not really understanding how the business operates.

And it’s not their fault. The business is in some sense an emergent super intelligence — more information than any one human mind can hold. When the individual human tries to comprehend it all, they struggle.

A lot of the idiosyncrasies are created for very good reasons, but sometimes those reasons don’t even exist anymore. They’re like vestigial organs of the enterprise.

James: But you don’t know which ones exist and which don’t.

Harrison: You don’t know that out of the box. That’s the AI use case — and why, from a career perspective, I thought it was worth pursuing. Can we apply some degree of limited super intelligence to help augment that process?

Can we pull in as much information from as many people as possible — we’re not going to understand everything, but can we at least understand more than the average person on the project? And if we can even a little bit lower the failure rate of projects from that cause, that becomes very worth it.

2. Interrogating legacy systems: ask how to use AI, not whether

• Modernization projects fail not from slow developers but from everyone — client, dev, PM — not understanding how the business actually operates.

• Systems are digital manifestations of business processes; what looks like a technical problem is almost always also a business problem.

• Reconstructing process from code, config, logs, and documents is the triangulation problem at the heart of legacy modernization.

James: Okay. So tell us about the creation of Rhino AI and tell us how the technology works.

Harrison: The creation was born out of the pain and suffering a lot of the other co-founders and original employees and myself had — modernization projects are miserable. They require so much specific information.

James: And just one definition — when you say modernization project, can you just define that because that could mean a few different things? Just scope it for us.

Harrison: So what we normally mean is the business has some existing capability, normally already implemented in some legacy tech stack. And legacy is in the eye of the beholder very often. Of course.

James: Yeah. I knew I was in trouble when I started hearing about legacy cloud. And in a couple of years we’re probably about three months away from people starting to talk about legacy AI.

Harrison: Oh, definitely. And part of that’s due to — the analysts have to make new buzzwords. I don’t know how many analysts are listening to this, so I’m going to maybe keep it there.

So that was the business problem — born out of the pain of those modernization projects, of taking these legacy software systems and having to rebuild them to reap modern benefits: modern security, more maintainable, easier to add new features, better UX, better performance, lower cost.

James: And sometimes a modernization project can be largely technical in nature — we’re running on outdated code. Sometimes it can be business and technical in nature — it’s not integrated enough, it doesn’t have the type of capabilities that business users are demanding. Fair?

Harrison: Yes, you’ll see both of those. And often when people think they have the former, it really is the latter. As you dig into these, the system is like a digital physical manifestation of the business’s job to be done and their processes. As you dig into these things, you’ll realize that people don’t actually like them and they don’t understand them.

You’ll often find — they’ll be like, hey wait, that’s how we do approval? I didn’t even know how approval logic worked. We should definitely change that now that we know how that works.

James: Years ago, a wise old architect told me a system is just an automated process — which I think is almost true, but not quite true. A system is automated parts of a process, because often you’ll see pre-processing and post-processing. We’ve all seen the spreadsheet gymnastics required sometimes to enter data into a quarterly close, as well as the spreadsheet gymnastics on the far end of some sort of system output in order to put the data into a format that people can use or understand.

Harrison: It’s going to depend on the system. Some systems really do capture — and people get into, what is a process? Sometimes a process is a purely technical or automated job.

But usually when people talk about processes, it’s with human actors. And therefore, almost by definition, the system is only part of the process because it is not the human actors — it might tell someone that an approval has to happen, but it is not the approver.

James: In banking you have many processes that are truly — clearing and settlement, in financial services broadly, we now have many transactions that are truly no-touch.

Harrison: I agree. And with AI agents, you’re seeing some processes that people traditionally thought couldn’t be done that way — people are starting to say, well, maybe some of these approvals really can just be handled by an agent. Where that goes is yet to be determined. But I do suspect we will see more and more people try to move processes to be like that.

And in many cases, they’ll succeed. In some cases, they’ll probably fail spectacularly.

James: In banking, if you look at highly structured products like equities, those are incredibly automated. On the other hand, exotic derivatives, much less automated because you could argue there’s just a lot more entropy associated with the product.

Harrison: It’s not just the entropy. It’s probably also how many people are doing it, because there’s always that cost tradeoff — is it even worth automating?

James: Equities or credit card transactions are a great example of processes with a lot of clarity, not an unreasonable amount of variation and very, very high scale.

Harrison: And what’s probably changed due to AI is that the ability to automate things that traditionally had a lot of unstructured data and lower frequency is going to go up — and it’s probably already gone up. So I think we’re going to see a lot of attempts and probably a lot of successes in automating those things.

People often compare AI-based solutions to current processes as determinism versus stochastic processes. That’s probably not a good comparison. A piece of code might be very deterministic, but AI can write code. So the question really becomes who’s generating the code.

The humans who write the code are often stochastic — they’re messy. Code is filled with bugs. That’s why there are implementation budgets to go through and do all this maintenance, fix all these bugs. As you zoom out to the 20,000-foot view, everything’s a messy stochastic process.

It becomes which messy stochastic process is going to be cheaper and have a lower defect rate. There’s a nice chart I like where it’s the performance of the best chess engine and the win rate of humans over chess. The win rate of the human grandmasters at 100%. And then one day you get Deep Blue and all of a sudden the human rate is zero.[2] I think you’re going to start seeing that in more and more industries — sure, the AI might mess up, it might hallucinate, it might write bad code with a bug.

But the goal was never to write zero bugs. Human engineers can supply plenty of bugs. You only have to have less costly bugs on average than the human. And as we see the models improve, that world is going to come.

3. Design time vs. runtime: where you process entropy matters

• Processing entropy at design time beats runtime: you can apply 30 years of software QA to the output. Most organizations are currently doing it backwards.

• LLMs are poor at saying “I don’t know” — the truly hard edge cases may be better handled by humans, at least until the models improve on calibration.

• As code gets cheaper, exception cases shrink. The agent-vs-human decision for the residual tail matters less than it appears.

James: I think about it slightly differently, which is: where do you want to turn the stochastic world into something less stochastic? Where do you want to process the entropy? One of the big decisions will be, do we want to do it at design time or runtime?

If you have a whole messy set of rules that are not well documented, you could either build an agent to apply those rules at runtime, or you could develop software using agents to clarify those rules and apply them in a more deterministic manner. The advantage of addressing stochastic processes at design time rather than runtime is that then we can apply everything we’ve learned over the past 30 years about software quality assurance to the output.

Harrison: That’s a very good point. It’s design time. And when people think about agents still, they’re thinking very much runtime agents — oh, we can have some agent do automatic approvals and stuff like that. But I think about — there’s an example of when the internet was getting big and people talked about the information superhighway.

If you remember that, I suspect I’m a little bit older than you are.

James: Yes, I remember the information superhighway. In college, I wanted to take the Brown Daily Herald and put it on the internet. I found out I couldn’t because at that point, advertising was still not allowed on the internet. They would disconnect you.

Harrison: Man. Wow.

James: Yeah. So before 1995, there was no advertising because the US government agency that managed the internet did not allow you to advertise on the internet.[1]

Harrison: I didn’t know. That’s why the internet took off in the late 1990s — because they allowed advertising on it. What I think about with the superhighway is everyone — there were people who were like, oh, we have the internet, but when are we getting the superhighway? And it’s like, well, you have the superhighway. It’s the internet, right?

And I think about that with agents now where you still have folks being like, how are we going to replace all these processes with agents? And it’s like, you did — it’s called Claude Code. If you built GPT-12 and GPT-12 is like Ultron and it can do anything — if you’re like, GPT-12, go solve ITSM — it’s not going to manually review a million tickets. It’s going to write code to do 99% of it.

You want to do as much at build time as possible because it’s cheaper, it’s faster, the AIs are probably better at coding than they are at anything else. Runtime is what you want to do the absolute bare minimum — exception cases, extremely fuzzy amounts of judgment, things that require a huge amount of natural language processing. That’s the only time you’re going to want to really do runtime. Then you might ask, if it’s that big an exception, it might be a small enough fraction that you may just want to give it to a human.

Harrison: You could just give it to a human. And that’s going to come back to what I was saying earlier — will the human on average make fewer bad calls? How often will humans outperform the machines in judgment? As time goes on, I think you’re going to see the machine judgment just continue to improve.

James: Let me offer a counter perspective. Large language models or GenAI is phenomenal at certain things — reading large amounts of text. It’s really bad at saying “I don’t know.”[3]

Harrison: It is, yes.

James: And the truly big edge cases, where there isn’t a dataset — we’ve never seen this edge case before. A lot of what you want from the human is less, oh, let me make a decision — can I even make this decision, or do I have to go ask these six other people?

Harrison: That’s a very fair point. And historically the LLMs have really struggled with that. They’re trained to maximize some objective function during reinforcement learning, and that objective function is answering math problems correctly, so it’s almost always valuable to guess. I’ve seen some interesting research about penalizing guessing.

There are many possible futures — there’s a world where that stays the case for decades.

James: From an efficiency standpoint, if you’re down to half a percent of all the transactions, whether you send those to an agent or send those to a human may not make that much of a difference.[4]

Harrison: It might not matter. And it might not be a dramatic amount of judgment either way — especially because in practice you want to get as few of those exception cases as possible. And often a huge portion of exceptions are not due to the fact that this couldn’t be done deterministically at build time, but because code was just expensive. Now that code is...

James: Code was expensive, yes. Code is now cheaper.

Harrison: And so as code becomes cheaper and cheaper, the exception cases are going to start declining.

James: The way I think about it is we’ve changed the operating leverage dynamics for automation.

4. What Becomes Scarce: When Code Is Cheap, Structure Is Scarce

• When code is cheap, the traditional SaaS moat — “we understand the problem and we’ve solved it” — erodes.

• Domain knowledge commoditizes; proprietary structure doesn’t.

• What remains scarce: hardware and compute, unique data nobody else can access, rare human judgment that outperforms machines, and the ontology of a vertical.

• Pure developer-army businesses face structural disruption. In periods of rapid change, the answer is not to wait.

Harrison: Companies in the past, especially on the software side, their value proposition was the software itself and domain knowledge — those would be the two things, especially in the SaaS space. We understand how this problem is supposed to be solved and we’ve solved it.

The latter is going to be not that important. What becomes scarce in a world where I can just give a very fuzzy spec and it just gets perfectly coded by a system that’s worked with millions of people and can really infer intent quite well? In that world, what becomes scarce?

Obviously hardware, chips, data, electric power — all of those things are scarce. And there’s also data that nobody else has access to — information that nobody else can see. That’s where software companies and companies in general are probably going to have to start consolidating around. You’re either going to need to double down on whatever rare human skills remain — good judgment that perhaps exceeds the LLMs.

Or hardware, physical resources, or unique data access. But there’s a whole world of companies that are just pure labor — our value proposition is that we have an army of developers, and we’ll go in for hire and fix your problems. That’s going to be dramatically disrupted.

James: Two thoughts for you. One is to your point about the exceptions — there are two reasons I think exceptions don’t get processed in an automated fashion. The first, which you mentioned, is it’s just expensive to write all the business rules. The second is — and we have to remember that business rules need data to operate on — the data required may be in a spreadsheet, in an email someplace, unstructured data that we haven’t been able to transact on.

Now we can, because in addition to writing code agentically, we can ingest data agentically. And then which leads me to believe there’s maybe one additional source of competitive advantage: structure. Because I think evidence indicates that models are much less likely to hallucinate when given a structure — which is why they write code better, they’re very good at writing code because it’s a structured output. When you don’t give them that type of structure, they’re more likely to have problems.

And then if you create the structure via the process of compounding, you can over time generate proprietary data. So I think getting the ontology right will be incredibly important and will be a source of competition going forward.

Harrison: I agree. The structure is the interface, in a sense. It’s the method of communication between parties. Even humans need structure when they talk to each other — that’s why they make forms.

James: Forms as ontology, I would suggest.

Harrison: And to me, when I think about ontology — I use that word a lot when we’re talking about our own software offering. It gets confusing sometimes because people mean different things. Some people mean the data ontology.

We often operate in a very process-centric world — what are the sequences of activities, business rules. But at a high level: what is the structure of your business? People call it use context now a lot.

Harrison: Like context engines. Buzzwords. But that ability to say we have a way of working with structure around it — structure is the good word — which includes things like the ontology of your data, the understanding of your processes, the context through which decisions need to be made, rules can be done deterministically. It becomes a way of operating as an enterprise. And that becomes a model that can be monetized and a competitive edge.

Harrison: I think also it ties very closely to just scarce state in general. Because if you think about it — and I think scarce state still becomes critical for that — the reason is: how do you know your ontology is good? The only way you know it is good is to be able to use some judgment, but you probably want to have some evidence and measure it. And therefore, if you’re in a specific vertical, you’re a company dealing with that vertical, and you have access to lots of metadata, metrics, and in some cases raw data, you can start to learn what interfaces work, what didn’t work, what processes work.

And then you can build — could turn that not just into aggregates, but into ways of working. And I think that’s what we’re going to see companies start moving more and more towards and away from. Some of them are going to move sooner, some slower, many will die. Companies always die.

But I do think that’s what we’ll see.

Harrison: In the long term, even that activity is a job that I expect will eventually be automated. You will literally just have machines learning about how to build ways of working for machines to solve business problems, probably solving problems for other machines with their ways of working.

James: I’ll avoid the obligatory Skynet joke here.

Harrison: We already brought up Ultron.

James: Different generations.

Harrison: I was sitting with someone the other day and talking about AI, and they were like, the perception in society — not unjustifiably — people are, there’s some fear because even if there’s only a 25% chance it ends up like that, a 15% chance. That’s a big deal.

James: So tell us — you guys ingest lots of code and other documents in order to identify a baseline and then identify and propose a future state business process? Is that correct?

Harrison: We pull from a couple of sources — code, obviously, documents. We also focus a lot on SaaS and COTS, and that’s a big area for us. People largely ignore that because one, LLMs aren’t well trained on it, and two, a lot of people just don’t know about that space.

So we do a lot of SaaS and COTS configurations. And then also some runtime information as well — log analysis is supplemental — we’ll look into it but it’s not our focus. And the goal is to pull out data structure, business rules, process as the orchestrating engine of those things, and also what the current user experience looks like. And then to be able to work with the human users — if they have desired target end states, figure out to honor those or propose new end states, updated processes, areas of redundancy.

We’re working with companies where company A bought company B, and now we have two of everything. So where can we do process consolidation and use case consolidation? And because we’re focusing both at the technical level — mapping out every technical component, method, class, program, etc. — and then process, use case, actor, core data object, etc. — we can start to say, if you want to consolidate these processes, then that’s going to reach down through these three different systems and these different sub-components. And your roadmap to modernization is going to need to take these chunks and convert them into these chunks so that you can change this process.

James: I like the fact that you’re pointing out you can derive the business actions from the tech — you can derive a set of business actions or business processes from the technical code.

Harrison: Yes, absolutely. In fact, I think that’s one of the best places to get it.

James: There are some companies out there seeking to derive information about business processes from code, which I think is great. There are other companies seeking to derive information about business processes by instrumenting user screens and seeing what users do. How do you think about that — there’s some part of me that says it has to be both, in the sense that there is always preprocessing and there are things that happen under the covers that you can’t see from the screen.

Harrison: You can’t do it just through screen analysis. There are many lenses, and different viewpoints give you access to different data. If you really want to know exactly how a user is clicking and which screen they go to in which order, there is valuable process you can infer from that.

Likewise, if you’re looking at pure log files, there are things you can learn. But those are going to help you more if your goal is to automate the human. Think about the RPA world, really automating the system processes — they were trying to replace human swivel-chairing and human activities. This is a really important decision you have to make when you’re automating: are you trying to replace human labor hours that are using systems, or are you trying to replace systems themselves?

And if you want to replace a system, then you have to look at the parts of the process the system does. And those system processes are literally one-to-one defined by the code that executes.

James: I’d come at it differently — I want a better process end to end.

Harrison: Fair.

James: I presume some of the processes are handled by Excel gymnasts who are pre-processing and post-processing data. So therefore, if I really wanted to understand the processes just today and get to hopefully a zero-touch process in the future, if appropriate — I’d need to both do exactly what you’re describing in terms of interrogating the code and other data sets and artifacts, and at the same time instrumenting the screen.

Harrison: You can probably get away with skipping some of the screen instrumentation. But at a high level, some indication of user input or user activity is important. When we’re doing that type of analysis, we’ll take supplementary information — logs with information about who clicked what in what order, SOP documents, user forms. The companies we work with, we do ingest from their spreadsheets. And all of that can start to be correlated and consolidated together into that overall process. Usually as long as you get n minus one of the sources, you’ll be able to infer the last one — there are only so many possible sequences a user can click through these forms.

I see the log files, I see the spreadsheet they’re filling out, I see how the code’s working, I see the documentation they’ve written about it. You can start to infer a lot from there. Pure screen scraping also has its use — traditionally from our side, we’ll just look at the outputs of those. If they have some other screen scraping technology and they’re like, here’s the dump of that, we’ll just ingest the logs of it.

As opposed to trying to build our own — not worth it.

James: You can ingest data from multiple sources, and it’s a game of triangulation.

Harrison: Exactly.

James: What are the markers of a process that you think are most ripe for reinvention? I’m running a bank, a consumer package company, a pharmaceutical company — how should I think about where to apply this first versus later?

Harrison: It depends on your business problem. What’s the issue you’re having? Is it wanting things faster, costs lower?

Which of those really matter to you? If you have a company with a legacy SaaS license that’s enormously expensive and killing them, then the answer is: literally any important process in there that you care about, you should get out, because you’re paying licenses for those and you need to shed those licenses.

Now if it’s a company on a bunch of old mainframe stuff, where perhaps they’re not paying expensive SaaS licenses — then it becomes, what are you trying to get from modernizing here? Is it you want a more maintainable, updateable process? It’s often not performance, because those systems usually perform pretty well. It becomes more about process transformation.

If they’re on the mainframe, it’s very complex for them to maintain and modify those processes, and therefore as a business they’re held back from their competitors.

James: It works great so long as you don’t need to change anything.

Harrison: Exactly. So if your pain point is we need to change stuff, then it’s — which are the processes that you need to change? Is your goal more flexibility in process improvement, or is your goal cost cutting? And sometimes it’s both. That will dictate the processes.

When I work with clients, depending on your stakeholder, they’ll care about one versus the other — or depending on your industry or the situation they’re in. It’s going to be based off one of those two criteria normally.

James: So what have I not asked about? What else should viewers or readers know?

Harrison: Every business — if you’re running a software business, a consulting firm, anything like that, and your goal is not to just get out and sell immediately — you need to be running hopefully five, ten years. The world is changing very fast now. There are very different possible futures right now, and they have very different outcomes. It’s really worth thinking about the top futures you could see within the next few years and where you see your company going. And being a little almost extreme with that.

The possible deviation in futures is very extreme. If you go back 15 years, people were like, you have software, you have consulting, we’re going to bill, we’re going to charge licenses, and we’re going to just keep doing that forever. That was true till now. It might not be true anymore.

Ask yourself: what if our core value proposition at a global level evaporates in the next five years? And what does that mean for us as a company? Every company should do that.

James: What do you do with that once you’ve done it?

Harrison: You need to start changing your plans to capitalize on the main scarcity. If you’re a business, your goal is to monetize scarcity. If scarcity is changing at a global level, your business strategy needs to change at a global level.

Let’s say we are moving towards Ultron World. That means potentially everything will become difficult to monetize at some point, at least for a human. But not everything will become difficult to monetize at the same time.

You need to start thinking about what do you see evaporating and in what order? Your business roadmap and your product roadmap need to start reflecting your bet there. You might make the wrong call, but it’s probably better than just doing nothing and waiting to die a slow death. In periods of more rapid change, you need to take more risk.

Legacy systems are not technical problems. They are high-entropy records of how a business actually evolved — carrying rules nobody wrote down, idiosyncrasies that exist for reasons nobody remembers, and constraints that may or may not still apply. The AI opportunity is not to manage that entropy in real time. It is to reconstruct it at design time, convert it into something deterministic, and apply thirty years of software QA to the output. As the cost of code falls, the exception cases shrink. What remains scarce is not development capacity. It is the structured understanding of a business that nobody else can see.

Footnotes

[1]: The NSFNet Acceptable Use Policy, administered by the National Science Foundation, prohibited commercial traffic on the internet backbone until it was retired in April 1995. The commercial internet effectively began with that transition. See: NSFNet AUP history.

[2]: Deep Blue (IBM) defeated world champion Garry Kasparov in a six-game match in May 1997 — the first time a computer won a match against a reigning world champion under standard chess tournament conditions. The human win rate against top chess engines has been effectively zero at the professional level since roughly 2005–2006.

[3]: Research on LLM calibration confirms this. See Kadavath et al., “Language Models (Mostly) Know What They Know” (Anthropic, 2022), which found that while LLMs show some self-knowledge about their own uncertainty, they systematically overstate confidence. RLHF training compounds this: the objective function rewards confident correct answers, which penalizes hedging even when hedging is warranted.

[4]: The “half a percent” figure is illustrative, not empirical — Harrison and James are reasoning through the asymptotic case where AI handles the vast majority of transactions and only extreme edge cases remain. No benchmark is cited for the specific threshold.

[5]: G.K. Chesterton (1874–1936) was an English writer and social critic, best known for the Father Brown mysteries and for aphorisms that have outlasted his more topical arguments. The fence passage appears in The Thing: Why I Am a Catholic (1929): “There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, ‘I don’t see the use of this; let us clear it away.’ To which the more intelligent type of reformer will do well to answer: ‘If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.’”

A classic formulation of epistemic humility: before removing something, understand why it was put there. The reason may have been silly. It may have become irrelevant as circumstances changed. But you must understand before you act. The principle maps cleanly onto legacy code — where the original intent of a module or business rule is often invisible to later teams.

See Tom Nijhof-Verhees, “Legacy code: Chesterton Fence vs. Ólafur’s yellow box”, ITNEXT (November 2024); and Christos Galanopoulos, “Chesterton’s Fence”, Medium (September 2025), which documents a digital transformation team that stripped out “redundant” validation rules from an inventory system — they turned out to be court-mandated procedures from a legal settlement.

A related mirror concept: “Chesterton’s gap” — the constraint you should have built but didn’t, because nobody understood the problem well enough to know it was needed. The empirical version of the fence is the Scream Test: announce you’re removing something and wait to see who objects. If nobody does, maybe the fence never mattered.

This reminds me of a storage re-tiering exercise from 2007. Developers swore their applications needed the highest class of Fibre Channel storage. The head of infrastructure quietly moved their storage anyway to a lower SAN tier. Nobody noticed. Except finance, which was happy.

I had outlined plans and aspirations at the previous year’s dinner. When I came to the podium at the end of 1991, I thought about everything the 126th board hadn’t accomplished — and all the political capital expended for mixed returns. Still: we published every day of the academic year despite two blackouts. We didn’t get sued. None of the corrections we had to run were catastrophic. We published at least a few good stories.

My successor called me to the stage. I received respectful applause — more due to the position than the man. I thanked each member of the board. The room exploded when I reached Adam’s name. The staff understood exactly the energy and creativity with which he had attacked the role of Opinions Editor. Despite our differences of, well, opinion, I remain grateful to Adam for his contributions to the paper, even decades later.

Adam and I ran into each other again at McKinsey. By then he had decided against litigation as a vocation and was already developing into one of the most rigorous thinkers I know on data and analytics. Senior roles at JPMorgan Chase, DirecTV, Zurich Insurance, and Point72 followed — teams as large as 170 people, enterprises with up to 60 million customer relationships. He now advises boards and senior leadership teams, teaches in Brown’s EMBA program, and runs an annual forecasting contest, which I fear to enter.

Everything we do — every business decision we make — implicitly rests on a forecast. Which is why I needed to get Adam’s view on what AI means for data, analytics, and the practice of forecasting itself.

Three things struck me as particularly worth your time.

First, the B2C-vs.-B2B gap in analytics is real — Adam puts it at twenty years — but the cause is not what most people assume. It is not that B2C data is cleaner. It is that B2C businesses have enough observations to find statistical regularities. A million customers generates surprises. Seventy-five institutional accounts does not. AI changes some of this at the margin, but domain expertise — knowing which variables to featurize, which hypotheses to form — remains the scarce resource.

Second, taking payoff curves into account as you thinking about your career and your job. Adam’s formative experience was as a litigator: limited upside, catastrophic downside, a profession structured for you to lose. He now teaches his kids to think about every career choice as a payoff curve before accepting it. Most technology managers are running the same analysis implicitly every time they commit to a timeline or decide whether to invest in redundancy. Making the curve explicit demystifies the decision.

Third, Adam’s argues that the manager who has actually formed a probability — even a rough one — about whether a project will come in on time is making a different kind of bet than the manager who just called it a plan. The first manager will be better calibrated over a portfolio of decisions. “It matters to be 53% right instead of 52% right” is not a hedge fund insight. It is a description of how operational advantage compounds.

Introduction: from College Hill, back to College Hill

James Kaplan:** Welcome to another Prosaic Times video podcast. We have with us Adam Braff, who I’ve known since about 1990. I’ll let Adam introduce himself and talk a little bit about his journey, and then we’ll start to dive deep into forecasting and what AI means for forecasting.

Adam Braff: Thanks for having me, James. I guess if I could describe what I do now, it is not strictly about forecasting. It’s helping corporates and investors figure out what to do with data and analytics, and increasingly AI. So some of that is descriptive analytics and trying to figure out how many widgets are we selling and why, and some of it is predictive, and how many widgets are we gonna sell next year and how do we make that number go up?

So predictive does come into the work that I do

James: Yes, and we all want to hear about the Narcissist forecasting contest, which I am proud never to have taken part in — because I’m sure I would lose badly.

Adam: Nobody loses in the contest. You gain knowledge, you get smarter. And even if you’re gunning for first place, which is fair to do, it actually influences your strategy. It’s like when you’re entering a March Madness bracket, do you pick a lot of weird long shots, or do you try to be as accurate as possible?

I try to persuade people to just get more accurate year over year and have the least error overall in their forecasting. So nobody loses in this contest. They get a score, they can get coaching and feedback from me for free, and then they try to get better every year

James: Okay. So tell us a little bit about your journey

Adam: We graduated into a recession, if you may recall.

James: Was not fun

Adam: That was the reason why my wife and I — then girlfriend — decided to go to law school. It was a good way to hide out from the economic storms of the early ’90s, and that was kind of a mistake, I would say. It was a big detour in my career, but I ended up going to law school and then practicing as a litigator at a big firm in DC for three years, really not enjoying any of it, and trying to find a way out.

And as it happened, I had put myself into a bit of a corner because the world doesn’t really need litigators. There aren’t a lot of obvious ways for litigators to turn into some kind of beautiful butterfly. So I took advantage of the fact that it was the dot-com boom, the first dot-com boom happening at the end of the ’90s, and ended up getting a job at McKinsey, and it was a fresh start for me.

I was 29 years old, and I just said, “Let’s, let’s start again at the bottom, and this time pretend I had gone to business school instead of law school,” I got my mini MBA from McKinsey, which consists of three weeks of getting bombarded with strategy ops, marketing, and org stuff, and then ended up staying at the firm for a lot longer than I thought I would be there.

I ended up doing work that was really what we would now call data analytics AI. At the time, I think we called it big data. It was how do companies use larger data sets than would fit in Excel and creative new kinds of data and A/B testing on their customers and calculations of customer lifetime value?

How do consumer businesses figure out how to do more of that stuff in order to attract and retain the most valuable customers? And that’s something you can do in a lot of different industries, as it turns out

James: Did you go to Mini MBA in Kitzbühel or do you go someplace else?

Adam: I went to Kellogg. I had a bunch of trainings in Kitzbühel, but I was in Kellogg freezing my ass off for three and a half weeks in January of that year

James: I’m sure it was warmer than it was in Kitzbühel and easier to get to

Adam: Exactly. It was nice.

So I stayed at the firm for 10 years. I was a generalist partner in the DC office. None of my clients were really government or particularly local to DC, so I was traveling a lot. Had three kids in that span of time, and at some point I said, “All right. It’s time for me to get a real job and figure out what I want to do in the real world.”

So I left in 2009 and had a few different offers — some in New York, one in Vegas, which my wife vetoed — and ended up going to JPMorgan Chase to become their head of customer data and analytics. That was for the Chase consumer businesses: figuring out what to do with information about customers who might have a Freedom credit card and a Chase mortgage and a Chase checking account.

What do we do to put all that information together and help the bank make better risk decisions, better anti-fraud decisions, better marketing decisions? I did that for a few years and then got recruited over to DirecTV to run business analytics there. That was different because there was an existing team of really good analytics people doing the same work but for pay television — a much simpler business, with some interesting lifetime value drivers.

James: Interesting. And then you did an insurance company for a while, and you’ve also recently been teaching at Brown.

Adam: DirecTV got bought by AT&T, a bunch of us bailed out. I ended up going to Zurich Insurance and ran data and analytics there. I got a taste of the IT world by reporting into the chief operations and technology officer — which let me see what it’s like to actually build the stuff and not just give the requirements.

Then I spent three years at Steve Cohen’s hedge fund as head of data sourcing and strategy — data acquisition, essentially. I’ve been independent since 2019. Hung out a shingle that year and started teaching at the same time.

I began at NYU, created a class called Business Analytics and Data Visualization, taught different variations of it for a while. Then we moved to Providence, where I’m sitting now, and I’ve been teaching versions of that class at Brown.

Is B2C 20 years ahead of B2B in customer analytics?

• B2C is roughly 20 years ahead of B2B in customer analytics — not because the data is cleaner, but because there are simply more data points to work with.

• The analytics opportunity in B2B looks fundamentally different: customer targeting and Salesforce effectiveness rather than churn modeling and cross-sell.

• AI and agentic data ingestion could narrow the gap — converting unstructured B2B data into analyzable signals.

• Domain expertise still matters: knowing how to featurize variables (competitor footprint, not just state) is what separates the old hands from the clever prompters.

James: Let me ask this question. You’ve done a ton of stuff in what I’d describe as the B2C world, and it’s been my observation that B2C is light years ahead of B2B on analytics — just because the data is cleaner. And I hypothesize one of the interesting things about gen AI is you can now clean up the data, correlate it, convert unstructured text into structured data you can analyze.

So I was wondering if you could comment on how far ahead the B2C world is compared to B2B on analytics, and to what extent might gen AI or agentic data ingestion and cleansing help the B2B world catch up?

Adam: It’s like 20 years ahead[1], but probably for a different reason than the reason that you set out. It’s more that there are more data points to measure in the B2C world. And so if you’re gonna list all the use cases, if a private equity firm comes in and buys a consumer business or buys an industrial business, all the things you’re gonna go work on, there are gonna be analytical big data things to do over here that have to do with acquiring more customers and retaining your best customers and figuring out who those best customers are and cross-selling and stuff.

Over here, you’re like optimizing a factory or something, right? So to the extent that there’s data stuff, and very little of my career has been over here, right?

James: Right

Adam: You’re gonna be getting information from things — what was briefly called the Internet of Things — and getting instrumentation data from over there.

So big data definitely exists, and there are use cases for it, and I sit on councils with people who do this stuff. It just looks very different from the kinds of big data and analytical stuff that I did, and that my father did before me. He’s retired now, but he was doing data-based marketing back in the ‘70s and ‘80s.

Second-generation data and analytics — something that hadn’t existed before.

James: I was thinking about this in the context of customer analytics. If you have a million households in a B2C business versus seventy-five or a couple hundred corporate institutions — which have complicated internal dynamics — the N question becomes obvious. You don’t typically have many decision-makers when someone decides to buy cable services. Maybe one, maybe two. Whereas in B2B procurement, there could be twenty decision-makers in the process, and they all interact with each other.

Adam: The analysis you would do in B2B Salesforce effectiveness would have a lot more to do with customer targeting — going out and grabbing more information about your target, using some agentic tool to pull that and put it somewhere you can analyze it and make good decisions.

The reason the million-customer B2C business got ahead is that a lot of analytics is looking for patterns, for statistical regularities. If you can determine that customers in this region are stickier, or that customers who came through this channel spend more, there are just many more ways to do those analyses — with genuine comparative advantage over an executive doing everything by intuition.

There’s at least a fighting chance for the data to tell you a different story. You think the higher-priced product is better, but the customers don’t stick around as long once you control for everything — and therefore you shouldn’t be charging more or assume that’s the right answer.

You’ll come up with intuitions like that on the B2C side. You won’t on the B2B side because you don’t have enough N to surprise anyone with that kind of finding.

James: Tell me if this is right. The more independent variables you’d have to take into account, the larger the N you need in order to get a relevant statistical sample.

Adam: I think that’s right. And I don’t want to make too much of statistical significance here. A lot of what you’re doing in B2C consumer analytics is descriptive analytics — a BI dashboard, not a giant regression model with a lot of independent variables. You want to slice your data one or two dimensions at a time and just look at the graph. Which numbers are higher? Is it this product, this region, this group of call center agents? That’s what lets you drill in another level and understand what’s happening.

You can have lots of dimensions and measures that you think of as independent variables — you’re just going to be doing them a little at a time, flexibly drilling in to find the hotspots. The regression is just one part of that.

James: What you’re saying is there’s a lot of power in just being able to do Pareto analysis — being able to look at your churn by segment, by size of spend, by region, by product mix.

Adam: Yes, exactly.

Adam: Right, exactly. So we were at DirecTV, churn was the number one thing. It was the era of cord cutting and cord nevers. probably a lot of your viewers have never thought to buy a monthly pay TV subscription ’cause it’s all, they may get it through a streaming product, but not through, a cable

James: every now and again, I will try to explain the concept of channels to my kids, and they’re just confused by it.

Adam: Yes

James: I try to explain that in New York in the 1970s you had channel 2, 4, 5, 7, 9, 11, and 13, and that was it. They accuse me of being old.

Adam: The reason I bring up DirecTV is not to make you feel old. It’s that the main problem we were trying to solve was why churn was so bad and how to make it better. And if you think about the ways to slice churn, first you want the churn rate — within any given customer population, what percentage are canceling over a month or a year?

When you start slicing it, the intuitions you might have — is it by demographics, age and gender? — that’s not what matters. What matters is things like which customers are rolling off a $5-a-month promotion this month. Those turn out to be the vulnerable ones.

Or which customers are in the Fios footprint or the Comcast footprint — does that make a difference, and is it trending differently over time? You need the data to do that kind of work.

James: So what I hear you saying is: the availability of the data, obviously, but also the person who can develop a hypothesis about what might be a relevant driver — competitor footprint, for example.

We needed that hypothesis generation in a world where analytics were expensive — someone had to go do the cuts in a spreadsheet or via SQL. In a world where analytics are cheaper, how much of it is “let’s just run all three hundred cuts and see what it tells you,” versus using a model to discern which cuts might actually have real differences?

Because I think both you and I have done an analytical cut a million times, said “region has no impact,” “size of spend has no impact,” and then — “overlap with competitive footprint, that has the impact.” You have to do nineteen analyses before you land on the twentieth that’s meaningful.

Adam: Domain expertise and taste matter because you have to figure out how to featurize these variables. Region by itself, cut generically into US states or metropolitan areas, gives you a boring answer.

But if you join that data up with another data set — this is the Comcast footprint, this is the AT&T pre-merger footprint — suddenly you’re testing something real. Knowing how to featurize the data to test hypotheses efficiently is still very valuable.

And AI tools, if you coach them correctly and bring enough taste and judgment to it, can let a sufficiently senior person test a much larger number of hypotheses. They’ll also surface a lot of spurious answers along the way.

A brand new data science graduate would have a hard time hitting the ground running in one of those businesses. Even a very clever prompter isn’t going to get to the right answer the way an old hand would.

James: Creativity and context matter here. You make the point about competitor footprint. Who knows — state may be a weak signal, but population density may be a much stronger one. You get a weak signal from New Mexico and Wyoming being different from New Jersey and Rhode Island, but when you really dig in, it’s the Providence metro versus less densely populated parts of Rhode Island that’s driving it.

Adam: And you’re keeping track of the time dimension. Things change over time. Everything changed in COVID. You might decide to cut off your analysis at the post-COVID era, or account for two competitors merging. This happened constantly with banking analyses.

One of the analyses I used to do at the firm was on customer experience. We ran a big annual panel surveying people about their banks — and it was always difficult because the banks kept changing. The American Customer Satisfaction Index, which tracks these things longitudinally, has the names of ancient banks nobody’s heard of — Chemical Bank — that we now know as Chase.

There is genuine value in domain expertise that AI cannot yet replicate.

James: What I should do one of these days is a quiz — Chemical Bank, Manufacturers Hanover, First USA — and you have to guess which bank they’re part of now.

Adam: The world’s most exciting quiz. I agree.

The debate on virtual panels

• Synthetic data is valuable for prototyping and pedagogy — stuffing a dashboard mockup with plausible fake data is now standard practice.

• Where it breaks down: using synthetic panels as a substitute for real market research, especially for purchase-intent questions. There is no signal like that in the model.

• The motte-and-bailey risk: vendors pitch synthetic panels as research-grade but deliver something closer to a prototype illustration.

• James’s CIO/CTO panel is more useful for testing message clarity and resonance than for predicting buying behavior — a meaningful distinction.

James: Never said I was cool. What do you think about virtual panels? Particularly in the B2B space, I’ve started playing with using agents to simulate the decision-making of certain people. Valid? Less than valid? Intriguing?

Adam: I remain skeptical of the whole field of synthetic creation. On the one hand, I use it for pedagogical purposes where I’m creating a data set to illustrate a point to my students. It’s great for that, especially if you’re gonna sprinkle in personally identifiable information, which you don’t wanna do with actual humans.

I use it to make, prototype dashboards. This is something that has become very common now, not just me, but many people since the Claude Code stuff really got going in earnest back in January. I’m sure you’ve done this and you’ve seen it, but many people are mocking up prototypes very quickly, and stuffing them with synthetic data is a pretty good idea, right?

To give people a sense of the art of the possible there.

James: A couple of weeks ago I created the data for a change management program at a major financial institution — all dummy data, but realistic enough to demonstrate something. That would have taken weeks to do manually.

Adam: Incorporating randomness and signal to make it feel like real data is genuinely hard. Agreed.

Now, on panels: I’m doing a lot of consumer insights work these days, back on the B2C side. You want to survey 500 Americans about something — and it’s getting harder and harder to find real people who aren’t robots or speeders or cheaters. So people are pitching synthetic panels: 500 simulated respondents. Why not?

Here’s why not. The whole point of a real panel is the signal — what actual people in the world want, the clusters that form, the principal components that emerge. It’s not just big spenders versus quick deciders; there’s a third dimension that actually explains the variance.

Trying to derive all that from synthetic data seems crazy to me. I’ve had a couple of conversations with these vendors, and I worry that what they’re pitching sits somewhere between the prototype mockup work we were just celebrating and the actual market research my clients need to make real decisions.

It’s a motte-and-bailey: they pitch it as research-grade but it’s really only as good as a prototype illustration. I’d love someone to steel-man what synthetic data is genuinely good for beyond that.

James: For the blog, I created a panel of five hundred CIOs and CTOs. I gave each member of the panel a persona — this person is the CIO of a pharma company with five hundred million dollars in IT spend, this person is the CIO of an asset manager with a billion dollars in IT spend. Then I used the OCEAN framework to create psychological profiles.

Adam: Mm-hmm.

James: Each individual has a job, a title, a company, and a personality profile. I run each draft through them. I wouldn’t bet the farm on the scores, but the quotes I get back are really useful, and I’ll go through about seven iterations. Part of me thinks it may be less helpful for predicting buying intent and more helpful for testing marketing messages — because that’s where large language models are genuinely good.

It’s hard for them to predict whether somebody will buy, but they may be better at understanding whether a message is more or less understandable, more or less compelling. Does that make sense?[5]

Adam: A little bit. You used the words “testing marketing messages.” I think it’s more like — in this case you’re testing your blog. Generating responses that would go outside of what you and I would naturally brainstorm on, how people are thinking about things.

James: It’s pretty good for that. I don’t workshop my blog posts with people who might be more emotionally invested than I am.

Adam: We’ll have to look at your Ocean scores later. We’ll compare them offline.

I like the idea of computers generating things. It’s a large corpus of material — you sift through it, see what’s interesting, throw away what’s not. You and I have been around long enough to tell the difference. You generated it cheaply, so the discount rate on discarding it is low.

But that’s not really what market research is. Qualitative research is different: a focus group has real human beings who can say unexpected things. Small N, unpredictable. But once in a while someone says “I never knew you could use the product this way” — and maybe only 1% of people use it that way, but knowing that might spark a brand campaign.

So I’m in favor of the tools for idea generation and checking your work. What I’m skeptical of is using synthetic panels for commercial due diligence. You’re deciding whether to acquire a BI tool or a security product, and you’re going to rely on numbers saying 20% of synthetic CIOs might spend more than USD 10MM on it.

That doesn’t seem right to me. I don’t think there’s signal like that in there.

James: My take is it’s more a part of the chain. It doesn’t preclude or replace going and doing the interviews. But you can’t test and re-test and re-test with a live interview set. You can workshop messages or hypotheses and then go confirm with actual human beings.

Adam: This is a good segue into forecasting.

All business is forecasting

• Every business decision is implicitly a forecast — a bet that one management action will outperform another.

• The distinction is sharpest for investors: a binary buy/short decision forces the forecast into the open. Operational managers face the same bets but rarely frame them that way.

• Tetlock’s superforecasting research showed that structured generalists — triage tractable problems, decompose, work as a team, ensemble independently — beat CIA analysts with classified intel.

• The Brier score disciplines probability estimates: being 52% right vs. 53% right sounds trivial, but at sufficient scale and leverage it is everything.

James: Go there

Adam: Due diligence is a form of forecasting. You’re trying to predict what the financials of this business are going to look like at current course and speed — and what they’ll look like if we apply our private equity magic on top of it.

All business decision-making is implicitly a forecast: a bet that this management action will produce better results than that one. The point is sharpest when you’re an investor at the margin — do I buy because it’s going up, or short because it’s going down?

James: Very binary — buy or do not buy — as opposed to operational decisions, which are more continuous in nature.

Adam: Exactly. When you’re thinking about numbers and where they’re going in the future, it probably helps to be good at forecasting more generally. And this is what Tetlock demonstrated, decades ago with IARPA and these defense intelligence agencies.

For podcast viewers and listeners who aren’t familiar: Tetlock is a professor at Penn who has been studying forecasting for a long time, and came out with a very influential book called Superforecasting, where he packaged the lessons of groups of generalists who — the legend has it, and I think I’m giving a fairly accurate version —

were able to forecast world events — will this world leader be deposed or die — better than CIA operatives on the inside who had all the intel collected expensively by our intelligence apparatus.

And so these generalists —

James: Did the generalists forecast the Knicks were gonna win the championship this year?

Adam: Nobody predicted that except my sons, who believed in it. And so it happened.

Tetlock codified the rules of what it means to be a superforecaster. These people were really good at triaging problems by tractability. Some things are impossible to forecast — the Knicks. Some are too easy — my soccer team, Tottenham Hotspur, doing badly. The Jets are a better example of the tractable middle ground: will they make the playoffs, will a company beat earnings, will this entity win a major award?

Allocate your time to the tractable problems. Decompose them into constituent parts. Work as a team, but have people develop independent points of view first, then bring the theories together and fight about who has the better argument. Ensemble different independently-made forecasts where possible.

Those are the Ten Commandments of superforecasting that Tetlock codified in 2015.[2] I started my forecasting contest that same year.

I read the book and launched the first Narcissist forecasting contest in 2016 — The Narcissist being a long-running annual newsletter I’ve produced since 1992. Twenty-five binary propositions about the world, each either going to happen or not.

Everyone predicted the likelihood of each from zero to 100%, including, at the time, whether Trump would get elected — which everyone gave very low numbers to.

The scoring mechanism is a Brier score. If I predict 40% for Trump getting elected and he’s not elected, the truth is zero: 0.4 minus 0 is 0.4, squared to exaggerate the impact of being far off, giving me a 0.16 Brier. If Trump is elected, my error is 0.6, and the square is 0.36. A high number is bad. It’s like a golf score.

James: Here’s a business question. Can you predict a probability, or do you only state one? You can predict whether a candidate is elected or not — but we’ll never know the true likelihood of that election at any given moment. You can estimate a likelihood, or you can predict an outcome. But can you actually predict a likelihood?

Adam: It is a bit of a metaphysical question. In a sense, all these predictions are wrong — everything goes to zero or one. There are people who look at the whole enterprise and say it’s stupid. There’s no difference between .4 likely and .6 likely. Just make the call. I’d call those people extremists.

The other camp — generally called Bayesians — believes that we don’t know ex ante whether a thing will happen, and that there is genuine utility in knowing whether something is 60% or 40% likely. The value is in the repetition. You make predictions over and over again.

The clearest illustration is betting markets. In 2016, Trump was trading at under 20% on the eve of the election. Nate Silver had him at 28% — out of consensus to the high side. If you’d looked at the pot odds and said “I can buy Trump contracts at 20 cents because Nate says 28,” you would have done well. Even though you thought it was less than 50% likely, you thought it was more likely than the market priced it.

I’m a Bayesian. Being able to tell a 52% from a 48% likelihood is useful because we make a lot of bets. You’re making them every day when you’re running a business. Being slightly more right and less wrong compounds.

James: Everybody I’ve known who’s managed money for a hedge fund is a fanatical Bayesian. There’ll be traffic, but it depends on three things that might drive more or less of it — let me think through the prior and posterior. Which is interesting, though it gets a bit exhausting.

Adam: One of the most common approaches in a long-short public equity fund is calling the quarter — is this stock going to beat or miss earnings? More precisely: beat or miss the whisper number on whatever KPIs matter.

The hit rate is 52%, 53%. It’s much better to be right 53% of the time than 52% — that’s how they make their money. They’re repeated gamblers doing it at a very high level, trying to maintain that little bit of edge in a zero-sum world where everyone else is trying to do the same.

It’s hard. But it matters to be 53% right instead of 52% right.[4]

James: Because a hedge fund portfolio manager who’s right 53% of the time with sufficient leverage is enormously value accretive. Fortunes can be made with a fifty-three/forty-seven split, plus leverage. Operational managers who are right 53% of the time tend to get fired. And in the technology world there’s the expression “all day, every day” — you can’t be wrong in one direction.

Actually, one of the interesting things here is that in some cases the hedge fund payoffs are symmetric. On the other hand, in an operational world, the payoffs are often highly asymmetric. Could you reflect on that — applying the insights from superforecasting to an operational environment for people who have to make decisions every day with sometimes highly asymmetric payoffs?

Asymmetric payoffs and career risk

• Hedge fund payoffs are roughly symmetric: being 53% right vs. 52% right is the whole game. Operational payoffs often aren’t — a missed security filing, a waived privilege, a breached system can be terminal.

• Adam’s formative lesson came from a malpractice case: the concave payoff curve of law (bounded upside, catastrophic downside) drove him out of litigation and eventually into analytics.

• He vibe-coded a career payoff visualizer to make this intuition concrete — the same tool every technology manager implicitly needs when committing to timelines, availability zones, or budget targets.

• Agile is a structural hedge against the same asymmetry: shorten the cycle, reduce the blast radius of being wrong.

Adam: I would focus on cybersecurity — an area you’ve spent more time in than I have. Risk management in cyber is an area with that extreme concave payoff curve[8], where being wrong in a certain direction is extremely career-limiting.

One of the formative experiences in that professional journey I sketched out earlier was a malpractice case I tried as a lawyer. Very few cases go to trial — almost everything is writing briefs and pleadings. But this one did. My client was a lawyer being sued because he had failed to supervise a young associate who was supposed to file in a telecom case and simply didn’t get it done on time.

Once they realized the deadline was approaching, they scrambled, missed the filings, and the telecom project couldn’t go forward. The client sued. We did good work at trial and settled before it went to the jury.

What that case made me realize was that litigation — and being a lawyer generally — has that extremely concave payoff curve. If you accidentally produce a document with attorney-client privileged information, when you’re going through warehouses of material —

It used to be physical warehouses — for lawyers today it’s all on a computer, it’s a cyber problem. But if you accidentally produce a privileged document, you’ve waived privilege and you’re in serious trouble. Being a lawyer felt like limited upside — a nice house if you make partner versus getting fired and never finding work again.

So I thought more carefully about these payoff curves. The first conversation I had with my kids when they were old enough was: don’t choose a profession with that kind of payoff. Do you want a venture capital payoff — an extreme tournament where the upside is a million times the median, if you’re genuinely confident in your skills? Maybe. But you’re probably overconfident. Most people want something with reasonable upside and limited catastrophic downside.

I actually vibe-coded a tool to visualize this — it lets you look at payoff curves for different employers and say: if I get a top-percentile outcome, here’s how I shake out; if I get the bottom outcome, here’s how I shake out. You can vary economic conditions and other factors. I stuffed it with synthetic data grounded in actual information. It’s more of a toy model and theoretical exercise — an intuition pump to make visible the thing you were saying. Do I really want the job where 10% of the time it’s utterly fatal?

James: It’s directly relevant. People make decisions like this every day. Do I launch this project? Do I use high availability for this application? Do I run it across multiple availability zones? Do I commit to two months versus three? Those are technology examples, but every business manager is asking: what target will I commit to, in revenue or in cost? Thinking through your own payoff matrix — and the payoff matrices of the people around you — changes the analysis.

Payoff matrices differ enormously by corporate culture. In some organizations, blowing a budget a little is “try to do better next quarter.” In others, exceeding a budget in a single quarter is career-limiting.

Adam: That’s right. The types of IT projects I mostly see and lead are business intelligence projects — building out and deploying predictive models. These, especially the dashboards, are generally developed in an agile environment, where agile is kind of a hedge against the asymmetry you’re talking about.

I’m not building a whole stack waterfall-style with a perfect delivery date. I’m making it good enough to get adoption, then making it better — two-week sprints, continuous improvement.

So I would argue that agile is a way of coping with an uncertain world. Do you agree?

James: It’s more emergent strategy than deliberative strategy. There are people who believe that whoever wrote the Agile Manifesto had some connection to John Boyd — I haven’t been able to find as much documentation for that, but the idea is the same: increase the number of cycles, shorten the duration between action and feedback, and revise your strategy accordingly.

Adam: Exactly. Agile development and hypothesis-driven problem-solving are both hedges against disaster. One of the first things you learn at a consulting firm — I taught the intro to consulting class several times — is that you have a day-one hypothesis about the answer.

Part of what’s good about that: when someone stops you in the hall and asks what you think the answer is, you have something. “I’m going to test it and refine it and make it better.” That’s much better than a long list of ideas with no organizing principle.

The risk otherwise is getting caught out with no answer at all. The OODA loop, hypothesis-driven problem-solving, agile — these are all hedges against uncertainty and against the weird events that shock you.[7]

James: The interesting thing is that the nature of the bad thing varies by the nature of the system. In an analytics system, the bad thing is bad information — you make a bad business decision. In an operational system, like an order capture system, the bad thing is different: downtime, a cybersecurity event, a transaction failure.

We deal with those types of negative payoffs differently, using different mechanisms. It’s probably worth thinking about that more rigorously. Let me pivot just a little bit.

What do we tell early career professionals about AI?

• Get a job in a for-profit company and help it make money with data. That is still good advice. Those jobs are not disappearing as fast as the pessimists predict.

• The supply of problems is highly elastic: better, cheaper analytics generates more questions, not fewer analysts.

• Proof-of-work has decayed — anyone can generate a slop deck. What has not decayed: domain knowledge, taste, and the ability to have a real conversation about a business.

• Adam’s standing advice: pick the domain you care about, grab the public data, do the analysis. Show up to the interview having already thought about how to help the company make money.

James: In my teaching, I’ve seen a lot of anxiety from people early in their careers about what they’re going to do with their lives in the age of AI. A number of college seniors asked me, and I said they should learn data structures and data science — because no matter what happens, that will be valuable. Did I give them good advice or bad advice? And what are you taking away from your interactions with college students?

Adam: Getting some kind of job and getting out into the real world to develop domain knowledge — for all the reasons we talked about — is important. Getting that job is a separate question; that’s tactics, informational interviewing, picking your spots.

But as advice for how to spend the next one to three years: get into a for-profit company and help it make money by analyzing data against real problems. Those jobs are not going away as fast as the most pessimistic people are predicting.

The supply of problems is highly elastic.[3] Having people ask good questions — and the return to a business from asking more good questions and getting quality answers back quickly — is positive. I’ve bet my whole career on the idea that most companies would benefit from having one more data scientist, or in this case one incremental unit of data science capability.

Which is not the same as replacing all the humans with AI. I’m on the optimistic side of this.

James: There’s more data, available publicly. There’s more tools that you can use for free. And my inclination, for example, if someone were to ask me, “Gee, I want a job doing analytics,” I would say, “Well, pick the domain you’re interested in and start doing the analytics.” Right? Because what’s gonna be more compelling in a first-round interview? It’s “Oh, gee, I’m, I’m really interested in the telecom industry, and I grabbed all this from the FCC and I did this analysis, and here’s what I found.”

Adam: I’ve given a talk on this subject probably every year for the last five years, including the pre-generative-AI era. The advice holds: do actual work, show that you know something about the business, demonstrate that you care about it.

I will say that that coming in with a deck, the proof of work aspect of it has gone to kinda zero, right? ‘Cause anyone can generate a slop deck. People like you and me might be exquisitely sensitive to seeing a deck and understanding immediately that it was written by AI and the, and the tells in the stylistic, that come out of a Claude, PowerPoint deck.

The concept is still correct: get in there, do the work, iterate, think about it. You’ll be able to have a real conversation about the business because you’ve learned something along the way — “I think 80% of the value is in this part of the product, and here’s why.”

You’re not reading off a slide. You’re engaging a person. There’s a lot of value in that. And people still show up at interviews without having thought seriously about the business and how they would help it make money. There’s still a lot of alpha in that.[6]

James: Terrific. Anything else to add before we wrap up?

Adam: The forecasting contest runs every year. Free to enter. You get a bowl of pho if you win, and a book — this year it’s George Orwell’s essays. All the information is at braff.co/advice: the current contest, how to enter next year, and other thoughts about food and analytics.

James: Terrific. Two great topics to discuss. Adam, thank you so much

Adam: Thanks for having me.

Notes

[1] Obviously twenty years is an estimate -- that doesn’t make it wrong. The world is entropic, and deterministic systems are not talked about how organized complexity is much tougher to understand than disorganized complexity.

A B2C business with a million customers faces disorganized complexity. Idiosyncratic individual behavior averages out into stable statistical regularities — churn rates, cross-sell lift, tenure effects.

A B2B software company with sixty enterprise accounts faces organized complexity. One decision-maker changing jobs, or having a bad quarter, creates a measurable swing in the entire dataset. The N is too small to smooth anything, especially since many of the data points are connected to each other. That is why domain expertise is required in B2B analytics in a way it is not in mature B2C analytics — the data cannot naturally control for the variables that large samples would otherwise absorb.

[2] All IT commitments are forecasts based on implicit probability estimates. When a CIO says “We’ll deliver in two months” she estimates the probability of coming in at two months is high enough to avoid the political cost of articulating a more conservative estimate.

[3] Adam describes here the applicability of the Jevons Paradox to knowledge work. When the churn data got good enough to slice, the analytics team didn’t shrink. It grew. Each answer generated three new questions — why are customers in this region stickier? What’s driving the gap between acquisition channels?

[4] You’ll never know whether the 60% probability you assigned to a project coming in on budget was the right number. It either did or it didn’t. But across a portfolio of similar decisions, the manager who has actually formed a probability — rather than suppressed the uncertainty — will be better calibrated over time. That’s what “it matters to be 53% right instead of 52% right” means outside a hedge fund. You’re not making one bet. You’re making hundreds.

[5] There is no perfect data set for the organized complexity of B2B commercial due diligence. Direct customer interviews and focus groups are great, but you only can do so many of them. On-line surveys? Decision-makers responsible for large technology bets at Fortune 100 companies lack the time to respond to them.

Adam is correct. No virtual panel can, well, forecast purchase intent. But they should provide invaluable feedback on value propositions and messaging. And they are both patient and indulgent. You test many variations of a value proposition for example to see which one best resonates.

[6] We’ve heard people confidently predict that early tenure technology jobs will disappear. We’ve all fielded anxious questions from candidates who should probably believe less of what they read on social media. We have all tried to figure out what to say. As Adam points out learning is the most important thing at the start of your career. And it is easier to learn useful things than it has ever been before.

[7] Colonel John Boyd’s Observe-Orient-Decide-Act (OODA) loop is a model of how people and institutions make better decisions through recursive learning in competitive games. It provides a mechanism for balancing deliberate and emergent strategies, which emerge from the bottom up. It appears to have influenced the agile manifesto.

[8] A concave payoff curve: bounded upside, catastrophic downside. Law. Cybersecurity. Most operational IT. A convex payoff curve: bounded downside, extreme upside. Venture capital. Early-stage software equity. CIOs and CTOs often face concave payoff curves. Flawless uptime is invisible. A database corruption is not. When you put together a major incident response plan, you are trying to truncate the ugly end of a concave payoff curve.

Cloud infrastructure, SaaS applications, a revolution in cybersecurity and now AI have upended that unhappy equilibrium of oligopolies. Large enterprises less exclusively act as “takers” of offerings from giant technology providers. They integrate a wider array of technologies from a wider array of providers — some of whom are venture-backed attackers.

Acknowledging this, we did something new at May’s Technology Leadership Forum session. We convened a panel of venture capitalists to discuss and debate how they see the enterprise technology market. Ed Sim from Boldstart, Daniel Frankenstein from Joule Ventures and Will Summerlin from Autopilot engaged with the group on how enterprises can best work with VC-funded companies and how AI will change B2B software markets

Here’s what I wrote about it after the event:

Wow, there is some frustration out there! What do TLF members see from their incumbent software vendors? Slower innovation, degraded quality and more aggressive negotiation. They think some providers see their products as “falling knives” and have resolved to extract as much cash as they can from the portfolio before it declines into irrelevance. Others simply don’t get AI — they want extortionate rates for unimpressive capabilities that only reinforce silos between different parts of the environment.

TLF members found the discussion so valuable and VCs had so much fun that we decided to reconvene (after much scheduling gymnastics) for a Prosaic Times video discussion.

The conversation covers five things.

1. Whether vibe coding and agentic software engineering are the same activity — they aren’t, and the distinction matters for how you staff and govern AI work

2. Where the moat lives as the cost of producing code approaches zero — my answer involves latent information, and it’s more interesting than the conclusion.

3. Which sectors are most exposed to disruption — legal and accounting are the easy answers; I have a less obvious one.

4. How enterprise technology leaders should actually engage with the startup ecosystem — the VC-as-intermediary model turns out to be more consequential than most enterprises realize.

5. And whether you should leave a corporate job to found a company. Ed has a checklist for that last one.

Introductions

James Kaplan: Welcome to a special Prosaic Times podcast. Back in May, we did something different — we always get together about 50 or 60 enterprise CIOs, CTOs, and CISOs, and this time we invited a few of my favorite venture capitalists to share their perspective on the enterprise technology market.

All of our VCs had a blast and found the session both enjoyable and informative. All the members of the Technology Leadership Forum told us they appreciated the session and found perspectives they hadn’t heard before.

So I said, we have to get this group together again for a podcast — so let me start out with some brief introductions. Will, do you want to start?

Will Summerlin: My name is Will Summerlin. I’m a co-founder and general partner at Autopilot. We’re a growth stage venture capital firm, typically investing from Series B onward

Daniel Frankenstein: A co-founder and partner at a firm called Joule Ventures. Seed and pre-seed investor doing B2B software investments, coming out of the Israeli ecosystem.

Ed Sim: Boldstart Ventures. We partner at inception with technical founders when they’re in the idea maze — companies automating the autonomous enterprise, physical AI.

James: Daniel, when we were chatting before, you said that the interaction with the members of TLF was very eye-opening for you. Could speak to that a little bit

Daniel: One of the challenges we face in commercializing companies that aren’t from the United States is building that connection to corporate decision-makers and technology integrators. What we got from the TLF session was direct feedback on specific technologies — candid views on where enterprises are struggling to integrate AI solutions, and where their long-standing incumbents are trying to introduce AI but not yet meeting the mark.

It was a fascinating conversation, and it clarified where the real opportunities are for new technology businesses to carve out space.

James: We’ll say incumbent rather than legacy.

Ed, what was your takeaway? What did you learn from the day?

Ed: Everyone is truly, truly interested in deploying agents, and two, it’s really, really early, and I think that everything we think and know today may be irrelevant tomorrow.

People are talking about RAG and all these other things — like, hey, that was gone yesterday. And in fact, everything that we talked about almost since the last TLF, what was that? Six weeks ago? Is almost irrelevant again. The speed at which things are moving is staggering.

Will: We’re extraordinarily early on the adoption curve in terms of enterprise AI adoption. And I think it’s interesting in that there seems to be a disconnect from the myopic Silicon Valley view and the reality of enterprises. If you talk to a lot of founders or early stage investors or even growth stage investors in Silicon Valley, there’s this view that adoption’s happening very, very quickly, and we’re farther along on that adoption curve.

James: But what we heard from members of the forum is that we’re still very early. It’s still very much in the experimentation phase, moving to the broad-based adoption phase. And so I think that presents an incredible amount of opportunity ahead, but I also think it reflects this disconnect with the Silicon Valley view. You hear a lot in the ecosystem around token costs, and news stories about companies struggling with token costs. But the enterprises I know are spending trivially on tokens in the context of, say, a USD 1B or USD 2B or USD 500MM IT budget.

And that is a measure of quite how early we are from an adoption standpoint.

Ed: Some of the companies that were the more advanced ones were the ones beholden to one large language model provider.

The events of the last six weeks — particularly some where providers said, “Hey, we’re gonna interfere in some of these things” — have shown that not only do token costs matter, but also which model you’re beholden to matters.

So no one’s gonna want to be beholden to one model. Multi-model architectures have to be built, I think, because of that.

James: It reminds me of the era when some people believed you should standardize on a single provider.

Will: I think another interesting data point related to token costs is compute resources. We’re already in an environment where compute is radically supply constrained, and if you look at the growth rates of demand for compute versus supply for compute, demand is growing at a much faster rate than supply possibly could. [2]

Demand is growing because we see more broad-based adoption. It’s growing because agentic models use a lot more compute than legacy LLMs from a year or two ago. And on the supply side, we’re hitting all these constraints and bottlenecks related to supply chain in the semi space.

We’re entering a world where that gap is gonna continue to grow. And that’s all in this backdrop of what you said a minute ago, which is, the single digit millions of spend. And so I think we’re in this interesting environment where part of the world, is super early on that adoption curve, but at the same time we’re already hitting these constraints around compute.

If you want any semblance of an SLA from one of these model providers, you’re going to have to start committing to more meaningful spend. There’s this conflict and tension in betting your entire AI strategy on a single model provider.

James: The enterprise is maybe the shoe that hasn’t dropped yet in terms of token demand, and my God, what happens once the, spenders start using, scale?

The flip side is that you’ll probably see a lot more efficiency in token consumption. You don’t need to do all your non-deterministic processing at runtime. More of it shifts to build time — software engineering, data ingestion — with deterministic execution at runtime. And we may see a meaningful share of inference move to edge hardware entirely.

Ed: Think about models like OpenRouter. Companies now are about to sell a box — or a virtual box — that has a router for any frontier model on top, and then adds your own open source model on the box itself with H200s bundled in.

The idea is to make it very, very easy for people to build an agentic workflow, deploy it, and then actually maximize... I think we’re gonna move to a world of ROI per outcome. It’s no longer gonna be, are you automating me? But what is my ROI per outcome?

How does that look? And then there’s lots of other things involved in measuring success.

Daniel: Obviously folks have concerns about costs and limiting those costs. But right now, those costs are the actual real costs businesses face when they start using this at scale.

So the demand curve is absolutely outstripping the supply curve when it comes to compute. Enterprise adoption is going to be more of an increase on a dimmer light switch.

James: Enterprise adoption is always an increase on a dimmer — not a flip of a switch — which is why claims about AI impact on the bottom line feel like an attempt to be cute.

How could you expect otherwise? We’re what? Maybe a couple of years into the use of gen AI. How could you possibly expect that to have impacted enterprise operating income statements at this point?

The only impact on the income statement has been for some of those tech companies who are spending. I’m thinking about banks and pharma companies at the moment.

Ed: As far as the ROI on that spend — questionable.

Will: I do think we have small case studies where we’re starting to see it.

As one indicator: we have a portfolio company called Replit, which is an AI-native software creation platform. They allow anybody to create software using natural language. And what we’ve seen is in some cases the replacement of incumbent software providers where a non-technical user is able to create their own custom CRM system for a USD 100,000-a-year software license. The ROI on that is extraordinary. That’s like nothing you’ve seen from traditional software.

Ed: I still think the super complex stuff — Workdays — when people say, “Hey, we can vibe code that stuff away,” I think people have moved on from that really.

Whether or not those companies are gonna be massively successful, who knows? But I do think the whole idea of vibe coding things, the maintenance becomes absolutely incredible for some of these people as well.

Will: On one end, you have the bottom of the market that has simple use cases where they can vibe code their own CRM and displace incumbents. So I think that’s one end of the market.

The other end of the market in regards to enterprise adoption is just building more — where now you can use tools like Replit to build agents on top. And so it’s not that you’re gonna get rid of your incumbent provider, it’s just that you’re gonna build more agents on top of what you already have.

We see this primarily around internal tools, where to build a custom internal tool for your sales operations team or for your legal team, you had to either go work with a third-party software development agency to build that, and it would cost you hundreds of thousands or millions of dollars, or you had your internal software engineering resources, which would be expensive and you’re competing for internal resources.

Now, a non-technical person could go into a tool like Replit and build those agents or build those custom pieces of software on top of the existing architecture that you already have. And so I don’t think it’s a replacement for the incumbents in this case. I think rather it’s just gonna enable more software to be developed on top.

Daniel: When we got together initially, there was a real fear-of-replacement moment for incumbents.

We’re more in an all-of-the-above moment now, where a lot of incumbents have the customers, they have the data they own — which, by the way, is one of the key things to be competitive in this moment.

And that’s actually what makes this really exciting from a venture perspective: these incumbents are your customers, and also your acquirers.

You also have this entire new world to go after as well.

Ed: The most impressive thing was the idea that unicorn SaaS companies are all dead. This founder went all in on AI three months after ChatGPT came out, and today Salesforce announced it was buying it for — I don’t know — three and a half billion or something, which is above their ZIRP-era financing round. [1]

It takes very special companies, but maybe there’s a five percent chance that some of the very forward-thinking ones can create that kind of value. And combined with some of what Will said about Replit, there’ll be net new — more things banging on the system.

Vibe coding vs. agentic software engineering

• Vibe coding and agentic software engineering are distinct activities: one is a non-technical user building something simple; the other is a professional engineer with 2–10x leverage.

• The non-technical user persona is larger than the professional developer pool — and that’s where the near-term adoption surge is coming from.

• In enterprise, the term “vibe coding” doesn’t travel well; the equivalent is building skills and automations on top of existing platforms.

• The abstraction layer keeps rising — but semantics still matters. Syntax can be generated; data models and business logic still require human understanding.

James: What’s the difference between vibe coding and agentic software engineering? When I say vibe coding, I mean someone who’s not particularly sophisticated building something — maybe it’s a reporting tool or analysis. Versus a software engineer using a set of 2x, 5x, 10x tools.

Will: There’s a completely different user persona between the professional software developer that now has these agentic tools and the non-technical user who’s now empowered to create software. We’re seeing the adoption of the non-technical user — people in sales operations, people in legal, people in finance who have never written a single line of code, who don’t understand any JavaScript syntax — who are now empowered to create their own software in a way that is easy, simple, secure, compliant.

That’s where we’re really starting to see this adoption. The other important nuance here is that the pool of users who are non-technical is larger than the pool of users who are professional software developers. And so if you look at even a technology company, you might have fifty, sixty, seventy percent of the employees falling in a category that’s non-technical, and they are now empowered to go create software.

James: I wonder if we’re gonna see the rise of strats. In banking we have the strats who were either former traders who learned how to code, or former coders who learned about markets — very fuzzy. I was wondering if that might happen in more sectors and more domains.

Daniel: I agree that non-technical users are increasingly empowered to vibe code solutions. The problem is the influx of people who are vibe coding something, white-labeling it, and pitching it as a venture-fundable startup — and it’s not. Across sales enablement, marketing, the CFO stack, I can tell within five minutes of a pitch that there’s no defensible moat, nothing that takes particular expertise or meaningful compute to maintain. Buyer beware.

To use your strats analogy: to be a great trader takes years of domain expertise and longevity in the space. The same applies here. The people who can build something special are the ones with that depth. A vibe-coded sales stack with no moat is not that.

James: what do you think of non-technical founders?

Ed: I agree that more people building things is continuing to get more abstracted. I think the word “vibe code” and enterprise just does not really mix together — I don’t think you’re gonna walk into a CIO and say, “Let’s vibe code stuff.”

But it’s the same thing. It’s the same thing as what Will said — skills. The enterprises we talk to are using skills platforms, where you can type something into your AI of choice and say, “Hey, I want to build this, add this in, and then create a skill or automation.”

That is happening, and there’s gonna be hundreds of thousands of skills out there, and you’re gonna need to manage that and package it like software. You’re gonna need a version control system where there’s a skills repo for company XYZ, where these are the approved skills, and these are security vulnerabilities that can pop up, so let’s scan those skills.

What happens when Daniel changes something that Ed made? Is that better or worse? So how do you do an eval around that? So I, I think, I think we’re gonna be moving towards a world where skills become software,

James: If you remember the late ‘80s, we went from assembler to C — people said software engineers would go away. The engineering continued.

And I wonder if two things are true here. Abstraction matters, but you still need to understand the data model, even if you’re programming in a very abstracted way.

Ed: I think what you’re talking about is that you need specialized humans. Back to your earlier point — everyone wants to get automated, but they don’t know where to start.

Those specialists can help people understand what their workflows are so they can automate them. So you need specialized skill for that. And then two, you need specialized skill for evaluating whether a workflow is actually doing what it’s supposed to do. And then what happens, for example, when a model changes — is it actually gonna do better or worse?

People are gonna be needed, and even more specialized to understand those things. And I think people are finally understanding that right now.

James: Sometimes I draw a distinction between syntax and semantics, and in an AI software engineering world, we can worry a lot less about syntax, but semantics still matters. So Will, let me ask you, are we being overly negative on vibe coding? Give us the other end of the case here.

Will: First off, I know of several examples, including one where a company, built entirely on Replit is doing well over 100 million ARR, mostly enterprise revenue.

And so you, you can build real businesses, and I think we’ve gotten to a point in the technical maturity of the platforms like Replit where you have, implicit security, you can host on a private cloud instance. You hit all the enterprise check boxes, and a lot of the code that’s now hosted on tools like Replit specifically is as good as what you would get from a junior engineer. And so I disagree with the premise that you can’t build a venture-backable company on platforms like Replit.

Ed: I’m getting my popcorn. This is fun

Will: I agree that we as investors should operate with this premise that the cost to develop software is approaching zero over the next three, five, seven, ten years — just like the premium for having more software engineers is eroding. As that skill barrier is eliminated and the cost to build approaches zero.

Daniel: Of course there’s going to be vibe coded businesses built on companies like Replit that are gonna be absolutely venture fundable and extraordinarily successful.

The barrier to entry to put a product in the market has gone to zero, which means there’s so much stuff that isn’t defensible and isn’t venture-backable. It’s a huge increase in the denominator without a proportional increase in the numerator.

James: The percentage of effort associated with the core logic, relative to the effort required to fit into a broader enterprise environment, is decreasing. The pain is now in the integration: connecting to identity and access management, compliance, the whole stack.

So Ed, how do you think about this challenge of integration? Because in many places that will be the long pole in the tent.

Ed: The last mile in the enterprise is the longest, and it’s probably getting longer. It’s not easy for a large bank or a healthcare firm or a large CIO to bet their reputation on deploying your agentic technology.

There’s a lot of stuff you’ve gotta pass — all the SOC compliance and everything else. What you’re seeing is the idea of these forward-deployed engineers showing up and just getting it to work. Part of that is a response to how hard the last mile is.

The model is: build product, then finish the last mile with people. And the learnings you get from it are invaluable. The key question is whether the most important data to own is not just the data you have to run the AI on top of, but the private evaluation of whether the outcome looked really good — because that is really the knowledge of your business. That’s what separates a P&G from another marketing company.

Are these forward-deployed engineers going in there and helping you get those outcomes? And who owns the data? Are they giving it to you? Or are the forward-deployed engineers from the model providers themselves taking that data and using it to build vertical solutions?

That’s going to be the big battle. It’s what Satya calls hill climbing — reinforcement learning feedback. The question is: if you give that to a model provider and they’re helping you improve, is that the right trade-off to make?

I think we’re moving toward a world where people want to control their own evals — which means infrastructure on the edge, private models. We need a lot better open source coming down the line. It’s still not anywhere close to what the labs are providing, but that’s where we’re gonna move towards.

Where the moat lives when code is free

• If code approaches zero cost, the competitive advantage shifts to ontology, data models, and latent institutional knowledge — the things that can’t be scraped.

• The right model for the right task matters more than any single model: orchestration layer bets are more durable than frontier-model bets.

• Enterprises that hand their outcome data to model providers for convenience may be signing their own death certificate — private evals are the new proprietary asset.

• Architecture commoditization is coming but isn’t here yet; scaling laws are still working and a step-change in model capability is 12–18 months out.

James: sometimes I wonder if code becomes free or close to free, but the ontology and the data model becomes the source of competition.

Will: It’s very possible. This goes back to a point that we were talking about earlier, you probably don’t want to bet on a single model. It’s not just about cost, it’s also about, performance in different domains. And so I think that- that’s benefit of betting on something more at the orchestration layer, where, if you’re trying to do a task, we’re using software engineering as the example here, you might be writing, some more complex code, you might need a frontier model from one of the labs.

You’re writing simple front-end code, you could use an open source model. You’re doing a design task, maybe, Gemini or another model, from a, a different provider is better at that specific design task. So I think you’re seeing mixture of experts, to, solve these

As software code itself becomes a commodity, what matters is matching the right model to the right task — and everything else that isn’t captured by coding benchmarks: platform depth, integrations with Databricks or Snowflake, security scans, the full enterprise stack.

Daniel: think having specialized humans that really have domain expertise combined with owning your data and your moat, somewhat model agnostic and having that’s what the future it’s a mixture of really great humans, different models, and, owning your data. I, companies that choose to allow their outcomes and their data to be out there for the LLMs to scrape, because they’re, they’re prioritizing speed, ultimately are, are signing their own death certificate.

James: And does architecture get commoditized?

Ed: Not anytime soon. So the answer is not today, but I wouldn’t be surprised, like in 18 months if we kinda get there, because this stuff is changing so quickly.

Will: I don’t know, but if I were to place a bet, yes. Just look at the improvement in performance over the last three years. It doesn’t appear that we’re plateauing — in certain skills or certain domains it’s actually accelerating. It’s really hard to extrapolate out the next two, three, five years. But I think if the curve continues to look like it has the last three years, it’s very possible that architecture gets commoditized.

Ed: In other words, scaling laws are actually working, and if you have the compute, it’s improving. Everyone I’ve talked to on the models they’re training now says it’s still moving in the same direction. Hasn’t been proven false yet.

James: I’ll answer my own question and say my question was invalid. Any model requires context, so it depends on explicit information rather than latent information. Models will only get good at architecture to the extent that people using them figure out how to extract or capture the latent information they need.

Ed: How much will they be willing to hand over of how their system is architected and actually operates to a model provider? That’s the question.

James: Do they even understand enough to be able to write it down in such a way that it can be consumed? Taking latent information and turning it into explicit information is not a trivially easy task.

Ed: It’s the last place that hasn’t been automated yet. If you’re thinking about most of the automations — it’s on the edges. IT ops themselves have not really been automated. Partly because people are afraid of AI just shutting things down. But I do believe we’re gonna move toward a world where there’s more trust with AI around automation of IT.

James: Let me ask a related question, maybe one that’ll be controversial. So I, I, I got myself told I was up a tree because I offered the thought that we’re gonna see more strats in the future, more, convergence the line between, business optimization and technology execution.

But then I offered the hypothesis that it may be easier to teach software engineers about the business domain than it will be to teach people in the business domain enough about data models, for example, to, sufficiently engage. I don’t know whether you call it vibe coding or agentic software engineering.

Daniel: I spend almost all of my train technical people on the business side of things. so, so I probably over-allocate to frustration in that department. So, maybe that skews my answer, that maybe it’s a little easier to teach business people, the software side, but I could go either way.

James: Ed, what do you think?

Is it easier to teach a bus- a business analyst software engineering, or easier to teach software engineers about how to think about a business problem?

Ed: I think the underlying models can be so good that what matters is the expert who knows what to prompt and ask. If you actually look at how to use LLMs today, it’s all about how you prompt — two of us could sit next to the same thing and get vastly different outputs if we’re trying to achieve the same goal.

Will: I completely agree with Ed. There are so many nuances to different problem sets or workflows. The people who intimately understand them will have access to tools that can manage all the technical complexity.

One case study from us: we vibe coded our own custom LP portal, and my co-founder, who’s not technical but who’s been running all of our operations, built this in probably 12 hours. And it’s better than anything we could find from third parties. Daniel and Ed probably lament the challenges of fund admin more than anyone else.

James: Nothing’s more fun than fund administration

Will: it’s the great joy of life. there are so many little nuances to it that I think y- you just wouldn’t understand unless you’ve spent months or years in the trenches

Ed: by the way, that goes back to my other point, is that your person that built it and you are the experts, and , you’re the ones that are gonna actually evaluate it as well. You’re the only ones that can keep evaluating everything else, right? So that’s kind of your workflow, that’s your model.

And, and your same model could be deployed at Daniel’s place and my place, but how we evaluate it and what successes might be different, right? And that’s kind of what I mean by the institutional knowledge and workflow that, that I think those private evals is so valuable to capture that

Daniel: One of your great moats is domain expertise. domain expertise can be found on the business side, and it can also be found on the technical side. It depends on what problem you’re solving and who’s your constituency.

James: I had a discussion with a bunch of 22-year-olds a couple months ago, and they were, you know, having the typical 22-year-old, ”Oh my God, any job I might consider is going to be replaced by, by AI.“ They asked what I thought would be a good thing to learn, and I said data modeling.

I don’t know whether that’s business domain or technology domain expertise, you both need to understand all the nuances of the business process, but there’s that, process of abstraction, that I think becomes incredibly important, which people who are only deep in the business domain don’t always get.

Which sectors face the most disruption

• Legal and accounting are the obvious targets — high information volume, largely objective outputs, limited customization requirements.

• James’s less obvious answer: B2B interactions broadly. They haven’t changed in 15 years while B2C was transformed. Gen AI’s ability to ingest unstructured data makes this the next frontier.

• Ed invokes Jevons: freed capacity can be absorbed by new demand. Companies that cut headcount fastest are already adding back — different kinds of people, more senior engineers, specialists.

• Robotics is the adjacent disruption no one is talking about enough. Ed’s portfolio company has 500,000 hours of manipulation data and is deployed at four large manufacturers — the ChatGPT moment for physical AI is close.

Okay, Daniel, predictions about which domain, technology domains do you think will be disrupted the most?

Daniel: I’d say I’m still a big believer in places where there are largely objective answers to questions that require sifting through a lot of information. I think legal and accounting are two of the low-hanging fruits.

Ed: I think, James, that everything is up for absolutely massive disruption right now. But I’m also a believer in Jevons paradox — because if things are cheaper and you can use AI more, you’re gonna be able to do more. And I do believe in a world of more productivity. The tech companies I’ve seen that have automated the fastest may have cut headcount and used AI as an excuse, but now they’re adding. They’re just adding different kinds of headcount — more senior engineers, different kinds of people. Perhaps the specialists you’re talking about.

So I think it’s gonna disrupt everything short term. The next two or three years will take a while to absorb the hit. But I believe in the longer term that we will actually be more productive as a society and generate more output with less cost. And hopefully you see those GDP growth numbers increasing.

James: Will, what do you think?

Will: I completely agree. If you look at any technology cycle throughout history, for the most part it’s led to wage increases, job creation, new goods — and I think the same thing will happen here over a ten to fifty to a hundred year time horizon. What we see in the next five years: the most disruption today is in two categories. Where incumbents have low-quality software products and have not innovated, you can now build that version yourself — and often it’s better, cheaper, and higher quality.

That’s our case with this fund: we built it ourselves because the incumbent alternatives were not high quality, they were very expensive, and there was a lot of low-hanging fruit.

I think the other area where we’re starting to see more disruption is in domains where software is highly customized — back to the point both Ed and Daniel made, which is that it’s really important to have deep domain knowledge specific to your workflows.

The way we build an LP portal might be different than the way Ed wants to build one, because he has nuances in his business and portfolio that we don’t. Where you have a high level of customization required to make software work for your business, there’s a lot of opportunity for disruption — both disrupting third-party software and disrupting the incumbents who have mediocre products that work okay for everyone but not great for anyone.

James: it’s what I call the one size fits none challenge.

Ed, you said in the session that you looked to fund companies that were problem-obsessed rather than solution-obsessed because, you, you iterate through different solutions, but problems are eternal.

Messiest part of, the advanced economies is B2B interactions, and that’s not just CRM, but the broad scope of all the large, complicated businesses. , Over the past fifteen years, maybe twenty years, we’ve seen an utter transformation in B2C interactions.

But many B2B interactions look a hell of a lot like they did ten or fifteen years ago, and I think that, the, the ability of, gen AI to, to ingest complicated, unstructured data to transform those domains.

Ed: I, I love that. And by the way, can I add one thing

James: Please

Ed: we didn’t talk about software and robotics,

I have a company. We’ve built our own LLM for robotics, with our own data, and we’ve proved that scaling laws actually work in robotics as well.

So I feel like we’re almost at that ChatGPT moment in robotics where a generalized robotic software model will be able to do a lot. So in other words, once upon a time where you would have to have 100 different robots or 100 different kind of brains operating and, and doing 100 different tasks, you can now have one.

And I can tell you this, that the market is moving so fast in that space, so manufacturing, pick, pack, and ship, auto manufacturing, all of those kinds of things are getting transformed. In the next three to five years, you’re gonna see a massive, massive dislocation in those markets as well

James: Is that an LLM for robotics or is that a type of world model, right? I mean, are we moving from language to physics when we talk about that?

Ed: there’s three different kinds. So the one that we have is a basically a foundational model for robotics. Other people are trying the world model approach, and what my company is doing is they’re getting their own data, right? There’s no Reddit for data.

They , ship these 3D-printed devices that goes on people’s hands that are very, cheap. we take video of people manipulating these things as if they had these grippers, and we’ve got 500,000 hours of data.

And now we’re deployed at four very large companies doing very complex manufacturing tasks all within two years. This is massively moving so fast. [3]

It’s basically building off the shoulders of giants? Because it’s already been done before, and now you’re applying it to a different realm,

James: Daniel, how bullish are you breaking the, breaking the barriers between the physical worlds when we come to,

Daniel: How can you not be bullish on it, right?

James: What’s the pace, do you think?

Daniel: One of the common themes we’ve discussed throughout this conversation — which, again, was part of the reason why I so enjoyed our in-person discussion — is the pace of innovation. It’s at a lightning speed.

Literally every week things are changing. Every day things are changing. That’s moving at a breakneck pace. But the integration of those changes — the integration of products that encapsulate some of this innovation into large businesses — is very slow.

And so I, we’re, we’re, we’re it’s, it’s one of those where you’re like in an F1 race where innovation is just lapping, the jogger, which is the, the, the enterprise integrator.

And, and so the question is how do you lean out the window and throw something that the jogger can actually digest? That’s, where the rubber hits the road, not to take the, this too far. But, that’s, where the bottleneck is.

Will: Agree with, with, everything said here and that there’s an incredible amount of opportunity for AI in the physical world. you look at some domains in manufacturing where AI is now used to inspect batteries coming off an assembly line, and it can do it, ten times faster and, fifty times better than a human inspector can.

And that’s a job that humans don’t like doing. You wouldn’t want to sit under bright, bright fluorescent lights all day and look at batteries. So I think there are incredible amount of opportunities we’re already seeing implementation, the ROI is there. But I will say, I think that humanoids broadly is probably in bubble territory.

And I say that for two reasons. I think number one, we’re very early on the S-curve and that, the, the technology is not quite there. when you start to do things in the physical world and chain together different skills and make that work successfully in an enterprise environment, the, the, the success rate has to be very high in each skill.

You know, if your success rate is ninety-eight percent in one skill, ninety-eight percent in another, ninety-eight percent a third, you’re gonna fail a lot of the time because you multiply the probabilities together.

You really need to get to like ninety-nine point nine nine percent accuracy in each skill set or each domain in order for this to work reliably over time. The second problem I think we have in the humanoid space is people underestimate how hard it’s gonna be to scale up manufacturing.

Like you go talk to the team that, that scaled up manufacturing for the Model 3 at Tesla, like it’s a really hard thing to do to go from, you know, zero to scaled production of, of complex hardware products.

And I think the sort of view that we’re gonna be shipping millions of these in two years or three years is, is probably a bit shortsighted.

Ed: One comment though. I, I agree with you on humanoids, but my company’s actually going after, robotic arms, So when you control the variables with just this and a gripper, you don’t need five joints on it to do things. that actually allows you to deploy much faster.

On the humanoid side, there’s so many more issues. Battery life is another one. Safety, what happens when the battery runs out? Does it fall on somebody? there’s so many issues there to, to your point.

The, more you constrain all the, variables and focus the processing power on the task at hand, the better off, you are in terms of deploying these things with real accuracy.

How enterprises should engage the startup ecosystem

• Routing startups through innovation teams is a trap — those teams are typically disconnected from the business owners who actually have the problem.

• VCs are intermediaries in two directions: LP → founder, and founder → enterprise. The second role is underappreciated. They filter signal from noise, translate languages, and set expectations on both sides.

• Enterprises build reputations too. Kick the tires on three companies and do nothing and VCs stop bringing deals.

• The right frame for CIOs: decide where you want to sit on the adoption curve, then match the VC tier accordingly — seed investors for early bets, growth investors for proven businesses.

James: Let me pivot a little bit. I’d love to discuss a bit how enterprises, CIOs, CTOs, CSOs, others, should interact, with venture funds and venture-backed companies.

So Daniel, let me start with you. Advice would you have, for, technology executives or IT executives at big traditional enterprises as they engage with venture-backed companies and potentially as they engage

Daniel: Absolutely. First and foremost, large businesses are structurally challenged when it comes to engaging with younger, earlier stage businesses. Some organizations have tried to address that through innovation departments or groups built to test technology. We tell our portfolio companies to avoid those like the plague, because they are typically disconnected from the business owners themselves — the folks who actually need solutions to solve problems. We as a fund try to serve as a bit of a filter there, because it’s really hard as a startup to knock on the door of a Fortune 1000 business and get any attention. Our hope is that when we help knock on those early doors with our portfolio companies, that comes with a vetting process, and an understanding that we’re gonna ask for that time only when there’s good ROI going both directions. We tell our portfolio companies to go directly to the person who has the problem — try to engage directly with the business unit.

James: Will, what are the mistakes that large companies make when they interact with venture-backed, companies?

Will: Trying to push companies through an innovation team that doesn’t really own the problem is often ineffective and wastes everyone’s time.

As an enterprise customer, you have to decide where you want to sit on the adoption curve. If you’re willing to be an early adopter and really partner with a company, I think that can be incredibly fruitful early in their life cycle — you’re gonna get a lot more attention and probably more customization specific to you.

If you’re not willing to put in that effort, if you’re not willing to view this as a partnership, you’re probably better off waiting until, other early adopters have embraced the startup and it’s gotten to this inflection point where it’s now a more mature company, with a fully baked product.

And then third, you know, a lot of, a lot of larger companies now have venture programs where they’re investing in startups, especially investing in startups that they’re customers of.

If you’re gonna have a venture program, connect that directly to the business unit that’s actually buying the software and, and understand why you’re making venture investments. Don’t just do it because you think it’s cool

James: Okay, Ed, why is it so tough for, for large enterprises to engage with venture-backed companies?

Ed: Filtering. There are just thousands and thousands of startups, and our job is to filter through all those and invest in the ones that make sense. When you partner with venture firms, you should partner with all different kinds — because there are folks that go super early, at inception. There are folks that go a click later. There are folks that invest after the company has USD 30MM of revenue.

You need to understand where you are on the innovation curve and figure out which venture capitalists you’re willing to engage with to see what they have.

And we as VCs have to be very careful as well. We’re not gonna throw something at an enterprise knowing full well that it’s gonna be an 18-month sales process — because that could also kill the startup, but also we don’t want to waste your time.

It’s all about trust and reputation. On both sides, you have to figure out what you’re willing to show an enterprise to say that it’s ready for deployment. Maybe the company and team have actually built something new, and they’ve done it 30 times before — so therefore there’s trust.

And on the enterprise side too, they build reputations as well. Because if you kick the tires for 18 months and do nothing with three companies, VCs will say, “Don’t ever go to them again.” And therefore that enterprise might miss out on innovation.

It’s a two-way street where you actually have to trust each other.

James: How do you think about the filter? How do you think about who to speak to versus not to speak to?

Ed: Well, it just comes down to people though, right? It’s all about the people, right? You want people that move very fast that actually can solve a problem today, but also presents a kind of vision to solve your problem 18 months from now.

And that’s what we look for, and hopefully you come to us and we can present the founders that actually do the same

Will: The bar for speaking to somebody is very low. I’ll try to speak to as many people as possible. But for us, us to actually make an investment, we’re, we’re investing at a different stage, and so typically the companies that we’re investing in already have tens or even hundreds of millions in revenue. It’s a real business at that point, and the question is not will this succeed? Do they have product market fit?

The question is, what is the sort of revenue scale gonna look like five years from now? And what are the unit economics gonna look like five years from now?

We’re asking a fundamentally different question , than Ed or Daniel are when they’re making investments. We have a set of criteria that we filter to. We look for technologies that are inevitable, . There’s adoption, but we’re early on the S-curve. We look for markets that are default dominant, where an outcome is gonna be an oligopoly or a monopoly.

To Daniel’s point earlier, we don’t like markets that are commoditized, where you have hundreds of companies without any real moats. And then finally, we look for what we call dynastic DNA. It’s really about the people. Is this founder pursuing their life’s mission? Do they have the wherewithal and the fortitude to push through over the next ten, fifteen, twenty years to build a large, enduring business? Can they attract amazing people around them? Do they move at a high velocity?

James: So it’s your job, Will, to, speak to people, but if you’re a CIO or a CTO, it’s like, well, it’s my job to keep the business up and running, and I got, some number of hours per week to go speak to people, and an infinite amount of demand to be spoken to. So what’s your advice for someone who in an enterprise, role

Daniel: very nature of the venture business and the very nature of us having a funnel that ultimately results in a set of investments means when we are, making intros and trying to have conversations with corporate decision-makers,

if you ask for a busy person’s time and you do not use it effectively, you will not get it again. it is my, desire to be able to go back to the same folks time and time again when there’s an opportunity that’s relevant.

And so by the time I’m asking for the time of an enterprise CIO or an enterprise CISO, I’ve done my homework. I have done the work to know that even if it doesn’t result in an investment for us, it’s going to be a good use of both of their times.

Ed: It’s always not us pitching them. I find the most value is when I talk to CIOs or CSOs and say, ”Hey, what’s top of mind for you?“ Maybe once a quarter I have, like, a dozen folks I’ll catch up. ”What’s top of mind for you? What are the biggest problems you’re seeing? What are the existing, incumbent vendors not providing for you? What do you wish you had? What are you thinking about building?“ Right?

Because a lot of the things that startups end up creating are things that companies want to build themselves, right? So I think that’s part one. So once we understand that, we can say, ”Hey, I’ve got this one or that one.

We funded a company, um, you know, like a year and a half ago in the agent identity space. I, I walked into a very large bank and we just said, “Hey, look, I would love your feedback.” And, and they had eight people in the room. We spent an hour together. We, we mapped out what our architecture would look like, what problems we’d solve.

And then guess what? We went away, built stuff, raised rounds of funding, came back a year later — not only did we show that company that we had built everything, but we also showed them what the forward roadmap was.

And I remember as I was leaving the room, three of them were huddling in the corner and saying, “Holy shit, did you see what they built in the last, you know, year?” We built it really fast, and then we had a future vision that kind of aligned with theirs. Another thing: we’re not expecting a sale. We want feedback. Why wouldn’t you provide feedback and spend the time? And then if we come back and make the mark, great.

James: You assume that VC funds serve as an intermediary between limited partners and founders. They channel investment to companies. But what I’m hearing here, and have heard in previous discussions, is you’re just as much an intermediary between startup companies and the enterprise — helping founders understand the enterprise, and helping the enterprise understand how to engage with startups.

Is that, is that a fair way of thinking about it?

Daniel: Absolutely. I have two track records. I have the track record to my LPs, and I have the track record to the entrepreneurs we back. And the track record that is for the entrepreneurs we back is: how many customers did I help you get?

How many versions of your product did I help you think about? how many key hires did I help you with? those are all critical things that are on the company support side of things. and it really involves being an intermediary with the enterprise, and understanding how to translate different languages.

A startup speaks a different language than a large enterprise. You gotta have somebody in the middle ideally making that translation

Ed: Look, I’ll toot our own horn here for the three of us — I’ve been doing this for 30 years, and not every venture firm does this. So if you’re a founder building in this space, come to guys like us who actually do this every single day, because we learn a lot during the process.

But all I’d like to say is our job is to help it, help you make it an unfair fight against your competitors so that, so that when you get funding from us, that we’ll , accelerate your path to your next round of funding and kind of product market fit or post-product market fit, depending on the stage.

One or two influential customers at the beginning of a company’s journey, like, of their first five customers, can actually reap tremendous dividends, create so much value, multipliers of value based on the contract size.

By the way, the contract size does not have to be massive. perhaps, James, that enterprise gets a massive discount in year one. The point is those referenceable customers are so massive for the success of the business because what you really want that CIO or CTO doing is talking to the next four or five large customers coming down the pike.

James: Will you invest in s- companies a little bit further on in the journey? How is your experience or your model similar or different?

Will: For a company that’s just starting out, having an Ed or a Daniel on your cap table is really important. It’s almost like they’re an extension of your founding team, to the extent that they can broker these relationships and help you navigate the enterprise. For us, the set of problems that a founder is facing is different.

They have often overwhelming market pull. The problem is not finding customers, the problem is scaling up the organization to meet the demands that you have. And so we try to help out a different way. It’s always great to bring customers. We try to do that where it makes sense. But I think often it’s more about talent.

It’s bringing in people who can scale, help you scale from 100 million in revenue to a billion in revenue. It’s more sort of strategic finance, and so how do you think about bringing in some of the larger crossover funds that will be shareholders, through an IPO and into the public markets?

It’s thinking about the next act. You have one product line that’s extraordinarily successful. You know, how do you start introducing a second product line in parallel, your second act? And so often we’re helping founders, navigate a different set of challenges than, than Daniel or Ed are.

Should you leave to found a company?

• The most compelling founding stories come from insiders who experienced a gap, built a workaround, and realized others had the same problem. Coralogix is the archetype.

• Ed’s checklist: Is this a market of one, or a market of many? Have you talked to peers at other companies? Who owns the technology? Who are you bringing with you?

• Domain expertise is necessary but not sufficient. The ability to abstract — to see that what solved your company’s problem could solve a category — is what separates a founder from someone who built a useful internal tool.

• Will’s criteria at the growth stage: problem obsession, grit, and “dynastic DNA” — the willingness to push past a billion-dollar exit toward a hundred-billion-dollar company.

James: So not infrequently, I have people working in enterprise technology organizations come to me and say, “Hey, I’ve done something really cool. I think maybe I should build a company out of this.” Maybe the grass is greener outside. Daniel, how do, how should someone think about that,

Daniel: Some of our most successful investments have come from that exact process where somebody is, at a business, they are experiencing a gap or a problem, and given their knowledge of the problem, their knowledge of the domain, decide, “Hey, I’m actually going to leave the company, and I’m going to build the solution I was looking for,.”

And, one of the, a, a really exciting company where we were involved from day one in the observability space called Coralogix is literally exactly that story, where , the founding team there was literally a product team at another business that built a solution they couldn’t find to buy. That’s a , very compelling, thesis. the challenge is a lot of times that thesis isn’t always right. The best thing to do is talk to guys like us, right? , Have a conversation while you’re still, ideating. Ed gets involved a little earlier than we do, we regularly meet with and advise founders that, aren’t yet founders.

They haven’t yet left their job. They don’t exactly know what they’re doing, but they’re really smart. They know their domain. They want to stay in the domain, and we want to stay close to them.so you gotta test the thesis, but you gotta test it with a toe in the water, not, jumping in the whole way, y-before that.

I, I, I always, when, when founders come to me and they say that they’re onto something big, I always say, “Show me your work. what validation did you do to, to achieve that conviction?” and to the degree we can be helpful in building that case with the founder that leads into an investment, great. but you gotta do the work to validate.

James: Ed, what do you think? And in particular, how should someone, what questions should someone ask themselves or him or herself,

Ed: There are a few lenses. You should have conversations with folks who do this. two is I think you should think about, is my solution a market of one, a market of a few, or a market of a many, ? Because I, I’ve talked to lots of folks building stuff, and they think they’re on their aha moment, but really their organizat- organization is so special that, I, I think it’s a snowflake, right?.

James: Abstraction is important

Ed: Do your homework, right? Also understand what’s in the market, ‘cause a lot of times also when you’re internal, you don’t understand what the other startup vendors are doing or what the other large incumbents are doing.

Like, why? Why is this built? Why’d you have to build this internally, doing a startup is really effing hard. You have to be absolutely stupid, insane, and crazy to go do a startup right now, and so I’m just warning you right now, it’s not all glory. It’s actually mostly 99% pain and 1% glory, right?

And, and so, so you better be pretty, pretty sure about that when you go out. And so let’s just have this conversation. A few things I’ll ask, will be understanding how’d you come to the conclusion that there’s just more than you. Have you talked to other people at other companies, your peers, for example, at other companies that might want to buy this solution? Two is who owns the technology? Are you gonna actually go leave and rebuild it yourself, or are you gonna spin this out of a larger org, and then perhaps maybe give them some equity, which also opens this a whole, a whole new ball of wax. I’ve tried that before, and that ends up becoming a very long legal nightmare.

I’m not advocating for that. You might be better off just going out and creating your own thing. If you’ve been locked in a corporate, corporate environment for, for 10, 15 years, man, I, I don’t know if you can... if you have even the stomach, that you can be a founder. so prove it to me, man. your, your salary’s gonna be 1/10th and 1/15th what you had before. It’s all gonna be about the equity. Who are you bringing with you? i-i-if you tell me, “I got five or six people I’m bringing with me” , I’m gonna know that you can recruit people, right?

I mean, those are the things you’re gonna have to think about once you get past even the does this make sense.

James: Will, what are, what are, what’s your observations about people who make for successful founders?

Will: I think first off, you have to be obsessed with a problem that you’re solving. I think that’s, that’s table stakes. And I think second, you’ve gotta have the grit and the fortitude to push through all the pain, all the moments of near death, all the suffering, and keep going and going. And for us at least, in the stage we’re investing at, we’re investing not because we think this could be a billion-dollar company.

Often it already is a billion-dollar company. It’s because we think it could be a $100 billion company. And any rational founder that got a billion-dollar offer , would sell their company and make tens or hundreds of millions of dollars and go retire.

It’s the people that, that have that fortitude, that grit, that drive to keep pushing farther and farther. And I think, it, it can happen. You look at one example is Daniel Dines, the founder of UiPath. he worked at a big corporate before, and, he decided to leave and, and start UiPath, and it took him, I think it took him, if I’m not mistaken, like six years to go from, zero to a million in ARR.

It was just this brutal slog. And so, you know, you look at that, and then obviously they went from, one to 100 million very quickly and, and now it’s a, it’s a large public company. And that’s the journey you have to expect going into this.

Daniel: Well, and also someone who can win, right? I, one, we talked about problem-obsessed. Absolutely. We talked about grit. Absolutely. we define it internally as like, do we think someone can win in their market? because it’s not enough to just have a good product.

It’s not enough just to, you know, have one of these pieces. You have to have all of the pieces, and you have to be resilient the entire way.

It’s actually one of the reasons why we focus on the Israeli ecosystem. , Really resilient founders, that have to persevere and go through a lot, that deal with real-world problems at a much younger age, that do their national service, that deal in real-world environments. and it creates a, a bit of a different type-built entrepreneur, someone that can, get up when they’ve been, you know, pushed over and, you know, when the market punches you in the face, you gotta get up. and that is , critical to being a successful founder.

James: All right. Let me ask for final words.

Will: I would say if you are a CIO or CTO trying to figure out where to spend your time, look inward. A lot of the most successful AI companies we’re seeing, at least at the application layer, are seeing incredible pull from the bottom up rather than being pushed top down. Go to your functional leaders, figure out where their problems are, figure out where they have pull, and focus your time and energy there rather than filtering all the people banging on your door trying to sell solutions top down.

Ed: Um, I would say that the time is now, right? Just don’t wait. Start small, start somewhere, just get rolling right now, and then don’t be afraid to throw things away. because I can promise you that by the time this podcast probably comes out, I know you’re fast, James, but the world may turn again one more time or two more times, right?

So whatever we say might be 90% irrelevant and 10% relevant right now. So I think the world’s just moving so fast. If I were a CEO or CIO, I would just build my own stuff on the weekend just to really understand the power of it.

That’s the only way you get to know these things

Daniel: We’re entering a really interesting moment where there’s not such a stigma anymore to try new things.

Companies need to look inward — to Will’s point — to really build the capabilities to integrate. And I think there’s openness now to try new stuff.

You’re not gonna get fired anymore for giving something a try. And I think that makes it a really exciting time to be an enterprise executive who can, to Ed’s earlier point, really put your foot on the gas on productivity.

James: Thank you all. This has been terrific.

Implications for CIOs and CTOs

Three things you probably expected going in: VCs are optimistic; enterprise AI adoption is early; legal and accounting are the obvious targets. One thing you probably didn’t: enterprises build reputations with venture funds too. Bring three companies through your procurement process, commit to nothing, and the introductions stop. The world is far enough from 2007 that waiting is no longer neutral. It has a cost now.

Footnotes

[1] Ed is referring to Fin, the AI customer service company formerly part of Intercom. Salesforce announced the acquisition for USD 3.6B — above Fin’s ZIRP-era financing round, as Ed notes.

[2] The imbalance is structural, not cyclical, and the data supports Will’s claim. On the demand side, Epoch AI data shows frontier model training compute has been expanding at roughly 5× per year since 2020. On the supply side, the global stock of AI chips is growing at approximately 3.4× per year — aggressive, but mathematically insufficient to close the gap.

The constraint is no longer primarily silicon: transformer lead times have stretched from one year to five years (Bessemer Venture Partners), and RAND Corporation projections show single training runs scaling toward 1 GW of power per site by 2028 — approximately the output of a nuclear reactor.

Broadcom’s Q2 disclosures illustrate the production gap directly: bookings for AI accelerators surpassed USD 30B against USD 10.8B in actual shipments. The one credible counter is algorithmic efficiency improvement (~3× per year), which could flatten demand before infrastructure matures — but that remains a scenario, not a trend. For the physical infrastructure constraints in more detail, see my conversation with Harqs Singh of InfraPartners.

[3] Ed is referring to GeneralistAI, a foundation model company for robotics — Boldstart Ventures portfolio. Ed is an investor.

They responded. Then Senate Majority Leader Lyndon Johnson said Americans would not go to sleep by the light of a Communist Moon. The National Aeronautics and Space Act of 1958 created the National Aeronautics and Space Administration (NASA) with responsibility for the American space program. The National Defense Education Act of 1958 sought to dismantle John Dewey’s legacy in American education, pushing schools to replace “life adjustment skills” with set theory and symbolic logic. Less than 12 years after Sputnik, Neil Armstrong and Buzz Aldrin walked on the surface of the Moon.

Share

Could Anthropic’s recent announcement of how Mythos can identify and exploit cybersecurity vulnerabilities create the Sputnik moment that will spur companies to use AI to change the way they operate enterprise technology?

The risks are real, and companies will need to move beyond buying tools and to build an agentic governance loop that uses a living graph of the environment to provide the context for spec-driven, immutable engineering, verified by adversarial automation rather than manual bottlenecks -- and then sustain and expand this change over time.

• Despite early indicators of transformative improvements, AI adoption in running enterprise technology has been shallow.

• Despite some fear-mongering, the impact of AI on the cybersecurity balance of power between attackers and defenders has been muted to date -- Mythos and subsequent models could change that.

• Mythos and subsequent models could dramatically improve companies’ cybersecurity posture in the medium term -- but they will need to use AI to accelerate their enterprise technology metabolism dramatically.

• Of course, the idea of a Sputnik moment is as much a warning as a call to action -- one-time programs are a lot easier than sustained cultural change.

AI adoption in running enterprise technology has been disappointingly shallow

Technology engineering and operations is one of the most exciting applications of AI for large companies. Large language models excel at interpreting and generating the structured content used in software engineering or technology configuration. AI can replace procedural programming with declarative programming [3], via spec-driven development. Agentic processes can better accommodate the edge cases and exceptions that have historically bedeviled efforts to automate technology operations. The early results have been exciting. My McKinsey colleagues have found that using AI to reinvent engineering processes can double team throughput. AWS has started to use agentic processes to reduce incident resolution time by three-quarters in some cases. Applied ruthlessly, AI could transform the economics of enterprise technology.

Yet adoption has been shallow. In last year’s DORA State of DevOps report, 90 percent of software practitioners said they use AI in some way, but most never used it in agent or autonomous mode and only 17 percent used it every day. The situation is no better with the cybersecurity team. According to a SANS report, Security Operations Centers use AI/ML tools, but don’t integrate them into their processes:

AI is present inside the SOC but not operationalized. Analysts use it informally, often with mixed reliability, while leadership has not yet established a consistent model for where AI belongs, how its output should be validated, or which workflows are mature enough to benefit from augmentation.

All this accords with my own observations: technology teams use AI as a tool to generate a code snippet or research an issue, rather than a lever to rip toil out of the way they do business. Why is this? The technology is still relatively new. Teams may be cautious or may not have the mental bandwidth required for change. Vendors have promised just installing a tool will solve their problems. And CIOs have not built the institutional support required to fund and prosecute the required change.

Mythos could change the cybersecurity balance of power between attackers and defenders

Since OpenAI released ChatGPT 4.0 in 2023 the great and the good have warned us about AI-enabled cyberattacks. The World Economic Forum said that specialized language models would allow hackers to get around endpoint security devices. The FBI said that AI would allow criminals to scale fraud schemes in a way that would swamp law enforcement. The UK’s National Cyber Security Centre said that GenAI lowers the barrier to entry for novice hackers allowing them to use vectors previously only available to experts. Some predictions approached fear-mongering -- sentient malware and HackerGPTs collapsing cybersecurity defenses. [4]

The worst...has not happened. I checked this morning, and the digital world continues to function. Only 16 percent of companies suffering breaches said they saw evidence of AI in prosecuting the attack. According to the Verizon Data Breach Investigations Report attackers have been just as dilatory as enterprises in using AI to reinvent their business processes:

It turns out the state-sponsored actors are just like legitimate organizations in their GenAI implementation life cycles. Attempts are being made, maybe some improvements are being found, but no one is revolutionizing anything yet.

At least as of 2024, GenAI tools could potentially assist attackers, but could not execute sophisticated attacks for them. One analysis found that GPT-4 only achieved a 7 percent success rate in exploiting vulnerabilities without clear human guidance.

Even before Mythos, the potential and the direction of travel have been worrisome. The structural factors that make LLMs effective in building and running systems also apply in compromising them.

• Intel matters in undertaking a cyberattack. LLMs have breadth of vulnerability knowledge no human analyst can read or retain -- LLM training data spans public CVEs, security research, disclosed exploits, and documented attack strategies.

• Success requires patience. Agents will cycle through potential vectors without boredom or fatigue.

• System compromise provides agents with a clear objective function they can optimize against.
  
  As a result, researchers have started to demonstrate that teams of LLM agents can cooperate to exploit zero-day vulnerabilities

Then came Mythos. Obviously we should be restrained in thinking about the implications of any software that isn’t generally available yet. And we’ve heard the too dangerous to release warning before. In its public statements, Anthropic said that Mythos had identified thousands of high-severity vulnerabilities across major operating systems and browsers—including legacy flaws like a 27-year-old bug in OpenBSD that evaded decades of manual audits. The model further demonstrated the ability to build complete, working exploits. Mythos can independently “chain” multiple vulnerabilities to gain a foothold, escalate privileges, and move laterally through a network, effectively allowing users with no formal security training to execute professional-grade, multi-stage cyberattacks at machine speed. Finding zero-days may get the headlines, but the ability to scale and operate autonomously may create the real risk.

This probably won’t realize the most dire predictions of 2024. [5] Several commentators have observed that a model’s ability to identify vulnerabilities and form plans doesn’t mean it will succeed in the face of sophisticated defenses (including the ones they have developed). But how many companies have sophisticated defenses like zero-trust in place comprehensively? And one compromise in the software supply chain could disable hundreds or thousands of institutions. Naturally, Anthropic and other frontier labs will seek to implement guardrails that limit attackers’ ability to exploit their models. The guardrails will not be perfect. And they will not apply to many of the open-weight models that will likely have Mythos-level capability within, maybe, a year.

Mythos and subsequent models could dramatically improve companies’ cybersecurity posture in the medium term. Could, not will.

After the Mythos announcement, American business and governmental elites acted. Anthropic delayed general availability of Mythos and launched Glasswing, giving early Mythos access to leading technology institutions so they could use it to identify vulnerabilities. Treasury Secretary and Federal Reserve Chair Jerome Powell called banking CEOs to Washington DC so they could urge them to take the risk seriously -- I expect they were pushing on an open door. Technology companies like AWS, MSFT, CRWD and CSCO reported that they were using Mythos to harden their products.

In the medium term, Mythos (and subsequent models) could provide a dramatic uplift in cybersecurity defenses. Companies spend fortunes each year scanning their code for vulnerabilities [6] -- Mythos-type capabilities will provide a level of transparency into vulnerabilities that we never could have imagined before. Most companies of any size do penetration testing, [7] but only the biggest tech spenders have dedicated red-team operations that figure out how a sophisticated attacker might compromise their environment. Mythos-type models should make this capability available to a much broader range of companies.

They may also revolutionize cybersecurity risk management and cyber insurance. Cyber-risk valuation frameworks like FAIR have foundered on the problem of likelihood assessment. Practitioners should be able to use a model like Mythos to simulate attack paths, determine the probability of success and make more fact-based remediation decisions. It could also revolutionize cyber-insurance, a segment historically held back by underwriting challenges.

And yet -- speed matters, and manual remediation is too slow. Mythos can help companies identify vulnerabilities. But identification protects nothing unless companies apply security patches from vendors and install fixes to code they have developed internally. That is the remediation gap the governance loop above is meant to close; in practice it breaks down into three concrete moves:

1. Create a living graph of your technology environment. You will very quickly face an overwhelming pipeline of vulnerabilities to remediate and vendor patches to apply. Not every one will be equally important, and the most critical nodes in your environment may not be immediately apparent given all the dependencies among business processes, systems, data and technology infrastructure.

Modeling your environment as a graph will allow you to identify the most critical nodes and prioritize what to remediate first. Ultimately every node in the graph should anchor in a non-human identity -- don’t connect IP addresses; connect non-human identities. Building the graph will also be an important step in moving to a zero-trust architecture.

2. Use spec-driven engineering to get to policy-driven systems. If you have bespoke software you will need to fix it. Autocomplete (or even asking models to write discrete code blocks) will not allow you to move quickly enough.

You need to retrain your engineering teams on how to use agents to diagnose root causes, build PRDs and execute on them autonomously. And you may need to do this on a timescale of months, not years.

As you develop strong capabilities in spec-driven development, you can accelerate efforts to retire technical debt, resulting in a more resilient environment. And you will want to define architecture, configuration and behavior in terms of policy-as-code so you can repave systems that demonstrate drift.

3. Move change control from human analysis to proof of safety. In many companies, the change approval board acts as a brake and a bottleneck on evolving the environment. It doesn’t have to be this way, and it cannot continue to be this way if companies seek to remediate the vulnerabilities Mythos identifies before attackers can exploit them. Heavyweight change approval processes are often ineffective. Teams of agents may collaborate to form an automated patch management pipeline.

Before you deploy a change, it must prove itself in a sandbox, both in terms of whether it breaks something and whether an adversary agent can compromise it, replacing the bottleneck of human analysis with the proof of safety. And you should deploy changes in stages, testing impact as you go. For years companies like Netflix have reconciled speed and safety by using canary analysis for staged change deployment.

None of these interventions are simple. [9] All will take attention, effort and time. But what is the alternative? Outsourcing might help, but it doesn’t remove the remediation burden at a stroke. Waiting for regulatory guidance (across dozens of jurisdictions and agencies) is uncertain and will likely take too much time. The age of security by obscurity is over. The cost of stasis may exceed the cost of change.

One-time programs are a lot easier than sustained cultural and organizational change

Less than a dozen years after Sputnik, Neil Armstrong and Buzz Aldrin explored the Sea of Tranquility. Ten more astronauts walked on the Moon in the next three years. Then, nothing. What poverty of the human spirit, what richness of bureaucratic incompetence caused us to tread on the moon and then retreat, without returning? Only this month has any human again transcended low Earth orbit?

Sputnik was a shock to the American educational system. By the 1980s, the National Science Foundation warned that Americans were in danger of scientific illiteracy. Shortly afterwards, the famous Nation at Risk report warned that post-Sputnik gains had wasted away. Not all the news is bad! American students have made large gains in fluid reasoning in recent decades -- and the dire standing of American students in global league tables may have more to do with compositional effects than school performance. But some of the news is really bad -- math scores have collapsed in the wake of Covid.

Just like a space program, the exploitation of AI in the enterprise is a generational project. Just like education reform, the ability of enterprise technology to use AI to build, run and protect systems is a foundational capability. Will your company move quickly enough to respond to the immediate challenge posed by AI-enabled cyberattacks? Will it sustain focus and attention over time to foster the capabilities to use AI not only to protect existing systems but to also make transformative leaps in business innovation, efficiency and resiliency?

Footnotes

[1] A great book. I read it every year in high school. The movie is pretty good too.

[2] Might I be evoking Arnold Toynbee’s theory of civilizational challenge and response here? Maybe.

[3] SQL is overwhelmingly the world’s most used declarative programming language. Perhaps its adoption provides the best historical parallel for spec-driven development. Replacing all the technical minutiae required for a query with a few SQL statements turned weeks’ worth of work into minutes.

[4] References not provided in order to protect the guilty.

[5] At first glance, you might ask: “How much does this matter for the enterprise? Once you get past the national security domain, how many attacks rely on zero-days?” More than you might think: a Mandiant analysis found that 70 percent of serious breaches they tracked involved a zero-day exploit. And of course a capable agentic attacker could assemble a sophisticated campaign out of a series of n-day exploits.

[6] The global security and vulnerability management market will shortly grow to the USD 20 billion.

[7] Itself a billion-dollar market.

[8] Special thanks to my colleagues Rich Isenberg and Charlie Lewis on these topics.

[9] These changes will require coordination across the technology organization. The infrastructure team will likely have to build the living graph of the environment, with input from each application team. Your core architecture or engineering team will lead the transition to spec-driven development, but much of the work will fall on application teams—and on infrastructure teams as they move from configuring systems to automating services. Transforming change control and patch management will require collaboration across the developer toolchain, infrastructure, and cybersecurity teams.

Thanks for reading Prosaic Times — share the entropy with a friend!

Share

1. Every computer system we build is an imperfect representation of reality

“No, I didn’t go to Catholic school. Why do you ask?”

An eminent partner at a previous consultancy looked at me across an empty conference room and explained: “You have an instinct for mapping data onto a grid -- you have a Cartesian mindset, which many good consultants learn from a Jesuit education.”

Grids distort as much as they reveal. We’ve all seen (or built) grids for evaluating outsourcing vendors: 20 points for stability, 30 for service quality, 30 for cost, 10 for innovation. These never produce the right answer -- they ignore non-linearity. You won’t select a vendor below your financial stability threshold no matter how cheap; once a bidder clears it, you care about cost and service, not financial stability.

Every slide, every analysis, every system is an imperfect representation of reality. CRM systems are a simplified model of how your business interacts with customers. Operational systems are a simplified model of your factory. I learned this crawling around telecom carriers in the 1990s, where you had to ask the service techs which USOC “1FR” lines had bridge taps that had to be removed before upgrading to DSL.

2. The world is entropic

Do you know whether that deal will close next week and at what price? Whether your flight to Chicago will land on time? Or whether a new employee will turn out to be a hero or a goat? I do not.

As a recovering history major, I believe the past provides counsel on the future. On June 21, 1948, the Small-Scale Experimental Machine became the first computer to run a program stored in its own electronic memory -- 128 bytes of it. Weeks later, Weaver and Shannon published articles foreshadowing many of the problems we struggle with today: automating Byzantine business processes, capturing latent or ambiguous data.

Shannon defined entropy as average amount of uncertainty in a probability distribution. [1] Maybe that’s okay -- in a world without entropy no business could exceed the risk-free rate of return. The more entropic a domain, the more information required, and the more expensive the computer system to automate it.

Weaver laid out a relationship between complexity and uncertainty. Some problems are simple: hold all variables constant except the dependent and independent ones, and you get the steam engine, the automobile, the telephone. A payroll system is the modern analogue -- fixed variables, describable rules, few feedback loops.

Starting in the late nineteenth century, scientists attacked problems of disorganized complexity. Statistics could predict the frequency of calls in a telephone exchange or the claims paid by a life insurance company, even when individual causes remained opaque -- provided each data point was atomic. Fair Isaac developed the FICO score on this basis in the late 1950s.

Then Weaver addressed problems of organized complexity -- macroeconomic management, ecology -- where many inter-related factors multiply uncertainty because each may influence the others in non-obvious ways. Neither nineteenth-century analytics nor twentieth-century statistics could handle them. He hoped new computing devices might, and pointed to the operations research developed in the Battle of the Atlantic as a way forward.

Problems of organized complexity abound in modern business -- order-to-cash, pharmaceutical manufacturing. Given enough contracts, even payroll can turn into one. [2] How much time do knowledge workers spend massaging data into or out of enterprise systems because the system couldn’t capture every exception the domain implied?

We should forgive Weaver for not foreseeing the organized complexity required to address organized complexity -- ERP programs suffer their own, and enterprise technology functions suffer from it themselves.

Writing with Shannon, Weaver named another contributor: latent meaning. Ask an account executive the status of a potential sale and she might say “We’re in final price negotiations with the CHRO and he would like to get a deal signed within the month, but the general counsel is hacked off about a couple of legal terms we require and the CHRO heard he is going to call the CEO and ask that they reopen discussions with another bidder.” What is she supposed to select among the four CRM choices for “status” -- RFP open, RFP submitted, financial negotiations or closed?

Weaver and Shannon identified one more problem -- whether a system creates the desired behavior in the people who interact with it. Think about computer systems the way the military thinks about weapons systems: as inclusive of both the technology and the user. Design choices affect user behavior in unpredictable ways. Complicated interfaces cause users to resist entering data, or to prejudice what they enter to make themselves look good.

Calendaring is deceptively entropic. If Suzy, my assistant, asks me about a conflict at 10 am on a Tuesday, I might say: “I’ll go to the meeting with client 1, because I think that colleague A can cover me in the meeting at client 2. And don’t decline or mark me tentative for anything, because I don’t want anyone giving away the time slot because I might not be there.” I don’t verbalize dozens of assessments about people and situations that shape my decisions. You have entropic communication about organized complexity, latent information and adaptive behavior all in a couple of sentences!

3. Entropy creates cost and frustration when we build systems to represent it

How much time do we all spend in conference rooms debating how much granularity the data model should have -- and how we balance fidelity to the business process versus the cost of maintaining data? How frequently do you find the correct state for a transaction not in the fields designed to contain it, but in the free-text notes or the accompanying email? And how much user anger derives either from the endless fields (specified to capture the subtleties of state) or the disconnect between what the system says and the reality they observe?

Put another way: how much time do we devote to designing around entropy when we build systems? And how much frustration do we create because of the choices we make in doing so?

Operational systems work best when the world can be reduced to stable categories, deterministic workflows, and enumerable exceptions -- all these make a domain easy to formalize. Nobody complains much about most payroll systems because they apply a bounded number of explicit rules to available data.

Analytic systems work best with huge sample sizes and a few relevant independent variables -- making the entropy here tractable to statistical analysis. Machine learning systems for pricing consumer products work because massive amounts of structured data allow probabilistic inference where humans might have struggled to discern patterns.

Other domains and use cases have more intractable entropy. Systems to support treasury management for large enterprises? Modeling a thousand-page contract, involving hundreds of legal entities, dozens of jurisdictions and a thousand different exceptions you can have for a transaction -- all of which generate entropy. Which messiness must you model and which can you simplify away? CIOs have exceeded budget, blown deadlines and angered users in seeking to answer that question.

Yes, machine learning has blunted the impact of entropy in some cases by sniffing out the relationships among variables, but often the sample size is too small and the data too messy for traditional machine learning to be effective. Years ago, someone said collections managers could offer definitive recommendations about how to reduce losses -- why couldn’t CISOs do the same when talking about how to protect the business against cyberattack?

I tried to explain that each demographic segment included millions of households. You could experiment with a new script and quickly determine whether it increased or decreased promises-to-pay. Any large company’s technology environment is a snowflake -- even two companies of similar size and in the same sector may have radically different technology environments. Vulnerability depends not on individual decisions, but on how you connect all the pieces in your environment. And you might not know whether you had been breached for years, if ever. [3]

4. GenAI-based agentic systems process entropy

Deterministic systems cannot process entropy. They can rely on humans to pre-process it for them -- as happens when product managers and engineers sit in a conference room debating how to capture the data required to automate an ambiguous process. They push it on to users like account managers who must fill in endless fields about their pipeline -- and still wonder which option they should select to describe deal status. Or they can store it inertly, like the free-text notes that exist in some customer service platforms. All of these imply some combination of low efficiency and lower effectiveness.

When large language models process text, they convert tokens into vectors, points in a high-dimensional space. This encodes meaning through proximity -- similar meanings cluster together. Large language models can do things deterministic systems cannot do or do poorly:

• Allow inference across stored entropy: Written and spoken language are entropic. Vector embeddings allow LLM-based systems to query and analyze free-text notes, email threads and meeting transcripts.

• Identify implicit relationships: Vector geometry represents connections between concepts, such as the general counsel wanting to block the deal for group health insurance because he disliked the contract terms.

• Understand gradations rather than discrete states: A deterministic system requires the account executive to choose whether the deal has advanced to final negotiations or not. A vector representation of the same situation can sit between two states.

GenAI-based agentic [4] systems give us new ways to process entropy.

• At design time, by using software engineering agents to create business logic that reflects all the organized complexity that Weaver described.

• As part of the user interface, to mediate between the entropy of written language and a deterministic system, rather than forcing the user to do the work.

• Via data ingestion, to derive insights from the massive stores of entropic, unstructured data every enterprise has sitting on its servers.

• At run-time (either with or without a human in the loop), to make decisions and execute transactions non-deterministically.

We can also store data used and produced by agentic systems in different ways. Traditional relational databases excel at storing and retrieving massive amounts of transactional data at speed and with near-perfect reliability. They struggle with more ambiguous data, with dense relationships among all the elements. [5] We can choose to store this data either in vector databases or in knowledge graphs.

5. You have choices about how and where you use agents to process entropy

So much of the agentic discourse we see mirrors the flat Cartesian mindset captured in the grid used to evaluate bidders for outsourcing deals. Agents are risky! Or: everything will be an agent!

But entropy is, well, entropic. It varies in scale and shape from business domain to business domain. Sometimes it takes the form of a dense web of interconnections among idiosyncratic products, contracts, processes or customer relationships. Sometimes it takes the form of latent data that doesn’t fit into any data structure you might define. Not a few business domains suffer from multiple forms of entropy.

GenAI-based agents also have disadvantages compared to deterministic systems. GPU-based inferencing is slower and more expensive than CPU-based processing -- a single agentic transaction often costs cents and adds hundreds of milliseconds, where the equivalent deterministic transaction costs fractions of a cent and resolves in single-digit milliseconds. Non-deterministic systems are only as good as the context they receive. An agentic system can process the free-text notes in a CRM platform. It won’t know anything about the discussion two account executives had in the car on the drive back from the customer site. [6]

Abjure the false binaries -- you have real choices about how and where in the value chain you process entropy.

• Agentic software engineering: This will be relevant for almost any systems effort. It will allow you to automate all the business logic required to reflect organized complexity with more speed and reliability and less cost. And after agents help you develop the code, you can still apply all the quality assurance mechanisms you have developed over decades, just as you would code developed by hand.

• User interface: Retain traditional interfaces for situations where users have to enter small volumes of easily understood data. Develop agentic- or chat-based interfaces for order entry, CRM, or transaction processing systems where users complain about having to fill in screen after screen of data. You can always use a combination of deterministic rules and user validation to ensure the agent correctly captures user intent.

• Data ingestion: This is one of the most powerful and most underestimated capabilities. All companies receive and store vast amounts of valuable but entropic data -- eighty percent of corporate data is unstructured and even structured data can be fragmented and hard to correlate. Customer requests for quotation? Customer service notes? Legal contracts. Agentic capabilities can ingest all of this either to support operational processing or to generate new business insights, even if many companies have not focused here yet. [7]

• Run-time: This is complicated and has the highest stakes. Use agentic patterns for low-volume heterogeneous decisions. I am helping technology organizations use agents to compare project designs with technology standards. The agent will compare two artifacts (a project design and a standards document) that describe organized complexity in natural language (which is inherently entropic) and determine whether one conforms to the other. Hybrid patterns will probably become increasingly common, with deterministic cores and agents to handle edge cases.

• Data storage: Naturally, relational databases will continue to store structured and transactional information. Knowledge graphs excel in modeling product portfolios, customer relationships, process maps and other domains where relationship structure carries meaning. Vector search enables retrieval by meaning from notes, documents and transcripts.

6. Precision matters because entropy is, well, entropic

I have always hated the formulation “The technology is easy. The governance is hard. The organization is hard. The line at the cafeteria is hard.” Here, design choices will shape cost structure, risk posture and user experience for years.

With a capability to process entropy at scale, you have to think about where the entropy sits in your business system -- even a simple one.

Managing invites for the Technology Leadership Forum is lower-entropy than a hundred-million-dollar group insurance deal, but there is plenty of “Joe really wants to attend, but can’t, depending on when a personal conflict lands -- and wants to know if Sally can possibly attend in her place.” I put invitees and members into a knowledge graph and built Agent Serena to translate the entropy in my email into the organized complexity of that graph. [8]

Taking a more highly-scaled domain: entropy pervades enterprise change management in banking. Dozens of interconnected process steps and artifacts; latent information about why a milestone might be at risk of slipping and under what circumstances. Traditionally, banks managed it with managerial talent copying data among word processing, spreadsheet and presentation files. And many, many emails. The result: frustration, expense, and less insight into major programs than anyone would like.

Banks can use agentic software engineering to build a system whose agents ingest program documents, extract the relevant risks, issues, decisions and action items, and store them in a knowledge graph with the relationships among them. Which risks affect which business lines? Which work-stream lead owns which decision? Further agents interrogate emails and videoconference transcripts to enrich the graph. Vector descriptions let program managers search by meaning, not keywords. Still more agents read the graph to assess risks and surface opportunities to improve the program.

This combination -- agents, knowledge graph, vector database -- removes the entropy from a painful business process. It reduces cost and improves transparency. Those of us on team cyborg (rather than team android) will note that it also empowers managers: less toil, better information.

Agentic systems -- with knowledge graphs and vector databases -- can be transformative. When I wrote that global business must move beyond organized factories and chaotic offices, this is what I meant. The benefits are both economic and humanistic. Nobody grew up hoping to spend days pasting data from email to spreadsheets and back.

Precision matters here. Agents are not magic. Inferencing is expensive, latency is real, and new vulnerabilities arrive faster than we can grasp them. But the harder discipline is the one Weaver and Shannon left us: see your business as a system, find where the entropy sits, and choose where to process it. A flat, Cartesian grid won’t help.

Thanks for reading Prosaic Times — subscribe to receive every issue!

Footnotes

[1] This differs from standard deviation, which measures the magnitude of the spread around a mean. Shannon entropy measures the unpredictability of a distribution. Relevant to us: you can measure the Shannon entropy over a set of non-quantitative values just as you can over a set of quantitative ones. In addition, there are more and less expansive definitions of entropy. I am using a relatively expansive one here.

[2] CityTime is a great example of Kolmogorov complexity. The shortest possible description of the rules governing what every city employee gets paid is approximately as long as the rules themselves — decades of negotiated union contracts, grandfathered provisions, and exceptions to exceptions, each one load-bearing. You cannot compress it further without losing something that will eventually matter. Automation doesn’t reduce this complexity; it just moves it from humans who held it in their heads to engineers who must encode it in systems.

[3] My interlocutor said I was over-complicating the situation and CISOs were probably just incompetent. Sigh.

[4] Agents predate widespread adoption of large language models and genAI. By some definitions, the cruise control system in your car is an agent. You set a speed. It monitors the speed, accelerating when the car drops below that speed (because you are going up a hill) and easing off the throttle when you exceed it. Of course calling LLMs makes agents infinitely more capable than the cruise control in your car.

[5] The notion that relational databases might struggle with relationships among data elements might puzzle some. But only those who have never stared at a screen in the early morning trying to make sense of an outer join -- or who developed a better command of SQL than I ever had.

[6] I like the idea of decision traces and context graphs, but we should be realistic about which decision traces we can capture and which we cannot, unless we want to build a panopticon for ourselves.

[7] I stared in disbelief the first time Zubin Ghafari showed me how he used GenAI to integrate messy CMDB data with other telemetry information. I had assumed this would have taken him weeks.

[8] The natural language front end to Prosaic Graff was a life-saver, but the latency sometimes made me want to put my fist through the screen. So I created Python scripts I could run (instantly) from the Terminal that told me how many members planned to attend or the status of any individual member.

That same year, I told our teacher that the Cherry Hill Study Skills program was rudimentary that teaching it wasted my time and the taxpayers’ money. I left to go read a book in the library, and got me detention. A couple of years later, I asked my Spanish teacher to lower her voice in class as I had a hangover. Also detention. I butted heads less with professors in college, but I also skipped a lot of class to take care of the Brown Daily Herald.

This guy. Me?

I have done a better job learning and sometimes teaching in my professional career than I ever did in high school or college. An email I just received reminded me of this.

Back in the day, Ed Hsu and I worked together fixing technology infrastructure organizations. He left McKinsey in 2010 and has since built a distinguished career at VMware, Rescale, and Mixpanel.

His note was brief:

hi James. This guy. You. :)

It included a link to his substack issue on The Personal Impact Chain, which read:

During my first weeks at McKinsey, a senior partner gave me the most concise career advice. Over dinner, I asked what I needed to get right first.

“Know the data,” he said.

Not “develop executive presence.” Not “build relationships.” Know the data. Everything else, the problem solving discipline, the story, the recommendation, was downstream.

Over the years, I built on it. The Personal Impact Chain is the result: a framework for staying grounded in facts, finding the insights that matter, building the case for change, earning the coalition to act, and delivering outcomes.

Accounts receivable optimization in Canada. In winter.

My first project out of business school (before even I worked at McKinsey) [1] sparked this insight. I know that the client wanted us to design customer programs to reduce Accounts Receivable, but the approach and the work-plan were mysteries.

Despite the confusion, I learned a ton on that study, including the importance of a healthy respect for the complexity and fragility of legacy systems.

The business unit’s IT department thought providing data for business analysis was not an important part of its job. Eventually I made friends with one of the DBAs, and we would log onto the mainframe together and download massive amounts of raw data that I imported into a SQL database I built in MS-Access. [For our younger readers, before you could use a cloud database…oh never mind.]

I could analyze consumer A/R patterns by BTN and enterprise A/R by major account. I could immerse myself in the data.

Like all the other consultants on the project I had a beat up metal desk on a big floor, and both other consultants and clients (some of whom had nothing to do with our project) would crowd around my desk asking me to query my Access database. People started calling me the counter-CIO. I liked being the counter-CIO.

I faced a limitation — I didn’t have any A/R or payment data on mid-market customers. After lots of investigation, I figured out the data I wanted lived in a system called CRIS (Customer Record Information System), but nobody knew how to get a query run against it.

So I sat at my beat up metal desk, and called everyone I could think of (using an actual landline telephone) to ask who could run a query against CRIS for me — then I would have all the data I needed. No luck.

Then one day my phone rang. The caller announced himself as Victor Rochambeau (not his real name), and asked if I knew who he was. Yes, I did. Victor was one of the most senior people in IT — not the type of person I was supposed to be talking to as a callow greenhorn.

Victor continued, “James, how old are you?”

I stuttered, “Excuse me?”

“How old are you?” he repeated.

“Twenty-six,” I replied.

“So you were born in 1970?” he asked. (This was in 1996.)

I assented.

Victor continued, “James, I have a new rule for you, so long as you are on this project. You are not allowed to request queries on systems older than you are.”

He went on to explain that they deployed CRIS in 1964 and ported it to minicomputers in the 1970s. And that ad-hoc queries crashed it. He was not crashing his system for my query.

Data is power

I never did get any mid-market A/R data, but familiarity with data increased my stature in small ways.

I thought it would be interesting to attend the first client progress review. So I asked my Manager, whom we called The Shadow), [2] suggesting I might be able to speak to the underlying data. The He scoffed: new associates had no place in progress reviews.

The meeting approach. After we printed out copies of the deck, [3] we watched the Shadow and the Senior Manager walk down a long hallway, wondering what progress reviews were like.

The Senior Manager and the Shadow stopped and talked for a minute. It looked like the Senior Manager was asking questions that the Shadow could not answer.

With a hangdog expression, the Shadow walked back toward us, pointed at me and indicated I should join them. So I excitedly trotted down the hall toward my first progress review. The project was a mess; the first progress review was a mess; and I learned a lot watching the mess.

At the end of that project I derived a theory of victory for my career in consulting. If you understand the data, you will be essential for the analysis. If you are in the middle of the analysis, people will want your point of view on the recommendations. If you understand the recommendations, you can help construct the narrative. Once you help craft the narrative you have an opening to participate in the client relationship. And then you’re getting somewhere.

That insight got me far. I resolved to understand more than anyone around me — about the telecom operations, then about technology infrastructure, cybersecurity, cloud computing and more recently GenAI in enterprise technology. I was a slacker in higher education, but I hit the books hard as an adult.

But I didn’t follow my theory of victory to the end. For too long, I focused too much on the data, analysis and recommendations -- and not enough on the narrative and how it motivates people to act. With much frustration, I haltingly learned to think as much about the second half of the chain as the first. Yes, the truth is the easiest thing to remember and you should ask every question. But also: to influence you must be open to influence and how you talk matters as much as what you say. [4]

Ed took advice I gate him and developed it further into something of his own — with a strong emphasis on the factors that I hadn’t focused on enough early in my career.

Pasted image 20260613225603.png
He writes:

Product leadership is fundamentally about leading without formal authority. You set the direction, align stakeholders, and own outcomes; all without controlling the people who make it happen. That requires something more basic than product intuition: a personal operating system for getting from facts to impact, on any type of project, at any scale.

There’s a progression that underlies almost every professional initiative. It’s not in job descriptions, but it structures careers:

Data → Insight → Story → Action → Impact

Like spirals in nature, this progression runs in any scale. From a junior analyst delivering a report to an executive driving a company-wide transformation, it’s the same structural progression, just at a different scope and time horizon.

Action at the small scale is personal discipline. At the large scale it’s about diplomacy, dependency management and a dose of formal authority. At senior levels, this framework maps to how people are evaluated.

One of the pleasures of a long career is hearing how others might remember and use some of the things that you’ve learned. And you don’t get detention.

Thank you, Ed. You made my day.

Footnotes

[1] Yes, there was a time before I joined McKinsey. Dinosaurs roamed the Earth. We used fax machines.

[2] We had great nicknames on that study. The BA was Nermal. The other associate complained about everything except Texas, so we called him Lone Star.

I got everyone to call him Lone Star: our team, all the consultants on all the other work streams and all of the clients. Here’s how thoroughly he became Lone Star in our minds.

One evening I needed to ask Lone Star about something, but he had already gone back to the hotel. Almost nobody had a cell phone in that era (before AT&T rolled out the Universal One Rate plan), so I used the PBX handset on my desk to call the local Marriott switchboard.

“Get me Lone Star,” I requested.

“I don’t understand,” the operator replied.

Slightly frustrated, I said “Lone Star. Lone Star. I need to speak with Lone Star.”

Watching me, with no small amusement, Nermal told me: “James, I don’t think they know about Lone Star at the Marriott.”

[3] Back before everybody had giant LCD screens in every conference room...oh, never mind.

[4] Me at 30:

Scene: 5:30 pm, Friday afternoon, CIO’s office: she is packing up to leave for the weekend.

CIO: “Oh, yeah, we have time now. I’m trying to get out the door.”

Kaplan: “I should tell you about that cost savings plan we were supposed to validate.”

CIO: “Yes?”

Kaplan: “You told the CEO you had a plan to save $20 million.”

CIO: “Yes?”

Kaplan: “We dug into all the plans and the underlying data and we don’t think it’s $20 million.”

CIO: “How much is it?”

Kaplan: “Maybe $3 million.”

There is a time, a place and mechanism for delivering bad news. This wasn’t it.

My favorite coffee shop has an enterprise technology vibe. You hear people discussing SQL query syntax on video conferences, as if text-to-SQL weren’t a thing. One of these days, I will launch a podcast sitcom (in the style of an old-fashioned radio comedy series) called the coffee shoppers. In the pilot episode, the regulars will conspire to rid their favorite establishment of a matcha machine that attracts the wrong element, like hipsters.

One of the regulars (also a devoted reader) asked me to start including a book recommendation related to the issue’s theme. Since I prattled on about Military Power: Explaining Victory in Defeat in Modern Battle last week, let me suggest Thinking in Systems by Donella Meadows.

What drives bad enterprise technology? Short term and siloed thinking. When you implement a security control without understanding the user experience, that’s siloed thinking. When you build a use case without worrying about what the underlying platform might be, that’s the same mistake. It leads to high cost, technical debt and frustrated users. You see a lot of it as companies wrestle with deploying GenAI.

Donella Meadows defined systems thinking as the discipline of understanding how the behavior of a whole emerges from the interactions of its parts over time. It focuses on the relationships, feedback loops and delays across a system that spans the human and technological domains. You might say systems thinking implies seeing the world as a graph — and using that insight to optimize the entirety of a business domain rather than individual pieces of it. The ten beliefs that follow are my attempt to apply that insight to AI strategy.

A colleague asked if I could get a perspective on GenAI strategy on a couple of pages. That’s tough — specificity, nuance and general applicability are uneasy bedfellows. How do you navigate between the Scylla of platitude and the Charybdis of over-simplification? You have to stop thinking about a collection of technologies and a collection of organizations, but of a business-technology system where each part influences every other part in some way.

10 beliefs on how to get value from GenAI

1. The business world is entropic. Generative AI represents a technology discontinuity because it can process entropy rather than ignore or externalize it, e.g.

• Complex and interconnected, incompletely documented business rules (e.g. like the ones in 1000-page contracts)

• Unstructured or uncorrelated data (e.g. doctors’ notes in eHR)

• Unstructured user instructions (natural language input)

• Latent information (e.g. status of B2B commercial proposal)

2. GenAI represents a strategic discontinuity because it allows granular analysis and digitization of business domains where you previously needed humans to manage complex and ambiguous information

• The largest opportunities will be in the most entropic domains because companies successfully digitized less entropic ones (like consumer auto insurance) years ago

• Returns to investment will be lower for B2C businesses than in B2B businesses

• They will be lower in operations for process manufacturing than in service operations

• They will be high in domains like R&D and product development where digitization has been limited

3. Speed and quality will be as important, if not more important, than efficiency in achieving competitive advantage from GenAI

• Returns from technology investment vary massively by period, sector and company — and companies compete away the value of productivity improvements as consumer surplus.

• Updating a contract in minutes rather than days may be essential when negotiating a transaction

• Reduced revenue leakage may swamp operational cost reduction in setting up the billing for an asset servicing or group health insurance arrangement

• You can also use GenAI to create less frustrating user experiences, even if the impact is harder to quantify — even more importantly you can use it to reshape markets by reducing commercial friction and transforming unit costs.

4. The Jevons paradox applies to busywork as well as knowledge work, so you want cyborgs not androids

• GenAI can rip the toil out of knowledge work and improve the rigor of your employees’ thinking — you need knowledge workers who can apply judgement and reason across multiple domains, rather than just provide specialized expertise

• A lower unit cost of business insight will create demand for business analysis that had previously been uneconomic — if you are willing to rethink how you manage knowledge and even how you produce documents

• But when you put GenAI on the desktop, employees will often devote tokens to writing and summarizing emails or performing more complex web searches — while GenAI can help your employees write more effectively, AI-generated prose is vague and unconvincing

5. Even though token prices have been declining roughly tenfold per year, the cost of inferencing will finally require enterprises to treat IT spend as COGS rather than G&A

• Run costs will increase in relation to build costs

• Companies will need to ensure both that they devote GenAI resources to valuable projects and that they design agentic systems for token efficiency

• But inferencing latency may big a bigger problem than token costs

6. Every business system processes entropy somewhere — in product managers who formalize ambiguous workflows, account managers filling in CRM fields, free-text notes nobody reads. Agentic capabilities give you choices on where to put that work, each with a different cost, risk, and speed profile:

• Agentic software engineering — automate the business logic that reflects organized complexity; apply your existing QA mechanisms to the output just as you would hand-written code

• User interface — deploy chat or agentic interfaces where users complain about screen after screen of fields

• Data ingestion — eighty percent of corporate data is unstructured; agents can ingest contracts, service notes, and RFQs that deterministic systems ignore entirely

• Run-time decisions — use agentic patterns for heterogeneous decisions (e.g. architecture review); hybrid patterns (deterministic core, agents for edge cases) will become the dominant architecture

7. Context is existential for GenAI, and requires different mechanisms for managing it

• Relational databases excel at storing transactions

• Knowledge graphs allow you to store and analyze the relationships among entities (e.g. customers, products, process steps, service offerings) that GenAI discovers

• Building an ontology and semantic layer (and encoding it as a knowledge graph) both reduces the likelihood of hallucination by over 80 percent and depicts your business as a system, allowing you to make better business decisions

8. Agentic technology will not make enterprise technology functions disappear. You must build robust common platforms in order to apply GenAI at scale, with efficiency, with security and with resiliency

• Agentic software engineering replaces procedural programming with declarative programming

• Doubling throughput and productivity will only be the start here for those companies that reimagine software engineering processes, rather than just providing engineers with copilot-type tools

• Reimagining software engineering can transform the ROI of tech-for-tech investment and the “IT doom loop” and double or triple the EBITDA lift from enterprise technology by freeing up budgetary capacity for new investment and reducing value leakage and engineering deadweight loss

• The challenge of Agentic cyberattacks will require enterprises to rethink risk management processes and increase the automation of their technology environments in order to remediate vulnerabilities discovered by frontier models like Mythos at speed

• Agentic software engineering will change buy/build decisions and challenge “one size fits none” SaaS models. More enterprises will connect disparate software tools or will contract more niche vendors whose products more closely support their business processes

• All of this requires treating enterprise technology as an integrated system and support from across the management team for the required investment and changes in the business-technology operating model

9. Agentic technology will change the relationship between users and the technology function

• Users can achieve wonders by acting more like software engineers for “edge” applications

• They will increasingly look like “Strats” who sit on a trading floor and update models intraday — the ED charge nurse who reweights a sepsis-triage rule when a new strain appears, the plant engineer who tunes a predictive-maintenance threshold when a new failure mode shows up, the claims supervisor who stands up a fraud agent overnight

10. Advantage will accrue to institutions that metabolize GenAI and scale its adoption

• Capturing value will disrupt existing assumptions about organizational structure, ways of working — and especially the role of governance functions like HR and procurement

• You need to treat the technology and the operations around it as a single system and evolve them together

• You want to change everything someplace rather than something everyplace. Transforming a business domain (rather than funding disconnected use cases) creates local critical mass and provides visible results

• Executive support in the face of resistance requires you start with hard problems (rather than easy ones) and a measurable target

GenAI is new and it is different. It does things that we could not get systems to do in any scalable way before. It applies to a far broader set of domains than traditional enterprise technology. Just as the railroad reshaped the geostrategic environment (empowering continental powers relative to maritime ones), GenAI will reshape the competitive dynamics in many sectors.

Those who seek simple checklists in applying GenAI will fail. You might ask why it is different — how it can allow us to automate new types of tasks. You must understand how it will interact with your strategic context and your organizational culture and capabilities. And then you can determine how you might use GenAI as a weapon. None of this is easy. But Edward Luttwak reminds us that strategic advantage derives from doing hard things, rather than easy ones.

I love Stephen Biddle’s book Military Power, which explains how armies have used the modern system of force employment (effectively tactical doctrine) to win battles. He explains that technology innovations since 1914 have requires armies to learn how to use:

• Dispersion

• Cover and concealment

• Suppression

• Small-unit maneuver

• Combined arms

• Defense in depth

• Decentralized initiative

Biddle points out that

• Technology provides nothing; the effective translation of technological change into coordinated tactics (via the modern system of force employment) provides everything, or least the ability to win battles and possibly wars

• Adopting the modern system of force employment requires a very different culture than more traditional forms of war-fighting, especially the ability to trust non-commissioned officers with a lot of responsibility

This tells us a lot about agentic software development

• Giving your engineers access to new tools buys you nothing; building a new method software engineering using some of those tools buys you 2x, or perhaps 10x, the productivity

• Adopting new methods of software engineering requires rethinking skills and mindsets

• The results could have strategic impact. For most companies, software development is the rate limiting factor for every new product, every new channel, every new market and most operational improvements. Enhancing software development productivity accelerates the metabolism of the enterprise.

I was excited to speak, with my colleague Matt Linderman, with Tessl CEO Guy Podjarny because of his ideas about how to create the scaffolding for agentic software engineering -- how to do it at scale. As always, Prosaic Times never endorses any product or offering, but we find great insight in hearing directly from builders bringing new capabilities to market.

1. The founder is a addict entrepreneur

In this section:

• Guy is x-Akamai CTO and Snyk founder, now founder/CEO of Tessl.

• He frames himself as an “official addict entrepreneur.”

• Matt is a McKinsey partner in New York leading the firm’s software practice — three to four years building an AI-first, now agentic, product and engineering practice. Grew up near an upstate-NY Air Force base that did AI research.

James Kaplan: Currently hanging out in southern Rhode Island with another Prosaic Times video podcast. Today we have my colleague, Matt Linderman from McKinsey, and Guy Padjarni from Tessl. Did I pronounce that correctly, Guy?

Guy Podjarny: Good.

James Kaplan: Guy, why don’t you tell us a little bit about yourself, and we’ll bring you to Tessl.

Guy Podjarny: Sure. I’m at this point an official addict entrepreneur. After being a developer and turning product and such through a few acquisitions, I founded my first company in the web performance space. I sold that to Akamai, where I became CTO, and did that for about three and a half years. After about three and a half years, I got the itch to found another company, and I went on to found Snyk, which I think had a good dent of impact on the application security world.

James Kaplan: Maybe just a little

Guy Podjarny: It had a couple of years of wandering the desert and near-death experiences that nobody remembers, because everybody remembers what happened post the sort of two years.

But then it grew nicely, formed the DevSecOps movement and the developer security space. So that grew nicely. And about two and a bit years ago, I accepted I’m an addict and fell in love with AI, and left Snyk, where I’m still chairman of the board, to found Tessl, focused on reinventing software development.

What is the new software development paradigm? That is what Tessl is focused on.

James Kaplan: You’re in London now?

Guy Podjarny: I am based in London. Born and raised in Israel, spent a decade in Canada, and I’ve been in London for the last 13 years.

James Kaplan: Matt, you wanna introduce yourself and tell us a little bit about your journey?

Matt Linderman: I’m a partner in McKinsey’s New York office, and in particular work in our software practice on engineering and product management topics. For the last three or four years, we’ve been building a practice around AI-first and now agentic product management and engineering practices, and lead that more broadly for McKinsey across software companies and across a number of companies outside of software — banks, telcos, et cetera — who are all going through this journey together.

And so Guy, very excited to chat with you about what we’re seeing, what you’re seeing, and mash this together as we go through the conversation here.

James Kaplan: And you grew up in upstate New York?

Matt Linderman: Grew up in upstate New York near an Air Force base that did AI research, actually. So I grew up with this very close to heart, and now live in the New York City area.

James Kaplan: Great. And we appreciate you classing up the joint here on the podcast by wearing a shirt with a collar, Matt. You’ve raised the bar for Guy.

Matt Linderman: I was forced to do it due to some bank conversations, but my T-shirt is available for later.

2. Code is disposable; context is the new code

In this section:

• Guy reframes “vibe coding” as the first leg of a journey toward agentic engineering — guiding the agent, not writing the code.

• The Tessl thesis, two years old now: code becomes disposable; context becomes the unit of work.

• Guy sketches the emerging stack — models → tools → context (skills, rules) → harnesses → factory lines → factories.

• Harnesses are deterministic guardrails on a probabilistic model: OpenAI’s no-commit-without-coverage rule; Intercom gating PRs on loaded guidelines.

James Kaplan: You’re allowed when it’s warm in London. Guy, give us a little bit of the big picture on the evolution of software development and the adoption of agentic — or spectroven — development.

I admit, I don’t love the term vibe coding. But tell us a little bit about where we are and where we’ve been and where you think the world is going.

Guy Podjarny: Vibe coding is interesting. I think about vibe coding to agentic engineering as a journey: there is vibe coding, where you just vibe away. But really what we want is agentic engineering. I’d say, thinking a little bit about Tessl’s journey, two and a half years ago — or just less than that, when we founded Tessl — we already had the conviction, which is more clear today, that software development will, at a high level, transform from revolving around code and implementation to revolving around intent and instructions.

It is more about guiding the LLM — at the time, and today the agent — to do what you believe to be right, versus writing the code yourself. At the time, we talked about how code will become disposable. It was a bit more heresy at the time. Today it’s well accepted that implementation will become something that is regenerated, and it’s less important.

We’re not fully there yet. We believe this will drive a new software development paradigm, and we didn’t really know what that is. What are the units? Today we’re starting to see the outline of what it is that you develop in this world. We’re still developing software, still creating something that will evolve, that we debug if it doesn’t work, that we observe in production, that we collaborate on.

So there’s still a thing we’re developing — what humans are developing — what I think of as the context development life cycle. I can describe a little bit of the stack that is shaping up, and I’m sure this will continue to morph and modify.

At the bottom of it, there’s the models. This is the new primitive we’re building on. Think of those like architecture. They’re like operating systems — whatever it is that you build, is it compatible with that layer?

A layer on top of that is a layer of tools that perform various actions. They might be your grep and FFmpeg. They might be custom built.

Above that is the layer of context. I think of context as the new code. We can dig into that a little bit more, but context is where most developers spend most of their time.

It’s conveying what they want the agent to do. We have skills, we have rules.

Further up the line, you start seeing harnesses. Harnesses are really about constraining the model — they’re harnessing the model. This is deterministic software that decides when to make decisions that are not delegated to the probabilistic model. Hooks, for instance — OpenAI saying, “You cannot commit, you cannot run Git commit until the test coverage is above a certain bar.”

Or Intercom saying, “You cannot open a GitHub pull request unless you loaded the relevant context around our PR guidelines.” These are examples where the harness — the configured harness — is telling the model, “You do not get to choose; this has to happen,” because it harnesses the model. And then in turn, harnesses compose up into factory lines.

These are more like pipelines. Harnesses are kind of like frameworks, if you will. Most organizations will choose and highly customize a framework, or they will build their own framework. They probably won’t have a gazillion of them, so it’s not the same as a dev. Up to the factory lines, they’re more like pipelines.

You want some consistent input. With a certain type of input, you have a successful output. You want to go all the way to factories, which are more like your development process. So this is a new software stack, and these analogies are helpful when we think about, okay, as we scale, what do we need?

What tools do we need? What practices do we need to build that out?

3. Stop spec-ing the product; start spec-ing the programmer

In this section:

• James offers three historical analogies for the shift — assembler to C, procedural to declarative, and entropy reduction down the traditional design chain.

• Guy takes the last two but insists this leap is larger than any prior transition, and is happening faster.

• The right comparison is to instructing humans: probabilistic, resilient, interpolating within boundaries — except agents can’t lose their jobs.

• Spec-driven engineering is a practice, not a product; specs are only one slice of the broader context-engineering problem.

• “Speccing the programmer” — encoding constraints, API choices, framework preferences, and billing limits alongside the spec itself.

James Kaplan: Which metaphor resonates most with you as we think about the movement to agentic development, or spectrum development? The first historical metaphor I sometimes think about is the transition from assembler to third-generation languages like C, which we went through in, say, the late ’80s, early ’90s.

And I’m old enough to remember a lot of rent garments and concern that, “Oh my God,” you know, third-generation languages would be slow and unwieldy compared to programs written in assembler. The second metaphor I sometimes think of is the transition, or the distinction, between procedural languages and declarative languages. And sometimes I think about when the world went from building database management systems by hand, or building databases by hand, to using SQL — which I think you can argue is a declarative language. And when you say spectrum development, that to me sounds like it’s declarative. And the third is entropy reduction — in the sense that in a traditional software engineering process, you went from, say, a senior business executive’s declaration of intent through to a business case, to a conceptual design, to a set of business requirements, to a set of technical requirements, to code.

You had humans at every step in the process, in effect moving entropy until you had deterministic code. Which of those metaphors resonates with you, or do they resonate in different ways?

Guy Podjarny: Yeah, I’d pick a spot if that was a continuum.

James Kaplan: Please.

Guy Podjarny: The last two. The analogy for software evolution — this is a bigger leap than any one of the changes that we’ve done. So even if it is directionally analogous, and that’s useful, ’cause we’re humans and we like analogies, and they help us reason about the world — but I think it is a bigger jump, so we have to acknowledge that, and it’s happening faster than the previous ones.

I’d say it’s somewhere between changing — taking that sort of entropy, or how do we instruct humans. As we cascade, in which we expect probabilistic behavior, we expect when we guide our reports — people that work for us — not to get perfect, but to get resilient. You want them to understand the spirit of what you’re saying and to have some judgment around when to bend the rules or expand the rules, to build it.

James Kaplan: Interpolate, often interpolate, right?

Guy Podjarny: Interpolate. And you want it within boundaries — which is always a tricky thing — and accountability. We should get back a little bit to accountability, ’cause the key distinction between that and the others is: a person who repeatedly makes bad decisions might lose their job, and an agent doesn’t really have that. But on the other side, where they’re meeting the other pull from software, is just the increased desire for abstraction. If you think about a bunch of these transitions you talked about — but even going into Java, and then in infrastructure going into the cloud — anything that became software-defined, suddenly you’re saying, “Hey, get me ten more servers.” You’re not dealing with anything. It’s just spin up ten more servers. Before, you said, “Give me ten more megabytes of memory.” You didn’t even say that. You said, “Give me an array of a thousand objects long.” And Java —

In each one of these things you’ve delegated decision-making to something downstream that you can configure, you can control, but is not entirely yours. The entropy piece is interesting because in all of those cases you still expect a lot more determinism, and a lot less resilience — a lot less adaptability — than you do with humans.

We meet somewhere between human instructions and a higher-level abstraction, and those are probably comparison tools as we think about what works and doesn’t. I’ll just refer one thing to the spec thing: at Tessl originally we talked about spec-centric software development. Spec-centric evolved into spec-driven development, which I believe to be a real practice.

I don’t think spec-driven development is a product. It is a practice.

James Kaplan: Of course. Yes.

Guy Podjarny: We should go from speccing the product, or speccing the program, to speccing the programmer. It’s important within the team — when you think about instructions, specs are just a part of the puzzle. What you expect from people in the team is not just to always update the information about the product and how it operates when they modify it.

That’s one of the things you want. But you generally expect them to make good decisions, and it includes that, but it also includes understanding your constraints and your preferences — how you chose what your API design is, how we chose to use this framework, what your billing constraints are — all of these other pieces. So I use spec-driven development, but I think it is a subset of agentic engineering and/or context engineering. Specs are just a piece of it.

4. Tech debt is becoming deflationary

In this section:

• Matt opens with the historical default — entropy increases in codebases over time, and tech debt is what we call it.

• Guy inverts the frame: tech debt is deflationary. If the modification will be cheaper in six months, accumulating debt can be the rational move.

• The carve-outs are one-way doors — architecture debt and data debt still warrant the cycles to keep fresh.

• James’s college-era friend said a program could be rewritten from scratch three or four times and made better; agents make that cheap enough to do routinely.

• At Tessl the team is pushing to eliminate interactive coding sessions entirely — one-shot prompts off a well-formed Linear issue, with tests as the enduring artifact.

James Kaplan: Matt, I’m sure you have questions. Let me not hog the mic here.

Matt Linderman: Well, just to add on to the entropy point, Guy — to your point, it’s a really interesting question, because in the past, at least, what we’ve often seen is that entropy increases in code bases over time. And you end up with tech debt, or different words to describe that. Now there’s a real interesting opportunity to think about how do we keep code bases evergreen and actually avoid the entropy degradation over time as you go forward.

Matt Pocock gave an interesting talk on this the other day about basically always doing your architectural reviews on a more frequent basis, keeping the code base more up-to-date and clean. There’s an interesting evolution there that I think historically was a one-way ship, and now we may actually be able to steer that in a slightly different direction, to maintain code bases far better than we have in the past.

So I think the entropy one is a really fascinating thing to look into, and we’ll see how it all evolves.

Guy Podjarny: I agree that you can maintain, because labor has become cheap. So you can do all these things that before were nonsensical financially. Now suddenly maybe they are. At the same time, there’s another view that is almost counter to that a little bit, and that is that tech debt is becoming deflationary. Whatever modification you’re gonna do in your code right now, in six months’ time it’ll be easier to make that modification.

The agents will be more able to help you resolve that. To an extent, this is an amazing time to accumulate debt because it’s deflationary. It’s gonna be cheaper. So if there’s a good ROI in terms of you not bothering with this, then you can do — heck, you’d be able to rewrite the whole thing in a path. There are types of debt that you need to be careful still of — maybe architecture debt, maybe data debt.

Maybe things that are one-way doors that are very hard to change — for those you might wanna invest the extra cycles, which are now cheaper and reasonable to do, to constantly keep it fresh. And then there’s the type of debt where, if you go even the step beyond, you might actually care less. It might be fine, because you would just be able to undo that. So it’s not worth the delay. It’s always about what’s on the other side of the equation — it’s not worth the delay or the opportunity cost to accumulate it.

Matt Linderman: Yeah, 100%.

James Kaplan: In college, I had a friend who’s a very good computer scientist, computer programmer, who liked to say that a software program could be rewritten from scratch three or four times and made better. I think what you’re articulating, Guy, is that now it’s a hell of a lot easier to do that.

We can imagine everything gets rewritten multiple times with what we’ve learned in the process.

Guy Podjarny: Yeah, absolutely. You have to work and adapt to get to that point. One barrier to that, for instance, is interactive coding sessions. At Tessl, when we develop software, we aim — we’re not fully there yet, but we aim to eliminate as much as we can interactive coding sessions.

Instead, you can say, “Fine, play around with Claude or Codex or whatever it is, build the thing that you want, help yourself shape the product to what you want.” ’Cause oftentimes as you build, you figure it out. Now translate all of those into the Linear issue that provides the right information, throw whatever it is — the code you’ve just created in the prototype that doesn’t go anywhere. That gets thrown away.

But the information, the learning out of that, gets done. And then it gets one shot. And if it fails one shot, you modify the information, you provide the relevant commentary, and you create that again. What that does is it puts you in a place in which the agent is, almost by definition, sufficiently informed to be able to build that.

Of course you want to then curate that context over time so that it doesn’t rot, so that it remains relevant. But yes, you’d be able to build it again and make it adaptable. Increasingly, code generation should become like compilation: “It’s okay, I don’t care if there’s a new version. I can compile this for this new version of Linux or whatever it is that I just have here.” You do come back to some sort of regular principles, which is you need to capture tests. You need to capture some definition of what good looks like, what correct behavior looks like. And you’re never gonna test everything — definitely not with agents — but you need enough test coverage, otherwise you cannot scale.

5. Taste is a preference you forgot to write down

In this section:

• In real enterprises the factory layer is mostly aspirational; for now the live action is in context.

• “Negligent skills” — those without safety instructions — force enterprises into governance: central registries, supply-chain controls, dedup, versioning.

• Skills rot like software; the carrot is auto-extraction from agent logs and PRs, the stick is the maintenance burden.

• “Taste is just a preference you didn’t bother writing down” — skills are how that preference becomes a rule, used both at development time and at code review.

• Three tiers of evals — regression, skill, project (unit / functional / end-to-end) — and LLM-as-Judge is good enough to make them tractable.

Matt Linderman: So Guy, you started to introduce the stack — models, tools, context, skills, harness, factory — which kind of grows in abstraction as you go down. I’d love to hear from you. There’s been a lot of talk on the upper half of that stack, all the way down to harness. The factories piece is really emerging.

I’d love to hear just what you’re seeing in practice in terms of the workflows people are building around the harness, and what impact you’re seeing day-to-day with the folks you’re working with.

Guy Podjarny: For sure. The reality is there’s the sort of AI-native tiny companies, full kind of greenfield world, and then you go all the way to the enterprises.

In enterprises, the reality is that there’s a massive chasm — both between the companies, and within the company as they grow. When you think about factories and factory lines, those are, in almost all companies of medium size and up, not the norm. They are a specific prototype, specific project, specific sections — they’re the forerunners as opposed to the majority. The majority of interest, or activity, that we’re seeing right now is around context.

Eventually the agent executes this stuff. It might be malicious. It might be vulnerable — vulnerable being things like it guides the user to put API keys in plain text, or things like that. Or it might be what I’ve come to call negligent skills. Negligent skills are skills that lack safety instructions — “add this to the database, update is needed, do not drop the table, delete the database,” or some sort of basic safety instructions. Once you get into risky skills, you naturally need the governance: who’s installing, what do I even have in my inventory, do people use it. To control, so they create a central registry. They control those, and all that. So that’s one pier. It’s the least sexy, but it is important for supply chain security, and it’s a blocker to roll things out.

The second thing that we see is challenges around standardization, reuse.

I heard a story that articulated this very well — a unicorn with about 1,000 developers — describing how everybody was creating skills. That’s wasteful because everybody’s creating the skill.

They’re wasting tokens. They’re wasting time. They’re creating a lot of the same thing.

So they put together a repo to be able to upload and share those skills, so everybody’s sharing those skills. Very quickly it becomes a mess — there’s a whole pile of duplicates: which one do I choose? They had compatibility issues — like compilation — one developer is using one agent, they publish the skill, and it doesn’t work well on another agent. To be able to collaborate, you need some basic software-like tools.

You need some quality barometer, and a means of knowing that it’s quality, some deduplication to be able to identify those, some versioning of the stuff that you roll out.

All basic stuff that we have for software.

Most organizations are not yet past that point.

There’s a carrot and stick over here. There’s the fact that skills rot just like software. They will get out of date. They live in a dynamic environment.

The software around them changes, the practices change, the learnings change. You have to maintain them, per the debt conversation we just had. And that’s the stick — you better maintain them, otherwise they’ll break.

And then the carrot is: can I look at agent logs? Can I look at the PRs? Can I auto-extract things that will improve that? That comes along. So that’s the exciting bit. What we’re seeing is that in organizations they do that on a nascent project. They do it on things where the blast radius, if the agent misbehaves, is relatively controlled.

James Kaplan: Fascinated by the ability to use context to enforce or encourage engineering standards. And I’ll give a very simplistic example. In the history of software development, nobody has been worse at naming variables consistently than myself. I am horrible about it.

I am the worst person in the world at it. And it was really interesting — as I started playing with Cursor and Claude Code, it’s, oh, I can set up some rules that determine how variables should be named. That’s an incredibly simple example, but it translates to a million things in terms of architectural standards and non-functional requirements. And we can be a lot more precise about how we engineer code and structure code, compared to a set of guidelines we would give to a new engineer or a relatively early-tenure engineer. And that to me is pretty exciting.

Guy Podjarny: It requires you to do something that many people don’t like, which is take the time to sit down and write down what good looks like.

I think with software, oftentimes we just don’t do the hard thing.

The word taste is thrown around a lot in the world of AI. And while it’s important, taste is just a preference that you didn’t bother writing down.

Skills are a very good way to enforce that. There are technical constraints right now — skills don’t always activate. So what we see in practical terms is there are three parts that you need to do.

One: you need to create the skill and write it down.

Two: you need to make sure that it is distributed. You need to make sure that it’s installed in various cases. On the Tessl side we help with that — both the tracking and the mandating of skills. But you need to know the skill was present when it was needed.

Third: you need to invest in verifying that it’s been acted on.

The beauty of skills is that you can use the same skill in two agent contexts. You can use the skill as part of the development process to say, “Hey, this is available to the agent to load,” and you’re trying to entice it to use it.

But then you can use literally the same skill in the code review process to say, “Hey agent, check if these practices have been applied,” because you’ve written it down once.

And that is actually a beautiful thing, because you can do it in both cases. And you can even further go on and say, “Look, historically, I learned that now this data pattern is not good.”

Not only from here on do you change that, but — Matt, to your comment on tech debt — go back in history and find all the cases in which that’s there, and set up a mini migration of something that you wouldn’t have bothered doing.

Matt Linderman: I’d love to maybe stick on this topic of context, ’cause obviously you’re a real expert in this space. One of the — I think there’s a two-part question. One is, when you look at the evolution, obviously the tools themselves have gotten a lot better at pulling in context, but what are you finding in addition to the standard, like grep and code-based awareness, that’s really critical to pull in?

I’d love to hear your thoughts on that. And then the second piece, which maybe we can go to after, is how do you then experiment and measure what context is more or less effective, and what should you be pulling in? We have a number of clients asking those questions and trying to wrestle through what is the information that they should connect via MCP, how should it be structured, et cetera.

And that comes down to some version of experimentation. Would love to hear your thoughts on how to think through that.

Guy Podjarny: I love the question.

The context window is the scarce resource that we optimize for. Everything is context. Your code is context. It’s important to separate between reusable context and real-time context.

In the real-time context you have things like prompts, tool outputs, and things like that. Those are more interactive context. It’s important to do prompt engineering and things like that — those are still competencies.

The models clearly need to make it easier, and they have interactive modes about knowing when to ask you questions.

There’s passive and active context. Passive context being the code itself. So you can do things like keep the code clean, add proper documentation, add some passive documentation inline — like MD files at the right spots.

There are advantages to continuing with a thing that the agent has regenerated. There’s a real advantage to having the agent rewrite the file, because when it rewrites the file it tends to follow a certain pattern that matches the training data that exists.

Its future decisions reasoning about that file are more likely to be successful. Clearly, it’s not practical to rewrite every file every time, but it’s still a useful guideline.

The third bit, though, that relates to all of those, is this reusable context — and how do you evaluate it, or how do you know that it’s good? This is really where the world is now evolving. Reusable context is mostly done with skills.

Rules are a more forceful set — your Claude MD, your Agents MD — information that is always shoved in.

But you have to be very careful about how much you put in there. If you put a lot in there, you basically make the agent dumber for everything else that it does.

Skills are more on demand — whether the user has invoked them or the agent has the hints to do them.

Define what good looks like for a skill.

Right now the most common barometer is the Anthropic best practices. Does it have progressive disclosure? Is it sufficiently concise?

But we see customers modifying it to their own barometer. So at least start by defining what a good skill is in your organization.

Does it have safety instructions?

Does it refer to data privacy?

The second quality measure is tests.

In skills, the equivalent is evals. In evals you define a scenario: here’s an environment, here’s the files that are involved.

Pull from this commit, modify this context file like this, install these different tools, and then you have a task.

In practice, running tests is just a lot harder to maintain, and LLM-as-Judge is pretty good. It’s like an expert reviewer.

So you define the criteria, you run the agent through it.

Test coverage is notorious: you can build amazing test coverage and have really poor quality controls with it, just because you’ve created useless tests.

State-of-the-art, which not many people are doing, is you have three tiers of evals.

You have things that are more regression tests — just a few samples to say this works.

Mostly they now serve as running something even in the CI, so when you’re modifying the skill it doesn’t break, and you can have some sanity checks on new models and things like that.

Skill evals — you’re evaluating the skill, like a unit test or a library test. You’re evaluating that unit of context on its own.

The next one up is more like project evals.

In this case you’re doing something that evaluates the entire project context. You now have 20 skills installed, and a bunch of rules, and a bunch of files, and maybe you’re giving a bigger task.

Those are heavier to run. You’re not gonna run them on every PR, probably, but you might run them on a weekly basis, on a monthly basis, to see that your context remains fresh.

And then the comprehensive test — the end-to-end test equivalent.

I think of the first one as unit tests. I think of the second one as functional tests. And I think of the third one as end-to-end tests or integration tests — which are comprehensive, so you can make strategic decisions based on them.

So, can I switch models over here? Can I run this on a different environment? Typically cost- or efficiency-related, but for things that matter.

6. The bottleneck is no longer coding; it is learning.

In this section:

• Guy’s diagnosis of what enterprises miss: how much they can actually steer agents — the binary “accept the risk or don’t” framing is the wrong question.

• At Tessl, 20% of engineering is dedicated to the factory itself; Guy doesn’t think that’s an overinvestment.

• Matt: the change-management piece — getting “I engineer the system” past the early-adopter teams to the rest of the org — is harder than the proof of concept.

• 10X productivity in five years is plausible, but the right metric isn’t coding speed — it’s iteration speed and time-to-market. The new bottlenecks are marketing throughput and user attention.

• Closing coda on the CS-degree question: don’t push the kid into the degree, push the kid to build something. Software matters more than ever; the university is the doubtful vehicle.

James Kaplan: So based on your experience, when you talk with enterprise CIOs and CTOs — banks, pharma companies, what have you, manufacturing companies — what do they not get about the future of agentic engineering? What do you think most people working in enterprise IT organizations need to understand about how agentic engineering will evolve over the next few years?

Guy Podjarny: A good question. People are confused between these two perspectives that feel binary.

I think people underestimate how much they can steer and guide the agents — both to success and to control — and that requires investment.

I’ve seen a mistake, and now I cannot deal with this creature.

They’ve seen the wonder around the vibe coding, so it’s: no, you just need to let the agent be and let it roam free.

They don’t appreciate just how much they can control it.

I think the companies that are at the cutting edge — they spend a lot of time on how they get the agents to build right, on enabling the agents.

And people underappreciate the importance, so they delay embracing the agent because they think of it as this absolute — all they need to decide is whether to accept the risk or not accept the risk.

James Kaplan: They can actually control a fair bit of that risk if they manage those agents.

Guy Podjarny: We have — at Tessl, 20% of my engineering team is primarily dedicated to improving the factory, to agent enablement. And I don’t think that’s an overinvestment.

James Kaplan: Matt, this accords quite a bit with what I’ve heard you say about operational change in software engineering — that it’s not just a set of tools, but a set of tools that fit into a broader system.

Matt Linderman: Yeah, to build on what you’re saying a little, Guy, we do a number of coaching initiatives with different folks, helping folks understand how do you move toward a more modern engineering stack. And one of the biggest things is actually more of a mindset shift: I’m not using a bunch of agents to just generate code, but I’m actually responsible for improving the factory, to use your word.

If I’m not getting exactly what I want, how do I go back into the skill, or the series of skills stitched together into some workflow, and re-engineer it in a way that gets me closer to that? And then that brings people, once you have that mindset, into all sorts of directions. How do we do the architecture, the context, better?

How do we feed InfoSec better into the different agents, so that they bring it in from the first time around? That simple mindset shift — from “I’m using the tools that I’m given” to “I am actually engineering the system that is then generating, and my job is to make that system better over time” — has been a massive shift.

You get a few teams usually that figure it out first. They actually are the ones building the agents, the workflows, et cetera. But what we found is if you can then get that mindset amongst the rest of the engineers, even if they’re already using what other folks have built as the baseline, they can then adapt it, they can shape it to work in their specific parts of the code base, and the types of work they’re doing.

But what’s quite interesting, at least from our point of view, is that a large share of that challenge is the change management piece that comes after defining and showing that it can work. Then it’s: how do you actually get everyone else working in that same way? And a lot of that’s the mindset shift that I was talking through.

Guy Podjarny: Yeah, no, I fully agree with that.

Look, it’s hard because — it is a change in the craft of what you’re operating. It’s a change in the types of mistakes that can happen.

With self-driving cars, when they make mistakes that are nonsensical, that a human would never make, people get actually mad. When there’s a leaf in the middle of the road and it thinks it’s a person and it would not continue, people are actually upset about it.

And I think we’re seeing things like that. There’s a new type of error that happens, and it’s hard for people to acknowledge.

You basically have this combo of: you see a problem, and you’re told, correctly, “Don’t fix the problem — don’t fix the symptom. Go upstream and get the agent to fix the problem.” Which loses a bunch of their craft. And is a new type of work that they might not want to do.

So yeah, a lot of this is culture change. I’m sufficiently a gray beard to have gone through the DevOps transformation. And DevSecOps, and the movement of security responsibilities.

These things are unsettling, and it doesn’t help that agents are happening maybe ten times faster.

It is a big change. So a lot of cultural — it always comes down to people.

James Kaplan: So for the companies that implement the model successfully — the operating model — is this a doubling of engineering throughput, a tripling, 50% improvement? Think five years down the road — what do you think the companies that enthusiastically embrace agentic engineering will be able to achieve?

I think it’s an order of magnitude. 10X.

Guy Podjarny: And potentially more. Not — again, maybe a bit of a common mistake — it’s not about the speed of coding.

James Kaplan: Of course.

Guy Podjarny: It’s the speed of iteration.

When you launch a product, you still should work iteratively. You still should build a minimal product so you get it out there and get people to validate it.

The amount of time it takes you to get a user, to get them to try the product, to give you the feedback and internalize it — those are all still relatively fixed.

You can only lightly optimize those.

But the type of product you can provide to them now can be a lot more comprehensive. You can bring them a product that is actually a lot more thought through.

Your ability to analyze and apply learnings from whatever it is that they did with the product is a lot faster.

And the number of people you need involved in each one of these iterations is a lot smaller, so you can learn more in parallel.

There are enormous opportunities to improve, and they compound. That sort of 2X improvement pace implies that if you’re at it and you’re progressing, you’re gonna be way ahead, ’cause of your pace of learning.

James Kaplan: You’re getting down the learning curve.

Guy Podjarny: It’s interesting to identify the new bottlenecks.

At Tessl we generally work in pairs most of the time.

That’s more because of organizational resilience. If someone’s on vacation or somehow cannot do it, then the other person can continue the work. They collaborate.

It’s mostly independently, and then they review each other’s work, so someone can step in a little bit more easily.

We’ve had a problem that we’re still working on fixing, which is product marketing is struggling to keep up with the pace of new capabilities that we have.

The answer is agents all the way down. You need to build more agentic analysis of what got built, move a few of the decision documents that happened earlier on, to be able to produce marketing material in parallel.

Once you have that, there’s still a scarce resource that we need to understand, which is the attention span of our users. You can’t email them ten times as many emails. You still have to send them a confined amount.

So it’s interesting to understand what the limiting factors are, what the new constraints are. And alignment is one of those.

But within each of those departments, more empowerment, more autonomy, less dependencies is a critical movement, because the cost of alignment relative to the cost of building is so much higher.

James Kaplan: Five years, 10X improvement in productivity via agentic engineering at best enterprises. You agree with that? More or less — what’s your view?

Matt Linderman: I think we need two things. One: it depends on the metric you look at, but I would say 10X order of magnitude makes a lot of sense. It could even be higher. If you look at your throughput metrics, the historical way of engineering — there are organizations getting five, 10X already, and they’re trying to now figure out how do you get that across the organization.

But I think that’s a bit misleading. To your point, Guy, really the metric to be solving for is more of a time-to-market view. If you look at the bottlenecks — it moves to your code review, it moves to your product management being able to build up the right requirements, it moves to product marketing, et cetera.

So really, I think there’s a measure of: one, if it’s a new product, how fast can you get to market? And then for existing products, how fast can you cycle through to get customer input, figure out what to build next, then go build it, go get more input, et cetera. I think that for sure can accelerate 10-plus X more.

But it requires real process change. You have to think, “Okay, how do I actually go get that customer input?” It used to be releasing it to actual customers, and then we went to alphas. Now can you even have customers on your team who can just test it and give you feedback every single day at 3:00 PM?

James Kaplan: Before I release something, before I write something, I have a panel of 500 virtual CIOs and CTOs who give me feedback. I often go through five or six rounds, and they help contain some of my literary excesses. Guy, final short question for both you and for Matt — would you advise a young person today to major in computer science if he or she were so interested?

Guy Podjarny: I would not advise someone to go do a computer science degree — not because — I think software development as a profession with some modifications will continue to live, and we will build software.

James Kaplan: And I think software will matter more than ever. I have a lot less faith that the universities would be the route — that the universities will be able to adapt. Your trepidation is about the degree, not about the computer science part.

Guy Podjarny: Yeah, exactly. Go build something. Go create a product. And I also feel like this is a world in which a breadth of perspective will come a long way.

Learning how to be a bit of a one-person army goes a long way — around touching product, touching marketing, touching your subject domain.

James Kaplan: Matt, computer science — 22-year-old or 18-year-old. Assuming that person will go to university, computer science or study something else?

Matt Linderman: Maybe building on what you mentioned, Guy — there’s never been a better time to build your own company. Going and doing that at some point will teach you far more of a breadth of experiences. Now, if you do go, I do think there’s really a skill around problem-solving, conceptual problem-solving, that is going to be applicable in any job that you have, in communications, et cetera.

That may come from engineering degrees, you could say math degrees, et cetera. But I would really be looking for something that pushes you in terms of how do you think, how do you structure problems, et cetera — that you can then bring into whatever type of work you’re doing moving forward.

And then go into the workforce and learn, as you said — entrepreneurship or not.

James Kaplan: Thank you so much. It was a great discussion.

Guy Podjarny: Thank you.

Matt Linderman: Thank you everyone.

7. What would Biddle say about agentic software engineering?

No single element of the modern system of force employment wins a battle—not combined arms, not suppression, not decentralized initiative. The doctrine wins.

The same is true of Podjarny’s stack: models, tools, context, harnesses, factories. None of them buy you anything in isolation. The factory is the doctrine.

And Biddle’s harder lesson—that adopting the modern system requires trusting non-commissioned officers with judgment they were not historically given—is the agentic problem in another voice. Just as you have to trust NCOs with fire teams, you have to trust engineers with agents.

The companies that learn it will not be 10X more productive in any narrow sense. They will be 10X faster at learning — which is perhaps the discriminant between victory and defeat in competitive markets.

1. Every computer system we build is an imperfect representation of reality

“No, I didn’t go to Catholic school. Why do you ask?”

An eminent partner at a previous consultancy looked at me across an empty conference room and explained: “You have an instinct for mapping data onto a grid -- you have a Cartesian mindset, which many good consultants learn from a Jesuit education.”

Grids distort as much as they reveal. We’ve all seen (or built) grids for evaluating outsourcing vendors: 20 points for stability, 30 for service quality, 30 for cost, 10 for innovation. These never produce the right answer -- they ignore non-linearity. You won’t select a vendor below your financial stability threshold no matter how cheap; once a bidder clears it, you care about cost and service, not financial stability.

Every slide, every analysis, every system is an imperfect representation of reality. CRM systems are a simplified model of how your business interacts with customers. Operational systems are a simplified model of your factory. I learned this crawling around telecom carriers in the 1990s, where you had to ask the service techs which USOC “1FR” lines had bridge taps that had to be removed before upgrading to DSL.

2. The world is entropic

Do you know whether that deal will close next week and at what price? Whether your flight to Chicago will land on time? Or whether a new employee will turn out to be a hero or a goat? I do not.

As a recovering history major, I believe the past provides counsel on the future. On June 21, 1948, the Small-Scale Experimental Machine became the first computer to run a program stored in its own electronic memory -- 128 bytes of it. Weeks later, Weaver and Shannon published articles foreshadowing many of the problems we struggle with today: automating Byzantine business processes, capturing latent or ambiguous data.

Shannon defined entropy as average amount of uncertainty in a probability distribution. [1] Maybe that’s okay -- in a world without entropy no business could exceed the risk-free rate of return. The more entropic a domain, the more information required, and the more expensive the computer system to automate it.

Weaver laid out a relationship between complexity and uncertainty. Some problems are simple: hold all variables constant except the dependent and independent ones, and you get the steam engine, the automobile, the telephone. A payroll system is the modern analogue -- fixed variables, describable rules, few feedback loops.

Starting in the late nineteenth century, scientists attacked problems of disorganized complexity. Statistics could predict the frequency of calls in a telephone exchange or the claims paid by a life insurance company, even when individual causes remained opaque -- provided each data point was atomic. Fair Isaac developed the FICO score on this basis in the late 1950s.

Then Weaver addressed problems of organized complexity -- macroeconomic management, ecology -- where many inter-related factors multiply uncertainty because each may influence the others in non-obvious ways. Neither nineteenth-century analytics nor twentieth-century statistics could handle them. He hoped new computing devices might, and pointed to the operations research developed in the Battle of the Atlantic as a way forward.

Problems of organized complexity abound in modern business -- order-to-cash, pharmaceutical manufacturing. Given enough contracts, even payroll can turn into one. [2] How much time do knowledge workers spend massaging data into or out of enterprise systems because the system couldn’t capture every exception the domain implied?

We should forgive Weaver for not foreseeing the organized complexity required to address organized complexity -- ERP programs suffer their own, and enterprise technology functions suffer from it themselves.

Writing with Shannon, Weaver named another contributor: latent meaning. Ask an account executive the status of a potential sale and she might say “We’re in final price negotiations with the CHRO and he would like to get a deal signed within the month, but the general counsel is hacked off about a couple of legal terms we require and the CHRO heard he is going to call the CEO and ask that they reopen discussions with another bidder.” What is she supposed to select among the four CRM choices for “status” -- RFP open, RFP submitted, financial negotiations or closed?

Weaver and Shannon identified one more problem -- whether a system creates the desired behavior in the people who interact with it. Think about computer systems the way the military thinks about weapons systems: as inclusive of both the technology and the user. Design choices affect user behavior in unpredictable ways. Complicated interfaces cause users to resist entering data, or to prejudice what they enter to make themselves look good.

Calendaring is deceptively entropic. If Suzy, my assistant, asks me about a conflict at 10 am on a Tuesday, I might say: “I’ll go to the meeting with client 1, because I think that colleague A can cover me in the meeting at client 2. And don’t decline or mark me tentative for anything, because I don’t want anyone giving away the time slot because I might not be there.” I don’t verbalize dozens of assessments about people and situations that shape my decisions. You have entropic communication about organized complexity, latent information and adaptive behavior all in a couple of sentences!

3. Entropy creates cost and frustration when we build systems to represent it

How much time do we all spend in conference rooms debating how much granularity the data model should have -- and how we balance fidelity to the business process versus the cost of maintaining data? How frequently do you find the correct state for a transaction not in the fields designed to contain it, but in the free-text notes or the accompanying email? And how much user anger derives either from the endless fields (specified to capture the subtleties of state) or the disconnect between what the system says and the reality they observe?

Put another way: how much time do we devote to designing around entropy when we build systems? And how much frustration do we create because of the choices we make in doing so?

Operational systems work best when the world can be reduced to stable categories, deterministic workflows, and enumerable exceptions -- all these make a domain easy to formalize. Nobody complains much about most payroll systems because they apply a bounded number of explicit rules to available data.

Analytic systems work best with huge sample sizes and a few relevant independent variables -- making the entropy here tractable to statistical analysis. Machine learning systems for pricing consumer products work because massive amounts of structured data allow probabilistic inference where humans might have struggled to discern patterns.

Other domains and use cases have more intractable entropy. Systems to support treasury management for large enterprises? Modeling a thousand-page contract, involving hundreds of legal entities, dozens of jurisdictions and a thousand different exceptions you can have for a transaction -- all of which generate entropy. Which messiness must you model and which can you simplify away? CIOs have exceeded budget, blown deadlines and angered users in seeking to answer that question.

Yes, machine learning has blunted the impact of entropy in some cases by sniffing out the relationships among variables, but often the sample size is too small and the data too messy for traditional machine learning to be effective. Years ago, someone said collections managers could offer definitive recommendations about how to reduce losses -- why couldn’t CISOs do the same when talking about how to protect the business against cyberattack?

I tried to explain that each demographic segment included millions of households. You could experiment with a new script and quickly determine whether it increased or decreased promises-to-pay. Any large company’s technology environment is a snowflake -- even two companies of similar size and in the same sector may have radically different technology environments. Vulnerability depends not on individual decisions, but on how you connect all the pieces in your environment. And you might not know whether you had been breached for years, if ever. [3]

4. GenAI-based agentic systems process entropy

Deterministic systems cannot process entropy. They can rely on humans to pre-process it for them -- as happens when product managers and engineers sit in a conference room debating how to capture the data required to automate an ambiguous process. They push it on to users like account managers who must fill in endless fields about their pipeline -- and still wonder which option they should select to describe deal status. Or they can store it inertly, like the free-text notes that exist in some customer service platforms. All of these imply some combination of low efficiency and lower effectiveness.

When large language models process text, they convert tokens into vectors, points in a high-dimensional space. This encodes meaning through proximity -- similar meanings cluster together. Large language models can do things deterministic systems cannot do or do poorly:

• Allow inference across stored entropy: Written and spoken language are entropic. Vector embeddings allow LLM-based systems to query and analyze free-text notes, email threads and meeting transcripts.

• Identify implicit relationships: Vector geometry represents connections between concepts, such as the general counsel wanting to block the deal for group health insurance because he disliked the contract terms.

• Understand gradations rather than discrete states: A deterministic system requires the account executive to choose whether the deal has advanced to final negotiations or not. A vector representation of the same situation can sit between two states.

GenAI-based agentic [4] systems give us new ways to process entropy.

• At design time, by using software engineering agents to create business logic that reflects all the organized complexity that Weaver described.

• As part of the user interface, to mediate between the entropy of written language and a deterministic system, rather than forcing the user to do the work.

• Via data ingestion, to derive insights from the massive stores of entropic, unstructured data every enterprise has sitting on its servers.

• At run-time (either with or without a human in the loop), to make decisions and execute transactions non-deterministically.

We can also store data used and produced by agentic systems in different ways. Traditional relational databases excel at storing and retrieving massive amounts of transactional data at speed and with near-perfect reliability. They struggle with more ambiguous data, with dense relationships among all the elements. [5] We can choose to store this data either in vector databases or in knowledge graphs.

5. You have choices about how and where you use agents to process entropy

So much of the agentic discourse we see mirrors the flat Cartesian mindset captured in the grid used to evaluate bidders for outsourcing deals. Agents are risky! Or: everything will be an agent!

But entropy is, well, entropic. It varies in scale and shape from business domain to business domain. Sometimes it takes the form of a dense web of interconnections among idiosyncratic products, contracts, processes or customer relationships. Sometimes it takes the form of latent data that doesn’t fit into any data structure you might define. Not a few business domains suffer from multiple forms of entropy.

GenAI-based agents also have disadvantages compared to deterministic systems. GPU-based inferencing is slower and more expensive than CPU-based processing -- a single agentic transaction often costs cents and adds hundreds of milliseconds, where the equivalent deterministic transaction costs fractions of a cent and resolves in single-digit milliseconds. Non-deterministic systems are only as good as the context they receive. An agentic system can process the free-text notes in a CRM platform. It won’t know anything about the discussion two account executives had in the car on the drive back from the customer site. [6]

Abjure the false binaries -- you have real choices about how and where in the value chain you process entropy.

• Agentic software engineering: This will be relevant for almost any systems effort. It will allow you to automate all the business logic required to reflect organized complexity with more speed and reliability and less cost. And after agents help you develop the code, you can still apply all the quality assurance mechanisms you have developed over decades, just as you would code developed by hand.

• User interface: Retain traditional interfaces for situations where users have to enter small volumes of easily understood data. Develop agentic- or chat-based interfaces for order entry, CRM, or transaction processing systems where users complain about having to fill in screen after screen of data. You can always use a combination of deterministic rules and user validation to ensure the agent correctly captures user intent.

• Data ingestion: This is one of the most powerful and most underestimated capabilities. All companies receive and store vast amounts of valuable but entropic data -- eighty percent of corporate data is unstructured and even structured data can be fragmented and hard to correlate. Customer requests for quotation? Customer service notes? Legal contracts. Agentic capabilities can ingest all of this either to support operational processing or to generate new business insights, even if many companies have not focused here yet. [7]

• Run-time: This is complicated and has the highest stakes. Use agentic patterns for low-volume heterogeneous decisions. I am helping technology organizations use agents to compare project designs with technology standards. The agent will compare two artifacts (a project design and a standards document) that describe organized complexity in natural language (which is inherently entropic) and determine whether one conforms to the other. Hybrid patterns will probably become increasingly common, with deterministic cores and agents to handle edge cases.

• Data storage: Naturally, relational databases will continue to store structured and transactional information. Knowledge graphs excel in modeling product portfolios, customer relationships, process maps and other domains where relationship structure carries meaning. Vector search enables retrieval by meaning from notes, documents and transcripts.

6. Precision matters because entropy is, well, entropic

I have always hated the formulation “The technology is easy. The governance is hard. The organization is hard. The line at the cafeteria is hard.” Here, design choices will shape cost structure, risk posture and user experience for years.

With a capability to process entropy at scale, you have to think about where the entropy sits in your business system -- even a simple one.

Managing invites for the Technology Leadership Forum is lower-entropy than a hundred-million-dollar group insurance deal, but there is plenty of “Joe really wants to attend, but can’t, depending on when a personal conflict lands -- and wants to know if Sally can possibly attend in her place.” I put invitees and members into a knowledge graph and built Agent Serena to translate the entropy in my email into the organized complexity of that graph. [8]

Taking a more highly-scaled domain: entropy pervades enterprise change management in banking. Dozens of interconnected process steps and artifacts; latent information about why a milestone might be at risk of slipping and under what circumstances. Traditionally, banks managed it with managerial talent copying data among word processing, spreadsheet and presentation files. And many, many emails. The result: frustration, expense, and less insight into major programs than anyone would like.

Banks can use agentic software engineering to build a system whose agents ingest program documents, extract the relevant risks, issues, decisions and action items, and store them in a knowledge graph with the relationships among them. Which risks affect which business lines? Which work-stream lead owns which decision? Further agents interrogate emails and videoconference transcripts to enrich the graph. Vector descriptions let program managers search by meaning, not keywords. Still more agents read the graph to assess risks and surface opportunities to improve the program.

This combination -- agents, knowledge graph, vector database -- removes the entropy from a painful business process. It reduces cost and improves transparency. Those of us on team cyborg (rather than team android) will note that it also empowers managers: less toil, better information.

Agentic systems -- with knowledge graphs and vector databases -- can be transformative. When I wrote that global business must move beyond organized factories and chaotic offices, this is what I meant. The benefits are both economic and humanistic. Nobody grew up hoping to spend days pasting data from email to spreadsheets and back.

Precision matters here. Agents are not magic. Inferencing is expensive, latency is real, and new vulnerabilities arrive faster than we can grasp them. But the harder discipline is the one Weaver and Shannon left us: see your business as a system, find where the entropy sits, and choose where to process it. A flat, Cartesian grid won’t help.

Footnotes

[1] This differs from standard deviation, which measures the magnitude of the spread around a mean. Shannon entropy measures the unpredictability of a distribution. Relevant to us: you can measure the Shannon entropy over a set of non-quantitative values just as you can over a set of quantitative ones. In addition, there are more and less expansive definitions of entropy. I am using a relatively expansive one here.

[2] CityTime is a great example of Kolmogorov complexity. The shortest possible description of the rules governing what every city employee gets paid is approximately as long as the rules themselves — decades of negotiated union contracts, grandfathered provisions, and exceptions to exceptions, each one load-bearing. You cannot compress it further without losing something that will eventually matter. Automation doesn’t reduce this complexity; it just moves it from humans who held it in their heads to engineers who must encode it in systems.

[3] My interlocutor said I was over-complicating the situation and CISOs were probably just incompetent. Sigh.

[4] Agents predate widespread adoption of large language models and genAI. By some definitions, the cruise control system in your car is an agent. You set a speed. It monitors the speed, accelerating when the car drops below that speed (because you are going up a hill) and easing off the throttle when you exceed it. Of course calling LLMs makes agents infinitely more capable than the cruise control in your car.

[5] The notion that relational databases might struggle with relationships among data elements might puzzle some. But only those who have never stared at a screen in the early morning trying to make sense of an outer join -- or who developed a better command of SQL than I ever had.

[6] I like the idea of decision traces and context graphs, but we should be realistic about which decision traces we can capture and which we cannot, unless we want to build a panopticon for ourselves.

[7] I stared in disbelief the first time Zubin Ghafari showed me how he used GenAI to integrate messy CMDB data with other telemetry information. I had assumed this would have taken him weeks.

[8] The natural language front end to Prosaic Graff was a life-saver, but the latency sometimes made me want to put my fist through the screen. So I created Python scripts I could run (instantly) from the Terminal that told me how many members planned to attend or the status of any individual member.

Back when I did the research that turned into Beyond Cybersecurity, several people asked “does securing the software really matter if we can’t trust the chip?” or “wouldn’t it be great if the chip could be part of the security architecture?”

A highly capable and motivated attacker could compromise firmware supporting the most sensitive workloads, making security controls at higher levels of the stack ornamental. While the US military’s Orange Book (1983) first formalized the logical boundary of a Trusted Computing Base (TCB), its multi-user specifications assumed the underlying physical hardware was secure inside a guarded facility. Distributed architectures and modern threat models shattered that assumption, forcing the industry to move that TCB boundary down into the architecture of the chip itself.

The Trusted Computing Platform Alliance (TCPA) — which became the Trusted Computing Group (TCG) — developed the idea of a Root of Trust, with three pillars:

• Root of Trust for Measurement (RTM): The initial, immutable piece of code (usually embedded in the motherboard ROM or BIOS) that boots first and measures (hashes) the next component before handing over execution.

• Root of Trust for Storage (RTS): A secure memory zone within the chip that holds the cryptographic keys and the accumulated measurements. Software cannot overwrite or read these keys directly.

• Root of Trust for Reporting (RTR): The cryptographic engine inside the chip that signs those measurements using an endorsement key burned into the silicon at the factory, proving to an outside party exactly what state the machine booted into.

As of 2013, some devices had a Trusted Platform Module 1.2 (TPM), a distinct, low-cost microcontroller soldered onto the motherboard, completely isolated from the main CPU lines — but its separation from the main CPU both introduced bottlenecks and limited its security efficacy. Some data center managers declined to turn on this functionality because they feared the operational complexity it required could cause outages.

TPM 2.0 improved on 1.2. It embraced cryptographic agility and it moved the silicon root of trust closer to the CPU, often embedding it as an isolated firmware routine (fTPM) directly inside the processor chipset, eliminating the exposed external motherboard bus. To fix the datacenter uptime issues where a benign driver update would brick a server boot, it supported Policy-Based Authorizations.

But TPM 2.0 is an authentication and state-verification mechanism. It can verify that a system started up in a clean state, but it cannot protect data from being stolen while in memory.

To address these problems the Linux Foundation birthed the Confidential Computing Consortium, which published A Technical Analysis of Confidential Computing. This document established the non-negotiable baseline that unauthorized entities could not view or alter data or code running in a Trusted Execution Environment. This required chip manufacturers to redesign how processors handle memory management, CPU registers, and privilege rings. They couldn’t just build a “secure sandbox”—they had to modify the fundamental instruction set architecture (ISA) so the CPU could treat its own operating system or hypervisor as a potential threat.

Today, most enterprise-grade server and device chips have Confidential Compute capabilities, and companies are starting to use them. How do they use confidential compute to enhance the security of agentic systems without writing systems-level code to manage CPU instructions, page tables, and hardware register states?

A discussion with Opaque Systems CEO Aaron Fulkerson

Opaque Systems aspires to bridge the gap between hardware primitives and the enterprise application layer, by providing software engineers with access to policy enforcement, orchestration and cryptographic proof.

CEO Aaron Fulkerson talked about what this all means as enterprises seek to implement AI-based systems. Prosaic Times remains studiously neutral on particular technologies, but hearing from builders in their own words is instructive, and we always respect people who are passionate about the products they develop.

Here are a few of the key takeaways:

Prompt engineering and code scanning are probabilistic mitigations of a problem that requires deterministic enforcement. Confidential AI uses the encryption key baked into modern CPUs and GPUs to do that enforcement cryptographically: what ran, where it ran, what rules applied, with a signed report any auditor can verify. The hardware capability has been sitting in silicon for a decade.

Regulators are starting to ask about runtime enforcement, not just configuration. The EU AI Act, emerging regulations in Asia and the Middle East, and likely HIPAA are converging on a requirement that isn’t “we configured this policy” but “we can cryptographically prove this policy was enforced at runtime.” That is precisely the proof confidential AI produces. The regulatory hook is probably what forces enterprise adoption ahead of any internal security posture. Design for sovereign cloud will only accelerate this.

The policy standards landscape is a fragmented patchwork waiting for consolidation. Anthropic ships mutually-attested TLS. Microsoft has its own flavor. Google, Meta, TikTok, ServiceNow each ship variants. None of it is portable across hosts. A consortium effort building on SPIFFE, EATS, and RATS is producing a superset specification where the policy travels with the data.

James Kaplan: This is James Kaplan with another Prosaic Times podcast. We have one of the most interesting people in the cybersecurity space, Aaron Fulkerson of Opaque. Aaron, welcome.

Aaron Fulkerson: Hi, James. It’s a pleasure to see you again.

James Kaplan: Why don’t we start out by talking a little bit about your journey? Let’s hear about your career and what brought you to the place where you’re at today.

Aaron Fulkerson: Sure. Opaque Systems spun out of UC Berkeley — the same lab that created a lot of the foundational AI infrastructure: Spark, Ray, vLLM. The team that runs the lab — folks like Ion Stoica and Raluca Ada Popa — are world-renowned, nerd-famous folks. I was approached by them while I was running a business unit at ServiceNow, and I was intrigued by their background building the essential foundational technologies that everybody uses.

Ion Stoica being the founder of Databricks certainly got my attention. When I spoke with them, what they helped me understand was that they had created a new technology called Confidential AI that allowed regulated enterprises, governments, or sovereign entities to bring AI to their most sensitive systems and data, with verifiable guarantees about what ran, where it ran, and what rules were enforced.

That’s now become a whole category that Gartner writes about and that all the silicon vendors, hyperscalers, and everybody else covers. It’s been an exciting ride over these last two years.

From confidential computing to confidential AI

James Kaplan: All right. Why don’t we step back? Tell us a little bit about the history of confidential computing — what it is, and why it’s important.

Aaron Fulkerson: Yeah. It’s been around maybe ten years, so it’s been around a long time. What it means is that the hardware — a CPU or GPU — has an encryption key baked into the silicon, and that enables two key capabilities. One is what’s called a trusted execution environment, or an encrypted runtime: you can run your workloads on data while encrypted. That’s what everybody thinks about when they think about confidential computing. There’s another capability of confidential computing that’s at least as important, if not more — the ability to do what’s called hardware attestation with that encryption key. What that means is that you can cryptographically sign software.

Now, confidential computing is a hardware layer that’s available on all hyperscalers. All modern CPUs and GPUs have these capabilities. It’s not specialized hardware. What this enables is what we call confidential AI — a software layer above the hardware, above Kubernetes — and that means you can have hardware enforcement of what ran, where it ran, and what rules were enforced at runtime.

I don’t need to tell you, James, or anybody who’s an AI builder, that you cannot enforce rules on AI agents at a software level. There’s a greater than 0% chance — at least 1%, typically higher — that these things are going to circumvent your software rules.

So you have to do this hardware enforcement, and the good news is this technology that’s been around for a decade has found a killer application: confidential AI.

James Kaplan: Tell us a little bit about that. Tell us why software enforcement doesn’t work for agents and why hardware enforcement does.

Aaron Fulkerson: Sure. AI systems are non-deterministic, so they behave in ways that are unpredictable. There are a couple of things here. There are adversarial attacks, which is what everybody immediately thinks about when you talk about an encrypted runtime — but adversarial attacks are far less of a threat than the non-adversarial ones.

So what’s a non-adversarial attack? These systems, designed the way they are with software enforcement, bleed sensitive data. Opaque, in collaboration with our partners at UC Berkeley and a bunch of ISVs and large systems integrators, has developed what we call an AI surface map for data bleeds. It catalogs 46 different ways these systems bleed data by design, simply because they haven’t been hardware-enforced. They will circumvent your software guardrails by design, and the only way to enforce the rules is cryptographically — hardware-enforced, as I described. It’s fundamentally different from legacy enterprise software.

We’ve shifted from a hardware compute layer to a software compute layer. As these agents build a context window, calling your most sensitive data, they pass all that context around to do software analysis — probability, right? That’s how language models work: an analysis that says, “Oh, here’s the highest-probability next one.”

That context lands in application performance monitoring packages like Splunk or Datadog. Your CloudOps or DevOps teams doing memory dumps may be able to see stock trades, maybe executive compensation — anything that passed through.

There are a whole lot of different ways this category of system, AI systems, bleed your data if you don’t upgrade the trust layer. The same way we had to upgrade the trust layer with the transition to the internet and encrypt data in transit, we have to upgrade the trust layer for these AI systems — or you’re just going to bleed your most sensitive information everywhere.

James Kaplan: Give us the use case or the example.

Aaron Fulkerson: I’ll give you some examples. We have customers like ServiceNow, Encore Capital, other financial services firms, and, in Thailand, SCBX. What they do is use confidential AI. They deploy what’s best thought of as an AI module, because they aren’t going to shift all their workloads onto confidential hardware in the cloud yet — they’ve already built a lot of their systems.

They’ll start with, “Hey, we’re doing some really sensitive data processing — stock trades, HR information, or a CFO tool for summarization and analysis.” They’ll deploy that, and using confidential AI, they’ll create policy enforcement at the infrastructure level. For example: it must run inside my virtual private cloud. It can only communicate over this subnet. All the way out to the agent graph, this agent can only speak with these tools. All of that gets rolled up into a strong, cryptographically enforced identity, so that before anybody sends data to a workload — I’m using “workload” generically here, to mean any AI workload or agent — they can inspect the signatures and the cryptographic enforcement.

Does it run inside my virtual private cloud? Does it have the data-ingress and data-egress policies I require? Does it use my identity? Whatever policies you want get hard-coded into the identity before you send the data, so you can verify the integrity of the system. When you send the data, it’s sent encrypted. The policies are verifiably enforced at the hardware level. And most importantly, James, you get proof. You get a report with cryptographic signatures that any internal or external auditor can check, proving exactly what ran, where it ran, and what rules were enforced.

Why agents require new types of guardrails

James Kaplan: Let me play this back to make sure I understand it. In the old days — say two years ago — if we were building an application and we had a set of rules about which tools that application could call, or where it could send data, we would scan code against a set of policies and see if it violated those rules.

And if it violated the set of rules, we’d send it back to the engineer and tell them to go fix things, right? Then we’d rescan, and we’d be fairly confident it wasn’t going to violate that set of rules because we’d scanned the code. So far, so good? Now, if we’re building an agent, the agent operates non-deterministically.

So we can’t know with certainty whether that agent will call one set of tools or not, and the guardrails we’ve placed around it… When we’ve tried to use prompting or other controls to limit the purview of that agent, sometimes that works, but you can’t say with certainty that it’s going to work.

However, if we build the enforcement of those rules into the hardware layer, then we can operate with certainty. Is that a fair summary?

Aaron Fulkerson: That’s exactly correct. You’re talking about the non-determinism of these systems — you’re exactly correct. Let’s say there’s a 1% probability that one of these agents bleeds data, which we know for a fact is at least 1%, probably greater. At 1%, maybe that’s okay if it’s a non-essential system or data set.

However, scale that to 100 agents and the math gets pretty frightening — you’re now at something like 40-something percent.

At 1,000 agents interoperating and communicating — which may seem like a lot, but I’m running thirty-something agents in the background on my desktop right now while I’m speaking to you — you’re at a 99.9% probability of bleeding data.

James Kaplan: And there’s plenty of workloads where one percent is unacceptable.

Aaron Fulkerson: Correct. Absolutely.

I was speaking with some industry analysts just last week, and one of them was asking, “Is it really that big of a deal? We’ve always had people who leak in elevators and hallways.” (A quick fact-check on my earlier math, by the way: at 100 agents, it’s 63% probability.) The analyst — from a big firm everybody knows — was asking, “Does it really matter? We have employees who talk in the elevator or the hallway, and they’re bleeding data at similar probabilities.” The response I gave, which their colleague already understood, was, “It does matter, because what an AI agent can achieve in a span of seconds or minutes vastly exceeds what a group of organized humans, even malicious ones, could achieve in a year.”

These things are operating at machine speed with human-like capability to reason, decide, and act. That’s quite different from an employee in the elevator accidentally leaking some competitive information. We’re talking about systems that can do damage within seconds or minutes that bad actors might not be able to achieve in a year. And furthermore, the leaked data — it used to be hard to sift through. Somebody leaks some data, is it really that bad? Who’s going to utilize that data? AI will.

James Kaplan: Yeah, there’s also an autonomous-vehicle analog here. You could probably make the case that an autonomous vehicle is safer than a vehicle operated by a human. But there’s just more cultural fear and nervousness around an accident caused by an autonomous vehicle than an accident caused by a human driver.

As we seek to advance agentic adoption, a problem involving an agent and exfiltration of data is going to be culturally more challenging than somebody talking in an elevator. So yes — I agree with everything you said, plus the bar is probably higher.

Aaron Fulkerson: Yeah, for sure. I think that’s true. To pull on that autonomous-vehicle analogy: hey, one bad driver can cause a lot of damage. But if you had a swarm of autonomous vehicles that could self-replicate on the fly, driving all over the freeway at a thousand times the speed — which is effectively what these agents are doing, compared to human drivers — don’t you think you should have some additional regulation and enforcement that’s verifiable in a deterministic way, rather than by probability or just rolling the dice?

James Kaplan: So let me ask a devil’s-advocate type question here — or maybe not a devil’s-advocate question, more an architectural-alternative type question. I saw a really interesting paper about how you enforce controls on agentic systems. The paper suggested that maybe the right way to do it is, instead of having the agentic systems operate directly, you have them generate procedural code in real time, which you can then scan against a set of policies.

Obviously that injects latency. But if you were an enterprise architect, how would you think about the option of using confidential AI versus the option of having an agent write procedural code that you’d then scan using traditional code-scanning techniques? How do you think about the alternatives there?

Aaron Fulkerson: I think it’s complementary — I don’t think it’s an either/or. Just to restate what you’re proposing —

James Kaplan: I’m not proposing — describing.

Aaron Fulkerson: You’re describing. Thank you. The scenario is that the agent generates deterministic procedural code, which then goes through a scan.

I think that’s complementary, right? You still have an agent making decisions about what procedural code to write, based on the sensitive systems it’s touching, the tools it’s calling, the data sources it’s pulling from. And I’d assert that even in that environment, you’ll want to have some rules — and you’ll have to have them, because it’s increasingly a requirement in most regions and nations to have proof of what ran, where it ran, and what rules were applied to that agent, even when it’s producing deterministic procedural code that goes through another scan. I suspect that whatever’s doing the scanning might itself be augmented by AI in some form, right? And there again, cryptographic enforcement, or hardware enforcement. I tend to use the two interchangeably because our customers — the people deploying confidential AI — are AI builders. They’re not the InfoSec or security team or the compliance team. So as soon as a lot of AI builders hear “cryptographic” or “encryption,” they go, “Yeah, that — I just wanna ship cool stuff.”

So I tend to use the two interchangeably because I want builders to know: no, this helps you ship cool stuff faster, because you don’t have to go through the protracted six- to eight-month surveys with your internal and external auditors that I’ve heard so many CTOs and AI builders describe as their current dilemma.

Hardware identity and the supply chain

James Kaplan: Trust me, I see it all the time. One thing that struck me hearing what you were describing is the ability to prove where something ran. Does this mean each chip has a unique identity, and therefore you’re able to confirm that it’s being run by who you think it’s being run by — in terms of an external service provider?

Aaron Fulkerson: That’s exactly correct. As I mentioned, with confidential computing there’s an — by the way, I’m oversimplifying. I’m not getting into too much technical detail —

James Kaplan: Every podcast everywhere oversimplifies everything, right? Otherwise they’d all be fourteen hours long.

Aaron Fulkerson: Exactly. I know somebody is going to say, “Well, the attestation service might be —” so I’m simplifying. But to your question: there’s an encryption key baked into the silicon, and that encryption key is what’s used to do the attestations. At the time you invoke a service, you’ll know exactly the profile. Where is it running? What is it running in — these Kubernetes nodes, that virtual private cloud? What are the network rules allowing it to connect to external services? Everything is encoded cryptographically and enforced by the hardware.

It’s physics. The significance here is, hey, can you trust AMD, Intel, NVIDIA at a hardware layer? And as long as you believe they know how to manufacture their chips, you don’t have to trust anything else. Nothing else in that stack do you trust.

James Kaplan: And do you know — or is there some way of knowing — that this individual chip was bought by this service provider versus that service provider versus somebody you may not want to be doing business with? Is there some registry somewhere? Apologies if that’s a naive question.

Aaron Fulkerson: That does exist. There’s actually a standard — a couple of them, in fact. SCITT is one, S-C-I-T-T. SALSA is another. They give you levels of verifiable provenance over the entire supply chain.

I don’t know if there’s a registry that exists independently. The technologies to do it exist, and I know all the silicon manufacturers and the hyperscalers have talked about having a registry so that they have complete supply-chain verifiability — but I’m not certain that registry exists yet. As an enterprise, though, you can bake that capability into confidential AI. That’s a feature of confidential AI, absolutely.

James Kaplan: Yeah. That’s an interesting idea. If you could say, “We know with certainty this is running on a set of chips that was bought by this service provider — there’s no chance it’s running someplace else,” or, “We know with certainty this is running on a set of chips located in this national jurisdiction versus that national jurisdiction.”

Aaron Fulkerson: Yeah. So I know there’s a podcast — AI Confidential — that I’ve had you on,

James Kaplan: Of course.

Aaron Fulkerson: A podcast that I host. I had a great conversation — I think on the very first AI Confidential — with Mark Russinovich, who’s the CTO of Azure,

James Kaplan: I’ve met him — he was on that panel I did at the conference you guys had.

Aaron Fulkerson: Exactly, yeah. And I’m looking forward to seeing you back at the Confidential Computing Summit at the end of June — the 23rd and 24th in San Francisco.

James Kaplan: I look forward to it. I’ll be there.

Aaron Fulkerson: Mark Russinovich, and Mark Papermaster — the CTO of AMD — in our very first AI Confidential were describing exactly what you’re talking about, James. And I was naive.

This was early in my tenure at Opaque. I was so focused on AI that I didn’t think about the entire hardware supply chain — securing it end to end. But to your point, you could extend this concept beyond provenance and supply chain to the actual manufacturer. You could do cryptographic enforcement of the design itself.

James Kaplan: I was going to say — that’s something incredibly important, I think, in the aerospace and defense community. They know exactly what the provenance of the hardware is, and exactly what’s running on what.

So let me ask a slightly different question. In some respect, what you’re describing reminds me of the early days of cloud security, when we started thinking about what became known as cloud security posture management — and we started to realize how important the business rules and policies were.

It took some time to sort out the model for defining those policies, for managing them, for figuring out what set of policies you wanted to have. Could you speak a little bit about that — about the process of policy management for confidential AI? How far along in the journey are people? What techniques do they use? What tends to work well versus less well?

Aaron Fulkerson: This is a really important topic you bring up. In the era of cloud, we did a trust-layer upgrade where we said, “Okay, SOC — we have to capture our policies at the time of deployment.” What’s different here, and what’s being demanded in a lot of different regions — the EU AI Act requires this, new regulations are coming online in Asia, same in the Middle East, and I believe it’s also true for HIPAA — is that you have to extend that to runtime.

It’s not just policies at the time of configuration; it’s policies at runtime, and you have to provide proof of runtime enforcement. The significance of confidential here is that it produces a report of all the policies that were enforced at runtime, and you can prove cryptographically that they were executed.

Because of the nature of agents behaving with human capabilities at machine speed, you have to have provable runtime policy enforcement. The good news is there’s been a proliferation of great frameworks and tools for policy-as-code. You don’t have to reinvent anything — you just take the policies-as-code, cryptographically enforce them, and measure at runtime that they were actually enforced.

James Kaplan: You’re building on all of these component parts. This is another one of those one-plus-one-equals-three situations you see in technology — the combinatorics of technology — where we already have this policy-as-code thing, and we already have this hardware key baked in. Right.

Aaron Fulkerson: Right. You add these two together and — oh my gosh — now we’ve actually got a way to adopt AI agents confidently and safely. Because we want to attach AI agents to all our systems and all our data sources — that’s how you get value. The more sensitive the data, the more value you can get out of it, but also the more risk there is in bleeding it. The key point is that this new security requirement in the agentic system, like all things in tech, is something we were doing previously, brought forward in a new way.

Sovereign AI and the standards landscape

James Kaplan: So how does this manifest itself in sovereign AI? Hark Singh, the CTO of InfraPartners, did a fireside chat at the Technology Leadership Forum last week, and was talking about how sovereign cloud and sovereign AI are an increasingly significant demand driver in the data center space.

How do confidential computing and confidential AI intersect with the desire for sovereign cloud and sovereign AI? I was wondering if you could speak a little bit about those dynamics.

Aaron Fulkerson: Absolutely. It’s an essential cornerstone capability. Look no further than Dr. Najwa Araj of the UAE’s ATRC and TII, who stated in a recent press release with Opaque that you can’t have sovereign without this kind of verifiability.

James Kaplan: And look at Jensen’s keynote at the April — was it April GTC?

Aaron Fulkerson: Was it April or March? I forget. I think —

James Kaplan: I think April, but I’m not sure.

Aaron Fulkerson: Jensen had it at the center of his keynote — the central topic was confidential and verifiability. Why? Because he understands what we’ve just been talking about. He said it in every session after the keynote: in order to safely adopt enterprise or personal agents, you have to have verifiability. He’s talking about confidential, hardware-enforced verifiability. That’s exactly what he means.

So why does this have to do with sovereign? If you look across all the big tech players, all the silicon vendors have oriented themselves around these confidential capabilities. Hyperscalers are demanding confidential. Frontier model labs are adopting confidential. What’s going on?

The hyperscalers demand it because they know they won’t get adoption in the rest of the world — outside the United States — if they can’t verify data privacy for sovereign cloud operators. So they’re demanding it from the silicon vendors, because otherwise the hyperscalers are going to get their lunch eaten by NeoClouds in the rest of the world. That’s happening right now.

For the silicon vendors upstream from the hyperscalers: if they don’t provide these verifiable guarantees, China is knocking on the door with great chips. They’re coming to eat the silicon vendors’ lunch, so the vendors have to differentiate. They’ve found that differentiating around confidential is a great way to do that — because the hyperscalers need it.

What about the frontier model labs? Why are they so insistent? They’re making incredible models — their intellectual property is their model weights. If they can’t protect their model weights in a sovereign cloud in the rest of the world, what’s their differentiation?

James Kaplan: Property is going to be stolen? And that’s what confidential does for the frontier model labs — it allows them to deploy in the rest of the world with verifiable proof that they protected their intellectual property, their model weights.

So I heard a couple of things. For the labs, you can use confidential AI to protect the model weights. For users and for AI or cloud providers in the rest of the world, you can demonstrate you’re compliant with local privacy regulations, which may mandate encryption, and compliant with data-localization regulations that demand you say, “Okay, this type of data or this type of workload can’t leave this national jurisdiction.”

Is that a fair way of thinking about it?

Aaron Fulkerson: That’s the simplest requirement, and it’s a good one to focus on.

The other thing we’re seeing in the rest of the world around sovereign goes back to what we already discussed — how do we reliably enforce policies on agents, not just data residency but every kind of policy. And another thing we’re seeing a lot is that many of these sovereign nations have their own frontier model labs, or they’re fine-tuning models with highly sensitive healthcare data, and they need to make sure that’s protected.

James Kaplan: So let me ask this question. You talked about what each participant in the ecosystem wants out of confidential AI. Where do you think things will shake out — in terms of what happens at the enterprise layer versus the application-vendor layer versus the cloud layer versus the frontier-lab / model-provider layer? How will those different pieces of the ecosystem interact with each other, and what functionality will they provide around confidential AI?

Aaron Fulkerson: Over the next two years, everybody will begin to offer this. We’re already seeing it. We saw it last year with Google’s offering — mutually attested components, or confidential Gemini. Everybody’s going to be offering endpoints to their language models and their applications.

That way, you can do mutual attestation and roll up verifiable guarantees. In fact, we’re working with a consortium of silicon, cloud, and frontier-model-lab partners to create an open standard that lets you create rules — not just on a single host, but portable rules that you can pass between hosts and that govern the policies of a particular workload. If you’re going to send your data, you can send it with, “Hey, here’s the specific set of rules I require enforced,” or it fails — and if it fails, I can prove that you couldn’t even access my data.

A lot of these standards already exist, but they’re very fragmented. To your point, you see frontier model labs enforcing their own flavors of confidential — Anthropic, a customer of Opaque, uses mutually-attested TLS, right? That’s a slice of policies being enforced. Microsoft does something different — their own flavor. TikTok, Meta, Google, ServiceNow — everybody’s got their own emerging patchwork quilt of cryptographic, hardware-enforced policies, but they’re not portable and they’re not standardized. What we’re going to see — and I think there’ll be an announcement at the Confidential Computing Summit this year on June 23rd and 24th in San Francisco — is that we’ll take all of these standards from the Linux Foundation and IETF, like SPIFFE, EATS, RATS, and say, “Here’s one standard that’s a superset, that you can enforce at your organization, and that will be portable as long as you write against this specific open specification.”

James Kaplan: Terrific. Anything we didn’t speak about? I’m sure there’s a zillion things. Thank you for joining us.

Aaron Fulkerson: Hey, thanks for having me, James. Look forward to seeing you.

CITER evolved and expanded over the years. After COVID, it re-emerged as the Cloud Leadership Forum (CLF), which was bigger and more ambitious. A couple of years ago CLF became the Technology Leadership Forum (TLF) as cloud became less of a distinct issue and more an organic part of the way you run enterprise technology.

TLF makes for two of my favorite days of the year. An opportunity to spend time with 50 of the most thoughtful enterprise technology executives I can find and discuss issues like AI platforms, AI security, product operating models, technology innovation and semantic layers/knowledge graphs. As you would expect, in recent sessions everyone there has wrestled with how AI can and should change enterprise technology.

Here are a few of my idiosyncratic takeaways from the day:

1. You can use AI to trade bad inefficiency for good inefficiency.

2. Mythos is cause for determination, not panic.

3. Transforming a business domain with AI requires hard problems and a number.

4. AI will disrupt, not destroy B2B software.

5. Token economics might not mirror ride-sharing economics.

6. Tech economics must focus on incentives, not precision.

1. You can use AI to trade bad inefficiency for good inefficiency

For decades, institutions removed craftsmanship, personalization and tactile experiences because the coordination costs were too high. AI may allow us to recapture warmth and texture — not despite efficiency gains, but because of them.

For each TLF session, we assemble a directory with the name, photo, role and contact information for every participant and faculty member. Historically, this was painful. Participant changes, updated photos and corrections to biographies required us to send a request to the visual aids team and wait 24 hours for them to update the document manually with design software.

A few years ago, we saved time by eliminating the printed version altogether. We just emailed participants a PDF. Operationally, it was more efficient. Even if people missed the physical book.

Agent Serena transformed our tradeoffs. She stored TLF information in a graph of Markdown files and allowed us to turn the event program into a composable document, assembled via a skill. We needed to update a photo or add a new participant? Just two instructions: one to update the information and a second to regenerate the PDF.

We used the time we recovered from pre-press production to print old-fashioned spiral-bound books containing the program, faculty information and breakout materials. They looked great. Participants loved them.

Where else can we use AI to fund the return of things lost to the imperative of rationalization?

2. Mythos is cause for determination, not panic

At the second CLF session in 2021 we held a cloud security breakout and nobody cared. It drew fewer participants than any other breakout. This year my colleagues Sven Blumberg and Rich Isenberg led a plenary session on what advancing frontier models mean for technology risk, and I had to drag them off the stage. The crowd would have kept discussing this issue for another couple of hours if I had let them.

Clearly the threat is real, and not only about zero days. Advanced models will provide attackers with unprecedented visibility into corporate technology environments — security by obscurity may not be a good strategy now, and it will be even less tenable shortly. For years the attackers with the most advanced capabilities didn’t have the destructive intent. And the attackers with the most destructive intent lacked access to the most destructive capabilities. New models can perform more complicated processes and allow a much broader range of attackers to employ new vectors.

US-based frontier labs may succeed in creating guardrails that limit malicious use of their products. None of those will apply to locally hosted, open weight models with capabilities that trail offerings from Anthropic, OpenAI and Google by months rather than years.

And TLF members are concerned. None of them believed that their company’s cybersecurity program was keeping pace with AI-enabled cybersecurity threats. Their boards were asking questions about how fast to move and where to start that they didn’t entirely know how to answer. And they had doubts about many of their software vendors. Patch velocity had increased, but not patch quality. They fear many vendor patches will create new vulnerabilities as they try to remediate older ones. One member said: “I don’t think vendors understand what they’re building.”

And yet I heard determination rather than panic or resignation. Some of this may be years of lived experience. Nearly fifteen years ago the US Secretary of Defense warned of a cyber Pearl Harbor. It hasn’t happened. Each year brings new challenges, but enterprise technology as a domain manages to stave off the cataclysm. At least for another few months.

TLF members indicated that they would push for transparency into their environments. They could isolate systems they couldn’t patch on dedicated network segments. They would automate their patching processes. And over time they might use AI-enabled software engineering to remediate technical debt — and build better software in place of the fragile environments they have now. All of which will require determination, funding and the ability to think in systems. One member said: “The leadership team thinks about innovation over here and risk over there — we haven’t figured out how to discuss this in an integrated way and make tradeoffs.”

3. Transforming a business domain with AI requires hard problems and a number

Almost no TLF members said their companies had deployed AI at scale. Most didn’t have any agents in production. Two sessions explored how to build organizational conviction behind and momentum in using AI to reshape business domains.

The session on building agentic workers wrestled with the shape and priorities for a transformation. Everyone agreed that you need a T-shaped transformation, one in which you pursue visible change early in some areas to create enthusiasm in the executive team — and at the same time build out the underlying technology platform to facilitate scaling and contain the technical debt you create.

Which led to a more contentious debate: if you create agentic workers, which workers should you start with? Yes, you need supportive business leaders, but you also need to pick hard problems. If you focus on easy wins in defining your digital workers, you give ammunition to those who describe AI as a toy rather than a tool.

My colleagues Brian Elliot and Mark Gu led a session based on their experiences deploying an AI operating system to drive business change. You need a platform that goes far beyond agent management to data pipelines, knowledge orchestration (often via a graph) and connection to traditional machine learning modules.

Starting with two or three related, difficult business problems allows you to justify the platform investment — but also implies organizational disruption. You will redesign roles for human employees, require new forms of collaboration and upend long-standing assumptions. Legal will resist using LLMs to process any employee data. Security teams may not yet be comfortable with agentic identities. HR is paying high salaries for AI experts who may not manage large teams. These fights are happening now.

You overcome resistance with a number: customer retention, operating margin, inventory turns — some metric with a direct enough relationship to share price that senior executives will say to those who push back on change, “I hear what you are saying, but I want my thing. So figure out a way to make it work.”

4. AI will disrupt, not destroy B2B software

We had a new type of plenary session at TLF last week — a panel of venture capitalists. Ed Sim from Boldstart, Daniel Frankenstein from Joule Ventures and Will Summerlin from Autopilot engaged with the group on how enterprises can best work with VC-funded companies and how AI will change B2B software markets.

Wow, there is some frustration out there! What do TLF members see from their incumbent software vendors? Slower innovation, degraded quality and more aggressive negotiation. They think some providers see their products as “falling knives” and have resolved to extract as much cash as they can from the portfolio before it declines into irrelevance. Others simply don’t get AI — they want extortionate rates for unimpressive capabilities that only reinforce silos between different parts of the environment.

Will enterprise software get eaten away from above and below? Will the layer between what companies build themselves and what frontier labs provide disappear as companies use AI-enabled engineering productivity to escape SaaS’s “one size fits none” business model and LLM-providers move up the stack?

History and market structure suggest not. Remember all the predictions about a decade ago that the cloud service providers would eat the entire enterprise software market? That (checks notes) didn’t happen. Enterprise software is an archipelago of hundreds of micro-niches, each with their own needs and idiosyncrasies. Many domains have astronomical switching costs. And companies resist letting one vendor dominate their technology future. AI changes none of that.

In some cases TLF members will make different buy-build decisions, but they have barely begun to uplift their own software engineering capabilities — and they want the specialized content or capability that third-party software can provide. They may want to build more, but they don’t want to build everything themselves.

The VCs on our panel have no illusions about the difficulty in building a disruptive company. They all expressed skepticism about the heady numbers some infant AI companies are reporting, observing that much of it might be trial rather than enduring revenue. Ed also pointed out that some startups are just white-labeling tokens from LLM-providers and would struggle if token economics became more challenging.

Still, they all believe that they face a generational opportunity to build companies that will use AI to displace incumbent software companies that are not meeting the moment. Ed talked about that here in his blog. I don’t think the CIOs and CTOs in TLF disagree with them.

5. Token economics might not mirror ride-sharing economics

Today most TLF members have little idea what they spend on inferencing. Their companies haven’t hit the steep part of the adoption curve yet. Low volumes mean low costs. Could that change? And what should they do if it does?

Infrapartners CTO Harqs Singh sees no slowdown in data center investment. He gets calls asking if they could launch a 100MW project Monday based on a PO sent over the weekend. Harqs turns constructing a 100MW facility into an industrial process, putting capacity in the ground more quickly and at less cost.

But that doesn’t remove other constraints in the system. You still need GPUs or TPUs to put in the data center, and you need electricity to run the chips. These capacity constraints — and the need for investors to generate a return on capital — cause many TLF members to ask whether we are in the early days of ride-sharing.

Several TLF members compared today’s token prices to the early days of ride-sharing. As Uber sought to grab market share, riders paid roughly 41% of the actual cost of each trip; the rest came from investors. Then fares rose 92% between 2018 and 2021. And some jurisdictions have levied additional fees or taxes on each ride.

The ride-sharing analogy isn’t perfect. Ride-sharing promised convenience, rather than massive corporate productivity improvements. American companies and public institutions spend USD 16 trillion in employee compensation. Frontier labs bet that any possible token costs will pale next to efficiencies there. Inferencing costs are probably declining by 90 percent per year. Ride-sharing investors lost a bet that autonomous vehicles would transform their cost structure by now. Ride-sharing also doesn’t have much in terms of attractive adjacencies. Frontier labs believe they can profitably move up the stack into applications and services — some railroads generated more returns dealing in real estate near their stations than from selling tickets.

Even so, you must plan for a world of escalating inferencing costs. As Ed Sim pointed out, “Compute is already fully utilized and Anthropic may ration with a high minimum spend. Token prices are going through the roof — you need to plan for scarcity.”

In response, TLF members expect their companies will develop more insight into inferencing economics so they can focus on accretive use cases, apply FinOps to AI so their applications will use tokens more efficiently and diversify their usage — by running open weight models on neo-cloud infrastructure, for example.

6. Tech economics must focus on incentives, not precision

I have been fascinated for decades by enterprise technology economics. What an interesting and complicated machine! Requests and money go in one side. They interact with policies, existing technology environments, operational processes, organizational capabilities and vendor arrangements. Systems and services come out the other side. How can we better understand the dials you turn to change the relationship between inputs and outputs?

I asked teams to create several generations of spreadsheet models over the years — all eventually collapsed under their own weight. Cursor and Claude Code helped me build the model that describes enterprise technology the way it is — an intricate, dynamic system, with dozens of economic and operational dependencies between nodes in the graph. Here’s what it looks like:

The model demonstrates several important ideas:

• Each company faces a pipeline of business-technology investment opportunities that you can stack rank based on ROI — and the ROI declines according to a half-life

• Incremental EBITDA lift each year depends on business-driven investment, adjusted for value leakage, engineering deadweight loss and adoption loss. Because these factors are multiplicative, collectively they can consume three-quarters of business investment.

• Each million dollars of business-technology investment generates USD 150,000-250,000 in incremental annual run and mandatory investment costs, whether you get business value or not.

• Given flat expenditures, companies will tend toward an “IT doom loop,” where run costs and mandatory investments consume the entire budget, driving EBITDA lift to zero.

• AI-enabled engineering (or spec-driven development) changes enterprise technology economics. It improves the ROI of retiring technical debt (reducing application maintenance costs) and run automation (reducing infrastructure costs), freeing up more resources to invest in initiatives that improve revenue or reduce operational cost. It also reduces engineering deadweight loss, so you get more EBITDA lift out of each dollar invested. That’s why investments in AI-enabled software engineering will deliver better-than-linear returns for many companies.

This resonated with many participants. They agreed both with the underlying economic dynamics and the need for management teams to understand them better in making investment decisions. The catch? The tendency for accounting to crowd out economic insight. Many bore scars from battles over tech chargebacks, and worried that any calculation of a unit cost would set off endless debates about whether a server image should cost USD 3,100 or USD 3,200.

As always, leadership will be key here. Members of the management team must make clear that they want transparency into technology cost and value to make better decisions, not to push allocations from one line of business to the other.

It was a great session — I look forward to the one in the Fall in NYC!

1. The classical skills of grammar, logic and rhetoric are essential to advocating for good business decisions in complex organizations.

2. Making shoddy arguments is easy in the face of time pressure and incomplete information.

3. Using AI to evaluate my own writing demonstrates how it can identify vulnerabilities in an argument.

4. A simple prompt enables you to apply this to your own work -- but you should treat the output as a guide, not a mandate.

1. Reviving the Trivium

In 1947, British writer Dorothy Sayers urged educators to embrace the principles of classical education, in the face of a culture of specialization.

Sayers worried that educators had failed to teach students how to learn, think and communicate. She wrote:

Is it not the great defect of our education to-day (—a defect traceable through all the disquieting symptoms of trouble that I have mentioned—) that although we often succeed in teaching our pupils “subjects,” we fail lamentably on the whole in teaching them how to think? They learn everything, except the art of learning.

Sayers offered the trivium as a solution. Roman thinker Martianus Capella divided the liberal arts into the Trivium (grammar, logic and rhetoric) and Quadrivium (arithmetic, geometry, astronomy and music).

The whole of the Trivium was in fact intended to teach the pupil the proper use of the tools of learning, before he began to apply them to “subjects” at all.

The Trivium applies in a special way to enterprise technologists. Engineers have always needed to make thorny design decisions and write technical specifications. The advent of spec-driven development will only make the Trivium more important to them. As Steve Jobs said, “It’s in Apple’s DNA that technology alone is not enough—it’s technology married with liberal arts, married with the humanities, that yields the results that make our hearts sing.”

Especially today -- no less than the students Sayers worried about -- enterprise technologists must be learners given the pace of change they face. The Trivium allows them to assimilate and evaluate new ideas more quickly.

Technologists must make -- in the face of incomplete information and massive ambiguity -- decisions they will have to live with for years. As my old professor Martha Nussbaum pointed out, critical thinking, argumentation, and narrative imagination are essential for making decisions in complex systems. [1]

No CIO or CTO is a sovereign. They need support and engagement from the rest of the management team to create a portfolio, define requirements, fund platforms and get value from systems investments. So they must make arguments. How many meetings have blown up because nobody asked, “What would the counter-argument be? Why would the client disagree?” How many initiatives have progressed because the business case anticipated the rebuttal the CFO might offer?

2. How robust is our thinking?

Can CIOs and CTOs make better arguments? In How AI Critiques an Argument, Steven Mintz [2] of the University of Texas, Austin suggests even trained professionals make shoddy arguments:

• Honest argument requires specifying not just the claim and evidence but the warrants, qualifications, and rebuttals — the conditions under which the claim would not hold

• Social incentives and norms (in education, in media) encourage speed, certainty, and strong positions over nuance and qualification -- we learn to overclaim, reducing causation to a single cause and crowding out alternatives with false dilemmas

• When challenged we learn to evade — changing the subject, moving the goalposts, retreating to vagueness.

Do the failure modes resonate here? Sometimes they do. Sometimes the imperative of just getting through the week or getting the document done leads to motivated reasoning, vagueness and over-simplification. [3]

One of my mentors used to counsel me “The direction of the hypothesis doesn’t matter here -- we’ll either prove or disprove it.” But how often does “Bottom Line Up Front” mean “start with the answer” rather than “start with a falsifiable proposition to validate or invalidate with facts.” All the time I see people locked into a position they don’t want to re-evaluate.

Mintz points out “And when challenged, arguers evade — changing the subject, moving the goalposts, retreating to vagueness.” How many of us have the fortitude to meet an objection head on? Or do we respond to clarifying questions with defensiveness and more vagueness?

I heard more than one CEO ask of the CIO “why does this have to be so complicated?” But you must use clear structure and clear writing to communicate nuance honestly. And not confuse the sometimes brutal reductionism required in decision making (i.e. go left or go right; launch the project or don’t) with all the nuance that goes into making that decision.

But Mintz also offers hope, in that AI can help us make better arguments -- as a complement to, not a replacement for, management judgment. We are all often time-constrained, stressed, distracted or exhausted -- AI is not any of those things.

• AI models the structural habits of careful argument more consistently than most humans educated to develop them: well-functioning AI follows a deliberative sequence before rendering judgment: reconstruct, calibrate, consider alternatives, steelman, treat the first response as provisional

• AI can provide immediate and specific correction of argumentative failures — showing exactly what a fair restatement looks like, where a causal claim outruns the evidence, which alternatives a false dilemma has collapsed

3. Applying Mintz’s advice to my writing

Mintz recommended three frameworks in his piece.

• Toulmin evaluates the structural anatomy of an argument — claim, evidence, warrant, backing, qualifier, and rebuttal

• Paul-Elder evaluates the intellectual quality of the thinking behind the argument — clarity, accuracy, precision, relevance, depth, breadth, logic, and fairness

• Walton identifies what type of argument is being made — analogy, causal, from authority, practical reasoning, from example — and then applies the critical questions specific to that type

I used an agent to evaluate Just like parents CIOs must be demon game theorists to elicit cooperation in terms of each framework plus Minto’s pyramid principle. Clearly I have work to do. None of the articles received more than seven points out of ten!

What do I need to do differently?

• Be explicit in naming the warrant that connects my evidence to my conclusion

• Engage directly with the strongest possible objections to my arguments, especially when using analogies

• Map prescriptions to diagnoses

• Explain why personal experiences are generally applicable

4. A prompt you can use

My writing has gotten better because I revise and revise based on feedback from agents and prompts. The prompt I used above even made this article better. As I used the prompt through about 10 iterations of the article my score improved from the mid-5s to 8.5. Here are some of the tweaks.

• I originally just asserted that better arguments win; with some encouragement from the prompt, I provided a few illustrations of how incomplete arguments can sabotage a meeting -- and rigorous ones can win the room. (Yes, I would have liked to be more specific -- but in some cases I must be discrete.)

• I also didn’t address an important potential objection to one of my key points. Some people believe CIOs win with good relationships rather than good arguments. I added a footnote explaining you need good relationships and good arguments (and the two reinforce each other).

Sometimes I addressed these issues in footnotes, in order to preserve narrative flow. If the CFO asks a killer question and you say, in response, let’s turn to page 25 in the appendix where we address that issue, that works great.

Try it on your next initiative request with this prompt.

But treat it as a guide, not a mandate. No prompt will capture all the context you have -- so sometimes the model will recommend justifying a proposition your audience will stipulate. Models can also be literal. Sometimes I should spell out my warrants, but sometimes letting the reader do a little work in connecting the dots creates investment in argument.

Footnotes

[1] Two notes here:

• In the spirit of transparency I took Nussbaum’s class “Philosophy and the Novel” with 200 other students. The lectures were terrific.

• Yes, in her book, Nussbaum talks about the humanities in the context of protecting democracy rather than improving corporations, but companies are themselves polities, with bylaws as constitutions and elections for boards of directors.

[2] Mintz is a professor of history at the University of Texas at Austin and a leading commentator on pedagogy and critical thinking. He writes the Higher Ed Gamma column at Inside Higher Ed and received the AAC&U’s President’s Award for Outstanding Contributions to Liberal Education in 2025.

[3] I know some have argued that relationships, not great problem solving and great arguments, win the day. Here’s why that doesn’t resonate for me.

• Great CIOs depend on great business relationships and great arguments -- and great arguments make for better business relationships.

• In a world where you’ll live with the impacts of today’s decisions for years, you want only the best arguments in the boardroom.

• Executive teams change. The business partner who doesn’t challenge you may take another job. His or her replacement might look at a business case and ask “What the bloody hell is this?”

Appendices

As noted above, I used AI to apply 4 argument frameworks to Just like parents CIOs must be demon game theorists to elicit cooperation. Here’s what it said:

• Thesis: CIOs/CTOs need cross–executive-suite cooperation to maximize multi-year EBITDA lift from enterprise technology, but coordination costs (information asymmetry, misaligned incentives, collective-action problems, weak “enforcement” inside the firm) make that cooperation scarce—so they have to think like game theorists, not optimists or petitioners.

• Analogy: Parents can sometimes establish escalation dominance (the piece’s restaurant / fireman’s-carry example); technology leaders usually cannot, so the workable substitute is to shape an information environment that raises the cost of non-cooperation rather than pretending good intent or a CEO edict will fix incentives.

• Mechanism: An EBITDA-lift model (value leakage, adoption loss, deadweight loss, run cost / T4T) to show where cooperation matters, despite symmetric frustrations between technology leaders and their peers. Only ~13% of senior technology executives report consistently getting the support and engagement needed to capture value—so the bottleneck is governance and politics.

• Prescription: Six tactics—develop a granular view of where cooperation drives lift; map political constraints coolly; force decisions with options and implications; make cooperation visible (including board-level transparency where appropriate); adopt “not my fault, but my problem”; and signal credibility (e.g., eating your own cooking on new ways of working)—as the practical translation of “demon game theorist,” not as a mandate to strong-arm peers.

Minto summary: The piece’s most important structural failure is at the BLUF level: “What you need to know” bundles two distinct key lines — the EBITDA cooperation need and the coordination cost diagnosis — into a single bullet, when they each deserve their own slot. A truly MECE BLUF would have three bullets: (1) CIOs need cross-executive cooperation to maximize EBITDA lift; (2) coordination costs explain why they rarely get it; (3) game theory provides a path — and the six tactics below show how. The current structure is close but the compression at the BLUF level obscures the argument’s logical spine.

This weeks Prosaic Times explains how you can use AI to evaluate your arguments against classic frameworks. Here’s a prompt you can use!

You are an expert in argumentation and logic, trained in multiple frameworks for evaluating the quality of reasoning. I am going to give you a piece of writing. Your job is to evaluate the quality of its argumentation using three frameworks, each of which illuminates a different dimension of the argument.

Before applying any framework, reconstruct the argument in its strongest possible form.
Be specific throughout: quote the text, identify exact failures, propose corrections. Vagueness and evasion are themselves argumentative failures — do not be diplomatic about them.

---

### STEP 1: RECONSTRUCT THE ARGUMENT

Identify the following before evaluating. Present as a brief structured summary.

1. **Main claim**: The central assertion the author wants the reader to accept.
2. **Supporting claims**: 2–5 sub-claims that support the main claim.
3. **Evidence**: For each supporting claim, the specific facts, data, or examples cited.
4. **Warrants**: The underlying assumptions connecting evidence to claims. (These are almost always implicit — surface them.)
5. **Qualifications**: The conditions under which the claim holds or is limited.
6. **Rebuttal**: The strongest counterargument the author acknowledges and responds to (if any).
7. **Argument type(s)**: What kind of argument is this primarily? (e.g., argument from analogy, from authority, causal argument, argument from precedent, argument from example — see Table 3.)

---

### TABLE 1: TOULMIN’S MODEL

*Stephen Toulmin, The Uses of Argument (1958). Most useful for finding what’s missing — especially warrants (almost always implicit) and rebuttals (almost always avoided).*

For each component, quote the relevant passage from the text (or note “implicit” / “absent”), assess its quality, score 1–5, and flag any problems.

| Component | Definition | What’s in the text | Quality assessment | Score (1–5) |
|---|---|---|---|---|
| **Claim** | The assertion being made — what the author wants the reader to accept | | Is it explicit? Falsifiable? Specific enough to act on? | |
| **Grounds** | The evidence or data offered in support of the claim | | Is it specific? Sufficient? Accurate? Or generic (“studies show…”)? | |
| **Warrant** | The assumption connecting the grounds to the claim — why the evidence should lead the reader to accept the claim | | Is it stated or implicit? Reasonable? Would a skeptical reader reject it? | |
| **Backing** | Support for the warrant itself — why the warrant should be trusted | | Is the warrant’s own foundation established, or simply assumed? | |
| **Qualifier** | The degree of certainty with which the claim is asserted (necessarily, probably, presumably, in most cases…) | | Does the qualifier match the strength of the evidence, or does the author overclaim? | |
| **Rebuttal** | The conditions under which the claim would not hold — and the author’s response to the strongest counterargument | | Does the author engage the best opposing argument, or a weakened version? Or avoid rebuttal entirely? | |

**Toulmin summary**: In 2–3 sentences, identify the single most important structural gap — the missing or weakest component — and explain what a stronger version would look like.

---

### TABLE 2: PAUL-ELDER CRITICAL THINKING STANDARDS

*Richard Paul and Linda Elder. Evaluates not just whether the argument holds together, but whether the thinking behind it is honest and fully developed — whether assumptions are examined, and whether the strongest counterarguments have been genuinely engaged.*

Score each standard 1–5. Quote specific evidence from the text. Identify the most important failure.

| Standard | Definition | Evidence from text | Score (1–5) | Key failure (if any) |
|---|---|---|---|---|
| **Clarity** | The argument can be understood without ambiguity. Key terms are defined. The reader does not have to guess what the author means. | | | |
| **Accuracy** | Claims are factually correct and properly attributed. The author has checked rather than assumed. | | | |
| **Precision** | Claims are specific enough to be useful — not “the process is inefficient” but “the process requires 17 approvals taking five days.” | | | |
| **Relevance** | Evidence and sub-claims bear directly on the main claim. No padding, tangents, or evidence that sounds related but does not actually support the point. | | | |
| **Depth** | The argument addresses the complexity of the problem rather than offering an oversimplified answer. Root causes are identified, not just symptoms. | | | |
| **Breadth** | The argument considers other perspectives and relevant viewpoints — not just the one most convenient to the author’s conclusion. | | | |
| **Logic** | The conclusions follow from the premises. Sub-claims support the main claim. There are no internal contradictions. | | | |
| **Fairness** | The author represents opposing views honestly, applies the same standards to all sides, and does not load the argument with assumptions that favor one conclusion. | | | |

**Paul-Elder summary**: Identify the two standards with the lowest scores. Explain the specific thinking failure each represents, and propose how the author could address it.

---

### TABLE 3: WALTON’S ARGUMENTATION SCHEMES

*Douglas Walton. Arguments come in different types, each with its own structure and its own characteristic weak points. The framework identifies which type of argument is being made, then applies the right critical questions.*

**Step A — Identify the scheme(s).** Which of the following argument types does this piece primarily use? (Check all that apply.)

| Scheme | Description | Present in text? |
|---|---|---|
| **Argument from example** | A general claim is supported by one or more specific cases | |
| **Argument from analogy** | A claim about X is supported by showing X resembles Y, where the claim already holds for Y | |
| **Causal argument** | X causes Y; therefore doing/preventing X will produce/prevent Y | |
| **Argument from authority** | A claim is supported by citing an expert, institution, or credentialed source | |
| **Argument from consequence** | We should/should not do X because of the good/bad outcomes it will produce | |
| **Argument from precedent** | X was done (or decided) before in a similar situation; therefore X is appropriate here | |
| **Argument from sign** | Observable evidence Y is treated as a reliable indicator that X is the case | |
| **Practical reasoning** | We have goal G; action A will achieve G; therefore we should do A | |
| **Argument from commitment** | The author (or opponent) has previously committed to a position that implies the current claim | |

**Step B — Apply the critical questions.** For each scheme identified in Step A, answer the scheme’s characteristic critical questions. Quote the text in each answer.

*Argument from example:*
- Are the examples representative, or cherry-picked?
- How many examples would be needed to support the generalization being made?
- Are there counterexamples the author has not addressed?

*Argument from analogy:*
- In what relevant respects are X and Y actually similar?
- In what relevant respects do they differ — and do those differences undermine the analogy?
- Is the analogy being used to illuminate or to substitute for argument?

*Causal argument:*
- Is the causal claim established, or merely asserted?
- Could the correlation be explained by a third factor?
- Has the author ruled out reverse causation?

*Argument from authority:*
- Is the cited authority genuinely expert in the relevant domain?
- Is there expert disagreement the author has not acknowledged?
- Is the authority being cited to support evidence, or to replace it?

*Argument from consequence:*
- Are the predicted consequences realistic and well-supported?
- Have alternative means to the same end been considered?
- Does the argument accurately weigh costs against benefits?

*Argument from precedent:*
- Is the precedent case genuinely analogous?
- Are there relevant differences between the precedent and the current case?
- Does the precedent actually establish the norm the author claims?

*Practical reasoning:*
- Is the goal clearly stated and agreed upon?
- Does the proposed action actually achieve the goal?
- Are there alternative actions that would achieve the goal more effectively or at lower cost?

**Walton summary**: Name the dominant scheme. Identify the one critical question it most urgently fails to answer. Explain what a satisfactory answer would require.

---

### OVERALL ASSESSMENT

1. **Argument score** (1–10): One number for the overall quality of the argumentation.
2. **Framework that reveals most**: Which of the three tables exposed the most important weakness?
3. **Strongest element**: The most compelling part of the argument — quote and explain.
4. **Weakest element**: The single most important argumentative failure — quote, explain, and propose a revised version.

---

### TABLE 4: MINTO PYRAMID PRINCIPLE

*Barbara Minto, The Pyramid Principle. Most useful for finding whether the conclusion is stated first, whether the support is genuinely MECE, and whether vertical and horizontal logic hold at every level.*

Before scoring, map the actual structure:

Governing Thought: [as stated or inferred — one complete sentence]
  ├── Key Line 1: [label]
  │     ├── [supporting point]
  │     └── [supporting point]
  ├── Key Line 2: [label]
  │     └── [supporting point]
  └── Key Line 3: [label]
        ├── [supporting point]
        └── [supporting point]

If the piece does not have a discernible pyramid, show the flat structure it does have and label the problem: stream of consciousness, inverted pyramid, buried lede, flat list, or other.

For each criterion, quote the relevant passage from the text (or note “absent”), assess its quality, and score 1–10.

| Criterion | Score (1–10) | Assessment |
|---|---|---|
| **Governing Thought** — One clear, complete sentence capturing the full conclusion. Stated explicitly and early. A topic or title is not a governing thought. | | Is it explicit? Complete? Does it state a conclusion or just name a subject? Quote it or flag its absence. |
| **Answer First** — The piece leads with the conclusion, not builds to it. BLUF applied. | | Where does the answer appear — paragraph 1, middle, last? Quote where the answer lands and assess the cost of any delay. |
| **Pyramid Structure** — Argument organized as a true pyramid: finite groups, explicit hierarchy, not a flat list or stream of consciousness. | | Can the hierarchy be diagrammed? Are groups clearly delimited? Quote the opening structure and assess whether it signals a pyramid or a list. |
| **MECE** — Supporting points are non-overlapping (mutually exclusive) and together cover all the ground the claim requires (collectively exhaustive). | | Do any two key lines make the same point? Can a key line be added without making the others redundant? Quote the key lines and identify the failure. |
| **Logical Integrity** — Vertical: each point answers “why?” from the level above. Horizontal: points within each group follow a single ordering principle. | | Does “why?” work top-to-bottom? Do points within each group follow a consistent ordering principle? Quote a specific failure if one exists. |

**Minto summary:** In 2–3 sentences, identify the single most important structural failure — the missing or weakest criterion — and explain what a stronger version would look like for this specific piece.

Then show what the pyramid should look like — same content, restructured:

Governing Thought: [revised one-sentence conclusion]
  ├── Key Line 1: [label]
  │     ├── [supporting point]
  │     └── [supporting point]
  ├── Key Line 2: [label]
  │     └── [supporting point]
  └── Key Line 3: [label]
        ├── [supporting point]
        └── [supporting point]

Assess the introduction against SCQA:

| Element | Present? | Where? | Assessment |
|---------|----------|--------|------------|
| Situation | Yes / No / Implied | Para X | |
| Complication | Yes / No / Implied | Para X | |
| Question | Yes / No / Implied | Para X | |
| Answer | Yes / No / Implied | Para X | |

---

### THE TEXT TO EVALUATE:

[PASTE TEXT HERE]

A more honest answer involves Professor Litchfield’s class on The Industrial Revolution in Early Modern England.

Using spinning jennies and mechanical looms in factories to make textiles changed everything in England. It moved people from the countryside to the city. It allowed ordinary Englishmen to own a second suit of clothes. It demolished artisans’ livelihoods. It empowered a rising class of bourgeoisie, and undermined the aristocracy. It created the surplus that underwrote an empire. Software applications and computer hardware were the spinning jennies and mechanical looms of my own era. All especially relevant as we debate the social, political and economic implications of AI.

Professor Litchfield liked to say that “Political Science has the theories. In the History Department we are custodians of the facts.” I like to know what happened; only facts can tell you that. But the facts of history are imperfect. Much of the work in formulating a business or technology strategy depends on work that feels like history — trying to make sense of incomplete, contradictory, subjective, and sometimes unreliable information.

Bob Pasker co-founded WebLogic, where he led development of the first independent J2EE application server. BEA later bought WebLogic and Oracle bought BEA. [1] Now he’s pursuing a PhD in history at the CUNY Graduate Center. To support his research, he developed a machine-learning tool he calls Roscoe to discern new insights in American legal history.

Today’s interview excites me for two reasons. It’s always good to spend time with a kindred spirit passionate about both history and technology. More importantly, using AI to discover more facts intrigues me no end. In an academic environment it allows us to understand ourselves and our world better. In a corporate environment it allows us to make better decisions and pursue better strategies.

Here’s the takeaways:

1. Wall Street, early internet experimentation, WebLogic and J2EE, post-acquisition chapters, then a PhD in history — technology innovation and academic aspirations can reinforce each other!

2. Enterprise stacks still echo mainframe-era problems, but the internet forced looser transaction models, distributed-systems humility, and resilience design given shared infrastructure and unreliable networks.

3. Mass digitization of historical documents means you can ask new questions at scale, but you have to cut through the “silence of abundance.”

4. Roscoe is semantic retrieval across collections — embeddings, ETL, metadata, re-ranking — aimed at evidence that keyword search will not find.

5. The hard problems ahead are precision, recall and cultural acceptance, richer analysis of hits, multimodal corpora, and partnerships with archives. Yes, the interpretive payoff is substantive, but attachment to existing methods bedevils the academy no less than the enterprise.

1. From Wall Street and the VAX to WebLogic — and back to graduate school

Bob traces Wall Street transaction systems, the Java and Usenet milieu, co-founding WebLogic and shipping the first J2EE implementation, later ventures and CTO-for-hire work, and his return to history for a PhD at CUNY.

James Kaplan: James Kaplan here with the Prosaic Times podcast. I’m very pleased to have Bob Pasker with us. He played an important role in the development of modern software over the past couple of decades, and he’s now doing exciting work as a history PhD candidate. Bob, give us a little bit of your background as a tech leader and entrepreneur, and what drove you to pursue a PhD in history.

Bob Pasker: That’s correct. Thank you very much for having me on, James.

I started way back on Wall Street, building transaction processing systems on the good old VAX, if you remember that. I got interested in moving to San Francisco because I wanted to be part of the tech community in Silicon Valley. I moved to San Francisco and started working for one of the database companies back then. It wasn’t a great company and I didn’t stay very long, so after about ten years in the computer industry I decided to go back to college.

I went back as a history student, got an undergraduate degree, and decided I was going to be a college professor. I went out to graduate school as a history student. Graduate school didn’t really agree with me at the time, so I came back to San Francisco just about when Java was coming on the scene.

I decided to do some experimentation. I built an SNMP stack in Java and was able to browse public servers on the internet completely undetected, because nobody had Cloudflare or anything like that at the time. I was active on Usenet, if you remember that — before Friendster and MySpace. It’s how people communicated with each other over the internet. I met other people who were interested in enterprise Java, and together we co-founded a company called WebLogic.

Our first products were JDBC drivers for accessing Sybase and Oracle. My interest, though, was building a transaction processing system in Java. I spent eighteen months building the WebLogic application server, which is what it became known as. That kind of launched the whole enterprise Java thing. Sun adopted our model, if you will, of having all these different services available, and they called it J2EE — and we had the only working implementation out of the gate.

The WebLogic company was acquired by BEA in 1998, and BEA was acquired by Oracle in 2008. That’s how it became part of Oracle’s technology stack. After that I started another company to do what we called the real-time internet. This was around 2000. The idea was server push instead of request-response, which is something we now take for granted. It was fairly early technology, and we didn’t make much progress because we got caught up in the dot-com bubble.

Over the next ten years I spent time at various venture firms, including Accel Partners, and I was kind of a CTO / chief architect for hire at VC- and PE-backed companies. I also spent a year at Expedia rebuilding their enterprise architecture.

Getting into the COVID years, as my kids started to get older I had more free time, and I decided to go back for my PhD in history. That’s how I wound up at the CUNY Graduate Center as a PhD student in American history.

James Kaplan: As someone who’s passionate about both history and technology, I applaud your varied career.

Bob Pasker: Thank you. I’ve gotten to do a lot of different things. Sometimes I feel like I’ve had five or eight different careers instead of just one.

James Kaplan: It’s a hell of a lot easier to understand the monumental changes happening now if one has a bit of historical sensibility and a historical mindset.

Bob Pasker: For sure.

2. Enterprise architecture: what changed, what didn’t, and why resilience still wins

VAX-era patterns persist, but networks are more decoupled; ACID loosens over the public internet, fallacies of distributed computing still apply, and major outages remind us nobody is immune.

James Kaplan: Before we dive into some of the research you’re doing now, any reflections on the evolution of enterprise architectures over the past twenty years? Obviously the app server was a tremendous advance. We’ve moved on to containers and so forth — but any reflections on that arc?

Bob Pasker: I think the biggest thing is that the more things change, the more they stay the same. A lot of what we were doing back on the VAX a long time ago still gets done today in enterprise systems. But I think the biggest change has been that networks and computer systems are designed much more robustly and to be much more decoupled.

We always thought about ACID transactions and the problem of doing ACID-style transactions over long distances. It was very easy to do inside the data center, but banks and other companies required that either both sides of the transaction completed or neither did.

Now we have much more flexible ideas about how that happens, and a lot of it has to happen over the internet, with the unreliability that implies. So we’ve really taken a new look at ACID transaction ideas and relaxed them enough to make it all work over the internet.

James Kaplan: I’m old enough to remember when many people didn’t believe servers could be physically remote from one another — a combination of the fragility of the application architecture and the fragility of the network. If the servers weren’t in the same facility, they didn’t have confidence in the ability to transact in a robust way.

Bob Pasker: Absolutely. I used to send people the list of the fallacies of distributed computing. One of them is that the network is reliable — and it’s not. Another is that they’re all managed by the same person — and they’re not. Whoever wrote that list was very prescient about what we needed to do to build reliable systems on the internet.

James Kaplan: You’re making an important point that belongs under “the more things change, the more they stay the same”: it’s critical to design for resiliency. You can’t assume any given component will be perfect, so you have to design a system that’s robust in the face of degradation.

Bob Pasker: Absolutely — that’s basically where we are today. We still see it every day: status.x.com and all the other status pages keeping track of what’s working or not on the internet, and we’ve taken that to heart. The biggest catastrophes are when major pieces of infrastructure go down. We’ve seen it with Cloudflare and Amazon and all sorts of companies — nobody is immune.

James Kaplan: I remember spending a lot of time on geo-resilient architectures starting around 2010 — application and system architectures that would be resilient in the face of network failure or infrastructure downtime. Let’s pivot to the research you’re doing now.

Bob Pasker: Sure.

3. Legal history, massive digitized corpora, and the dissertation problem Roscoe was built to solve

Early spreadsheet-era legal history meets an eight-million-case digitized corpus — motivating Roscoe and a dissertation on nineteenth-century courts mediating ideals of liberty against laws of slavery, suffrage, and Native policy at scale.

James Kaplan: I asked you to join because I’m fascinated by digital humanities and the extent to which we can use AI and other digital techniques to enhance historical understanding. Could you tell us a little about the historical research you’re pursuing now and what got you interested in that topic?

Bob Pasker: When I was an undergraduate and in my first attempt as a graduate student, I became interested in legal history. For me it’s a unique field. At the time there were many untapped sources of legal documents that historians had never or rarely used. Personally, law had been a longstanding interest of mine, and I like to do things that are a little off the beaten path — that’s what I wound up doing.

I wrote papers on legal history: kinship and the way people left money to their children in the eighteenth century, based on published wills; and a paper on sex crimes in Providence, Rhode Island, in the late eighteenth and early nineteenth centuries. This was all done with word processors and spreadsheets — so I was doing digital history even then, taking the documents I was reviewing, putting them into spreadsheets, tabulating, and so on.

Fast-forward to 2023: Harvard Law Library has transcribed the entire corpus of American appellate case law — about eight million cases — and digitized them, so you can download text files of all of those cases. I decided to combine my two fields, history and computers, build a conceptual search engine for that case law, and use that search engine for my dissertation research.

The system is called Roscoe. It’s named after the first legal historian, Roscoe Pound, who lived from 1870 to 1964 — he really started the field. My dissertation is a study of how, in the nineteenth century, American courts became the venue for working out conflicts between our constitutional ideals of freedom and liberty and the actual law that permitted slavery, denied women’s suffrage, and affected Native Americans.

A lot of historians have studied these topics; they’ve only used case law as evidence. Nobody has used case law to study the court system as an institution itself — on par with the other branches of government, religious institutions, and industries. The reason nobody could do that is scale: there are 226,000 cases up through 1860, and that’s the basis of my dissertation research.

4. How Roscoe works — embeddings, collections, ingestion — and how historians react

Semantic search over multiple public-domain collections via embeddings, vector indexes, relational metadata, and re-ranking — plus the human story of academic uptake, the ninety-three-case find, and “silences” created by bad retrieval, not missing archives.

James Kaplan: Tell us a bit about Roscoe. How does it work? Take us under the hood a little.

Bob Pasker: Roscoe is a semantic search engine. The idea is to replace arcane keyword and Boolean searches, which is how most archives still work. If you want to find case law on a particular topic, you have to know the exact words they used back in the nineteenth century — and the words they used in Georgia versus New Hampshire.

If you’re interested in a concept like canal building, you’d have to look up locks, canals, waterways, and so on to surface all the relevant documents. With Roscoe, you type something like “disputes over canals,” and it surfaces documents related to that concept.

The fundamental technology is embeddings and a vector database. An embedding takes a piece of text and turns it into a high-dimensional vector. That vector can be stored in a vector database; you embed the query, look it up in the database, find the k nearest neighbors, use those neighbors to look up the specific cases in Roscoe, and hopefully those cases are conceptually similar to your query.

I’ve organized Roscoe by collections — each collection has its own vector database. The first collection was those 226,000 cases. I’ve extended it to another collection called Chronicling America, which is millions of nineteenth-century newspaper articles. I have another collection with the papers of the founders, and also the Congressional Record. These are all public domain, and each collection is available inside Roscoe.

What makes Roscoe different is that you’re not searching one database at a time with arcane keywords — you’re searching across all of them at the same time. The key is the ingestion process: an ETL layer — extract, transform, load — that takes data as it comes from the archive, tests different chunking algorithms and embedding strategies, creates an index in a vector database, and cross-references that with a relational database that holds document metadata — names, dates, location — used for filtering and re-ranking. That’s basically how it works underneath.

Version one had a very simple user interface that produced a result table with metadata. Version two has multiple collections, searches across collections, and does unified re-ranking: it takes results from the different collections and re-ranks them against each other so the most relevant results rise to the top, regardless of which collection they came from. That’s basically how version two of Roscoe works right now.

James Kaplan: What’s been the reaction from people you interact with in academic history? I ask because some academics I know are incredibly excited about what AI can do for research, and others push back — anything involving quantification, or “that’s a science way of thinking, not a humanities way.” What’s the balance of enthusiasm versus skepticism?

Bob Pasker: It’s similar to the experience I had trying to get people to use WebLogic. There’s a whole lot of people who couldn’t care less, and a very few who are really interested and see the value. So there’s a huge evangelization process — different from a startup, but still a big thing.

I’ve had professors who, when I’m writing a paper using Roscoe, say: I don’t want anything in the paper about technology — I just want a history paper. I’ve had others who are extremely helpful and excited — but to be honest they don’t really understand it. They can conceptualize the benefit, but until it becomes a public utility they can try out, with enough collections for their own work, it’s mostly curiosity rather than adoption.

Right now I’m trying to write some papers using Roscoe. I’m working on a paper about how to explain Roscoe to the community of historians, which turns out to be fairly difficult — but I’m making progress, and I hope to publish it as an independent research paper. It’s not meant to be pure evangelism; it’s meant to ground Roscoe in historiography, the process of doing history, and archival science — what it means for both disciplines.

James Kaplan: It strikes me as historiographically important. A professor described to us how certain historians were paging through records to find birth and death dates to understand lifespans in early nineteenth-century England and how the industrial revolution changed mortality — whether it increased or decreased mortality in different places. Your approach is a way to vastly increase the datasets available to historians without sending grad students to page through bound volumes by hand.

Bob Pasker: Yes — and in a sense that’s a slightly different kind of digital history: it’s tabular. There’s been a lot of work since the late fifties on tabular analysis of data, the way an economist might do. I’ve been interested in that too; I did it in those earlier papers.

Roscoe is very different. It’s for finding documents that already exist in archives but are impossible to find. My paper last year was on whether Black people could testify in courts before the Civil War in the nineteenth century. The laws were basically against it, and we don’t have much conception that it was still a possibility. Using Roscoe I found ninety-three cases out of 226,000 — about four in ten thousand — in the appellate court records that would otherwise have been impossible to find. They span from the 1790s to the 1860s across eleven different territories and states. There was no keyword search in the world that was going to find those ninety-three.

Archivists have this idea of archival silences: what archivists admit into their archives. For the most part archives contain documents they consider important and leave out what they thought marginal or uninteresting — they have to curate; we can’t save everything.

I have a different kind of silence in mind: documents that are in existing archives, useful to historians’ research, but that they can’t find because they can’t come up with the right keyword search in the user interface. My paper argues that Roscoe makes it possible to find those — that there are interesting documents that have been, in a sense, silenced by arcane interfaces. That’s what I’m trying to create: a system that surfaces many more interesting documents than a historian would otherwise find.

5. What’s next: precision and recall, multimodal search, partnerships — then evidence, interpretation

Roadmap: recall versus precision, deeper per-hit explanation, map-level multimodal search — then partnerships and “index not copy” for archives, historiography of evidence, reading the ninety-three cases, and why he prefers “machine learning” to “AI.”

James Kaplan: To push one level further — and this is a little about where Roscoe might go — ninety-three cases you could read yourself, but you can imagine a search that surfaces a thousand or fifteen hundred cases. To what extent do you think the state of the art will advance so you can use analysis to identify trends in legal thinking? Could some of these documents go into a graph so you can see how legal thinking in one set of cases influenced another? What comes next after archival search? Does that make sense?

Bob Pasker: Yeah, it does.

Version three of Roscoe, which I’m already working on, will address some of this. First, on returning too many results — that’s well known in information science: recall versus precision. You want enough cases in your result set that you see everything useful, but you don’t want false positives — things returned that aren’t useful. Search engines have dealt with that for a long time. You also want precision: the cases most relevant to you should rise to the top, and the useless ones should drop out. You don’t want to leave useful cases outside the result set, and you don’t want useless cases inside it. I work on that constantly: refining the system for better precision and recall.

Second, I want deeper analysis of how each case relates to the query. In version one, as results returned, the system re-ranked them and analyzed cases more deeply to identify exactly how each case related to the query. Once you have a large result set, you can go through it more deeply with machine learning to pull out the cases specific to what you’re looking for and leave out the rest.

Another direction I’ve experimented with is visual search — my experiments have been with maps. Old maps are crude line drawings with handwritten type. In the archive you get: “Here’s the Smith map of New York City from 1823” — and that’s all; it doesn’t tell you what’s on the map until you open it. I’ve used machine learning to read the maps, identify places written on them, get latitude and longitude, overlay them on modern mapping systems, and identify features — waterways, canals, mountains, farms. That information goes into a vector database so it can be searched semantically.

So when someone searches “disputes over canals,” you get not only case law, debates in the Congressional Record, and newspaper articles, but maps where those disputes actually took place — spatial context as well as temporal context from the dates. I think you can do that for other artifacts too: paintings, sculpture, textiles — so people doing research on material culture could search catalogs, say at the Museum of Natural History or the Museum of Modern Art, and find artifacts related to their topics.

James Kaplan: What’s the toughest thing technologically — where is the technology there, and where is it harder?

Bob Pasker: I guess I’m an optimist: I think I can build something really fantastic here. The hardest part isn’t really the technology. It’s twofold: one, making it useful to historians in a way that comports with historiography and archival science; two, building relationships and partnerships with libraries and archives so they’re interested in doing this without feeling they’re giving up their walled gardens around these materials.

The good thing about how Roscoe works is it doesn’t duplicate the archive — it creates an index, the way a card catalog is an index, not the contents of everything. Those are really human difficulties more than technological ones. We’ll keep wrestling with precision and recall and the right way to visualize and display what’s useful. At this point I don’t see anything I can’t get out of the technology.

James Kaplan: It’s potentially disruptive within the history profession in the sense that, over time, techniques like this could make history even more of an empirical than a theoretical discipline — ground it more tightly in the historical record by accessing a broader set of documents easily.

Bob Pasker: How historians use evidence is itself a historiographic topic — it goes back to ancient Greece and the way Thucydides used evidence to describe what happened. That had a transformation in the nineteenth century as people became more interested in an evidentiary basis for history rather than only the stories they had told. The rational, evidence-based side of history has been developing for a couple of hundred years.

I think this extends the same trajectory as building archives, electronic card catalogs, transcriptions, photocopies, seeing old documents as images on the web. I’m a novice historian; others could expound on this much more. But I think Roscoe is doing what needs to happen given the scale of digitization and transcription at the archive level — making huge corpuses visible. I don’t think it’s disruptive; I think it’s enabling.

James Kaplan: Hearing what you just said, it’s a continuation — the next evolution in a long series of transitions over the past couple of hundred years, increasing the dataset available to historians as they do history.

Bob Pasker: Yes — and that’s what my paper this semester is about: what this deluge of information means for historians and how Roscoe will help. I call it the silence of abundance: what’s hidden in this great abundance of historical records.

James Kaplan: As you looked at those ninety-three antebellum cases, was there anything especially insightful that wouldn’t have been available if you hadn’t found them?

Bob Pasker: The fact that those cases exist at all. For the most part we “know” that Black people were not allowed to testify in court — not as witnesses, they couldn’t give evidence. But now we see: wait, that’s not completely true, even given what the laws say.

I had hoped I’d find justices who really wanted to give people an opportunity to testify on their own behalf or on behalf of something they had seen — in a positive, rights-expanding sense. That’s not really why they were allowed to testify. They were allowed to testify because nineteenth-century justices had a very specific concept of justice. It wasn’t liberty and freedom in the abstract; justice was the process of adjudicating cases.

So you had very specific situations in these ninety-three cases: someone was injured, the only witness was a Black man, everyone knew the person was injured and the defendant was guilty — but there was no witness except this one Black man. The only way for the justice system to maintain its reputation as an institution that could adjudicate cases was to let that witness testify. Otherwise it would be as if nobody had seen it, the defendant would go free, and that would violate their notion of procedural justice. It was more about maintaining institutional coherence than about a grander sense of justice. That was my conclusion.

James Kaplan: Very helpful. Anything I neglected to ask — anything else you’d like to cover?

Bob Pasker: As I’ve talked to historians — classmates, people in my department — and looked at what historians’ associations have said about artificial intelligence: by the way, I don’t use the term “artificial intelligence” because I find it unhelpful. I use “machine learning,” the technology I use, without the generative piece.

The resistance to something like Roscoe — what’s often lumped as “AI” — comes down to three concerns. One is hallucinations, which we’ve discussed. Two is teaching — how this affects pedagogy. Three is the human aspect of writing history: history is a process conducted by humans, not machines, because history gives us a sense of who we are, where we came from, the story of our path — and humans should own that, not computers.

I’m hoping something like Roscoe, which uses the same underlying technology in a different way, will have a positive impact — people will understand it and find it useful in their research. It may take ten or twenty years, another generation of scholars, before that really bears fruit. I’m enjoying being at the forefront and I’m proud of what I’ve done so far.

James Kaplan: Congratulations. Thank you so much.

Bob Pasker: Thank you. I really appreciate it, James. This is something I’ve wanted to talk about for a long time.

Footnotes

[1] For our younger readers: Before containers, app servers provided transaction management, connection pooling and a runtime environment for J2EE applications.