Knowledge Used to Be Power. In the AI Era, there’s a New Advantage

Since OSS were first built, they’ve been designed around the belief that more complete information creates better operations.

That belief made sense when they were designed by Engineers for Engineers.

When network, service, customer, inventory, topology and assurance data was scarce, fragmented and hard to access.

The organisation with the best information usually had the advantage. If you could see more, correlate more and understand more, you could operate better than competitors that were still piecing things together with spreadsheets, swivel-chair processes and disconnected systems.

But AI is highlighting a massive strategic shift. One I’m patently aware of, but still making blunders on, even as recently as the last few weeks (more on that later).

We used to say information was power. But data is no longer scarce.

The scarce resource now is the operator’s time, attention and confidence to act.

Decision speed is the competitive advantage (realistically, it probably always was).

.

Lesson 1 – More information doesn’t automatically create better operations

Similarly, much of traditional OSS design has been built around completeness of knowledge.

More alarms. More inventory. More topology. More telemetry. More dashboards. More reports. More integrations. More data sources.

More, more, more.

If your teams couldn’t see the network clearly, they couldn’t operate it effectively. If they didn’t know which services were impacted, which customers were affected or which assets were connected, they were forced to make decisions blindly, or after painstakingly piecing all the fragments together.

AI has shifted the bottleneck. Or at least it has the potential to shift the bottleneck. It also has the potential to make the bottleneck much worse!

When data is abundant, as supplied by LLM’s today, the challenge is not more information. The bigger challenge becomes, “Can someone (or something) quickly sort through the larger information pile, understand what matters and rapidly decide what to do next?”

This is where many traditional OSS environments (and traditional OSS with a new AI wrapper) start to struggle. They may provide technically rich views, but they still leave the human operator to perform the hardest part of the workflow – interpretation, prioritisation and decision-making under pressure.

Every extra screen, alarm, report or AI-generated explanation consumes attention, and potentially slows the whole process down.

In the AI era, the best OSS interfaces won’t show more. They’ll show less.

They won’t take minutes to generate verbose responses that take time to process (algorithmically and intellectually). They’ll take seconds (or less) to suggest the immediate best action to take next.

They may hide what’s irrelevant, suppress what’s low-confidence, prioritise what’s urgent and present only the information needed for the decision at hand (if they can’t already make the decision themselves).

.

Lesson 2 – AI can easily amplify an information overload problem

There’s a very real risk that AI becomes the next layer of OSS information overload.

OSS and LLMs are impressive because they can generate explanations, summaries, recommendations and context very quickly. But impressive output isn’t the same as useful output.

An AI agent that takes a few minutes to infer, then write a ten-paragraph explanation during an outage may look intelligent. But if the operator still has to read and interpret it, before deciding what action to take, then AI hasn’t removed the bottleneck. It’s simply changed the shape of the bottleneck.

AI shouldn’t be judged by how much content it can produce or even how much of a workflow it can automate. It should be judged by whether it shortens the path from signal to action. Whether it shortens the resolution of an alarm storm. Whether it makes the right decision every time.

The best use of AI in OSS may be much less glamorous than the demos suggest. It won’t be a chatbot that explains everything. It won’t automate everything whilst verbosely walking you through all its workings.

It will be successful when it quietly removes five steps from an assurance workflow. Or pre-assembles the relevant context before a human opens a ticket, allowing for rapid resolution. Or highlights the safest next action based on known dependencies, live service impacts, recent changes and past resolution patterns.

In other words, the best AI isn’t about fancy new human user interfaces. It’s about compressing workflows.

.

Lesson 3 – Start with the decision, not the dataset

One of the most useful OSS design questions is also one of the simplest:

What decision are we supporting?

Not, “What new data can we expose?”

Not, “What can the AI summarise?”

Not, “What dashboard should we build?”

But, “What decision does this help someone make faster, more accurately or more reliably?” Or even automatically!?

This mindset shift changes the design conversation.

A fault management view is almost certainly not the list of alarms or tickets we’ve built our operations around for decades.

A change management workflow won’t just be the traditional approval trail based on gut-feel from the Change Review Board (CRB). A change tool will validate whether the proposed change is likely to create downstream impact, observe before / during / after the change and help to decide to roll forward or back based on any adverse impacts it sees.

