Episode 17 — What Is Knowledge? Why Humans Can Guess but Agents Can't

All opinions expressed are those of the individuals themselves, not necessarily of any company they work for.

What Is Knowledge?

Sunil Baliga: Welcome to this week's episode of Token Drop. We have a special guest, Ranjit Pabla, who's with Stack Overflow — very happy to have him join us today. There's been a lot of talk recently about knowledge, so I want to start there. Standard disclaimer before I forget: all opinions are those of the individual, not necessarily the company they work for.

Ranjit, what do you think knowledge actually is — from a human perspective, and from an AI agent's perspective, since that's what we're really here to talk about?

Ranjit Pabla: Great question. From my perspective, knowledge is an understanding — either a studied understanding or an experiential one — of an activity, or something we've actually thought about or discussed. That's the fundamental core of it to me: either I've studied it, experienced it, or heard about it somewhere.

I'd also extend it a bit into memory. When I take that knowledge, see it play out somewhere, and have an experience with it, it gets etched as memory. That connection between knowledge and memory is extremely important — I look at the two as somewhat distinct, but tightly linked.

Sunil: In an enterprise, knowledge is really the sum total of information across all the different employees, right? You have to somehow gather that institutional knowledge to actually apply it — which I think is a real challenge.

Ranjit: Correct.

Knowledge as the Enterprise's Real Differentiator

Sajjad Khazipura: That presupposes something, Sunil — that knowledge is the dominant differentiator for an enterprise, increasingly so going forward. Because that's ultimately what differentiates a business: who you are, what you stand for, how you compete. Their knowledge — the company's knowledge, the organizational knowledge.

Ranjit: That's a really important underlying point, Sajjad. As we talk to more and more organizations — especially in the AI and agent world — what's actually happening is the conversation has shifted. It's no longer "how do I deploy an agent?" It's "how do I make it operational, how do I scale it, how do I make sure knowledge compounds instead of getting recreated every single day?" Those questions are coming up more and more, and that's exactly the foundation of why knowledge — especially trusted knowledge — has become so paramount in organizations today.

Sajjad: I recall, even at companies I worked at as far back as 20 years ago, knowledge management used to be a formal function — there was literally a "knowledge manager" whose job was to organize institutional knowledge. But in hindsight, those efforts look minuscule compared to the knowledge frontier we face today: the immense amount of knowledge not just carried by employees, but encoded inside applications, and embedded inside the processes we use to transact with customers and everyone else. That's tacit or implicit knowledge. All of it constitutes real knowledge — and if aggregating it was already a challenge back then, it's become far more challenging now: recognizing where the knowledge boundaries even are, let alone aggregating, accumulating, and actually acting on it.

Handling Omission: What Happens When You Don't Know Something?

Sam Pooni: I've got a couple of questions for you on this, Ranjit. One thing I'd like to understand: what actually counts as an omission? Have you thought about what it means when, at authorship time, you genuinely don't know something — some facts simply don't exist yet until a certain point? What's the escape hatch for that? Does it just become the default path unless correcting it costs something?

Sunil: What do you mean, Sam — like someone asks how to bake a cake, and you don't know?

Sam: Right — some facts don't exist until something actually happens.

Sajjad: Until you actually try to make the cake, you don't realize there were steps you didn't have enough know-how about.

Sam: Exactly — so what do you do? You're in the business of collecting knowledge, and you don't have all the facts. What then?

Ranjit: The way I look at it: you make your best judgment based on the facts you have at hand. As the facts evolve, as learning improves, your understanding of that knowledge evolves too. If your approach is purely static — "this is what it is, like it or not" — and you never actually bake the cake, you'll end up losing the egg somewhere, or not having the right temperature. But as you evolve, that becomes experiential knowledge. There's a lot of tacit knowledge in play too — this very conversation we're recording right now, and its transcript, informs an existing body of knowledge. Knowledge can't be that definitive; it has to continuously evolve, the same way human understanding evolves.

Sunil: It would come with some level of confidence too, right? If my wife asks me something and I know it, I'll tell her exactly how to do it. If I don't, I might say, "I think this is roughly how you do it." I imagine AI faces the same challenge.

