I guess we have been there before, with waves of new technologies reaching the Peak of Inflated Expectations. As one British exec told me after a meeting over a decade ago: you are the first person in two weeks who didn’t say “Big Data” once for the whole hour.

Such keyword density and saturation of the information space make it harder to think about the real consequences of different modes of LLM adoption without falling into dismissive or apocalyptic extremes in judgment.

For example, if we take a benign and borderline boring topic like network inventory, it is worth considering what the ubiquity of LLMs means for the whole domain. So let’s try to look at it from first principles.

There is probably some advantage in choosing a boring topic here. Network inventory is unlikely to produce an impressive five-minute AI demo, and there is no obvious way to make it look revolutionary by adding a chatbot to the screen.

It is also a domain where the difference between something that looks convincing and something that is actually correct becomes rather important.

A generated paragraph can contain a small factual error and still remain useful. A network inventory containing a fictional device, interface, or dependency is a different matter entirely.

Which makes it a good test case for a more practical question: not whether LLMs can replace existing OSS, but where exactly they can make an unpleasant and complicated system less unpleasant and complicated.

Why Network Inventory Projects Become Difficult

I participated in multiple network inventory implementations, and they all had several things in common:

• It is an unhappy place to be.
• Complexity derived from the complexity of the network itself and was always underestimated by stakeholders — sometimes deliberately, to make the project happen.
• An integration nightmare: attempting to chase a moving target of ever-evolving infrastructure while carrying the burden of legacy technologies at the same time.
• A discrepancy in goals between those who are paying for the project and those who are supposed to keep the inventory up to date.
• As a result of the three points above, the system usually tends to be universally hated by both its developers and users — probably the only point on which they reach unanimity).

Once you finally cut the ribbon, the inventory you built starts degrading by developing a growing gap with reality. With determined effort, you can keep the gap manageable, although it will grow larger as the environment changes faster than you can update your rigid and complex set of integrations.

The unpleasant thing is that this degradation rarely happens because of one catastrophic event.

It is usually a collection of very normal events.

A device is upgraded. An API changes. A new vendor appears in one region. Somebody implements a temporary workaround that becomes permanent three years later. Another system contains slightly different naming conventions. A field which used to be mandatory suddenly isn’t. A network element appears in discovery but does not quite fit the data model created two years earlier.

None of these events is particularly dramatic. Combined, they create a permanent reconciliation problem.

Traditional OSS deals with this by adding more rules, more integrations, more transformations and, eventually, more people who understand why a certain strange exception exists.

The inventory becomes more capable and more fragile at the same time.

Structured Data Still Has to Remain the Foundation

The basis of network inventory will, in my opinion, always be structured data collected via deterministic interfaces. You don’t want LLMs to hallucinate some non-existent ports or sites for you.

This is probably the least exciting part of the AI discussion, but also the most important one.

If inventory is used only as a reference tool, an incorrect answer is annoying.

If inventory data participates in fulfilment, assurance, planning, capacity management or automated network operations, an incorrect answer can propagate much further.

The distinction, therefore, should probably be made between determining facts and dealing with uncertainty around those facts.

A device reporting an interface through a known protocol is a fact that should remain deterministic.

An unfamiliar object appearing during discovery, an unexpected schema variation, or conflicting information coming from two systems is a different problem. This is where reasoning becomes potentially useful.

Where an Agentic Approach Could Help

At the same time, an agentic approach could help deal with the rigidity of predefined integration interfaces. A properly configured agent could interpret the data received with more flexibility, troubleshoot integration errors, enrich changes requiring manual verification with context, and assign confidence scores to inventory changes requiring human approval.

An agentic approach to discovery is yet to be proven as a working solution, but it has the potential to remove one of the key bottlenecks and limiting factors in solution adoption: accurate and reliable data discovery.

This does not necessarily mean allowing an AI agent to directly rewrite the inventory whenever it sees something new.

There is a much less dramatic and probably more useful role available.

Imagine an automated network discovery process encountering a device which mostly resembles a known model but contains several unexpected attributes.

A conventional integration will normally either process it according to predefined rules or fail.

An agent could take another route: identify the closest known model, describe what is different, compare it with previous discoveries, suggest a mapping and mark the result as requiring verification.

The same applies to integration failures.

Instead of giving an engineer an error message and several thousand lines of logs, the system could collect the relevant context and say, essentially: this integration worked yesterday; today this object has a different structure; these three fields changed; this is probably why the import failed.

Not autonomous OSS. Just less stupid OSS.

There is considerable value in that.

Confidence Might Be More Useful Than Full Autonomy

