Talking Transformation, The Appledore Research Podcast. Episode 61: Agentic AI and the Semantic Knowledge Plane, with Vitria Technology

• Host: Robert Curran, Consulting Analyst, Appledore Research
• Guest: Dr. Dale Skeen, CTO and Co-founder, Vitria Technology
• Published: May 8, 2026 · Length: 28 minutes
• Listen: Acast · YouTube

Episode summary

Agentic AI works well in narrow, well-bounded telecom use cases. It struggles with complex, cross-domain problems where accuracy and trust matter most. In this episode of Talking Transformation, Appledore Research’s Robert Curran talks with Vitria CTO Dale Skeen about why more data isn’t enough, and how a Semantic Knowledge Plane gives AI the context it needs.

Skeen explains how semantic knowledge differs from a database: it captures the nature of relationships, such as the total dependency of a Kubernetes pod on its host versus the partial dependency between two linked routers. He describes how the knowledge plane is built and kept current from inventory systems, telemetry, troubleshooting guides and closed trouble tickets. He also explains why Vitria recommends “incremental transformation”: a minimum viable knowledge graph, delivered in 90- to 100-day sprints tied to measurable ROI.

The conversation covers results from Vitria deployments, how knowledge graphs make AI reasoning explainable and verifiable, and why knowledge will remain a lasting advantage even as AI models improve.

Key takeaways

• Data alone is not sufficient. A database can record that device A connects to device B. Semantic knowledge captures what that relationship means for failure and impact.
• Scope matters. Projects fail when scoped too small (lab conditions, perfect data) or too large (modeling an entire domain over years). Start with use cases that have measurable ROI.
• Knowledge is cumulative, and its benefit is multiplicative. Each new source adds relationships of its own and reveals new ones across what’s already there.
• The knowledge plane can maintain itself. Tools harvest and refresh knowledge from inventory systems and CMDBs, mine telemetry and troubleshooting guides, and learn from closed trouble tickets.
• Reported results: one operator detected and triaged problems before customer impact 95% of the time. A long-term customer has seen 20–30% year-over-year NOC productivity gains over more than five years.
• Trust comes from structure. Knowledge graphs give AI a chain of reasoning to follow, make answers explainable and verifiable, and act as guardrails.

Full transcript

Robert Curran: Hello and welcome back to Talking Transformation, the Appledore Research podcast. My name is Robert Curran, consulting analyst with Appledore. There’s no doubting that agentic AI is capturing the imagination of pretty much everybody involved in automating the operations of telecom networks. It’s a hugely exciting prospect: the idea that software agents are going to relieve the workload of frontline teams in identifying, diagnosing and resolving network issues autonomously. Really great idea. However, from our recent research, examples thus far seem largely constrained to narrow domains with pretty well-bounded problems and well-behaved data. It’s good progress. It’s somewhere to start. But where things get more challenging is in the sorts of everyday issues that involve more complex networks and services, where deeper understanding is necessary, not just more data. Exactly how telcos can bridge to this next level of sophistication is our topic of conversation today.

I’m very pleased to be joined by a true pioneer and veteran of the networking business, Dr. Dale Skeen, CTO at Vitria Technology. Dale has a PhD in computer science from the University of California at Berkeley. He co-founded TIBCO, a legendary company, and he’s been an assistant professor at Cornell University. He also just happens to have numerous patents in networking. In 1994, he co-founded Vitria with Dr. JoMei Chang, and in the last three decades Vitria has been building deep expertise in telecom domain knowledge, network operations and the whole business of automation. In fact, Vitria’s VIA AIOps platform is deployed in some of the world’s largest global networks, delivering measurable reductions in incident volume and mean time to repair, improved service availability, and accelerated time to value. Hi Dale, and welcome to Talking Transformation.

Dale Skeen: Well, it’s a pleasure to be with you today, Robert, talking about some of my favorite topics. And I thank the audience also for joining.

Robert Curran: Excellent. Dale, it was good to see you at FutureNet in London last week. That was quite a sizable event. And thank you for bringing over the Californian weather.

Dale Skeen: I think those who have been to London more than once know it was unseasonably warm and pleasant.

Robert Curran: The FutureNet audience has grown over the years, and I think that indicates the strength of interest in automation and in AI. Is that what you’re seeing reflected in your conversations with your telco customers? What are they seeing as challenges as they try to increase the levels of automation?