Ranjit: It does — and the opportunity for all of us is having the right control parameters around that. Going back to Sam's point about omissions: as long as we can accurately state and accept that something isn't at 100% trust — that it's more experiential at this point, hasn't come from a subject matter expert, and hasn't gone through the rigor needed to prove it in the market — that keeps the boundaries clear. If you document it in a clear, declarative way, that makes it usable by an agent in a way that's actually clearer than how a human would use it. A human sees something like an orange warning light and makes a judgment call — "let me go double check this." An agent needs an actual score: maybe 40% confidence instead of 75% or 80%.

Distinguishing Omission from Contradiction

Sam: That's exactly why I asked — you have knowledge, and you have omission. A contradiction is findable, because you have two conflicting values for one fact. But a fact nobody even thought to mention — you need to be able to distinguish that. That's where completeness and verifiability come in. How do you actually detect an omission? How do you know true facts simply weren't presented, when it's not even a contradiction at that level? That makes it even harder, I think.

Sajjad: Exactly.

Ranjit: Spot on. Another important point: knowledge consumption isn't linear. Traditionally, humans consume knowledge in a very linear way — read this, then this, in order. But machines can go in every direction, which is exactly where graphical relationships become so important, because the signals that reveal omissions or validate facts can come from completely different places. That's what makes graph-based knowledge so relevant to how we gather and store knowledge today.

The "Spider Web": How Machines Consume Knowledge Differently

Sunil: Let me make sure I follow — you're saying humans read a book chapter by chapter, but an AI doesn't need to go chapter 1, then 2. It can jump to chapter 1, then 10, then 3, then 8, and still piece together the full knowledge?

Ranjit: Exactly — and it's not even just jumping between chapters. It can move in multiple dimensions at once. Take a practical example: the engine warning light in a traditional internal-combustion-engine car. As humans, we're trained to see that light and think "there's a problem with the engine" — a fairly linear conclusion.

An agent looking at the same signal thinks differently — it could be a diode failure, some other kind of LED failure, or something else entirely triggering that response in the system. It considers every element at once, almost like a spider web spreading in multiple directions simultaneously. If it has the authority to actually investigate, it can reach the answer — and detect the real problem — far faster than a linear human thought process would.

Sajjad: Spot on, Ranjit — that reminds me of something from my time at AWS. One of the practices they emphasized was: if you have a thought or an idea, write it down — at least six pages. Even on subjects you assume you know well, the moment you start writing it out, you discover the sloppiness of your own thinking. You discover how inexact your estimates actually were. By the time you've written your first paragraph, you often realize you need to go do more research just to write the next one — that's how sloppy human thinking naturally is.

But when you have a machine systematically executing that same process — what you rightly pointed to — we used to call this a "360-degree perspective" when we were building knowledge graphs years ago: an oil well 360, a customer 360, trying to get a truly all-round view. Your facts can come from any direction, and you're stitching them together, connecting them to an entity, building out that spider web around a nugget of knowledge. That extends and bridges gaps across multiple entities, and you quickly discover they're connected through pathways you hadn't seen before.

Why Serving Knowledge to Agents Is Harder Than Serving It to Humans

Sajjad: And if you have to serve that knowledge to agents, it's far more challenging than serving it to humans. Humans can make assumptions, go discover through experience, come back, maybe fill in gaps with reasonable guesses, and keep making progress. An agent can just fall flat instead. So you have to serve exact, precise knowledge — with real depth.

Increasingly, we're also discovering the value of automated reasoning here — much like a human would reason. If someone hands you a nugget of knowledge, you might think about it subconsciously while walking, having dinner, watching TV — connecting it to other experiences or pieces of knowledge you already have. Sometimes that takes conscious effort. With machines, this is actually far easier, because you can run background processes that are continuously reasoning over knowledge, discovering gaps, and calling those gaps out — exactly the challenge Sam raised. Agents doing this reasoning can discover gaps in their own knowledge without being explicitly told those gaps exist; they can surface them just by reasoning through the material. It's a fascinating subject, and given that we're now tasked with serving knowledge to both humans and agents, I think serving agents is significantly more challenging.

Where Does "Rationality" Live — In the Reasoning Layer, or Somewhere Else?

Sam: I had a related thought — look at what "rationale" really means. Say you have a statement like "we chose X because the customer's security team rejected Y." That's a generic reasoning statement — you'd put it in a document as reasoning, but it has no direct machine consumer. How could it even be typed as a fact? That's the bigger question: where does rationality actually live? In the reasoning layer, or somewhere else entirely?

