---
title: "4 Steps to Maximize Your Investment in AI"
id: "27225"
type: "post"
slug: "4-steps-to-maximize-your-investment-in-ai"
published_at: "2026-07-27T16:21:27+00:00"
modified_at: "2026-10-26T21:15:04+00:00"
url: "https://ipfabric.io/blog/4-steps-to-maximize-your-investment-in-ai/"
markdown_url: "https://ipfabric.io/blog/4-steps-to-maximize-your-investment-in-ai.md"
excerpt: "Four steps to maximize your investment in AI."
taxonomy_category:
  - "AI & automation"
taxonomy_post_tag:
  - "AIOps"
  - "Network automation"
---

# 4 Steps to Maximize Your Investment in AI

Four steps to maximize your investment in AI.

[https://ipfabric.io/author/pavel-bykov/](https://ipfabric.io/author/pavel-bykov/)
[Pavel Bykov](https://ipfabric.io/author/pavel-bykov/)
CEO

Published

27 Jul 2026

Updated

26 Oct 2026

When the boardroom conversation inevitably shifts to AI, leaders tend to gravitate toward questions like: How will this technology impact our productivity? How will this impact hiring? But according to a [recent study](https://www.nber.org/papers/w34836)
 by the National Bureau of Economic Research, 90% of surveyed businesses reported that AI had no meaningful effect on either.

That’s because many businesses are overlooking AI’s most important capital investment. It’s the people who are actually using AI, rather than the cutting-edge software or shiny new chatbots.

Early AI adopters have moved past the experimentation phase and begun implementing it across their operational workflows. But in doing so, a hidden risk emerges: When AI systems are missing critical context, how can humans trust them to help with their work?

## Where Trust in AI Breaks Down

In theory, AI should help us to make better, faster decisions in our day-to-day work. But in practice, if an AI agent is trained on a dataset that misses critical business and operational context, it doesn’t add much to human workflows.

Consider a common scenario: a critical business service slows down. Your monitoring tool shows an overloaded component, so the obvious response is to add capacity. But the real cause is that traffic was quietly rerouted onto a longer path. The most obvious response is to add more capacity. While this may fix the overload, it does not address the delays caused by that data taking the slower path.

What’s missing here is context. In order to be effective, an AI agent needs not only to know *what* is happening in the network but also to diagnose *why* it’s happening. In this example, the component may be behaving exactly as designed for a different set of assumptions. Traffic may be taking an unexpected path due to a recent change elsewhere in the environment. If you don’t understandwhy traffic flows as it does, you’re treating surface-level symptoms without addressing the underlying problem.

As anyone who’s used a chatbot knows, AI doesn’t always know when the right response requires pausing, asking better questions, or admitting that the situation calls for deeper context. And without this crucial operational context, AI can act in ways that reinforce incorrect assumptions.

Transcript It all hinges really on understanding  
 how the network infrastructure supports  
 your business. So it’s it’s being able  
 to understand the impact and that’s  
 really mapping through those  
 dependencies from um different parts of  
 the network on each other but also on  
 applications and how they sit on the  
 network infrastructure. So um typically  
 that’s in people’s heads or or you know  
 really tribal knowledge that’s been  
 arrived at through experience in an  
 organization. Things like reacting to  
 unplanned change. So resolving incidents  
 that have occurred um by being able to  
 diagnose them and and so as a result  
 minimizing the outage time for any of  
 the services that run across the network  
 and of course the number of outages as  
 well because you’re proactively able to  
 to to see what’s going on. the idea of  
 plan change where you’re where you’re  
 having to prepare and and and consider  
 what a change is going to to consist of  
 to validate that it’s been completed  
 correctly and of course to to you know  
 look after the roll back or fix forward  
 approach that you take. So much  
 understanding of the network is needed  
 in that process and again so much of  
 that is is embedded in people’s heads.  
 um exposing that in a in a more uh  
 programmatically available way. a key to  
 automation and potentially to to um a  
 aentic approaches as well

## Humans Are the Key to Unlocking AI’s Value

When organizations treat AI as a shortcut around human expertise, they often discover that they’ve merely added noise. Although AI excels in pattern recognition and language-based reasoning, it lacks institutional knowledge. It doesn’t know your company’s business model, risk tolerance, or customer relationships. This knowledge belongs to people. AI adoption only works when paired with human judgment.

This dynamic mirrors how organizations develop talent. New hires may arrive with strong credentials and broad knowledge, but effectiveness comes from guidance, feedback, and exposure to real-world constraints. AI is no different. It needs domain experts to determine how it’s trained, where it’s implemented, and how human employees can use it most effectively.

## 4 Steps to Maximize Your Investment in AI

The key to achieving lasting value from AI? Investing in human capabilities. When we observe the current leaders in AI, we can extract several best practices:

### 1. Establish an Actionable Source of Truth

As your business grows, it becomes increasingly important to maintain a view of the network that’s both stateful and structured. Stateful data incorporates the full context of how your network is behaving from end to end, while structured data is normalized and presented in a format that AI can actually understand and use to take action.

Humans and AI agents can both benefit from having a shared view of how critical services are meant to operate. When every leader and AI agent are informed by a reliable understanding of their network, it creates a culture of trust. Only when you have that trust can you begin to delegate tasks to AI systems.

Transcript All right, good uh good afternoon  
 everyone. Uh I can see we still have some people are joining in so I’m going to start slowly. Um my name is  
 Sebastian. So thank you everyone for joining today. Um while people are still settling in uh  
 I’m going to start with something that I’ve heard a lot today also previously but it’s the question that someone we  
 will ask someone. It’s like how h how accurate is your CMDB? Can you trust it?  
 And today I actually had an interesting answer from from someone saying have you ever seen a CMDB that you can trust?  
 which I thought is quite funny but unfortunately where we entering  
 everywhere are talking about AI obviously automation as well both put them in the same bucket  
 that CMDB accuracy is going to become something that’s going to be critical for your project  
 um so most organization don’t really have uh a single source of truth for the  
 network because what’s going to happen is you’re going to have different versions of Right? You’re going to have  
 some of your information that’s going to be in your monitoring tool or in your CMDB, in your IPAM, some Excel  
 spreadsheet as well. So all that data give you part of the truth of what you have on your network. So each of those  
 are going to be important and they give you part of the information like I said  
 but the the problem is the are they cons consistent with each other and how often  
 do you keep them up to date so the reason why it’s hard to keep them up to date it’s because the network is  
 the only source of truth where your network is a decentralized or has information which is decentralized where  
 each of your switches, routters, firewall and all those pieces in your network contains information that you  
 want to gather in one place and this is what is difficult to capture this  
 information consistently. But for that what you need is the right tooling something that can actually help  
 by continuously validating the state of your network. uh but so validating but also  
 discovering those nodes that you have in your network without relying on those  
 manual updates uh because otherwise if you rely on those manual updates and you have to  
 const consistently updating those information and you don’t this is where you’re going to have that wrong  
 information wrong data and now with automation and AI if you trust your  
 automation to do some actions If they don’t have if that source of information  
 is incorrect, this is where the decision that’s going to be made based on that is also going to be incorrect. Now the  
 problem is the faster we are trying to go by automating doing things at scale.  
 Now what it means is that bad data and will generate bad decision and at scale  
 throughout your network. So this is where you need the right information to  
 be able to make the right decision. So what [clears throat] we’re going to  
 do is put ourselves in a very normal situation which I’m pretty sure most of  
 you are in a similar situation where at some point we can take the image of  
 you’ve joined a new network or you are a new company so you’ve got to look after a network that you don’t know yet or  
 you’ve been working in the same company for a number of years and now you’ve got a merger so you’re going to on board a  
 new network that you don’t know about or maybe someone is leaving the company and now you’ve got to look after a part of  
 the infrastructure that you’ve haven’t seen before or that last time you’ve checked it was a number of years ago and  
 it’s that thing where you don’t really know what you have and this is the image there is like it’s it’s guess work is  
 you think you know something people might give you some information this is saying this is our vis diagram this is  
 what our network looks like now you can manage it because you’ve got the data that you need but the reality is we’ve  
 all seen those um incident or changes that you would perform where the moment you start  
 your change window you’re about to do something and oh it’s weird it’s not how I’ve planned it  
 because maybe you were looking at that vis diagram and now you realize that ah that’s not the same what I’m seeing on  
 the device doesn’t match the vis diagram so now you’ve got to go back to oh what  
 what am I about to do am I about to break something if I apply my confusion  
 just the way it is. Do I need to review the actual config I’m going to apply?  
 And now you go back to the drawing board of saying, well, I need to go few step back looking at the current state of my  
 network. Can I still apply my change? And then you may or may not be in a in a  
 situation where if you’re still within your maintenance windows, you can still perform your change. If you’re not, it  
 could be a situation where you’ve got to say, “Well, I don’t have time to do it now, so I’ll roll back and I’ll try  
 again next week involving tester and all that things.” So, it’s a lot of wasted time just because you didn’t have the  
 right information to start with. So, how can we help? So now what we’re  
 going to do is try to imagine if you could get that understanding of that unknown or unsure that I fully know that  
 network in a minute in a few minutes rather than getting it throughout painful discovery and manual updates.  
 So what we’re going to do is trying to look at what does it look like to get that understanding in a few minutes. So  
 now what you’re seeing in here will look like a network diagram. But I’m going to say something is it’s  
 not just a network diagram. And the reason I’ve kind of mentioned it before is your visual diagram the moment you’re  
 going to click save you’ve got now you’re unsure that is it still going to  
 be up to date. Within the first few minutes hopefully it would still be but now after a few months a few years this  
 is where you’ve got the uncertainty. you don’t really know what you have.  
 So now the picture that you have there, this is what IP fabric will after  
 discovering your network will be able to discover what are the devices in your  
 infrastructure. But it’s not just about saying great I know that you’ve got a switch there and a router there. What we  
 are doing as well during the discovery is piecing that information together. So now the key part in here is really  
 having the relationship between your devices. It’s great to know that you’ve got 10,000 network devices, but what’s  
 really useful is to know how are they connected to each other. Where are the relationships? What could be the impact  
 if that device disappear or how how the application relying on the network.  
 [clears throat] So yeah, so the the key part in here is really the relationship.  
 So what we’re going to do they’re just looking at a specific site in here and  
 what we might be able to see here I don’t know how clear the image is for my angle it’s not but uh um [clears throat]  
 those relationship between devices where you see some in yellow you’re going to have your SPF your layer two further  
 down now if you are trying to do that manually this is the part where you connect to one device you do your show  
 ip whatever the command is you see some output and now you’re going to keep that  
 output in mind go to the next device do the same command and I’m trying to find is this this neighbor is it another one  
 and this is the part that takes time so now when we’ve done the discovery you don’t have to worry about it we’ve  
 done that relationship mapping we know how those devices are interconnected  
 so now this is where I’m going to see that as it’s the difference of knowing  
 what you own. So the devices that you have and how your network behaves or  
 operates  
 because the understanding the dependencies between your network is what really going to help you understand  
 the risk and the impact of a change or having a better understanding of an incident when such things happens. So  
 now what you’re seeing on the right hand side is a similar topology as the one that we see there which has been pushed  
 into service now with that dependency mapping of how are those devices connected. So now if you want to put  
 that in place into your CMDB, you can have the uh the affected CI that would  
 kind of say if I’ve got an incident affecting one of those devices, what are the dependents? What else could be  
 affected in my network? So now because as I can see we’re  
 showing in here, we understand [clears throat] sorry how things connect. But it also mean that if we can  
 show this, it also means that we’ve got a good understanding of what are those things. So going back a few step backs  
 is it starts with that inventory. I was talking about the relationship but if  
 [clears throat] we know the relationship it means we’ve got the understanding of the devices that we have in our network.  
 So in here what you have is a CMDB something that looks that maybe you have  
 the same in your Excel spreadsheet maybe you have that somewhere else in your source of truth. The main difference in  
 that situation is you haven’t done that manually that data is coming directly from the devices that we’ve discovered.  
 So no more I’ve mistyped a serial number and now I’ve got duplicate entries with  
 different ser number which is going to have an impact from a maintenance perspective. uh or the wrong um model number for for  
 a switch because I forgot that there was a a letter somewhere where the same model doesn’t have that letter. So  
 you’ve got information that’s available extremely quickly and that you can trust  
 because there is no more manual error when you’ve extracted that information.  
 Uh so that’s the example in what we had in IP fabric and now that’s the same information that has been pushed into a  
 CMDB. So that’s the example with service now and again with that you’ve got the  
 option now of having an accurate CMDB. So when you’ve got your security team, your cyber ops or depending on how we  
 want to call them and they’re going to say how many devices do we have that are running this OS and that version instead  
 of doing that guesswork before we say well we think we’ve upgraded the last  
 devices on that version and you’re not too sure. So what do you do? You’re probably going to spend some  
 time more or less quickly depending on your automation strategy if you’ve already got ways of gathering that  
 information but you still have to be involved as a as a network engineer to help that cyber security team to find  
 the right information where now if you’ve got that process where you’re pushing that and now your CMDB become a  
 place that they can trust because they know they’ve got up to date information in a good way. You’re out of the loop.  
 They want a question. They they’re asking a question. They know where to fetch the information. They don’t have  
 to come to you for can you check this now. Maybe they’ll come back to you only because it’s like well we’ve seen that  
 you’ve got three devices using that version that we should not have. Can you please correct this?  
 Um and I’ve mentioned service now but this is not the only place where having that upto-ate information matters.  
 and okay. Okay. Well, anyway, that in here what  
 I’m trying to show there is an example of other tools that we integrate with. So, you would have your not in the  
 background, Netbox slightly closer to the front where those  
 are the tools that we’re going to see when you want to build your source of truth of what is in your network. So  
 similar story as the CMDB but slightly different use case where you probably won’t be using your service now from an  
 automation strategy to know what are the villain configured on the devices what are the state of my interfaces the IPAM  
 now you probably want to focus on a more automation focused source of truth  
 [clears throat] or I mean I forgot to mention again in here but it’s or you could also put that  
 information somewhere in an Excel file but And there’s chances that uh that  
 file will become out of date the moment you send it to someone by email and now everyone’s going to create their own  
 final version v2 v3 which uh unfortunately I’ve seen way too many  
 times. Okay. So this is really what I’m trying to do there is the end goal is being  
 able to have simple information. If we think an inventory is a fairly basic information  
 automated where you now have a way of having that information populated in your different tooling of your ecosystem  
 so that you can make the right decision for the network team but that the right decision for the business to rely on.  
 Okay. [clears throat] So now we’ve seen that what the a good situation would  
 look like. How how do we get to that? So if it seems that we can get there, why  
 are we not there already? Why do we still hear people saying I do not trust my CMDB?  
 And [clears throat] there are several reason for this is  
 it’s not one of the reason that we know it’s not it’s not like people are bad at documenting is we can do network  
 documentation. It usually comes to other problem is first there is the always the  
 what I think we have on our network versus what we really have and this is that gap in between which the drift  
 between those two which create that delta which is going to cause some issues. So the drift is the main factor  
 for struggling to get that CMDB up to date because the network is going to  
 change. So despite having the best intention, there is always going to be a moment where a drift is going to appear  
 between what you have in your source of truth versus what you really have on your network.  
 So the the second um I guess issues with this or the the gap with that is the is  
 the impact for this is a cost. So there is a cost impact of not having that  
 correct information. I’ve mentioned earlier potentially having a change windows having to be rescheduled just  
 because of the wrong information. So those are not necessarily the the first and obvious one but there is that  
 time risk because without the right information you may create a change having side effect that you didn’t  
 foresee and financial as well because obviously if you create an an outage  
 there could be as well a financial repercussion of such issue and what we’re going to see as well is the why  
 now why do we need to start fixing that problem now and I’ve mentioned it briefly but obviously automation and AI  
 uh tooling that are coming more and more of uh at the moment and without the right  
 foundation it becomes very useful to to use them utilize them fully.  
 [snorts] Okay. So now [clears throat] let’s look a little bit more in detail in term of uh why do we diverge from the  
 reality. So the network is going to change continuously. We know that a  
 network never stays the same. There’s always going to be changes because users want to do something else. We need to  
 add villain, we need to configure whatever we the network is there to serve a purpose the business and then if  
 the business doesn’t change then there’s probably something that’s not going well. So generally speaking, we are  
 going to have to do changes to the network and that’s why I was mentioning that that drift is going to happen and  
 now is how do we control that drift and make sure we can document it back.  
 The another issue in term of the gap is manual updates. So when I’ve mentioned this is you do a change, you finish  
 late, you’ve done some quick test and now you’re like, “Oh, I haven’t got time to do the documentation.” It’s all  
 right. I saw that next week, tomorrow morning. But then we all know the reality is there’s probably going to be  
 another fire next time. And documentation can wait. And unfortunately, it’s often something that  
 keep being postponed until there is an incident and then we’ve got to go back  
 to the drawing board or some regularity audit. Someone wants to actually we need  
 to prove that we have documented our network and now this is where people are going to spend a huge amount of time to  
 update that information. So the relationship drift is really what  
 is the problem there where even if you think about that simple example of updating your vis diagram  
 because you’ve changed added a device somewhere it becomes difficult to also update  
 everything that’s kind of depending on those devices where it’s easy to add one device into a diagram but in term of is  
 the application going to be monitored somewhere do we know what else is changing by just adding that one device  
 and this is where there is that drift that becomes bigger where your monitoring tool for example may have an  
 understanding of the devices but without understanding the relationship in between.  
 So that was for the kind of the drift between the what you have on your network and documentation. Now we’re  
 going to look slightly more into the the cost like what’s the cost of the having that wrong information.  
 I’ve mentioned it is slower uh troubleshooting or more time to prepare  
 or plan or or or do a change perform a change windows including your post  
 checks as well. So everything is is going to tend to be a lot slower.  
 the risk I’ve mentioned as well where now having a change that’s not properly  
 managed is going to create those risk uh by you change something somewhere but  
 now you didn’t know that another application was also using this that you’ve affected and now you’ve got that  
 outage in your hand which could also cause that problem with the money  
 whether it’s going to be a fine or the example I’ve got in here as well is something and I’ll mention as well from  
 um a customer example people where what we did with them when they started P  
 with us they they they knew they had a big problem with their CMDB accuracy and  
 with a small gap and I’m just looking at the number I can remember but they’ve started with discovering around 400  
 devices and what they’ve realized once they’ve discovered those 400 devices and  
 compared that information with what they had in RCMDB they’ve realized that there was a 10% gap and by that I  
 10 extra uh 10% so around 40 devices inside service now which were not on the  
 network. So now it may not seem like a lot for some people they would say 40 is not too  
 bad but now that wasn’t the full scope for them. That was only a partial part of the network. Then they discovered the  
 full scope and obviously that gap did not go smaller. It tend to be even more.  
 But what does it mean in term of impact for them? It was just like what we have in our CMDB is what we’re going to use  
 for maintenance renewal. So it means that those number the information that  
 we have in service now it’s very possible that we are paying maintenance for it but those devices are not in  
 production. So now if you multiply I don’t know the cost but the average cost  
 of maintenance for a device but once you start multiplying by the number of phantom devices now you start thinking  
 oh that’s a huge amount of money that we’ve spent for absolutely no reason  
 but that’s only one side [clears throat] of the story. There is also the the other side of the story where it could  
 be the other way around where we would see a device in your network but it’s not in your CMDB and now slightly  
 different but now you don’t have any maintenance for it because maybe you don’t have it in your CMDB so the day  
 there is a problem you can’t easily contact the support so then there’s always that extra process because it’s  
 like well it’s not supported can we add the support the maintenance so not having that information is also  
 going to slow you or add extra processes or things that you have to perform.  
 Yeah. And um so so yeah, so it’s really finding that gap both ways of things that we have discovered and that maybe  
 are not in your documentation. The other example as well where outside of the  
 CMDB, it’s also what do you use to update and populate your monitoring tools. Now, if we’ve discovered a  
 network device that is not in your CMDB, are we sure that it’s fully monitored?  
 Is it on our monitoring system? Has it got the standard configuration that we were meant to be using? So, all those  
 questions can cause some impact as well.  
 Okay. And now the why now? Why do we need to do that change now? So, this is  
 the part where there is the the pace at which things changes. So we always  
 change the network and we need to do more changes and we don’t have time to go back. So yeah we keeping things  
 updated manually is not going to work. Now there’s also the regular regulatory  
 requirement where we have to be compliant with some specific framework  
 and for that we need to provide documentation because if we don’t we we know that  
 there’s going to be the the impact which could be fine uh depending on where you  
 are. Yeah, could be different framework but where the network has to show the documentation we have to show that we  
 are in control of our network. we we have control over it.  
 And the last one is going to be the automation and AI where we know that  
 human used to be what would do the cor the correction layer but now we are  
 doing more and faster using the help of automation and AI but like I’ve  
 mentioned if the inputs that you’re sending to your AI or automation is based on that wrong information you’re  
 just going to get not just the wrong output but also the wrong action that is going to  
 perform which can be uh causing more issues to your environment.  
 Okay. So now that we’ve defined the the problem and the potential solution, what  
 I want to know to to show now is going to be how how can we help with  
 validating this reality. So IP fabric  
 its role is going to like I’ve mentioned is going to be first to discover your network and this is where we go from a  
 very uh similar approach to the network engineer to find out what the devices  
 are in your network extract that information normalize that information because it  
 could be multi- vendor where you could have your fabric in your data center which is not going to use the same  
 technology as your campus or your plan or your firewall and all of that  
 information, it’s going to be brought into the same place with a similar  
 output. Because from our perspective, a routing table or a firewall policy  
 regardless of what device is behind it, it’s always going to look the same.  
 And now we’re able to do that verification as well because we’ve got that normalized data.  
 And finally once you’ve got and collected that data you can reconcile it with your ecosystem like we’ve mentioned  
 before whether it’s to push into one network source of truth your netbox or  
 equivalent and then from there that tool would now start populating different  
 system which could be now your CMDB your inventory your monitoring tools. So where everything now that you have your  
 correct representation of what you have in your network can be fully updated.  
 Okay. So before I start I’m going to move to a live the presentation of IP  
 fabric but also show some example of MCP. But before I do that, I just wanted to if if there are any question I want,  
 you know, please feel free to to ask because the goal of that live demo is something that I want to make sure like  
 you see something that you find useful. So feel free to ask any questions. Thanks.  
 And yeah, perfect. [clears throat]  
 Okay. So, so for this, so what I’m going to do, uh, sorry, I’ve just realized  
 this. Okay. Should be slightly more visible.  
 Okay. Can we see? Okay. At the back, I just want to make sure. Is that is that visible enough or would you prefer  
 bigger? No. Okay. Thank you. [snorts] Um, okay. So, now I’m in the UI of IP  
 Fabric and what we’re going to see here is different snapshot. The snapshot being what is produced after that  
 discovery. So discovery is IP fabric find what are the devices extract the  
 information and bring it into the UI or into the tool which we can then query.  
 So we’ve shown earlier this inventory table. Right now I’ve got my inventory.  
 I know what are my devices that I have. uh and if I filter for something like  
 this now I can see that I’ve got a mix of different platform from that same vendor and all that information is now  
 available I can query it as well via API so from a if I want to use that  
 information to push into different tool or different ecosystem I’ve got that  
 programmatic access to it so just to show the example I’m just going to take  
 the the net box but the information that we see for example in here in Netbox has  
 been pushed via plug-in that we’ve done with them to say take the information  
 from IP fabric put it in a new branch in Netbox show me the div and now what do  
 you want to do with that new branch do we merge it or not but now you’ve got that way of having that feedback loop of  
 I’ve got my source of truth networks is the data on the network still the  
 same or is there already some sort of drift that has happened where maybe if I look at one  
 device somewhere in here for example I don’t know it’s uh yeah is the IP  
 address that’s configured on that specific interface still this is what netbox is saying so what has been put  
 but what if someone has manually changed that information on my device now this is where you’ve got a drift you’ve got a  
 conflict of information where my source of truth netbox tells one thing but my  
 network tells something else now who’s right I don’t know. It depends. Was it  
 that IP change for a reason, a project, or was it an accident? Someone changed  
 something in net box that maybe should not have been updated that I don’t know. And this is where you might still need a  
 human to check the drift or if depending on what are the use cases and how you  
 plan on using it, maybe it’s actually the automation should take care of that  
 uh correction in that situation.  
 Okay. So that’s from the simple um CMDB I guess uh um updates. The the other  
 thing I wanted to to show now just to uh to have a better understanding. It was based on the the diagram. So we’ve we’ve  
 seen this topology which is a representation  
 of connection that we have between the devices. So now if I zoom to that same site that we had before now understand  
 my relationship I want to see what was connected to those devices at a specific moment in time I can go back to my  
 previous snapshot or the one from last week to see relationship that maybe were not present before. So if I zoom in into  
 those devices in this specific snapshot, I know if I go back to a previous  
 snapshot, I’m having links that were not present back then. So now if I wanted, I  
 could compare those two snapshot to say show me the difference again from a relationship perspective. And now that  
 would show me that between those two moments in time, new links have been added between those devices.  
 That’s from a relationship perspective. Now maybe I want to go further than that. It’s it’s great that I can see the  
 relationship between devices. But now I want to understand further how my  
 network behaves. So if I’ve got a user somewhere connected into one of my sites and maybe  
 the issue that I’m going to get is I’m going to receive a ticket from someone saying I cannot access a specific  
 application. So I’m going to use this one where I’ve got a source IP destination and someone is going to tell  
 me I’ve got an issue. I cannot access my destination. So now what IP Fabric will do in that  
 situation what we’ve collected from the devices is not just the configuration  
 but the state of those devices. So by that I mean it’s like we showed earlier the OPF relationship. You don’t get that  
 relationship just from the configuration. you need to look at the state of my SPF in that situation. But  
 we’re also collecting rooting table, art table, MAC address table which help us understand the forwarding that those  
 devices were doing at the time of that discovery. So in this example, we see that there is  
 a firewall that’s dropping this flow. But then what I can also see it’s what’s  
 happening further down the line and why that could be useful. So this one is a lot more from an operational  
 perspective. It would avoid potentially having the I receive a ticket, I open one firewall, I close the ticket, and  
 the next day you’ve got the user complaining that it’s still not working. Oh, we didn’t know that there was  
 another firewall further down the path. So now that we have this information, what we can do is perform the change. If  
 we want to change this, create the new snapshot and now we can have that  
 confirmation of how does it look like afterwards.  
 And that’s because I’m using the wrong one. So, so I was using the wrong port. I was on 3389 for different use cases.  
 So, okay. So, just to show again. So, now I’m on port 443.  
 That was the use case. So, before we actually had both firewall blocking the port 443 and after the change now we can  
 see that both firewall are green. So in that case the security has applied the  
 the policy correctly on both firewall. So now I’ve got confirmation that the pass is working.  
 Okay. And now the the last thing I wanted to show is going to compare  
 further that path lookup and show how an AI so an MCP server in our situation  
 with the help of LLM can use that data to provide I would say human readable  
 and not just as a diagram information that that would help with the understanding of what has changed on the  
 network. So this is the use cases where I need to go back to my  
 firewall in here. So now it’s a slightly different it looks the same. It’s a slightly different use case where now my  
 firewall in red is there for a compliance perspective where I do not want those users to be able to access  
 that destination on that specific port on RDP in that situation. So now what I’m seeing is my firewall is currently  
 blocking that flow and I’m happy because that’s what I wanted. But now what what happens on the next  
 snapshot? It looks pretty much similar but the firewall is no longer there. So in this  
 situation what happened is rooting has been done differently. So now the firewall is  
 being bypassed and we go directly to the next device. In reality, it could be something a lot more complex than this  
 where you perform a change and then there is something somewhere where now you’re going through you’re going to  
 route that network through a slightly different path and maybe instead of going through one firewall over there  
 the traffic is now going to use a different one which may not have the same rules in your firewall or like in  
 this case maybe you don’t even go through a firewall. So if you’re a compliance uh for looking at it from a compliance  
 perspective, you look at the firewall and it looks good because you’re blocking what you should be blocking,  
 but if your traffic doesn’t hit that firewall, that’s not going to achieve the the goal that you are trying to do  
 with this. So now in the in the example that we’ve done using the our MCP server  
 was we’ve asked to say show me the difference uh between those two snapshot  
 for this specific path. And what so in this one it was done by  
 close using the MCP server that we have with IP fabric where with that question  
 it generated an HTML report where I’m taking the source to destination pass  
 lookup from the previous snapshot and this is what we are seeing on the left  
 hand side and that looks like this is what we had on the on the graph earlier but we can  
 already see that it added that extra command to say now that device has been  
 removed when we look at the next snapshot. And now if we look at the the the next snapshot, we see that similar  
 format and now we’ve been highlighted in red that that firewall has been removed.  
 And now you’ve got clude who decided to make a a red warning about this to say  
 it looks like there’s been a firewall bypass with some explanation as well on from a rooting perspective that now we  
 are no longer going through the firewall but pointing directly to the device after. So now this is some sort of the  
 use case that you can start achieving because you’ve got information that you  
 can feed to an LLM via via the MCP server where without that correct  
 information it would be very difficult to use such uh such agent  
 because it won’t know how to get that information and that’s going to be I guess even more true when there when  
 you’re not using some sort controller for your network and that information is going to be spread throughout an  
 environment. Um, and probably the last thing before I  
 guess further question I want to show is something or maybe the second one was  
 similar past lookup but this one was an interesting topic that we had as well with few few people last yesterday about  
 the MTU as well. How can we put on top of that representation MTU information?  
 Because I want to ensure that my MTU is going to be consistent not just on the link to see that are both of my  
 interfaces configured the same way but now looking at it from a full path perspective.  
 And the last one is another classic use case that goes back to the CMDB  
 accuracy, your inventory. But this one was more from an end of life perspective where we already have that information  
 in IP fabric. It was just using the MCP and build uh a different visual for that  
 representation where now we’re looking for a specific snapshot where we would see which devices are now end of life or  
 end of maintenance. Uh I just wanted to bring it here to give the perspective  
 from that angle. And now this is the what the MCP took and the LLM decided to  
 create again a different reporting for that. But that information we would have so from the moment you do the discovery  
 to see that now we know what’s no longer up to date and as we mentioned with the  
 the customer I was mentioning earlier for them being able to see that information was a great help to say but  
 now we know that we can ask our management for further budget just because we’ve know we’ve got this  
 potential problem and we just need someone to say what do we do? Do we accept the risk that we’re running  
 devices that are no longer under support or if we don’t then we need to ensure  
 that we’re going to have the right budget so that we can work on the replacement for those.  
 Okay. Thank you very much. Are there any questions? Any comments?  
 Nope. Okay. Otherwise, if you’ve got any further question, you can always come and see us. If it’s to do more deep dive  
 from a an MCP server to see the what are the things that we can achieve with  
 those is obviously from our perspective the holidays. We haven’t released it publicly yet, but we’re doing some beta  
 testing or if it’s more from the use cases that where we can help as well,  
 feel free to come and see us in a in a world of solution. Thank you very much.

### 2. Prioritize Context in Automated Workflows

Even the most robust dataset isn’t any good unless it’s relevant to the teams and tools that are using it. Humans and AI systems alike thrive on context. The more focused the context, the better AI systems are at making decisions that align with business intent.

If an AI agent is tasked with validating network changes but it lacks the necessary business context, then it might greenlight a change that could cascade into security or compliance issues. However, if that same agent were given end-to-end visibility into network behavior and dependencies, it would have the context to identify the downstream impact before the change is made. This ultimately protects the business from unnecessary risk.

Transcript So welcome everyone to today’s ONUG webinar. Our topic today is unlocking AI  
 ops with Red Hat and IP fabric, the power of dependency mapping. Um I’m your  
 host um Stephen Collins. I am the ONG CTO and I’ll be your moderator today.  
 And we have two speakers. We have Martin Machka who’s um manager of IT networks  
 at Red Hat. and we have VTEC Savo who’s the senior channel development manager  
 at IP Fabric. Um, we’re going to have an interesting u discussion today about how  
 um Red Hat’s been working with the IP fabric to uh to do a a much better job  
 of getting handled what’s going on inside of the network infrastructure and um um responding better to um issues and  
 anomalies and incidents within the network and um and leveraging this dependency mapping capability to do a  
 much better job of being proactive and automating ating workflows, etc. It’s a really interesting topic and I think  
 very timely given the state of where networks are today. Um, before we dive  
 in though, I want to let everybody know feel free to ask any questions um that may arise during the course of the uh  
 next half hour or so. You can do that by entering your question via the uh Q&A  
 tab at any time. We’ll probably cue the questions up uh to towards the end, but  
 um but feel free to ask them at any time, especially if they’re really relevant. maybe we’ll just stop and answer it right at that at that point.  
 So, um that’s a little bit of housekeeping here. Um I just wanted to help set the stage here a little bit and  
 since the you know topic is AI ops um and and how this is you know related to  
 AI ops and the interesting thing here is AI ops that term was coined by Gartner way back in 2016. So you know in the  
 industry we’ve got almost a decade decades worth of experience with AI ops solutions. Um, you know, and back when  
 this kind of first came on the scene, a lot of the AI ops actually boiled down  
 to kind of machine learning using statistical analysis of time series  
 data. Usually, um, processes that were focused on a  
 given domain or a given layer within the network. um some fairly powerful tools  
 were developed but again kind of really zeroing in on on a given domain or a given layer. Um then the you know neural  
 networks u became kind of commercially viable. So we started doing more um actual machine learning on data and that  
 actually allowed not just um to look backward and do kind of historical views  
 of what was going on but you could actually use those types of capabilities to do predictions about what was going  
 on. So there’s been a lot of really interesting technology that’s been developed and of course the amount of  
 data that can now be consumed and analyzed and processed is now kind of mind-blowing. So you know tools have  
 gotten nothing but more powerful kind of at that kind of atomic level. Um but but  
 what’s interesting is as AI ops has progressed in its capabilities the environments that were operating in have  
 progressed in terms of complexity um and and scale. So, you know, back 10  
 years ago, a lot of folks were probably just running applications within their own data center. Maybe they were  
 starting to dabble with the cloud. You know, if you look at where we are today, you’ve still got a lot going on, of  
 course, inside of, you know, on premise data centers, but there’s also a whole lot that’s going on in the cloud and  
 actually in multiple clouds and multiple SAS applications. So the whole environment has become much more  
 distributed uh much more dynamic much more complex and and so it’s been a  
 challenge I think for AI ops techniques to kind of evolve out of that kind of private data center environment into  
 this now highly um complex and distributed environment with layers of  
 virtualization etc. So the interesting thing is, you know, what needs to be  
 done to kind of harness the power of AI ops in these environments and and really what it boils down to is being able to  
 understand and track the relationships between different elements, network elements, devices,  
 elements of the application infrastructure, what the relationships are between all those components and and  
 also the relationships between them as they change over time. And some of that  
 can be highly dynamic in these, you know, very virtualized application environments that are now becoming, you  
 know, commonplace with things like Kubernetes, containerbased applications. So, we’re in a world now where  
 um AI ops is is going to be not just a nice to have, it’s going to be a got to  
 have. And I think what we’re going to talk about today with Martin and VTEC here is a a really important concept  
 called dependency mapping and how that can be used um to keep track of what the  
 relationships are between um different components or different elements and different layers or different domains  
 and and then just do a much better job of keeping track of what’s going on, predicting what might be going on and  
 doing a leveraging the power of automation tools that are now at our disposal.  
 And that’s before we even start to apply things like, you know, generative AI and large language models to to the problems  
 that need to be solved. So, um, we’re kind of really, I think, at another inflection point here in the way  
 networks and application environments are envir are evolving. And so, I think today’s topic is, uh, particularly  
 relevant to all of that. So, with that little bit of a long- winded introduction, I’m going to hand this  
 over to Martin and VTEC and and let them run with it.  
 Thank you Steve. Uh let me move us on on on the topic. So uh thank you for the  
 introduction there and I think what we are dealing at this moment um with is is  
 really the paradox. So the promise is huge having proactive self-healing um it  
 that saves money and and time uh but eventually um  
 we have vast amount of data that is overwhelming and it it as you mentioned  
 Steve it’s very hard to navigate through the complex infrastructure of uh  
 virtualization containers uh all the systems being very distributed in  
 multiple data centers on premise or even in the cloud. Well, so uh basically the  
 core problem at this moment is that teams lack the real visibility into the infrastructure. They they they uh fail  
 to understand how things are being connected, what is dependent on what and  
 what happens when something breaks or what happens when I do a change somewhere? Uh what what am I what am I  
 breaking potentially? So um that that’s the biggest question that we have currently. Um and what AIO ops actually  
 is um well AI ops is not a a magic AI that you just go and plug it into your  
 infrastructure and it will suddenly understand everything be able to uh make all the decisions be able to provide you  
 with the full visibility uh end to end but you uh eventually need to provide  
 that context and provide that so so you can augment your expertise with with the  
 tooling with with uh with data for data driven decisions um and really moving  
 from proactive to uh sorry from reactive to proactive uh and eventually automated  
 remediation for that as I said you need the context so you need a single source of truth that is showing um in a machine  
 readable format of how things are actually connected how things are dependent on each other and you have to  
 go with from very bottom layer of of infrastructure up to the application  
 stack and and individual application uh resources because one application is not  
 just one VM running somewhere but it’s multiple resources that are connecting to each other and uh discussing or  
 talking data. So you need to have that context somewhere  
 and that is where the dependency map is uh is  
 coming in. Right? So you can eventually you cannot eventually automate what you  
 don’t understand and dependency mapping is there to help you understand that uh dependency mapping is there to be able  
 to connect everything uh instantly understand and see the blast radius if  
 there is an outage. So you can have a um fast or automated root cause analysis  
 nowadays with uh a AI agents and everything with this context that you  
 provide to AI agent. It can pretty much automate uh the root cause analyszis  
 with all that context. You can have smarter automation where uh you are  
 really hitting the right playbook for the right target and and and you get the automated remediation in no time and um  
 well as I mentioned you understand what what you are eventually breaking when when you do a change. So whenever you do  
 a change planning you know uh your upstream downstream relationships. So you you know who to notify who to talk  
 to. you have some stakeholders that that are dependent on your piece of infrastructure. So when when you do that  
 change, you can clearly articulate what the impact is uh and and have that uh  
 scheduled. So so nobody nobody um is affected or you limit that impact of of  
 the change. How we actually started with building the the dependency map. Now that I talk  
 about so much of the dependency map, we have a lot of tooling but we decided to start with uh couple of tools uh we have  
 some data in service now where we have the cmdb where we store all the data about um  
 business applications and and what actually forms these applications like VMs uh open shift kubernetes resources  
 and um storage and all that stuff. So we have that information there but that  
 it’s not showing how it’s connected uh down to the to the networking layer. We have network automation. We basically  
 automate the the whole network infrastructure and we know how network infrastructure is connected.  
 Uh we have open shift where we run basically nowadays all the virtualization and containers uh and and  
 that can provide by API quite a lot of context but again it’s not showing the  
 full context. So we chose netbox uh as an open source tool to actually be the  
 uh aggregator of the information. uh we put there all we wanted to put  
 there all the data from network from uh those sources like service now open shift network automation and kind of  
 connect it all together but for that uh to to be achieved that we needed the glue and um that’s why we are um  
 partnering on this on this webinar with IP fabric because we we used IP fabric as the glue for for the data to connect  
 the dots between uh the application resources uh the  
 virtualization workers uh and the infrastructure u the network  
 infrastructure basically uh IP fabric as automated network assurance uh  
 uh platform allowed us to pull data via API for all the mechads tables to be  
 able to use that data as the glue between what we had uh on one side and the other side. So application CMDB and  
 the network uh infrastructure and open shift um they resulted in pretty much simple  
 script that you can use go to the API of IP fabric and can get all the data  
 basically get the exact edge of where it’s connected what and connect it all  
 the all into one picture. Martin, listening to you, it’s very  
 interesting to me because I’ve been speaking with large Fortune 500 companies for for the past few years and  
 it seems, you know, that this issue with operating in silos and having data in  
 multiple different places. They’ve always had it. They always knew it’s a problem and they always were figuring  
 out workarounds or it wasn’t being tackled proactively. So I hope that now  
 as this AI op starts picking up, people will finally have a reason to uh move away from this and really figure out a  
 way to standardize everything. Yeah, definitely. And I agree with you. I mean silos are a big issue, right?  
 When when you have siloed data and you don’t have the the overall picture, you you cannot achieve anything because you  
 will have blind spots. You will have gap in in the in the logic in correlations that AIO ops needs to do. So literally  
 you have to have uh some level of standardization some level of uh visibility and and the better you  
 standardize the better visibility that you have u from on-prem infrastructure  
 up to the cloud the better you can do with with implementing AI ops.  
 Um on the next slide basically uh what what is next right when you have the dependency map what is actually the next  
 step so I’m I mentioned multiple times uh uh something um like automated  
 remediation uh for that you have to go you you can  
 go with uh well from the mapping into the action for us uh the chosen platform  
 was anible uh where basically you have an event, you have correlation of events  
 to incident and then then you can have uh or make datadriven smart decisions  
 and just go and and trigger event- driven automation to remediate um which with that you are basically uh  
 reducing the toil as as as uh much as you can and and you can keep adding to  
 that. uh and also you have basically contact context level automation that  
 that that can resolve things for you. So you are basically moving or this is the  
 first step where you are moving from reactive to to automated or to proactive eventually. So that’s the next step  
 there. Um I would just maybe uh summarize it from my side with key t  
 takeaways here. Uh what you need to do you have to reframe your goal. uh you  
 have to aim for um intelligent automation rather than some  
 mythical all knowing AI that is a black box that you plug in and and all your uh  
 things are being sold instantly going to the AIOS is he have a lift  
 that’s for sure but it is achievable you have to start with the foundation you have to uh you have to uh rather than  
 building complex auto complex a platform uh you have to start with the dependency  
 map. You have to understand what you are actually going to connect what what what context you need to provide. Uh then for  
 the data that you already have, find your glue. Uh as I mentioned for us it was IP fabric but find find a glue that  
 that can do it for you. Then when you have that glue, you have the dependency map, start stop start building on top of  
 that. So when you have the foundation, start building on top of that. Start with automating with context and then go  
 uh to the proactive. Having the automation with context, having some automated remediation will remove the  
 toil for you. And with that um with that you actually can uh invest  
 more time in in going proactive, going smart and going with with new tools. Nowadays with with the boom of uh LLMs  
 and AI agents, it’s even uh easier than before.  
 And Martin with implementing this uh in your infrastructure and your teams  
 starting use to use it would you say that of course you save time you make  
 things more efficient but is this unlocking some new interesting processes  
 or things that you weren’t doing before in general? Uh certainly it it uh identifies some uh  
 uh data quality gaps where we need to address those with standardization as as  
 we mentioned. Uh what it what it opens on on the processes side. Um  
 being proactive breaking down the silos as well. uh but being proactive really identify maybe uh uh circle the  
 dependencies where where where you have uh basically chicken egg problem and and  
 you are creating infrastructure that is impossible to to recover from a failure  
 uh that that all can be done with uh with well code and and some some further  
 analysis. So those are the new things that that it unlocks for you or for us. Uh and u well I think that that’s the  
 major thing. Um there is many more but you know it’s small things here and there that that it unlocks and and it’s  
 actually uh eye opening when you when you see something like this in action that you see uh context that you you  
 didn’t you couldn’t see before. Thank you.  
 Thank you. Thank you for that question. Um, and let me open up this slide. So, we take it’s  
 it’s your time. I guess it’s my time. So, uh, I think, uh, what you said as the last  
 thought is a nice intro to what we’re doing because it’s really about being proactive and Martin, we’ve been working  
 together with you and with Redhead for the last three years where IP Fabric was always used as a baseline for  
 automation. The reason I’m saying this is that uh most of the people that  
 listen right now are probably just thinking about AI ops or maybe just doing the initial research. But IP  
 Fabric is very relevant. If you’re not there yet, maybe if you’re just thinking to automate or if you’re thinking about  
 observability because all of these new trends, what they have in common is that  
 you really need a solid standardized data set to make them work. And you have  
 multiple options how to approach this. You have options to uh start writing your scripts on your own or just  
 collecting very specific data or to get a tool that will do it for you and  
 really accelerate your development because you don’t need to think about uh this part and you can immediately get to  
 a point where you are you have the data and you can start working with them.  
 So what this look like if I  
 let me this is screen two. Perfect. So what this means is that you get one  
 tool which gets information from all of  
 your islands from of your all of your silos. I have my AWS here. I have my Azure, my F5 load balancers, my VMware  
 NSXT, my firewalls, and all of this is ready for you out of the box to uh start  
 working with it. what we what Martin was talking about with you know the information about the hosts about the  
 ARP tables uh this is not just a list of devices but there is hundreds and  
 hundreds of pre-colcted tables uh that are very relevant to give context to any  
 of the advanced initiatives that uh you may have uh Martin was talking about ARP  
 table which I have here uh but for the ones that are not so advanced Usually  
 the first step in automation or probably the first step in leveraging AI would be  
 tell me what problems I have. So for to understand this first you need the data  
 and then you need to put the logic in. And sometimes you can even just use IP  
 fabric where if I just put one example uh we’re just working with a customer  
 where after they run the first discovery and we went to this table they noticed  
 why do I have V1 here? We just failed an audit. Everything should be V3. So if you get a use case like this, you can  
 just use IP fabric directly to make your intent check. Tell IP fabric my intent  
 is if version is  
 V1, make it red or in this case make it green if it’s V3 because this is what I want. And make everything else red. So I  
 can just easily use a tool like this to  
 quickly proactively validate my network. And this saves me a lot of time because now  
 I can action all of these insights. I can uh feed them to my AI or automation  
 logic and I can get the results based on this. So really accelerates all of these  
 projects. Uh while we’re at this, we can also do topology maps which I don’t want  
 to spend too much time on today, but if this is relevant, please do reach out to us or we have an online demo available.  
 But another thing that is very important for the context and for let’s say understanding uh the dependencies in  
 your infrastructure is that if you have a project where you know you will be adding a new application or you need to  
 troubleshoot you need to understand how the infrastructure actually communicates and uh how the path looks and based on  
 all of that data that we collect we can show you I can say okay this is my IPA  
 this is my second IP I can be much more specific specific  
 and now from the perspective of getting a context I immediately see this is where the device is connected it’s being  
 blocked by this firewall and  
 because IP fabric really is a in-depth data platform we also have the historical views so I can then go back  
 in time you see that now I’m looking at the network after the change and I can say how did this look before the change  
 and now I can dig deeper. I can evaluate. I can overlay immediately. See that I  
 don’t need to open that firewall because someone actually changed the route here. And all of these things are very  
 relevant for you to complement the standard reactive tooling that throws alerts at you. But it’s very hard to get  
 to the analytical part. And this analytical part is what will be required by all the upcoming AI initiatives to  
 actually give you the value. And we take now that you you showed that  
 you you can have the intent based checks and uh comparing the snapshots  
 uh I spoke about event- driven automation. So can you fire an event from IP fabric. So it says hey this  
 failed and you can do an action based on it. No, absolutely you can. Uh we do  
 support web hooks and uh there’s multiple ways how to approach this. Uh  
 the way we think about IP fabric is that we want everyone to have this one tool to go to and look at information. But at  
 the same time, we respect the fact that specialized teams have their own dashboards. It can be graphana, can be  
 zabix, can be solar wind that they already fine-tuned, have some workflows in there. So everything that I’m showing  
 can be gathered through API even this end to end I can just get the API documentation right here every check so  
 for instance we do have customers if I just stay on this screen that use IP fabric to validate segmentation I can  
 just say if I go to post change here I see it’s being blocked I can say this is correct this should always fail and now  
 after I save the path the next time IP fabric does a discovery and sees  
 uh careful someone made a bypass around your firewall just like we’ve seen in this use case you will know about it  
 thank you this is good thank you  
 I’m conscious of the time because I could keep talking about IP fabric  
 for a long long time we barely scratched the surface but I think really The key  
 takeaway is don’t think think about how you can  
 collect data. There’s a lot of tools that can already do this for you. They can integrate to your service now to  
 your netbox or you can just use them uh on their own and this will save you many  
 months of development.  
 Okay. Um, we’ve got plenty of time here for questions and um, I would encourage  
 people that have any questions to uh, enter them now in the Q&A tab. I I have a couple um, that I’d like to ask and we  
 had one that did come in through the chat, but uh, preferred vehicles to put them in through the Q&A. Um, but uh,  
 just to start off here, Martin, um, okay, so you talked about what you’ve done to date. You know, what’s next for  
 Red Hat in terms of uh, IP fabric data? what do you have planned?  
 So for us um well as VC was showing for us the next is is intentbased checking  
 and and uh plugging it that plugging that into those uh signals and events. I  
 mentioned that AIO ops is also about making or grouping um the individual  
 signals from the infrastructure and applications and everything. So getting those signals in as well is is one of  
 the next steps for us. Um, for us it’s also uh getting more out of the out of  
 the API and and filling in more data into into uh the dependency map. So when  
 the AI uh is is enriching events that are already there, it has more context  
 of what what is running where not only how things are connected but what device  
 it is, what version, everything like that. Um yeah, another question is kind of an  
 obvious one actually. So if you didn’t have IP fabric at your disposal, um you know, where would you where would  
 that leave you? What would you have to do otherwise um in terms of achieving the levels of automation you’re you’re  
 trying to get to here? Uh good question. we would have to go uh  
 look for any other tool like that or develop something our own because uh you  
 still need this level of insight and uh the well I I will keep it calling the  
 glue for for the data uh that you have from other sources and uh well it it was  
 just wiser for us to go with IP fabric than spending huge amount of time on  
 developing something custom. Yeah. Do you have any idea how long that would take you? You know, how big a  
 project that would be? Well, depending on the size of the team, but it would it would certainly take  
 ages. I it’s I mean with the variety of of uh uh platforms that we have and and  
 you know maintaining everything for each platform when code changes you have to change something um yeah that I don’t  
 want to Martin I’m still sometimes using what you told me a long time ago when we were  
 initially talking together and you told me how you’re planning to you know  
 increase what you’re automating and you were saying that many of your tools have native API but you don’t have this for  
 your legacy infrastructure and you told that you see IP fabric as an API endpoint for your legacy network and I  
 really like that. So this is something that stuck with me. Yeah. Um that that’s uh a good quote to  
 be honest because we don’t have that legacy network anymore. Uh as as you said we we use IP fabric for quite a  
 long time but we still use the API endpoint. uh it’s it’s just  
 with with S sur way of working and AI ops nowadays uh it’s it’s just nice when  
 you can hit an API and get the data that you are looking for.  
 Okay, we had a question that came in earlier which is um how can IP fabric discover telco provided provider edges  
 for MLS? Uh I’m going to just talk about how IP  
 fabric discovers in general. uh we we we had just a little bit of time so this was more of a sneak peek but uh this is  
 what makes us unique because we don’t use any SNMP we don’t use any IP scanning anything like this but this is  
 really based on a best practice of what a CCIE engineer would do if you ask him please uh map my network so we are using  
 SSH for the legacy devices and then we’re using API for the devices that do  
 support API and we usually only need few starting points where we connect to  
 device number one. We see there’s CDP here. We see there is a routing relation. We look into the ARP table. We  
 think this MAC looks like a a Cisco router. Let’s connect there as well. So,  
 we don’t try to blindly go everywhere. But it’s very efficient and very accurate. I’ll be happy to talk about  
 this later with you. Yeah. I guess the takeaway is you’re going to do what an expert CCIE person  
 would do in terms of probing the network. I got you. Yeah. Um, another question came in here. I’m  
 going to just read it verbatim. Um, is there a common sweet spot you see for enterprise customers taking snapshots of  
 their network to best help assure intended state? In other words, snapshots every two hours, every four  
 hours. I have an answer, but Martin, I’m curious. What is your approach?  
 How many time do you do  
 snapshots? Let me try to remember from top of my head. I think currently we have  
 full snapshot every four hours and do on demand snapshots when we need  
 in between. In general, we can discover let’s say 2,000 switches, routers, firewalls  
 within 20 minutes. So it it it’s very fast. Uh I would say the best practice  
 is uh two times maximum three times a day uh to to do a very large snapshot  
 and this is usually enough you know just to compare the state and so on. Then of course you can do smaller snapshots uh  
 before a change after change and so on. All of this can be triggered through API  
 as well. Hi, we just had a question pop in here  
 via the uh via the chat. Um, so this is  
 directed at you, Martin. Um, and I’m going to read it verbatim. How many do you have? How many interfaces? How many  
 vendors? How old is your network infrastructure? How many hosts?  
 There’s a lot of questions there. Quite specific. I will try to answer uh  
 without going into into the uh knowledge base that we have  
 uh or the DCM that we have. Um number of network devices  
 um I think it goes with couple of thousands. Um  
 did in well in addition of that access points and other other network devices  
 as well or appliances you just uh multiply that by default  
 number of interfaces I I don’t know from top of my head to be honest how many interfaces uh when it comes to the  
 number of vendors we we intend to be multi vendors so we have multiple vendors two to five depending on what  
 you count into that um how fault is the infrastructure um as  
 as old as as we can stay with uh being compliant. So so everything is uh under  
 support. So um basically the usual life cycle  
 um and I think that that’s probably what I  
 can tell um at this moment. Yeah, which by by the way this life cycle piece uh was one of the aspects when  
 Martin was testing IP fabric uh back be back before you were the manager right  
 Martin? It was some time ago. Uh so we do have the end of life information out  
 of the box as well. So I know that this was another thing that you back then was  
 impressed by saying how much time it saved. Um VTEC I had I had a question for you.  
 Oh, I’m sorry. Somebody No, go ahead, Steve. Yeah, VTEC, I I just was wondering, could you just elaborate a little bit  
 more on the specific types of dependency mappings that you maintain, not, you  
 know, more more based on okay, these types of mappings versus these rather than, you know, enumerating  
 all of them in those different categories just to give people a better feeling for, you know, what those mappings are. Yeah, I would say that  
 dependency map is the let’s say one step above uh what IP fabric gives you. It  
 gives you hundreds and hundreds of uh standardized parsed information. So if  
 you have a question about how is my AAA configured, if you have a questionnaire, how does my 1x look? Uh uh how is my BGP  
 configured? What is my global route table? all of that you have one place to go and it doesn’t matter if you have uh  
 one vendor in infrastructure or if you have five it is all standardized ready to be used and then with the dependency  
 maps you know we we do know about all the hosts we do know how they’re connected we can show you if the path is  
 redundant uh so this is right there in IP fabric uh sometimes it makes sense to  
 use the integrations we have with tools like netbox or service now and really use this as a baseline and still enrich  
 it with some other sources as well that we can’t get directly through the command line of the devices.  
 Okay, we got another question in the chat here. Um, interesting question. Martin, what functionality do you see as  
 a gap in IP fabric? I guess asked another way, you know, what would you like to see IP fabric add to the uh the  
 product capability? Yeah, thank you Steve. Um, it’s pretty good question and and as you said, I I  
 wouldn’t call it a gap. maybe um um something that we would like to see going forward and we actually are  
 planning to submit some of the requests for features with IP fabric. So as I  
 mentioned we are using MAC address our tables to collect a lot of data but we  
 are also planning to go even step further with LLDP and and well XDP  
 protocols. uh and we we like some flexibility there of uh the the custom fields that you can  
 use within the LLDP to to to have IP fabric to parse those. So definitely one  
 of the RFPs that we are going to uh submit but you get the the the basic information is there. Um I think it’s  
 sufficient for most of most of the companies but for us we we just require that cherry on top with being a little  
 bit more flexible. Um and nowadays what I would like to see  
 definitely uh support for MCP server uh with with agent ops uh becoming a thing.  
 We are talking about AIOS but now it’s it’s also a term agent ops. Uh it it’s  
 definitely going to be helpful with if we can get um MCP server that will be  
 natively supported by IP fabric that can connect and and provide context for your LMS. Mhm. uh we m Martin maybe from this  
 perspective this is something we’re thinking about we’re still evaluating the best way to add you know support for  
 AI into IP fabric because we don’t want to be another v vendor with just uh  
 improved chatbot calling it AI with the the GUI and IP fabric is very  
 straightforward it’s easy to get data but uh something like what Martin described is definitely what we’re  
 considering for the future of the tool All right. I think um I think this is  
 going to be a wrap. I think we’re heading up about 40 minutes after the hour here. So um um I’d say I’ I’d like  
 to conclude, but um before we do that, um I believe we’re going to put some information in the in the uh chat for  
 folks who want to follow up and learn more about Red Hat and about IP Fabric. So I think there’s a a set of links  
 there that have just popped into the chat. by all means access those. Also, um the folks at um IP Fabric will be  
 following up with all the attendees. So, if you have any other, you know, specific questions, technical questions,  
 business related questions, by all means, um feel free to to ask those. Um  
 so, in conclusion here, I’d like again to thank Red Hat, thank I fabric, uh  
 specifically thank Martin and VTEC for taking the time with us today, and thank you all for for tuning in. um those of  
 you who just tuned in live and those who are you’re going to catch this via the replay. And um I think that’s it and I  
 will call that a wrap. Um look forward to having everyone back here for our  
 next ONG webinar somewhere down the road. Thank you. Thank you.

### 3. Rethink Hiring Practices

AI is forcing us to consider where humans can add the most value. Look for people able to translate digital infrastructure decisions into business outcomes, as they can give AI the context it needs to be useful. We should also consider data interpretation and long-term strategy as key factors in the hiring process, alongside technical skills.

Transcript Thank you Matt. Hello everyone. Welcome  
 to this session. My name is Timcraft. I  
 am regional sales lead for IP fabric. I  
 just celebrated my seventh years at this  
 lovely company and this is actually my  
 sixth attendance at the Cisco live. Uh  
 not to brag but we are quite a  
 celebrity, a local celebrity with my  
 solution architect uh after our standout  
 performance last year at the live  
 karaoke but it’s another story. Uh I  
 remember my very first attendance at the  
 Cisco live. was back in 2019 in  
 Barcelona and we had a very small hidden  
 booth and we were desperately trying to  
 catch people attention and try to  
 educate them on our uh emerging  
 technology and now I see today it’s the  
 fourth time in a row that we are diamond  
 sponsor of the event we have a very  
 large and central booth in the world of  
 solution so it’s really with a great  
 pleasure and a bit of pride that I’m  
 presenting today with Andre and Kelvin  
 from entity data the result of our  
 partners ship in the AI ops space. So  
 guys, it’s no surprise we’re going to  
 cover AI today. Like almost all session  
 you’re going to see this week,  
 AI is in the mouth of every single CIO,  
 partner, vendor, your leadership is  
 requesting you to leverage AI  
 capabilities in your process to increase  
 the efficiency. But we see two main  
 challenges to that. First of all, how  
 can you trust the model? How can you  
 trust the data? How can you base your  
 important IT decision on a model, on an  
 output that you don’t fully trust? And  
 second of all, how sticky will become  
 the AI in your process if it’s artifici  
 artificially plugged into your process  
 in your tool without a real problem to  
 solve. And this give us a lot to think  
 about and raise a fundamental question  
 which is guidel guidelining this  
 presentation today. So if you are  
 intending on leveraging AI as part of  
 your process, I want you to consider  
 this.  
 Is AI the means or the end?  
 Am I adopting AI for the sake of the AI  
 adoption or is AI the perfect tool to  
 fix a problem worth solving?  
 And this is exactly the second approach  
 that took entity data. They had concrete  
 issues in the managed service space and  
 AI became the logical answer to answer  
 that. So today I’m going to let Calvin  
 and Andre present you um first of all  
 the challenge that raised this whole  
 initiative then the journey they took  
 and finally the result of their  
 development effort into the beline  
 platform that they are launching. Over  
 to you Andre  
 thank you very much Tilman. I think like  
 many of you I started my career in  
 frontline operations. I finally remember  
 doing L1 network support and Windows  
 3.11 support back in Port Elizabeth Port  
 Elizabeth South Africa and I think many  
 of you just thought Windows 3.1 what yes  
 it was a very long time ago since then  
 I’ve always been in frontline operations  
 and this is where our journey starts  
 frontline operations I was joining a  
 late night major incident call where  
 plan change had an unintended outcome we  
 cause a site isolation and I was  
 thinking surely this is where I AI could  
 assist us to a do a far more  
 comprehensive and thorough change and  
 impact risk assessment and B if  
 something does go wrong accelerate root  
 cause analysis. 60 to 80% of service  
 impacting incidents are caused by failed  
 changes. What if we can make that less  
 than 10%.  
 Beline was born out of real operational  
 needs, real nights on real bridges, not  
 a top down AI strategy set by  
 executives. Although to increase  
 efficiency and reduce cost, although  
 those are side effects, it wasn’t the  
 main driver.  
 our dev journey. Um, in my mind, this  
 was going to be easy. We got data  
 sources, slap the LL on top of it, Bob’s  
 your uncle. Then we started planning and  
 we quickly ran into some interesting  
 roadblocks. Now, I’m not going to say  
 much more about our dev journey today,  
 but you can join us in the IP Fabric  
 booth later this week. We will do some  
 more behindthescenes stories and demos.  
 What I will say is this. IP Fabric’s  
 digital twin and snapshot technology did  
 make this entire journey far more or  
 less complicated for us especially since  
 one of our core design principles from  
 the beginning was to be vendor agnostic.  
 Introducing Beite. All I want to say  
 here is we made this for engineers to  
 make their lives simpler, better,  
 faster. Less grunt work, less fewer  
 mistakes, more time solving problems,  
 less time digging for them just doing  
 engineering work.  
 And now, are you here? We’re going to do  
 some use case demonstrations today.  
 Unfortunately, they can’t be live today,  
 but like I said, we’ll do some live  
 demos later this week in the booth. For  
 the first one, I will be an L1 engineer  
 doing an incident ticket. For the second  
 one, Calvin will do a more complex  
 change planning for ISP move.  
 Think again.  
 And again. So, here we have our ticket.  
 All I did here was ask Beline to do a  
 root cause analysis. And I copy and  
 pasted the service now information into  
 the ticket. A user can’t access an  
 internal application. Yesterday it  
 worked. Today it didn’t work. And all  
 the necessary other information within  
 the ticket. The user move desks. They  
 change switchboards. They move back to  
 Wi-Fi. No, they don’t know which network  
 they’re on. And obviously the browser’s  
 connection timed out.  
 Here we got Beline coming back. We  
 should get a nice pass analysis. And now  
 we can see that the prog firewall is  
 blocking the traffic. And if we look up  
 at the details, we’ll see the policy  
 firewall policy that’s also causing this  
 problem. Now we know what caused it. We  
 need to know what changed this behavior  
 in the network in the first place. So  
 what we’re doing now, we’re asking  
 beline to check for configs, config  
 changes that could have caused this. So  
 in the background, Beline is pulling  
 some some rag information, doing some  
 conflict diffs, and we should get a  
 summary back in a second where we see  
 which firewall change it was and what  
 has been removed and what’s been added.  
 We should see HTTP removed and we should  
 see HTTPS now being the only protocol  
 being allowed.  
 And there we have it, a nice description  
 what is there, a nice summary at the  
 bottom. Now we can go back to the user.  
 Tell them to log a new request with the  
 security team. Case closed. over to you.  
 Thank you, Andre. Okay. Um, so as Andre  
 mentioned, I’ll be running uh a change  
 formal change planning. Um, my use case  
 is a little bit more open-ended and, uh,  
 hopefully I can show how Beline can be  
 useful to an engineer planning a formal  
 change. Andre, if you want to go ahead.  
 So, to start with, um, what we’ll do is  
 I’ll ask Beline if it can pull a site  
 diagram for me, um, and explain the  
 connection to the MLS cloud. So yeah,  
 what we’re looking for is just a nice  
 clear diagram of the site, something  
 that we can get a quick handle on what  
 we’re working with. Um, and an  
 explanation of the MLS connection uh to  
 the MLS cloud. So would be nice to have  
 some interface information, maybe some  
 IP addressing, um, just some basic info  
 about this connection.  
 We should get a response in a few  
 seconds.  
 Here we go.  
 Okay, so obviously the diagram uh here  
 we go. Nice clear diagram shows us D5X1  
 is the breakout to the MLS cloud. Um and  
 in the summary there we can see there is  
 some interface information. GI01  
 uh is the interface and there’s a subnet  
 being used for this link. Um at this  
 stage I’m going to give Elon a little  
 bit more context. Tell it we’re cutting  
 over to a new telco for the Helsinki  
 site. I’ve told it which device and  
 which interface the new telco will uh  
 terminate on and I’ve asked it to go and  
 suggest some IP addresses we could use  
 for this new link based on the current  
 configuration. So obvious output here is  
 we would like a /30 uh subnet to use. Um  
 but something that’s important is uh  
 you’ll see there’s a show tool use  
 toggle at the bottom. Um, I need to make  
 sure that Beline is checking the actual  
 configuration of the device so we know  
 that the answer is grounded in reality,  
 not just a hallucination. So, I’ll wait  
 for it to finish and then we’ll see  
 enable that toggle.  
 Okay, so we’re looking for a  
 configuration rag call up there. I can  
 see it has queried the correct device.  
 So now I know that its answer is  
 grounded in reality and we did get a 10  
 1 0212/30  
 as the suggested network. So very nice.  
 Um now I’ve asked Beline if it can  
 explain the routing configuration to me  
 uh specifically in relation to the MLS  
 cloud and to break it down by routing  
 protocol. Um as this is a demo  
 environment I obviously know that the  
 primary routing protocol in UCI is OPF.  
 So what we’re looking for is a nice  
 clear description of that OPF  
 configuration, some details about that,  
 and then just a summary of the other  
 routing protocols at play. So we should  
 get our response in a second.  
 Here we go. In the summary at the top,  
 we’ll see that MLS is primarily  
 connected via OPF. Um there’s a nice  
 summary of the OPF configuration. Um  
 some details about it, and then the rest  
 of the protocols are listed thereafter.  
 Um,  
 now based on all of this uh context that  
 we’ve gathered, all of this  
 investigation that we’ve done, I’m  
 asking beline if it can provide me with  
 some CLI commands, something we can just  
 copy and paste and we could put it in a  
 runbook and we could use this uh as part  
 of the change to just apply this new  
 switch over to this new telco. So, what  
 I’m looking for here, obviously um it  
 needs to be correct, but I’m also just  
 looking for something easily copy and  
 pasteable. So we’ll see in the response  
 I get a nice config block that we can  
 copy and paste. Um it’s using the  
 correct interface. There’s a  
 description. IP address looks good.  
 Subnet mask  
 and some additional details. So  
 as a final test what we’re going to do  
 is I have got a a config block that um  
 I’m asking beline to validate for me. So  
 in this situation I’ve given it some  
 commands and I’ve asked what would be  
 the impact of applying these commands to  
 the device and specifically I have  
 corrupted the subnet mask on this this  
 configuration. So instead of a slash30  
 I’ve given it a /24. I know that’ll  
 cause problems. I’m expecting beline  
 will highlight that for us. So let’s  
 see. Uh at the top it does give a nice  
 little description to say you know the  
 primary problem is the /24 mask. it  
 overlaps with many existing SL30s and  
 will cause serious routing and  
 forwarding conflicts. It then goes into  
 details on each of the other additional  
 areas of conflict. And there’s a  
 recommendation at the bottom to don’t  
 use a /24, use a SL30. Um hopefully with  
 that very quick and very simple use  
 case, you can see how Beline could  
 assist an engineer with planning a  
 change, validating commands, and  
 hopefully just make their lives a lot  
 easier.  
 Tman, back to you. Thank you Calvin. Um  
 so we clearly can see that this is for  
 engineer and I guess it’s more in a  
 managed service context but who is the  
 audience for this? Is it for your own  
 entity engineers operating large and  
 complex customer environment or it is  
 also for the end customer to have better  
 better visibility?  
 So like I mentioned first and foremost  
 this is to enable our engineers to work  
 simpler better faster. However, we are  
 planning a client front end which will  
 probably release in quarter three this  
 year. So if we are do have a managed  
 service with with entity, you’ll  
 probably end up with a client front end  
 as well later quarter 3 quarter four  
 this year. Super  
 but like I said it’s for the engineers  
 first enabling our teams  
 of course and maybe another question for  
 you Calvin because you have developed  
 this this platform and I’m sure you have  
 been through up and down. if you have  
 few lessons learned to share with the  
 audience  
 regarding leveraging AI and trying to  
 build something out of AI.  
 Yeah, absolutely. So, um I’m not going  
 to get into a deep dive of the  
 challenges or the architecture here, but  
 if you’re interested in that, come to  
 the booth. Um, but I will say that this  
 MCP agentic AI solution is definitely  
 the bleeding edge of technology and if  
 you are going to get involved with this  
 be prepared for multiple updates to  
 dependencies every day. It is a  
 extremely rapidly evolving space and  
 just uh trying to keep up has been a  
 challenge.  
 Super. Thank you guys. We are slowly  
 heading towards the end. I wanted to  
 wrap up. Another question for you uh  
 Andre, how do you envision the future of  
 this beline platform?  
 If you look at our future platform is we  
 definitely want to add more data sources  
 like data is everything. We’ve built the  
 engine the model. Um and we’re going to  
 add an agentic AI agent on top of this  
 to to validate service now tickets  
 before it comes to the engineer. So get  
 into the pipe sooner. So by the time  
 engineer receives a ticket, Beline would  
 have analyzed it already. So instead of  
 copying and pasting, we’re just going to  
 plum it straight in from Service Now. So  
 we’ll have a agent check those tickets.  
 Okay, cool.  
 Guys, if you want to see a bit more of  
 this beline platform if you want to see  
 it live and see the extent of the  
 platform and ask any question as Andre  
 Cavin was saying, we’re going to have  
 two uh invoo platform um sessions. So  
 one in on Wednesday at uh 1:30, the  
 second one on Thursday at 11:00. So feel  
 free to come and ask uh Andre and Calvin  
 every question that you have. If you  
 want to reach out directly to us, feel  
 free to to come after this session or uh  
 you can invite us on LinkedIn and we’ll  
 be more than happy to discuss your  
 concrete uh case and situation. So now  
 we wanted to thank you for your  
 attendance. We wanted to wish you a very  
 nice and interesting Cisco live. And for  
 those who would like to be interested in  
 other type of performance, I say I see  
 you on Thursday for the live karaoke.  
 So, thank you very much.

### 4. Treat AI Literacy as a Critical Skill

It is essential for all employees to develop AI literacy so that oversight can keep pace with automation. Understanding how AI behaves is just as important as financial or operational literacy.

Do your employees know what tasks AI should and shouldn’t be used for? Do they know what “good” AI outputs look like in any given scenario? Do they know when and how AI needs human guidance? Leaders should invest in training programs to teach their employees how to answer these questions, and to work most effectively with AI.

Transcript Welcome everyone. Today I’m going to  
 demo some of the uh capabilities that  
 we’ve created using uh an internal  
 self-service portal kind of mimicking  
 what you probably are already running in  
 your environments or if you’re not using  
 a self-service portal, you know, the  
 Ansible playbooks or Python scripts or  
 or things like that um to automate some  
 commonly done activities. We’re also  
 going to show how you can better utilize  
 the the technical stack that you’re  
 already working with. Um, so you can see  
 at the top of this internally built  
 portal, uh, our IP fabric netbox  
 integration sync status. And what I have  
 here is just the ability to show what’s  
 happening um, in our IP fabric netbox  
 integration. So we have an official  
 Netbox integration. I can actually  
 trigger uh syncing right from my  
 self-service portal. But if I want to  
 pop into Netbox and see a little bit  
 about what that looks like, I can see  
 I’ve triggered this job. So I’m here in  
 the community of edition of Netbox. If I  
 scroll down, I can see that IP Fabric  
 integration. And of course, we have tons  
 of of things that you can look through.  
 We’re going to sync that information,  
 sync all of the the network information  
 that IP Fabric gathers, which is  
 incredibly uh it’s it’s a the most  
 accurate discovery on the market today  
 because of the way that we do our  
 discovery. And therefore we can update  
 um your your netbox, your other DSIMs,  
 your CMDBs, your IPAMS, uh any source of  
 truth really um because of our  
 incredibly accurate discovery so that  
 you’re not looking at stale records um  
 and trying to you know work with your  
 compliance teams, work with your finance  
 teams, work with renewals and all of  
 that um with stale information.  
 So that’s kind of the the idea behind  
 this IP fabric netbox integration.  
 Again, we’re just bringing incredibly  
 accurate information to this source of  
 truth that you might be using. If I go  
 back to my uh self-service portal, I can  
 see, you know, again, I have a job  
 syncing already. It’s reminding me  
 because of the version that I’m working  
 with, the latest version. I can actually  
 um trigger this automatically. So I have  
 uh web hook triggers available. Every  
 time uh a snapshot finishes, I can  
 trigger it to do a sync with NetBox. So  
 we’re always constantly up todate. And  
 then branch um branching is enabled as  
 well if you’re familiar with the coding  
 term branching. So basically we can  
 branch this information and then merge  
 it into main when we’re ready when we’re  
 sure that we are ready to do our merges.  
 And maybe you saw that here. Uh you can  
 see my demo 2 is ready to merge. I’ve  
 already run a sync and and we can merge  
 that information to make sure that you  
 know we’re not working with multiple uh  
 versions of of what’s actually on hand.  
 And then to kind of tell the story a  
 little bit further, I’ll run this VLAN  
 provisioning uh service from my  
 self-service catalog. And you know, this  
 is a pretty common activity where we  
 want to just make a new VLAN available  
 on our switches in let’s say Helsinki.  
 So, I’m going to put in a new VLAN uh  
 that I want provisioned. And we’ll say  
 um new service. That’s not a great name,  
 but for the sake of the demo, that’ll  
 work. Um we’ll select a subnet. Now, all  
 of this information, especially from the  
 pulld downs, is available because of IP  
 Fabric. It’s actually pulling this  
 information from the IP Fabric APIs into  
 my self-service portal with just some  
 really easy API calls. And of course, we  
 always need a justification because  
 eventually this is going to turn into a  
 change management ticket. So I need this  
 VLAN to provision my new revenue  
 generating service  
 and then of course who it’s requested by  
 and we’ll validate with IP fabric. Now  
 here we go. We we always want to  
 validate and make sure VLAN 100 is  
 available. And IP Fabric actually says  
 that it is available. And I can pop in  
 through my deep link back to IP Fabric  
 and see what this is all about. And I  
 see VLAN 100. So why is it telling me  
 it’s not available? Well, because it’s  
 actually not um taken in the Helsinki  
 site. If you’ll recall, we chose  
 Helsinki. Um so we still have VLAN 100  
 available there. So that’s all good.  
 That’s correct. But Netbox is showing  
 that VLAN 100 is already allocated. And  
 a couple things could be happening here.  
 So maybe we haven’t done a sync recently  
 with uh the Netbox integration and we  
 need to do that sync because maybe we’re  
 seeing some stale records or a really  
 legitimate reason why VLAN 100 might be  
 showing up in Netbox is that maybe  
 another team, another person has already  
 requested that VLAN but hasn’t had the  
 change management window yet uh to  
 provision it for real on the switches.  
 So IP Fabric wouldn’t know about it yet.  
 IP Fabric knows what’s actually  
 happening on your network today. Netbox  
 is showing you what your intent is for  
 tomorrow maybe or next weekend. So no  
 problem. We’ll go ahead and use one of  
 these suggested VLANs and we’ll go  
 through the validation again. And now we  
 see, okay, the subnet that we selected,  
 the VLAN that we selected is available.  
 We could go back into IP Fabric and and  
 you know validate that. But I’m going to  
 go ahead and confirm and provision. Now  
 here I’m not actually provisioning that  
 new VLAN on my my switch interfaces  
 right what I what I want to do is  
 actually create a change request ticket  
 because you know I work for a large  
 enterprise and all of this will need to  
 go through uh during a change management  
 window and of course the first thing is  
 to get approved during for that change  
 management window. So what I’ve done  
 here is I’ve automated the uh population  
 of a service now ticket then and again  
 all of this information comes from  
 either templates from the back end of my  
 self-service portal but the the actual  
 data comes from IP fabric itself and so  
 if I scroll down I can actually see okay  
 this comes from the self-service portal  
 I entered in my justification  
 um all of the subnet information the  
 gateway information again comes from IP  
 fabric and And through templates, I’ve  
 said, okay, every time I provision a new  
 VLAN, then we need to run through phase  
 one, which is a pre-change snapshot. And  
 I already have an Ansible playbook set  
 up to do a pre-change snapshot. So  
 that’s going to be the first thing that  
 gets run in an automated way, right,  
 through an ansible playbook. And I do  
 have that set up um with Ansible  
 Semaphore here. You know, again, we’re  
 we’re working with a lab situation, so  
 this is kind of a lighter version of of  
 tower basically. But whatever you’re  
 using um for automation, whether it’s  
 Ansible or Terraform, Python scripts, it  
 doesn’t matter. Um I’m just showing how  
 this all kind of works together um to  
 make sure that you’re using the best  
 data, especially as you bring automation  
 or even AI into your regular practices.  
 And so phase two, of course, is going to  
 be the actual VLAN provisioning. We have  
 another anal playbook that’s set up to  
 do that. We have all of the accurate  
 information. Um once that those or that  
 one VLAN in this case gets provisioned,  
 then we’ll do another post change  
 snapshot again via an Anible playbook.  
 So these these IP fabric snapshots run  
 on either side of it so that we can  
 compare, make sure everything is set up  
 as it should be um as we intended, make  
 sure that things are are routing and  
 frames are moving the way that they’re  
 supposed to be. Um and then we can go  
 through and you know be feel good about  
 our changes that that happen you know  
 Sunday night or whatever. It also  
 prepopulates the risk impact uh analysis  
 um again with a lot of that information  
 that we’ve already run. Um but you can  
 see you know even information about BGP  
 neighbor state device reload reasons all  
 of our intent checks. Let me just show  
 you what that looks like really quickly.  
 Um you can see we have over 160 intent  
 checks just built in out of the box. You  
 can create your own custom ones, but you  
 could specify any of these intent checks  
 to run that would be applicable to uh  
 whatever change you’re making. And just  
 make sure again everything is copacetic  
 as you go. And it’s just a really easy  
 traffic light system uh that uses logic  
 to understand whether you are within the  
 the best configuration or you’re you’re  
 starting to sprawl.  
 And then again, we have a backout plan.  
 Of course, the change management team is  
 going to want to see that. And the great  
 thing again about IP Fabric is that we  
 have config backups already. That’s  
 another capability within the IP Fabric  
 platform. So, not only do we do that pre  
 and post change snapshot, we can  
 actually give you the configs of all of  
 your devices um individually and what  
 they looked like before you made the  
 change. So now you have basically that  
 holistic view of the entire network  
 through the snapshots and then the  
 actual configs on the devices. So we can  
 basically do a roll back and the the  
 change management team is going to love  
 to see that. And then of course a test  
 plan. So that’s all I had planned for  
 this demo today. Thanks for watching.

With every passing year, AI will become more deeply ingrained in enterprise operations. However, this won’t have the intended impact if we don’t focus on how people actually use AI. Ultimately, the leaders who integrate AI more thoughtfully will be the ones who pull ahead in the end.

*This byline was originally published in*[Fast Company](https://www.fastcompany.com/91564458/ais-most-important-capital-investment-humans)
*.*

*Want to learn how IP Fabric can help you maximize your investment in AI? [Sign up for a demo](https://link.ipfabric.io/4cr7lnK)
 today!*

## Related Resources

AI & automation

### [AI Is Turning Data Governance Into A Competitive Advantage](https://ipfabric.io/blog/ai-data-governance-as-a-competitive-advantage/)

Consider these 3 questions on data governance before adopting a third-party AI solution.

AI & automation

### [The Network Data Problem Slowing Down Enterprise AIOps](https://ipfabric.io/blog/aiops-and-network-autonomy-network-digital-twins/)

Why Does AI fail on fragmented data? And how can network digital twins help to build a foundation for network autonomy?

AI & automation

### [Network Intelligence & AI-Ready Data](https://ipfabric.io/blog/network-intelligence-and-ai-ready-data/)

How does a network digital twin help you to achieve AI-ready data?