Interviews

From DTW26: Why Live-Network AI Needs Deterministic Logic

July 16, 2026
← Back to All Insights
From DTW26: Executive insights with our CTO, Luis Ortega

Trust is the word every operator uses when they talk about AI in their network, but few can define what it actually means in engineering terms.

We sat down with Luis Ortega, our CTO, at DTW26 to get a straight answer on that: what separates a system that's trustworthy enough to run autonomously on live infrastructure from one that just looks good in a demo. His answer runs through hybrid architecture, auditability, and why the industry keeps confusing agentic interaction with real operational autonomy.

What makes an AI system trustworthy enough to run autonomously on a live network, and where does most of the industry still get that wrong?

Trust is not a property of the model, it's a property of the system around the model, the harness.

I believe live-network autonomy requires a hybrid approach: deterministic logic for repeatable execution, ML for prediction and classification, and Agents for reasoning, explanation, discovery, and configuration. The agents should not sit in the critical path of heavy operational data or execute consequential actions directly. They should reason over governed insights, while deterministic engines, policies, approvals, and action managers execute safely.

An AI agentic system becomes trustworthy when every action is confidence-based (it can be via simulations or digital twins), auditable, reversible, validated after execution, and able to keep the human in the loop with full traceability. That is the difference between a useful copilot or LLMs that generate recommendations, and a real agentic system with closed-loop autonomy.

Where the industry still gets it wrong is confusing agentic interaction with operational autonomy. A chatbot that explains an alarm is not enough. Agents propose, and TuplOS governs and executes.

From a technical standpoint, what separates an AI system that actually works in production from one that looks good in a demo?

From a technical perspective, the difference is usually everything you don't see in the demo.

A demo proves that an AI is capable of almost anything you imagine, but a POC is very different from a production system. A production system has to answer questions a demo never has to: who changed what, how many interactions the agent has had, how it behaves compared to what was expected, whether its reasoning is traceable and justified, what it costs to run 24/7, and so on. Each new AI interaction adds cost, and I see people use AI as a compute engine while also building if-then logic into the prompts, so they end up paying for both the AI cost and the programming logic itself.

At Tupl, we see production AI as a hybrid execution architecture, not just a model. You need deterministic pipelines for heavy operational data, ML where statistical confidence matters, and Agents for reasoning, analysis, discovery, explanation, and configuration. The LLM should not be the system of record or the execution engine. It should reason over governed insights, while TuplOS governs workflows, actions, validation, rollback, and audit.

A production system also has to learn. If an engineer corrects a diagnosis, that knowledge should become part of the platform, not disappear after the conversation. And it needs governance: not all new knowledge is good. It's like a child without guidance: they can just as easily learn bad habits as good ones.

A demo answers, and anyone can put one together in an afternoon now. A production system acts, proves, learns, and stays governed while doing it.

Trust is the word everyone uses, but what does it actually mean in engineering terms? How do you build a system that operators can audit and override?

In engineering terms, trust means control.

It means an operator can always answer several questions: how and why this analysis was performed, what data was used, why this alternative and no other, what actions are proposed, what's the impact on the system, who can apply the proposed action, and what happened after the action.

At Tupl, we build that through a hybrid approach. Agents can reason, explain, investigate and propose. Agents should not be the uncontrolled execution engine. Our system is designed around that separation: AI discovers, TuplOS governs and executes.

Auditability means every run has traces: inputs, model outputs, tool calls, policy checks, approvals, cost, timing, action logs and outcome validation. Override means the human is not outside the system. They are part of the control plane. They can approve, reject, correct, pause, roll back, change thresholds, or retrain the model or modify the pipelines when the system gets something wrong.

That is why in our Agent Builder we use typed tools, role-based access, budgets, hallucination guards, sandboxing, human approvals and full run logs. The principle is simple: agents can propose, but humans and governed automation commit.

For operators, trust isn't a buzzword. It's the difference between a system they'll actually deploy and one they won't. It's observability, policy, versioning, accountability and the ability to stop or reverse the system before risk becomes impact.

Most operators already have AI tools. Why aren't they enough, and what has to change at the infrastructure level?

Most operators do have AI tools, but many of them are still isolated tools like ChatGPT, Claude, analytics platforms, copilots, chatbots, or "smart" dashboards. They are useful, but they are not enough across the full value chain. They do not consistently turn that insight into a governed action across customers' operations and systems.

What should change is the infrastructure underneath. Operators need an operational AI layer, not just more AI features. That means deterministic data pipelines for PM, FM, CM, topology, tickets and customer data, ML for prediction and confidence, agents for reasoning and configuration, and a governed execution layer for workflows, actions, approvals, rollback and audit.

The other missing piece is compounding knowledge. If an agent solves a case once but does not capture the expert correction, the root cause, the action and the outcome as reusable knowledge, the operator is not building autonomy, the system is not learning and the compounding effect that lets agentic impact grow never kicks in. In Network Advisor, for example, the feedback loop is designed to codify engineer expertise into the platform so recurring high-confidence cases can move toward low-cost, constant, deterministic automation.

Where is the technical frontier right now, and where is Tupl heading next?

The technical frontier has moved beyond "Agents can recommend what to do." The real frontier is AI that can safely close the loop on live operations.

We see three big areas. First, the architecture has to remain hybrid. Raw operational data should not go straight into an LLM. Heavy data processing, KPI computation and correlation must be deterministic, ML should handle prediction and confidence, and agents should be used for reasoning, explanation, discovery and configuration. That separation is what makes the system scalable and trustworthy.

Second, closed loop has to become much richer. It is not enough to say, "I recommend this parameter change." The system must explain why the action is justified, predict the expected impact, prepare the rollback action, execute through governed tools, validate the result afterwards, and summarize the reasoning chain for audit. That is the difference between automation and accountable autonomy.

Third, knowledge management becomes critical. Agents generate hypotheses, fixes, decisions, lessons learned and new operational patterns. If that knowledge is not captured, the system repeats itself. Our direction with TuplOS, Agent Builder and the Hive is to turn every resolved case, human correction, action and outcome into reusable, governed knowledge that improves the next automation.

So where is Tupl heading? Toward an operational intelligence layer where agents do not just answer questions, they help build, govern and improve the automation itself. The goal is full closed-loop autonomy, but with evidence, impact analysis, rollback, auditability and human control built in from the beginning.

The takeaway

Across every question, Luis keeps coming back to the same design principle: agentic AI can reason, explain, and propose, but it doesn't get to act alone on a live network. That job belongs to the governed layer underneath it, TuplOS, which executes, validates, and keeps a human in the loop at every step.

That's a different definition of "trustworthy AI" than most of the industry is selling. The bet isn't on a smarter model, but on a system where autonomy never comes at the cost of control.

Related articles
Pablo Tapia about the importance of attracting young talent for companies to grow
Interviews
Pablo Tapia about the importance of attracting young talent for companies to grow
July 27, 2021
Interview to Mr. Valentin Neacsu, Former Kyivstar’s CTO. VEON Group
Interviews
Interview to Mr. Valentin Neacsu, Former Kyivstar’s CTO. VEON Group
November 29, 2021
Expert insights: Pablo Tapia on Avoiding Mistakes when Buying AI Solutions
Interviews
Expert insights: Pablo Tapia on Avoiding Mistakes when Buying AI Solutions
April 4, 2024
How to Choose the Right MLOps Partner?
Interviews
How to Choose the Right MLOps Partner?
May 3, 2024