Dale Skeen: Yes, certainly we’re seeing that with our customers and with the market at large. People get into the conversation of how they can use AI, how they can use agentic AI. As you mentioned, most of our customers tend to be top-tier telcos and ISPs, with a mix of networks: legacy and new networks, 5G, cable. So it’s a real mix. But they’re really struggling to bring agentic AI to help with their problems. And I should mention that for our customers, we provide observability, AIOps and automation. Working with customers, especially in trying to install this functionality, we realized that they were having limited success with their agentic AI, as you pointed out. It works for smaller deployments and simpler tasks. But when you try to scale it up to more complex tasks and decision making, we see limits: limits in accuracy, and in trust. These become very real limiting factors.

So a few years ago, we started researching how we could get around those barriers, and we started pioneering the use of knowledge to address these limitations. Over the past few years, we have bundled knowledge capabilities into something we call a Semantic Knowledge Plane that serves as a layer above our AIOps tool sets, to, if you will, infuse the AIs with better knowledge, leading to better accuracy and better results.

Robert Curran: Interesting. We’re right in the meat of it here: this transition from data into knowledge, and your experience with your customers. Something listeners might be aware of is the concept of a knowledge graph. Can you distinguish between the Semantic Knowledge Plane that you’ve mentioned and knowledge graph technology? Are these one and the same thing, or how do they differ?

Dale Skeen: No, they’re different. Let’s break it down by component. You already mentioned the knowledge graph, which I assume most listeners are familiar with. Knowledge graphs are represented in something like RDF format. They’re both machine- and human-readable, and they’ve been around for quite a while.

Now, let’s focus on the word “semantics” for a moment. The true power of a knowledge graph is not that it can relate data together. It’s that you can layer semantics on top of the data, something a database cannot do. Think about a database. You can know that device A is connected to device B. But what’s the nature of that connection? What’s the nature of that relationship? You’re not going to get that from a database. With semantic knowledge, using a knowledge graph and the tools around it, you can specify those types of relationships down to a fine level of semantics.

For example, if one of those two devices is a Kubernetes pod and the other is a host computer, you can add to the knowledge graph that this is a containment relationship with total dependency. If the host fails, the pod has failed. Whereas if those two devices are routers with a link between them, it’s a partial dependency. One may fail, and it will impair the other. Or the link may fail, and it will impair both, but they won’t stop working. To really get to the level of accuracy you need for automation, you need to be able to distinguish these types of relationships and their semantics. This also illustrates why data alone is not sufficient. You need knowledge.

If I may continue: what does “plane” mean? A Semantic Knowledge Plane is a layer that contains the semantic knowledge, plus a set of tools that allow you to access, maintain, discover and reason over that knowledge. It supports importing data from multiple existing databases and systems, like network inventory systems, fusing that together, and perhaps learning relationships between those previously isolated data sources, which you can do now that you’ve brought them together in a knowledge graph. You can also mine other sources, like telemetry data; you may find knowledge there. You may find knowledge in your troubleshooting guides: you can have an LLM parse them, identify the elements in them, and put that into the knowledge graph. And you may capture knowledge from other sources of truth, such as the chats between your experts, to capture the institutional knowledge they have in their heads that isn’t written down anywhere. That can become a source you add to the knowledge graph.

The good thing is that all of this is cumulative. It’s additive. All these sources add together. So even though the addition of knowledge is cumulative, the benefit is multiplicative, because now you can do cross-correlation between all of those knowledge elements.

Robert Curran: I think operators are getting to a point where they know they’ve got a lot of data. What you’re describing about knowledge is something they’re becoming more aware of, especially, as you’ve indicated, the ways in which knowledge is distributed throughout the organization and different systems. What’s the right approach to building a knowledge plane? It sounds like the kind of thing operators might try to do for themselves. What kinds of mistakes have you seen companies make in trying to assemble one? Because it’s a very different type of information from raw data.

Dale Skeen: First of all, you’ll need some tooling for this. I don’t think operators want to build all the tools I just mentioned, so you want to find a source for the tooling you need to build knowledge graphs. But when they take on a project, we typically find two issues. One is scoping too small: a lab experiment under ideal conditions, with perfect data perhaps. Because of the size of the scope, it’s not going to scale up very well in the wild, where you have imperfect and missing data. You need more realistic assumptions.

Then there’s the other extreme: scoping too large. Taking on a complete domain, like the transport domain, and saying, “We’re going to model that, put all the data we have into a knowledge graph, and then either integrate it with existing functionality or bring new functionality to it.” Something that large is going to take years to accomplish. It’s just too long, and you don’t get to learn as you go, because you’re not really testing it out; you’re building a huge project.