It also seems reasonable that AI should not participate equally in every inventory operation.

If the same interface on the same type of device has been discovered in exactly the same way ten thousand times, we probably don’t need an LLM to admire it once again.

Where agents become useful is at the edges.

New object types. Conflicting information. Unexpected relationships. Discovery results that do not fit the existing model. Cases which today end up in somebody’s queue because the system itself cannot make sense of them.

Her Majesty the End User

Another peculiar aspect of a network inventory project is Her Majesty the end user.

Due to the objective complexity of the network mentioned above, the learning curve might become so steep that, at some point, a user able to navigate and use the tool is seen as a magician not only by colleagues, but even by the product vendor.

As the project grows, it becomes so convoluted and loaded with detail that it scares potential users away. Using it without training and extensive on-the-job practice becomes practically impossible.

This presents another opportunity to use AI to improve the adoption and usability of traditional OSS. If the user is presented with an assistant that helps them navigate through the system while also being able to respond to specific queries about the network in a chat format, the tool suddenly becomes much less scary and more usable for a wider user community without extensive training.

And this might actually be one of the easier wins.

A large part of the difficulty in using a complex OSS product comes not from lack of data, but from having to understand how the product expects you to search for that data.

Users do not naturally think in database objects and product navigation structures.

They ask questions.

Which services depend on this device?

What changed at this site last week?

Why does the discovered equipment differ from what we have in inventory?

Which customers could be affected if this link disappears?

All the necessary information might already exist in the system. The difficult part is knowing where to find it and how several different objects have to be combined to produce the answer.

A conversational interface can remove some of this friction without making the LLM the source of truth.

The model interprets the question.

The structured inventory provides the facts.

The user receives an answer without first acquiring several years of highly specialised knowledge about where somebody decided to put a certain button.

This seems rather more useful than asking AI to generate another dashboard.

AI Makes Accurate Network Inventory More Important, Not Less

There is also a slightly ironic consequence of the current movement towards agentic telecom operations.

The more autonomy we expect from software, the more important it becomes that the software has an accurate understanding of the network.

An agent deciding how to resolve a problem needs to know which resources exist, how they are connected, which services depend on them and what the consequences of changing something might be.

In other words, many sophisticated AI use cases quietly depend on the same old problem of having reliable inventory data.

Human operators can compensate for imperfect systems surprisingly well.

They know that one particular database is outdated. They remember that a naming convention means something different in one region. They know which topology data should not be trusted after a migration.

An AI agent does not magically inherit this institutional knowledge.

If its model of the network is wrong, greater autonomy simply allows it to act on wrong information more efficiently.

So perhaps AI does not make traditional network inventory obsolete.

It creates another consumer which is even more dependent on inventory accuracy than the humans were.

From “AI-Powered” to Actually Useful

The more useful way to think about this is not as an “AI-powered network inventory”, but as a traditional inventory system with fewer rigid edges.

The core remains the same: structured data, deterministic interfaces, explicit topology, and controlled updates. What changes is how the system deals with everything that does not fit neatly into those predefined paths.

Discovery can become more tolerant of changes in external systems. Integration failures can be analyzed with more context instead of simply producing another cryptic error. Suspicious inventory updates can arrive together with an explanation of why they were flagged. And users can ask specific questions about the network without first learning every corner of the product interface.

In other words, the value is not in replacing network inventory with AI, but in using AI around the parts that have traditionally made these systems painful to operate and maintain.

That does not make the network less complex. It does not remove the need for accurate structured data or disciplined inventory management either.

But if it can make integrations less brittle, troubleshooting faster, and the system itself easier to use, that already addresses several of the reasons network inventory projects tend to become so difficult over time.

Conclusion

While LLMs cannot replace structured data discovery in a reliable OSS solution, the adoption of AI agents can help transform such solutions into something more usable and maintainable. It can also reduce some of the traditional difficulties involved in keeping network inventory accurate and reliable.

And perhaps this is one of the more realistic directions for LLM adoption in telecom OSS generally.

Not replacing systems which already perform deterministic tasks perfectly well, and definitely not asking an LLM to invent the network topology for us.

Instead, putting intelligence around those systems where humans currently spend considerable time dealing with exceptions, interpreting inconsistencies, navigating unnecessarily complicated interfaces and figuring out why something that worked yesterday has suddenly stopped working today.

Less revolutionary, admittedly.

But probably rather more useful.

The post AI Agents and Network Inventory: What Can LLMs Actually Change? appeared first on Globberry.

The post The Future of Software Development in the Age of AI Coding appeared first on Globberry.