Six-Agent AI Voice Orchestration for a National Fiber Infrastructure Builder

Client Profile

One of the United Kingdom’s largest alternative fiber infrastructure builders, constructing and operating a full-fiber network that spans dozens of cities and towns across the country. The organisation doesn’t sell directly to consumers — it builds the fiber network and then makes it available to ISP partners who deliver retail broadband services to homes and businesses over the top of it.

This creates a uniquely complex stakeholder landscape. On any given day, the organisation handles interactions with: members of the public affected by construction works, consumers experiencing broadband outages (who may not understand that their ISP and the infrastructure builder are separate companies), ISP partners managing orders and account queries, field engineers validating installations and running line tests, and internal operations teams scheduling surveys and appointments.

Each of these audiences requires a fundamentally different type of conversation — different tone, different technical depth, different systems access, and different escalation paths. And yet, until now, many of these calls landed on the same general reception line.

Industry: Telecommunications (Fiber Infrastructure) · Region: United Kingdom · Products Used: VoiceFlow AgentIQ (Multi-Agent Orchestration) · Knowledge Base RAG · CRM Integration · Calendar Integration

The Challenge

One phone number, six completely different conversations.

The organisation’s main contact number received calls from the full spectrum of stakeholders, and the reception team had to perform real-time triage: is this a member of the public complaining about a traffic light? A consumer whose internet is down? An ISP partner checking on an order? An engineer who needs a line test run? A property developer requesting a survey?

Each conversation type required different knowledge, different system access, and different handling. The reception team was spending more time figuring out who was calling and what they needed than actually resolving the query. Transfers between teams were frequent, often multiple times per call, and callers regularly had to repeat their information at each handoff.

Specific pain points by audience:

• Public complaints about construction works (temporary traffic lights not functioning, road surface damage, access obstructions) needed to be captured with precise location details, categorised correctly, and given a reference number — but the reception team wasn’t trained on construction operations and frequently miscategorised issues or gathered incomplete information.
• Consumer outage calls were particularly frustrating because the infrastructure builder doesn’t have a direct relationship with the end consumer — the ISP does. But consumers often don’t know who their infrastructure provider is, so they call whoever they can find. These calls needed to be quickly diagnosed (is it a network fault or an ISP-side issue?), and the consumer needed to be directed to their specific ISP’s support team with the correct phone number.
• ISP partner account queries — order status checks, provisioning updates, portal guidance — were being handled by generalist reception staff who couldn’t access the partner portal systems and had to manually transfer to account management teams that were often in meetings or unavailable.
• Technical validation calls from field engineers who had completed physical installations but needed the order desk to validate the network connection by checking OLT status, ONT details, manufacturer serial numbers, and running live line tests. These calls were highly technical, time-sensitive (the engineer is on-site waiting), and required access to specific network databases.
• Appointment scheduling for site surveys and engineer visits required calendar access, customer confirmation calls, and rescheduling capabilities that the reception team managed manually through shared calendars and phone calls.

Our Approach

Rather than building a single AI agent and hoping it could handle the full range of interactions, we designed a multi-agent orchestrated system with a central dispatcher and five specialist agents. Each specialist is purpose-built for its specific audience and use case, with its own personality, knowledge base, system integrations, and escalation protocols.

The architecture mirrors how a well-run organisation would structure human teams — except these teams are available 24/7, never transfer a caller to voicemail, and share information between themselves instantly.

What We Built

Agent 1: Beth — The Orchestrator

Beth is the central intelligence hub — the first voice every caller hears. Her role is rapid, accurate triage.

Within the first few seconds of a conversation, Beth determines:

• Who is calling (public, consumer, ISP partner, engineer, developer)
• What they need (complaint, outage, order status, technical test, appointment)
• Which specialist agent should handle the call

Beth doesn’t just transfer blindly. She gathers enough context to brief the specialist agent before the handoff, so the caller never has to repeat themselves. She also handles general information queries directly — company information, coverage areas, partnership enquiries — without needing to involve a specialist.

Beth has full knowledge of the organisation’s services, network coverage, partner ecosystem, and public-facing information. She’s the knowledgeable first impression that sets the tone for the entire interaction.

Agent 2: Meghan — Public Infrastructure & Complaints

Meghan handles calls from members of the public about construction-related issues.

• Traffic light faults — temporary traffic management installed for road works that isn’t functioning correctly. Meghan captures the precise location, the nature of the fault, the time it was observed, and any safety concerns, then generates a structured report with a unique reference number.
• Road surface complaints — damage to roads, pavements, or driveways caused by construction activity. Meghan documents the location, photographs if available, and the nature of the damage.
• Access and obstruction issues — construction works blocking pedestrian access, vehicle access, or causing safety hazards. Meghan assesses urgency and escalates immediately if there’s a safety risk.
• Noise and disruption complaints — out-of-hours work, excessive noise, or construction activity exceeding permitted hours.

Every complaint is logged with a reference number, categorised for the correct construction team, and the caller is given a clear expectation of response timeline. Meghan’s tone is empathetic and professional — she represents the organisation to its neighbours and communities.

Agent 3: Charles — Consumer Service & Outage Support

Charles handles calls from broadband consumers who may not understand the relationship between the infrastructure provider and their ISP.