So we find a better approach is a methodology we call incremental transformation. Choose a domain, but don’t try to “knowledge-fy” the entire domain. Instead, choose some use cases, preferably with measurable ROI, because that’s important to decision makers in deciding next steps, and it’s also a proof of value. Scope it properly so it’s deployable. We like to do things in 90- to 100-day chunks, or sprints, as we call them. Then you start building what we call the minimum viable knowledge graph, bringing in the knowledge you need to solve that problem. Don’t be too ambitious, especially in your first few projects. Narrow the scope, solve the problem, deploy, verify, learn and correct a little, and then take on the next project. You repeat this. It’s an iterative process.

And it works because, as I mentioned, knowledge is cumulative. When you add it in, you not only have the new relationships in what you’ve added, but you discover new relationships between what you’ve added and what’s already there. So you’re building up this knowledge, and we find that this is where and when customers are most successful. While each step in the journey is incremental, the overall journey is transformative. You really transform what you’re doing.

Robert Curran: I can see that’s likely to be very appealing to operators. We’ve been talking throughout our research about the difficulties of transformation, certainly in a big-bang context, so incremental approaches are definitely to be desired.

Dale Skeen: Yes. And this can be applied to a brownfield or a greenfield environment. Sometimes brownfields are easier, because you already have a lot of the functionality you need. What’s missing is knowledge, and you can layer that in on top. So it doesn’t have to be a new greenfield environment. Brownfield environments are often where we start.

Robert Curran: Great. To make it concrete, could you share some examples of where the Semantic Knowledge Plane has really addressed a critical issue for an operator?

Dale Skeen: In customers’ operations, we focus a lot on correlation and root cause analysis, because those functions are critical to making the right recommendation and getting the right problem fixed: not fixing too many, too few, or the wrong issue. By adding knowledge to that, for one customer, we were able to detect and triage problems before customer impact 95% of the time. They could do it faster. The knowledge allowed the AI to either recommend or, in some cases, completely automate the solution quickly. That was a dramatic change for them.

We’ve also seen 20 to 30% improvement in NOC productivity year over year. It’s consistent when you start putting this in, through knowledge-augmented root cause analysis, likely fix and automation. We’ve had one customer on this journey for more than five years, and they’ve seen that consistently.

You can also reduce the mean time to repair for really hard-to-resolve service degradations, the ones that confound the group, where you may bring 20 experts together. In these cases, knowledge-augmented insights can dramatically reduce the time those teams spend, and the size of those teams, in solving those hard problems.

And sometimes you tackle problems that teams handle very poorly. One is correlation across domains, because typically the systems are siloed. Even the monitoring and observability systems are siloed. Take a 5G network. If a customer is having problems in the radio network, dropping calls and so on, and that problem is caused by a virtualized router running in a data center somewhere, then you have to do that correlation across three domains: the radio network, the transport network that takes those signals back to the data center, and the data center itself, where IT is very different. Putting knowledge together that allows you to do this cross-correlation can make a tremendous impact on these hard-to-solve problems.

Robert Curran: That core issue of identifying issues and restoring service is so much a part of the business of telecom operations. It’s great to hear you’ve got some real success stories. Something I noticed from the FutureNet discussions and your presentations there: you were taking the knowledge plane concept a step further. For most people, just getting to the idea of building that kind of knowledge base is an achievement in itself. But you’ve extended it to how it’s maintained over time, with what I think you call a self-evolving knowledge plane. Can you explain how that plays out? How does it work as a living, breathing entity over time?

Dale Skeen: One of your points is well made: people struggle with the idea that if they build up this knowledge, they have to maintain it, because stale knowledge will cause problems. So we decided to craft a set of tools that make the knowledge plane self-maintaining insofar as possible, self-governing, and, to a certain extent, self-learning: learning new knowledge about the system.

We have a wide variety of tools; I can give some examples. First, harvesting knowledge from your typical sources of data (your databases, your inventory management systems, your CMDBs) and refreshing it periodically so it stays in sync. Then, tools for mining more non-traditional sources of data. Telemetry data often has real-time knowledge embedded within it of which items are related. If it’s reporting on one device, it may include that device’s neighbors, other links, and diagnostics. So you mine for that and put it into the knowledge plane as well.

We’ve developed, and continue to develop, tools that take natural-language sources like troubleshooting guides and put them into the knowledge plane. That’s a new source of data for most people, because it’s diagnostic data. It says: when you see this symptom and this root cause, this is the most likely fix. Typically, people learn that on the job, but if you can find it in guides, you can put it in there. That’s the beauty of knowledge: you can represent almost anything in it.

