The 30-Second Splash
Ido: Most overhyped phrase in data right now?
Abe: Probably context graph. It's a good phrase — there's something real there — but it's also hugely overhyped.
Ido: Dream vacation destination?
Abe: My parents are taking me on a safari to Nairobi this summer. Call that a dream.
Ido: Will Full Stack Data Engineer be the most common data title in 2028?
Abe: Probably not. It's a good title, but probably not.
How did you arrive at knowledge bases?
Ido: Can you start with a short brief about you and how you arrived at the concept of knowledge bases inside organizations?
Abe: I came up through data engineering and data science, starting my career out of grad school in 2012. At that time, I kept getting hired to build data teams and cool algorithms — and discovered everywhere I went that the actual problems were all on the engineering side. You had to get the supply chain for the data to work before you could do the algorithm stuff. When you do that, both from a technical perspective and from a company-building perspective, you end up thinking a lot about what people need to know in order to get their work done. That made me fascinated with knowledge management, and it's a big part of what I'm working on now.
Ido: It's interesting that you came from the downstream usage — you started with the algorithm and understood that the real work is knowing what you already know. That's exactly what people feel right now. They're trying to leverage very cool AI models, and then they remember they need to explain to the model what they have. It's garbage in, garbage out. If companies really want to be AI native, they first have to understand how they're building their internal knowledge base.
Abe: I've seen so many teams that are trying to, for example, attach agents to a CRM — and then they realize: we need to deduplicate our CRM first. Otherwise we're going to end up sending the wrong offers to the wrong people. There are a lot of horror stories about scaling up AI on bad data that way.
What is a knowledge base, really?
Ido: How would you define a knowledge base?
Abe: I'm still fishing for the really concise, boiled-down definition, but I think memory is a good place to start. Memory gets complicated when you start thinking about the read and write access patterns you need from it. It's not just remembering what one person did or what one agent did — you're remembering across many different people, many different agents.
And ideally, you're not just keeping a log. A log doesn't feel like a full knowledge base. There's some layer of curation: extracting the important parts, understanding how they connect together, and surfacing them in a way where they become more useful in the future.
Ido: When I think about a knowledge base, it's some kind of central storage that condenses all the entities, relationships, and meaning inside an organization. Would you agree with that high-level definition?
Abe: I'd agree in an aspirational way — that's what you want a knowledge base to do. But look at the things people actually call knowledge bases. You have the giant SharePoint folder with 15 years of documents in it: not well organized, certainly not tied together in a relational way. In theory it could be, but it's a lot of work to get there. At the other end of the spectrum, people running personal agents treat a wiki — a folder with a bunch of markdown files — as their knowledge base. That's not ideal either, but it's actually adequate for a lot of tasks.
I think it's useful to consider all of those things collectively as knowledge bases, and then start to understand which operations are and aren't supported by different infrastructure.
Why does curation matter?
Ido: Something that intrigued me: you said knowledge needs to be curated. We can call a fifteen-year-old drive with thousands of documents a knowledge base, but it's not really usable. It reminds me of the old analytics days — you had all this raw data that was garbage, and to use it you had to curate it through classical data pipelines or a medallion architecture. From what I hear, this is the same thing in a broader view: not just tables, but documents, things agents gather from around the environment. From that, you curate something that really represents the ongoing business.
Abe: I think that's right. I'd just push on the "you need to curate it" — I'd ask why. For me, the why is that you curate in order to support certain operations. Take the giant SharePoint: does it support search? Sure. How useful is search on its own? Not very. If you pull up a document from ten years ago, do you still trust it? Is it still current? To make that judgment, you have to compare it with a bunch of other things.
So I'm starting to think of it as a sliding scale made up of discrete operations: which specific things can you do with this knowledge base? It gets more useful as you enable more functionality. And this thing we call curation — a lot of it is making it so that you can look in one place and be confident that it's the right answer, without having to look in a lot of other places.
Ido: So in the end, everything comes back to trust. When I get a piece of knowledge — how much can I trust it before I need to investigate further?
How do companies manage knowledge today?
Ido: How do you see companies managing their knowledge bases today?
Abe: Every CIO has a technology strategy and a knowledge management strategy — and one of the things I find really interesting is that those are still largely separate in most places. Forward-thinking organizations are starting to engage with the question: we've been storing stuff for a long time — how do we start curating it now?
Actually, this is one of the reasons I don't love the term "context graph." It implies the problem is strictly technical. A lot of it comes down to: how is it going to be used? Who's going to be looking at it? When are they going to need it? Unless you know those things, it's very hard to design a knowledge base that works. One microcosm of this is the whole semantic layers discussion going on in data teams. Defining your semantic layer is fundamentally a business problem. The hard part is getting buy-in from around the organization. There's a technical phase too, but unless you can get people to agree on what's a useful definition, it doesn't matter how good your query is.
But you're seeing this landscape too — are you seeing something different?
Ido: I think it's evolving. Traditional companies still look at unstructured and structured data separately. The unstructured data goes under some kind of search — Glean, or the Gemini tools in G Suite — and it's really not curated. People trust agents to give them the right information, and sometimes it works, sometimes it doesn't. It's certainly not something you can act on automatically.
On the structured side, I think the semantic layer is really catching on for the first time, because suddenly there's a broader organizational opportunity. The semantic layer is no longer only for analysts — every user in the organization can open an AI tool and talk with the data. So the buy-in to manage it properly is increasing. And the last thing: the agentic tools we have now really help us incorporate this context. The ability to create skills — to put all the context you have into a markdown file that's genuinely usable — is something magical. It helps us federate the collection of context from all around the organization.
So in short: search over your unstructured data, semantic layers starting to get traction, and people starting to use skills as knowledge collectors across the business.
The bottlenecks have flipped
Abe: Riffing on that — even once you have search on the unstructured stuff, there's so much more you could do with curation. And here's an observation from the other side. If you talk to folks really pushing hard on agentic engineering, everybody's talking about the bottleneck around review. Previously, writing the code was the slow part. Now that you can pour out lines and lines of mostly-correct code, suddenly review is the bottleneck — and there's a whole industry growing up around solving that.
The way you describe the value of the semantic layer strikes me as the same problem in reverse. Go back five or ten years: people talked about data democratization forever, and the issue was that analysts were the bottleneck. You needed somebody to translate between the business need and how to actually query the database. Now agents are getting good enough that the bottleneck is being relieved. Fully democratized data access doesn't feel like a pipe dream to me anymore.
Ido: But I think the new bottleneck is, again, structuring this knowledge so everything is grounded.
Abe: Totally. The reason a lot of previous data democratization efforts fell down: if everybody could just hit Looker or Metabase, it was very predictable — three to six months later you'd have nine different definitions of churn and endless arguments about how to define your metrics as an organization. Now, I wouldn't say metric definition is a solved problem, but it's a solvable problem. If you build the right infrastructure, the right skills, the right views, you can solve it.
What happens to data teams?
Ido: How does the need for knowledge bases affect the traditional data team? In the past, data teams focused on structured data, raw data pipelines, tests, models. Now there's this new notion of knowledge, unrelated to the classic pipeline. But from an organizational perspective, the data team is the one that should be in charge of this knowledge — it's the central place that collects all the raw data you need to curate. Where do you see data teams in the future?
Abe: I agree with your vision of what data teams should be doing. I think it may be a struggle for a lot of teams. A lot of data people have defined themselves in terms of their technical skill set: I'm really good at writing SQL, I know how to run a regression, I'm good at building pipelines in Spark. Those skills aren't completely commoditized yet, but AI is making a lot of them much faster and easier.
There's always been a split between data teams that define themselves by their technical prowess and teams that define themselves by their value to the business. Now it's becoming an existential thing. If you can be the trusted team that helps people solve the gnarly organizational alignment questions — agreeing on definitions, building that information architecture together — you can be hugely valuable. Suddenly, agents are your consumers, and you're playing a really important role. But it's a mixed bag: some executive teams haven't been willing to let data teams play that role, and a lot of data teams haven't thought of themselves in those terms. It's time to step up and see yourself as a crucial player within the business. The technical side remains important — but it's a means to that end, not the primary reason you exist.
Ido: We're continuing a line I discussed with Shachar in a previous episode: from the days when data engineers were DBAs thinking about indexes and storage, to more abstract models and dbt objects. Over almost twenty years, the technology part shrank and the business side got bigger and bigger. Now we're seeing the extreme of that — and it's happening to software engineers too. The technical part is not the bottleneck most of the time anymore.
So the new-age data team is the judge of the organization: settling disagreements between people, teams, and departments about what's right, and encapsulating that in the knowledge base.
Abe: It's a little like the role finance teams play in many organizations — the auditor, the arbiter, the final decider of what's worth investment. There are good things and bad things about it, but most large organizations need something centralized like that. And I think most CFO orgs are not equipped to do what we're talking about. There's a much deeper layer of really understanding how the product works and how the service is delivered that data teams are better positioned for.
Are we there yet?
Ido: To be honest, I think the technology is still not there. Data teams still need a lot of technical skills, and there are a lot of bottlenecks in this autonomous data engineer concept.
Abe: Right — we're not fully there yet. But I've flipped in the last two years. I used to think we'd plateau and it would be a long time before agents perform anything close to whole human roles. Now I think the writing's on the wall: agents are going to be able to perform a lot of the technical work within the next few years. You still have to write SQL today, you still have to commit and push code. But I'm planning for a future where most of that is delegated to agents, and it's the higher level of thinking, reasoning, and consensus-building within an organization that becomes the valuable skill set.
One thing I wouldn't want to lose, though: technical thinking gives you a rigor — the ability to take apart problems and build logically coherent arguments. Doing technical work really flexes that muscle. Even if it's not writing code, it shows up in how you think about building the right metrics, or which teams to bring on board when. Really well-grounded critical thinking — data people tend to be very good at that. It'll stay valuable; it's just going to be expressed in different ways over time.
What's the effect on the business?
Ido: Last question. Knowledge bases on their own aren't interesting — what's interesting is how they change how businesses operate.
Abe: The prize here is getting to a place where humans and agents can really successfully collaborate. And this is the thing I could nerd out about forever, because human collaboration is more art than science right now. It's very hard to replicate a good collaborative culture — there's this specific type of very human chemistry. Now we've got a new type of intelligence with different strengths and different weaknesses, one that can scale up infinitely as long as you can pay for the tokens and can work much faster in certain places — but is also totally idiotic at some things that are obvious to people. We barely understand collaboration among humans, and now we're mixing in this new type of intelligence.
The organizations that figure that out are going to live on a totally different plane than the other ones. And I can't see any way that works without a really well-functioning, well-curated knowledge base. Exactly what that means — we're unpacking it right now.
Ido: I love this analogy: your knowledge base as your organizational culture. The common ground between people working on different tasks — that's the culture, and that's exactly what we're trying to capture in the knowledge base. I'd carefully say that an organization with a good culture is going to mirror that into a good knowledge base — one that helps them carry their human-to-human culture into their human-to-agent interaction.
Abe: I think that's right — and to take it a step farther: just because you have a really good culture now doesn't mean it will be adaptive for the world to come. In general, I'd much rather build from a good culture than a bad one. But I don't see any world where we introduce a whole new kind of intelligence into our organizations and it doesn't change the organizational laws of physics. There are teams running experiments like: can you superpower an engineering manager so they manage 30 people instead of six or eight? Maybe that falls on its face. But if it works and you can have flatter organizations because of it — okay, the laws of physics just changed. Good culture will breed good evolution in culture, but it's going to have to evolve.
One level where I really strongly agree: a good knowledge base is going to make culture legible. In the past, culture was almost entirely invisible — at best you could see what your team was doing, maybe one layer up, one layer down. Now, our skill files — you can diff skill files. I don't think we're at this stage of practice yet, but we're going to get to the point where we can measure them and say: some of these are better than others. Some of our organizational habits aren't just different — they're better.
Closing takeaways
Ido: A few takeaways I'm leaving with:
- The knowledge base is the foundation for the new evolution of businesses that want to leverage AI. Without it, it's garbage in, garbage out — you can't really leverage the model.
- It's going to affect every person in the organization, especially the data team, whose role shifts from a technical role to the judge inside the organization — deciding what's right and what's not, and encapsulating it in the knowledge base.
- The knowledge base is the enabler of human–agent interaction: the one thing that synchronizes the whole organization and lets it operate in an autonomous way.
Abe: Thanks, Ido. This has been an awesome conversation.
If you enjoyed this conversation, follow the Data Splash podcast. We have a lot more coming. Until next time — keep your data flowing.
For the full episode:
Watch on Youtube: https://www.youtube.com/watch?v=qxMaSdRNhpY&list=PLJboMtNQp-MtIK1v7fn6eA35Ylh2T85IN&index=5
Listen on Spotify: https://open.spotify.com/episode/2ymLfsbNpNVdIqtZEYVUGd?si=p26dgKpsTgKVp-aTiwbz-Q
To follow the Data Splash:
Youtube: https://www.youtube.com/playlist?list=PLJboMtNQp-MtIK1v7fn6eA35Ylh2T85IN
Spotify: https://open.spotify.com/show/4MD8LSNbpzW46qeq3qptpr