• Outage diagnosis — Charles first determines whether the issue is likely on the infrastructure side (a fiber fault, a cabinet outage, planned maintenance) or the ISP side (a configuration issue, a billing suspension, a router problem). He queries the network status system for known outages in the caller’s area using their postcode.
• ISP identification — if the issue is ISP-side, Charles identifies which ISP serves the caller (by address lookup or by asking) and provides the correct customer support number for that specific ISP.
• Infrastructure fault reporting — if the issue appears to be on the infrastructure side (confirmed outage, damage to street cabinet, fiber cut), Charles logs the fault with full details and provides the caller with a reference number and expected resolution timeline.

Charles’s key design challenge is managing caller frustration when the answer is “you need to call your ISP, not us” — doing so with empathy and practical help (providing the exact phone number, explaining why the ISP is the right contact) rather than feeling like a runaround.

Agent 4: Katherine — Technical Validation & Network Testing

Katherine serves the internal engineering workflow — specifically the moment after a field engineer completes a physical fiber installation and needs the network side validated.

• OLT/ONT validation — Katherine accesses the network database to verify that the Optical Line Terminal and Optical Network Terminal are registered, matched, and communicating correctly. She checks manufacturer details and serial numbers against the provisioning records.
• Live line testing — Katherine initiates automated line tests to confirm end-to-end connectivity, measuring signal levels and confirming the connection meets quality thresholds.
• Installation closure — if all tests pass, Katherine confirms the installation as complete in the order management system. If issues are found, she overrides the closure as incomplete and raises a case for further investigation, providing the field engineer with specific details about what failed and why.

Katherine’s interactions are highly technical, fast-paced, and engineer-to-engineer in tone. There’s no hand-holding — she provides data, results, and next steps efficiently.

Agent 5: William — B2B Account Management

William handles calls from ISP partners — the commercial customers who buy wholesale access to the fiber network.

• Order status updates — William queries the order management system to provide real-time status on installations, activations, and any pending actions. He covers the common “where is my order?” query that account managers handle dozens of times daily.
• Portal guidance — many ISP partners have access to a self-service portal but don’t use it. William walks them through the portal, explains where to find the information they need, and encourages self-service for future queries.
• Bulk order queries — for partners managing large rollouts, William can provide summary status across multiple orders.
• Escalation to account management — for commercial discussions, contract queries, or issues requiring human judgement, William schedules a callback with the partner’s dedicated account manager.

Agent 6: Harry — Field Operations & Scheduling

Harry manages the logistics of getting engineers to the right place at the right time.

• Survey appointment booking — when a new connection requires a site survey, Harry accesses the engineering team’s calendar system and books an available slot, confirming the date, time window, and any site access requirements with the customer.
• Appointment confirmation calls — Harry proactively calls customers ahead of scheduled engineer visits to confirm the appointment, verify access arrangements, and reschedule if needed.
• Rescheduling — when a customer can’t make their appointment, Harry offers alternative dates and manages the calendar update, notifying the engineering team of the change.
• Pre-visit preparation — Harry confirms what the customer needs to have ready for the engineer visit (access to specific areas, parking availability, someone over 18 present).

Orchestration Architecture

The six agents don’t operate in silos. The orchestration layer provides:

• Seamless handoff — when Beth transfers to a specialist, the full context of the initial conversation travels with the call. The specialist knows who’s calling and why before they speak.
• Cross-agent awareness — if Katherine identifies a network fault during a line test, that information is immediately available to Charles when consumers call about outages in the same area.
• Unified knowledge base — all agents share access to the organisation’s network status, coverage data, partner directory, and company information, ensuring consistent answers regardless of which agent handles the query.
• Centralised analytics — every interaction across all six agents feeds into a unified analytics layer, providing visibility into call volumes, resolution rates, and emerging issues across the entire operation.

Projected Impact

Metric	Before	After
Average time to correct specialist	Multiple transfers, 3–5 minutes	Single handoff via Beth, seconds
Public complaint data completeness	Inconsistent, often incomplete	Structured, 100% of required fields captured
Consumer outage misdirection	Frequent — consumers calling wrong entity	Instant ISP identification and correct redirection
Engineer on-site wait time for line tests	15–30 minute phone queue to order desk	Instant automated validation via Katherine
ISP partner “where is my order?” calls to account managers	High volume, disruptive to commercial work	Handled entirely by William
Appointment scheduling accuracy	Manual calendar management, double-bookings	System-integrated, conflict-free scheduling

Why This Matters

This deployment is architecturally different from a single-agent customer support deployment. The challenge isn’t “build a chatbot that answers questions” — it’s “build an intelligent routing and handling system that serves six fundamentally different audiences through a single entry point, each with their own expectations, technical requirements, and emotional context.”

The multi-agent orchestration pattern — central dispatcher plus domain specialists — is a design that scales. Adding a seventh agent for a new audience (say, property developers requesting fiber provisions for new-build sites) requires building one new specialist and updating Beth’s routing logic. It doesn’t require rearchitecting the entire system.

For the organisation, this transforms their public-facing communication from a bottleneck into a capability. Every call is handled by the right specialist immediately, every interaction generates structured data, and the human teams are freed from reception and triage duties to focus on the work that requires their expertise.