We also experiment with capturing chats and logs from the people really doing the work, so we can learn from their experience. And, which we’ve already done with some of our customers, we’ve tied the knowledge back to closed trouble tickets. A closed trouble ticket tells you what was actually repaired and on which device, compared with what the AI predicted and the fix it recommended. So we’ve now made this a learning system, one that can learn from its mistakes. It’s a continuously refreshing and learning system, and it sets up virtuous cycles of learning and refreshing.

Robert Curran: Excellent. Dale, you mentioned decision making right at the top of our conversation. I know there’s been quite a lot of sensitivity in telecom about agents and the whole question of trust; we’re never very far away from that conversation. How does the Semantic Knowledge Plane help overcome issues around trust and letting agents take control?

Dale Skeen: There are several ways it helps. First, improved accuracy: the knowledge graph, with its broader context and better semantics, allows the LLM to reason better, if you’re using an LLM. It applies to any agent; you can tie it to ML agents as well, though you may have to convert from a knowledge format to a format the AI can understand. So it can improve their accuracy.

Second, especially with a reasoning tool or an LLM, you can get better reasoning, because you can require it to use the knowledge graph as the basis for step-by-step reasoning. You give it the chain of reasoning, and by following that chain it delivers better results. There was an interesting study, I believe by a group of professors at MIT. They took the current releases of most of the frontier LLMs (ChatGPT, Claude, Gemini and others) and asked them a set of problems. One was: give me the 83rd Fibonacci number. The Fibonacci sequence is something people may have heard of; it occurs a lot in nature and is studied a lot, so it should be in their training. It turned out every one of them gave the wrong answer, because they guessed by looking at patterns. However, if you told them to generate the first 83 Fibonacci numbers, they got all 83 correct, including the 83rd. That shows the power of directing the chain of reasoning, or chain-of-thought prompting. So: better reasoning, and improved accuracy because of better reasoning.

Third is explainability. You can ask the LLM to explain its answer as a chain of reasoning across the knowledge graph, so it exposes the part of the knowledge graph it used. Then an independent LLM, or a human, can verify it. That gives you explainability and verifiability.

And finally, you can use the knowledge graph as guardrails. Not only for verifying: you can also say, “Constrain your answer and your reasoning to the knowledge graph, and report where your reasoning does not conform to it.” That restricts it. So what you get is better accuracy, better reasoning, explainability, verifiability and guardrails.

Robert Curran: That’s a great, clear explanation. I can see how it fits together and reduces some of the concerns operators have around transparency, going beyond observability into how these systems are working. What you’ve described in the last 20 minutes or so is a critical capability for telcos, given the enormous pressures on speed and agility. Looking ahead, will there be an increasing difference between telcos that adopt this concept and this kind of platform, and ones that stay where they are and manage with more staffing or something else? How will we see that diverge, and what will be the evidence?

Dale Skeen: I’d break that question into two parts. First, can knowledge create a business advantage? And second, is knowledge necessary?

Can knowledge create a business advantage? It enables more accurate automation at a faster rate. Once you start putting it in place (and, as we said, you can do it incrementally, so you’re not waiting three years), you’re changing the way you build things. That accuracy means you can automate more, and faster. It gives the companies adopting it a cost advantage, which they may translate into a competitive advantage, because they’ll have more autonomous operations and can operate faster or with fewer people. And I think it gives them an agility and innovation advantage as well, because it’s easier to introduce new services by generating new knowledge rather than new code. They may be able to innovate faster on the existing network and try out new types of services more quickly.

The bigger question is whether knowledge is really necessary in the medium to longer term, because LLMs are getting better. Do improvements in AI make knowledge irrelevant? That’s especially the argument if you believe artificial general intelligence is coming: when AGI arrives, why would you need knowledge? First, we don’t know if AGI is arriving, and it’s hard to predict how fast current generations of LLMs will improve. But regardless, knowledge is a tangible asset that can be shared and represents persistent learning over time. That’s an advantage that will stay with the companies that adopt it, however smart the AIs get. Look at the smartest beings on the planet today, which are still humans. When we study problems, we create knowledge, we compile books of knowledge, we teach knowledge. That’s how we teach the next generation and how we research with our peers. Intelligent beings have already proven that knowledge is a great advantage.

Robert Curran: Dale, thank you so much for your time today and your insights. It’s been really good to have someone with such great experience and knowledge of our industry, of telecom, networking and operations. I hope you’ve enjoyed our conversation.

Dale Skeen: I’ve enjoyed it too, and I appreciate the questions and the dialogue. And I want to thank the audience. If you made it to the end, I think you’re doing pretty well. Thank you.

Robert Curran: That’s great. Dale, thanks very much.