Ranjit: If I take a stab at that — the way we look at it, both at my organization and personally — let's flip the framing. If I'm a machine, an agent, consuming knowledge to do a task, I need clear instructions. Going back to the cake example: I need the actual steps to bake the cake. It's not "go ask your mom, or your dad, or your grandma how to do it" — a human can do that, but an agent needs clear instructions: this much flour, and if you're using whole milk, use this amount; if it's skim milk, use this amount instead; the rigidity should be this much. That's the experiential, tacit knowledge that needs to be very clearly defined.

That's the real challenge most organizations face today. It's not about tools like Confluence storing end-state knowledge — architecture diagrams and the like, which capture what has already been done. The problem is capturing why it was done that way. That experiential, conversational, tacit information is what most organizations struggle to actually store. Combined with the structured knowledge they already have, that's the ideal recipe to serve an agent.

The Token Cost of Reasoning — and Why Combining Structured + Tacit Knowledge Matters

Ranjit: The reason this combination matters so much: you can let an agent do its own reasoning from scratch — but the moment you do, it starts consuming tokens like crazy. In a world of real tokenomics, you can't afford that at scale. So the answer to "what is knowledge, and how do I operationalize it at scale without burning down my budget" comes down to combining structured knowledge with the experiential and tacit knowledge that already exists inside most organizations — together, they give you a declarative way to tell a machine exactly how to do things.

A human will always find a way to muddle through. A machine needs to understand very clearly what needs to be done. That doesn't mean there won't be omissions along the way, as Sam raised — there will be, especially as new solutions get created in the process. But bringing that tacit layer in gives you a full organizational layer of knowledge and memory, combined, that can actually be served to agents.

The Path to "Business as Code"

Ranjit: That combined knowledge-and-memory layer also becomes the foundation for the next frontier a lot of organizations are trying to reach: "business as code." Many are only at the very early stages of that journey — because even the fundamental knowledge of what's already been clearly defined often isn't clearly defined in the first place. Getting to a stage where you can write out entire business operations as a declarative process path is genuinely difficult. The classic example: if either of you left your organization tomorrow, there'd be a huge knowledge gap — extremely hard for anyone to fill unless you've actually codified what's in your head.

Sunil: We actually had a guest, Werner Goertz, on the podcast who talked about exactly that — when employees leave, their knowledge walks right out the door with them. Really interesting conversation.

Ranjit: Exactly.

Tokenomics and Tiering: Not All Knowledge Deserves Equal Investment

Sam: That's a really important point — the tokenomics of this. You've got hundreds of metadata questions and facts, but only a subset are cheap to retrieve; others are expensive to govern properly. If everything's "tier one," nothing really is. So practically, how do you figure out what's actually blocking you, in your own space, as you work through this?

Ranjit: Our biggest focus is creating a real trust layer around knowledge. We look at how topics emerge, how organizations identify who their actual subject matter experts are — whose answers are being used and adopted regularly. That trust layer, combined with a provenance layer — how often something's been used, where it goes, who's using it, what kind of rating it gets, how often it's been challenged, and its freshness (was it created yesterday, or two years ago?) — all feeds into a real trust signal. That's the fundamental difference: you can bring in all the knowledge you want, but without a trust level attached to it, it's of no value, because you don't know what's right or wrong.

That trust layer lets both humans and agents understand how to best consume the knowledge — though it's easier said than done. Part of the real challenge is bringing in a genuine subset of the actual data, not just metadata about it. If you've worked in search, you know how dependent it usually is on the source document — if that document disappears tomorrow, all that metadata and indexing goes out the door with it, because you're still fundamentally tying everything back to the source. We approach it a bit differently: we bring in a subset of the knowledge itself, so the organization retains that knowledge regardless of whether the original source document still exists. That's part of what lets us give a more validated, trustworthy score.

Does Knowledge Need to Be Timestamped?

Sam: But isn't the temporality of that data critical? Something can be true today and false tomorrow — you just made the point that knowledge is inherently time-based. As time progresses, accumulated knowledge may no longer hold. So when you're searching, knowing when something was created matters for trustworthiness. Are you saying everything needs to be timestamped — graphs, notes, everything — so you know exactly what you're retrieving?

Sunil: The thing is, Sam, you're assuming old is bad and new is good — but E equals mc² is still perfectly good.

Ranjit: Exactly right, Sunil — I'll answer Sam the same way. I don't change architecture diagrams every three or six months. If I'm a bank, I might design a two- or three-year architecture — that's how long it genuinely takes an organization like that to move and make real change happen. So something two years old in a base document doesn't automatically mean it's invalid.

