Domain Expertise Is the Asset. AI Is the Delivery Mechanism.

There's a lot of noise about AI tools right now. Most of it focuses on the wrong thing.

The interesting question isn't whether an AI can analyze a network config. It's whether the system knows what to look for — and that knowledge has to come from somewhere other than the model's training data.

Last week I built something that makes this concrete.

The SBC Analyzer

The Oracle SBC Analyzer takes an enterprise session border controller running configuration and produces a structured, prioritized analysis: security issues with severity ratings, call flow diagrams, session agent classification, compliance gaps, remediation guidance. It runs in about fifteen seconds. It found fourteen issues in a real client config, five of them high severity.

The code is not the impressive part. The code is a React frontend that calls the Claude API with a carefully constructed system prompt. Anyone can write that code.

What makes the tool useful is what's in the system prompt. And what's in the system prompt comes from thirty-two years of living in enterprise telecom infrastructure.

What the System Prompt Encodes

The prompt tells the model what matters in a session border controller configuration. Not generically — specifically.

It tells it that SRTP and SRTPnoRekey on different legs of the same call path might indicate an asymmetry that needs explanation or remediation. It tells it that an InternalTeamsUsers realm with no SIP interface pointing to it is almost certainly an orphaned object from a deprecated integration. It tells it that a SIP manipulation rule that exists to fix a known bug in another system should be tracked as a dependency on that bug — not just accepted as ambient config. It tells it that on an E911 path, if there's no codec policy enforced that restricts to PCMU, a G.722 offer could reach a PSAP that only supports G.711 mu-law.

None of that is in a language model's training data at a level of specificity that would make it reliable in production. It's in the prompt because someone who has done this work for thirty years knows it.

That's the pattern. The AI provides the reasoning capability and the structured output. The domain knowledge provides the evaluation criteria. Neither alone produces something useful.

Why This Matters for AI Applications Generally

There's a common failure mode in AI tooling: people use the model as a general reasoner and expect it to know things it doesn't. It writes plausible-sounding analysis that misses the specific, non-obvious patterns that make an expert different from a smart generalist.

The fix isn't a better model. The fix is encoding the expert knowledge explicitly, in a form the model can apply consistently.

This is what I mean when I talk about AI-native work: not using AI to do things faster, but using AI as a delivery mechanism for expertise that previously could only be delivered by a person, one engagement at a time.

The SBC Analyzer is a small example. A senior SBC engineer's pattern recognition, available instantly to anyone who uploads a config file. That same engineer's time freed for the work that actually requires judgment — not the part that requires knowing what to look for.

What I'm Building Toward

This isn't a tool. It's an existence proof.

Thirty-two years of enterprise IT across unified communications, telephony, network engineering, and AI-native operations — all of it is amenable to the same treatment. The knowledge that used to be locked in my head, deployable only by me showing up in a room, can increasingly be encoded in systems that apply it at scale.

The SBC Analyzer is one instance of that. The JARVIS operations system I've built to run my entire portfolio is another. The pattern is consistent: domain expertise is the moat, AI is the mechanism, and the combination produces things that neither could produce alone.

That's what I'm building. Session by session.