Six vendors, one question: tracing a call across systems that don't know each other

A phone problem can live in any of six layers owned by five different vendors. This is how the ops stack from the earlier case study actually works: a diagnostic ladder that walks the whole call path from one conversation.

Share
Six stacked translucent network layers with a single light beam passing through all of them

An earlier case study described the operations stack that lets one engineer run a large voice fleet. This one goes a level deeper, because the interesting part is not that AI reads logs. It is what it takes to make six systems that have never heard of each other answer one question.

The problem

When a business phone call sounds bad or fails, the cause lives in one of six layers: the customer's network, the edge device, the phone system itself, the server underneath it, the carrier trunk, or the public phone network beyond. Each layer has its own vendor, its own portal, its own API, its own log format, and its own idea of what the customer is called. Diagnosing one complaint used to mean six logins and a legal pad.

What the system does

Each layer got its own purpose-built read-only tool server: network monitoring, the phone platform, the cloud VMs, and one per carrier. An AI assistant can walk the ladder in order, pull the evidence for the same call from every layer, and line the timestamps up. Server log collection runs through the cloud provider's management channel, so the fleet keeps zero open inbound ports.

The unglamorous part turned out to be the most important: the same customer has a different name in every system. The billing platform, the phone system, the VM tags, and the carrier accounts all disagree. A hand-maintained cross-reference maps every customer across all of them, and without it, none of the automation works. Nobody puts that file on a conference slide, and it is the single most load-bearing artifact in the stack.

The guardrails

  • Reads are broad, writes are gated. Diagnosis is unrestricted. Change requires explicit flags plus per-action confirmation, the riskiest customer environments require an additional override, and scheduled jobs run read-only, always.
  • Real APIs fail, so the tooling assumes it. Vendor APIs time out, rate-limit, and return garbage at honest rates. Every call is retried, logged, and measured. If your automation demo never shows a failed API call, you are watching a demo.

What happened

  • A complaint that used to cost an hour across six consoles now starts with one question and returns correlated evidence from every layer.
  • Megabytes of server logs come back on demand from a fleet with no inbound ports open at all.
  • The pattern scales sideways: any business running on a stack of vendor systems that do not talk to each other has this exact shape of problem.

What this means for your business

Your business probably is not phones. But it almost certainly runs on five systems with five logins and five names for the same customer, and somebody spends their day being the human API between them. That correlation layer is buildable, the read-only version of it is low-risk, and it is usually the highest-leverage automation in the building.


Vendors, customers, and infrastructure identifiers are omitted. The architecture is real. If your team is the glue between six portals, start with a roadmap session.