But say two years ago I designed something around API access as the fundamental way of connecting to a system. In the two years since, MCP has become the new standard way of accessing a lot of things. That's exactly where timestamping matters — but more specifically, there might be a tacit conversation in a Teams call where someone says, "don't bother updating the architecture diagram, it's such a pain to push that change through approvals — just use MCP as the first-level connector, and fall back to APIs if you don't have it." That conversation, wherever it happened — Teams, Slack, elsewhere — needs to get captured and attached to the core knowledge base, so both humans and agents consuming it know there's an override: made at a specific time, by an SME — either the original author, or someone currently more authoritative in that same role — and that override supersedes what's in the architecture diagram unless it's later shown not to hold. That clarity is what makes the full trust signal on a given node so much stronger. The diagram doesn't go "bad" just because it's two years old.

What's Happening at the Frontier of "Business as Code"

Sajjad: I have one last question, given your role and what your company does — what are you seeing at the actual frontier of "business as code"? What are people doing at the leading edge of this?

Ranjit: Interesting question — between the three of us, we've collectively got a lot of years of experience across different companies, and there's a real pattern-repetition to what we're seeing. Think about the RPA days — everyone jumped on "RPA, RPA, RPA." Same with cloud — everyone rushed to get on the cloud bandwagon, and then once consumption spiraled, the conversation shifted to optimization. AI is following the same arc: adopt aggressively, then optimize once it starts getting out of hand. On the business-as-code side specifically, I think everyone's still experimenting — though with LLMs, things are moving noticeably faster than those earlier cycles.

We see organizations focused on three different fronts. First, the CIO's office (not the CTO's) — how do I run my own organization better? What RPA used to handle for back-office transactions, they now want converted into clear, declarative policies and knowledge paths an LLM can execute — rather than another RPA build, which breaks the moment something like SAP moves a button. Configure the policy correctly instead, and you solve for that kind of change more durably.

Second, we're seeing a lot of activity from the CTO's organization — particularly for as-a-service products, continuously evolving newer versions, data points, and capabilities much faster than before.

Third, go-to-market teams — systems spread across silos like Salesforce, ServiceNow, and various contract lifecycle management tools, and the challenge of codifying an entire code-to-cash process so an agent can actually manage it end-to-end.

And finally, there's a real push around partners — most large organizations have extensive partner networks, but everyone's building so fast that partners struggle to internalize new capabilities quickly enough. Partner-manager roles have been slashed dramatically at a lot of organizations, even as new products keep evolving and conflicting information keeps flowing in — so they're trying to codify that side too.

Across nearly every space, we're seeing the same pattern as RPA: back office is taking precedence over front office. When you push humans to the front end of a process and automate everything behind them — the paper-shuffling, table-to-table movement that used to eat up so much time — that's where things are actually getting identified and automated. Front-office, go-to-market work isn't going fully agentic; people talking to people still matters enormously. But the background work is getting codified substantially. Something as simple as generating a proposal, or building an account plan, is dramatically easier today than it was even a short time ago.

Sajjad's Closing Reflection: From "LLMs Alone" to Demanding Real Guardrails

Ranjit: So that's what we're seeing — how about you two?

Sajjad: It's a real challenge. Our view was that customers initially went all-in on LLMs, believing they could solve almost everything on their own. But over the past year to year and a half, we've seen people start demanding a real trust layer — real guardrails. If an LLM makes a mistake, how do you prevent an autonomous agent from creating a cascade of compounding problems with genuinely disastrous downstream effects?

If you've been on social media lately, a couple of months ago it was all "loop engineering." Then people realized loops burn tokens, and now, over just the last week or two, "graph engineering" is the new phrase — people are realizing graphs are really the way to build reliable systems. It's becoming a genuine trial-and-error process, discovered one step at a time. But for those who've been in this industry a long time and already understood the kinds of challenges businesses would run into, defining that vision early and letting the market catch up to you has proven to be the right approach. That's really what we're starting to see play out.

Wrap-Up

Sunil: I think that's going to have to be the last word — we've gone over time, but it was worth it. Ranjit, thank you so much for joining us, I really enjoyed this conversation. If you can hang on for just a second, I'll stop the recording and we'll wrap up from there.

Sajjad: If you—

Sunil: If you could hang out for just a second, that'd be great.