A field workforce dispatch process is not just about assigning a job from a queue. It will reason over many factors, including resources, risks, impacts, availability, time criticality and much more before deciding whether immediate dispatch is even necessary.

This is a shift from data-centric OSS to decision-centric OSS.

Data still matters. It’s the foundation. It’s not the outcome.

The outcome is better judgement at speed.

Decision-centric OSS create designs for the next-best action. They reduce ambiguity. They present options clearly and concisely. They make confidence-levels clearly visible.

They help people understand not just what’s happening now, but what they should do next.

.

Lesson 4 – Decision speed compounds (positively or negatively)

As we discussed in the previous article, this is also why slow OSS procurement has a bigger opportunity cost than many organisations realise.

A new OSS is not just a system purchase. At its best, a new OSS can be a massive decision-improvement engine.

It improves effectiveness (eg how teams detect issues, interpret signals, prioritise work, assess risk, coordinate activity and learn from operational outcomes). Every day that decision quality improves, the benefits compound. Teams respond faster. They make fewer avoidable mistakes. They reduce duplicated and/or manual effort. They learn which recommendations to trust and which workflows still generate friction.

But when organisations take months or years to procure, evaluate, negotiate and implement a new OSS, they’re not only delaying functionality. They’re delaying the thousands of operational decisions that could’ve been clearer, faster or better during that period.

This is why decision latency should become a more important OSS metric for us to judge ourselves against.

This is the big factor I need to keep front-of-mind too. My blunder over the last few weeks is an example of needing to continually refine and improve on this.

I’m not a fan of documentation. I figure it’s only useful as a coordination and communication tool, especially if it’s created once and used many times and/or by many people. When starting a new project, I try to create collateral that helps the rest of the team to understand the project context, their roles and activities, allowing them to get rolling quickly.

Unfortunately, I sometimes get carried away with too much context (and too much content). The last few weeks are an example of that. Too much complexity in the materials I created. They needed to be stripped right back to be clearer and to be more useful for the team.

Just as I make this mistake, I feel that many OSS designers do too.

If you look at your OSS, what can you strip away to make the tools easier, clearer and faster to use?

Can AI help you elegantly remove from, not just add to, your OSS?

.

Lesson 5 – Decision-centric OSS needs confidence, governance and trust

Of course, faster decisions only create value if they can be trusted.

Speed without trust is dangerous.

This is especially important as AI becomes more embedded in OSS workflows. Operators need to know why a recommendation has been made, what evidence supports it, how confident the system is and when the recommendation should be challenged.

A decision-centric OSS must therefore make confidence visible…. but without adding unnecessary delays.

Was the recommendation based on confirmed telemetry, inferred service impact, historical pattern matching, recent change data or a best-guess?

Is the system highly confident, moderately confident or just taking a stab in the dark? Has a similar recommendation worked before? What would be the consequence of acting on it?

The best systems will combine reliable, deterministic decisions, at machine speed, but with human judgement. They will help operators act faster, but also give enough provenance, explainability and auditability to trust their actions.

This is partly a technology design challenge and partly a governance challenge.

Your AI-enabled OSS must define clear rules for when AI can recommend, when it can automate, when it must escalate and when a human must remain firmly in control.

.

The real shift – from data-centric to decision-centric

The shift from data-centric OSS to decision-centric OSS isn’t about abandoning information.

Near-perfect information is arguably more important than ever before. It’s just that information is only an input, not an outcome. Decisions are the key point of value.

AI makes this shift more urgent because it can so easily drag us either way:

• It can produce an overwhelming amount of information. Without careful design, it can flood our ops teams
• But with clever design intent, AI can do something far more valuable. It can reduce decision friction. It can expedite action. It can reduce complexity

This is our primary remit too. PAOSS helps organisations make OSS decisions clearer and faster.

That includes OSS strategy, procurement, architecture, workflow design, implementation and guided decision support. The goal is to help your teams reduce decision friction, focus attention where it matters and turn operational complexity into confident actions you can trust.

Think your OSS is intuitive and fast? Would you like us to review its effectiveness?

If your OSS environment is giving your teams more information but slower decisions, it may be time to rethink your design goals.