AI-Powered Network Operations Assistant with Multi-Agent RAG Architecture

swisscom · Telecommunications · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Telecommunications network operations

Swisscom needed to reduce the time network engineers spent gathering documentation, telemetry, KPIs, and calculations across fragmented tools while preserving calculation accuracy, telecom data security, and sovereignty requirements.

Constraints:

• engineers spent more than 10% of their availability on routine data retrieval and analysis in some scenarios
• network insights require both documentation lookup and precise numerical KPI calculations
• telecom data must satisfy strict data sovereignty, security, and regulatory requirements
• complex calculations over significant data volume cannot rely on model interpretation alone
• the assistant must guard against malicious inputs, sensitive identifier leakage, and prompt-based threats
• answers need factual grounding and relevance checks

Architecture

Swisscom built a Network Assistant on Amazon Bedrock. The initial design used Bedrock Knowledge Bases for RAG over documentation and tabular data. Accuracy gaps in calculations led the team to add Lambda action groups with Pandas or Spark, then evolve into a multi-agent Bedrock Agents architecture. A supervisor agent orchestrates documentation and calculator agents. The documentation agent retrieves information about data sources, parameters, configuration, and tooling. The calculator agent translates natural-language prompts into SQL, dynamically selects relevant Athena queries, and returns accurate KPI results over an S3/Glue/Athena data pipeline fed by daily batch ingestion from Swisscom's on-premises data lake. Bedrock Guardrails, filters, regex/pattern detection, contextual grounding, threat modeling, and STRIDE countermeasures protect sensitive telecom data.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  engineer-query-interface["engineer-query-interface"] --> supervisor-agent["supervisor-agent"]
  supervisor-agent --> documentation-management-agent["documentation-management-agent"]
  supervisor-agent --> calculator-agent["calculator-agent"]
  supervisor-agent --> bedrock-guardrails["bedrock-guardrails"]
  documentation-management-agent --> bedrock-knowledge-base["bedrock-knowledge-base"]
  on-prem-data-lake["on-prem-data-lake"] --> daily-batch-ingestion["daily-batch-ingestion"]
  daily-batch-ingestion --> s3-data-lake["s3-data-lake"]
  s3-data-lake --> glue-catalog["glue-catalog"]
  s3-data-lake --> bedrock-knowledge-base
  glue-catalog --> athena-sql-querying["athena-sql-querying"]
  calculator-agent --> athena-sql-querying
  calculator-agent --> bedrock-guardrails
  threat-model["threat-model"] --> bedrock-guardrails

Components

Data flow

Network data is ingested daily from Swisscom's on-premises data lake into S3, crawled/cataloged with Glue, and queried through Athena. Documentation and tabular knowledge feed Bedrock Knowledge Bases. A network engineer asks a natural-language question. The supervisor agent routes to the documentation management agent for source and parameter context, and to the calculator agent for KPI calculation. The calculator translates the request into SQL and executes relevant Athena queries. Guardrails filter malicious content, sensitive identifiers, and prompt-based threats, while grounding and relevance checks constrain responses.

Why this architecture

Swisscom evolved from basic RAG because documentation retrieval alone could not perform reliable numerical calculations. Lambda/Pandas/Spark action groups improved accuracy, but the later S3/Glue/Athena pipeline let the calculator agent translate prompts to SQL and query authoritative data directly. The multi-agent split keeps documentation retrieval and KPI calculation separate while a supervisor coordinates them. Guardrails, threat modeling, and trust-boundary work are central because telecom operations include sensitive identifiers and sovereignty requirements.

Models used: Amazon Bedrock · Amazon Bedrock Knowledge Bases · Amazon Bedrock Agents · Amazon Bedrock Guardrails

Scale

• Some network-engineer tasks consumed more than 10% of engineers' availability.
  “In certain scenarios, fulfilling the assigned tasks consumed more than 10% of their availability.”article, stated
• The projected routine data-retrieval and analysis time reduction was 10%.
  “Network engineers are estimated to experience 10% reduction in time spent on routine data retrieval and analysis tasks.”article, stated
• The projected savings were nearly 200 hours per engineer annually.
  “This efficiency gain translates to nearly 200 hours per engineer saved annually”article, stated
• Operational costs were projected at less than 1% of generated value.
  “with minimal operational costs at less than 1% of the total value generated.”article, stated
• Data ingestion from the on-premises data lake runs daily.
  “The system integrates with Swisscom’s on-premises data lake through daily batch data ingestion”article, stated

Alternatives considered (roads not taken)

Manual data gathering and analysis

Rejected because: It consumed substantial engineer time, introduced human error, and diverted engineers from strategic work.

Basic RAG over documentation and tabular data

Rejected because: The assistant also needed accurate formula and KPI calculations.

Pandas or Spark Lambda calculation action groups

Rejected because: A serverless S3/Glue/Athena pipeline enabled SQL-based calculation by the calculator agent.

Patterns

multi-agent-orchestration (orchestration)

A supervisor agent coordinates documentation and calculator agents to answer mixed retrieval and calculation questions.

rag-retrieval (retrieval)

Bedrock Knowledge Bases retrieve relevant documentation and contextual information for engineer questions.

tool-use-orchestration (orchestration)

The calculator agent uses SQL querying over the S3/Glue/Athena data pipeline instead of trying to calculate only inside the model.

guardrails-io-filtering (governance)

Bedrock Guardrails block malicious categories, SQL injection, denied topics, sensitive identifiers, PII, AWS keys, and serial numbers.

privacy-preserving-processing (governance)

Sensitive telecom identifiers and PII are filtered, masked, or denied according to security and sovereignty requirements.

Tradeoffs

Use specialized agents instead of one assistant role.

Chose supervisor, documentation, and calculator agents over single general RAG assistant.

Rationale: Network operations needs both documentation retrieval and precise numerical calculation.

Move calculator logic to SQL over curated data.

Chose Athena SQL queries over S3/Glue data over Pandas or Spark Lambda action groups.

Rationale: The serverless data pipeline supports scalability, cost-effectiveness, and accurate KPI calculations.

Process on AWS while preserving telecom security posture.

Chose Bedrock Guardrails plus threat modeling and sovereignty controls over unrestricted cloud-hosted assistant behavior.

Rationale: Telecommunications data requires classification, trust boundaries, and explicit countermeasures.

Gotchas (what bit them)

RAG alone was not accurate enough for KPI calculations.

Root cause: Network tasks required formulas and significant data volume, not just documentation retrieval.

Resolution: Add calculator tooling first through Lambda/Pandas/Spark and later through SQL queries over S3/Glue/Athena.

Telecom AI assistants must handle sensitive identifiers and security threats.

Root cause: Network operations data can include PII, subscriber/device identifiers, access keys, and prompt attack surfaces.

Resolution: Use Bedrock Guardrails, denied topics, regex/pattern filters, masking, grounding, relevance checks, and threat modeling.

Fragmented network tools increase human-error risk.

Root cause: Engineers had to manually gather telemetry, documentation, KPIs, and calculations from multiple systems.

Resolution: Provide a single natural-language assistant backed by RAG, agents, and SQL calculation tools.

Evaluation

Swisscom evaluated the assistant through projected time savings, KPI calculation accuracy, threat modeling, STRIDE analysis, data-flow diagrams, trust-boundary review, and guardrail behavior for sensitive or restricted requests.

Metrics: 10% reduction in routine retrieval and analysis time · nearly 200 hours saved per engineer annually · operational cost below 1% of generated value · KPI calculation accuracy · threat model robustness · guardrail filtering/masking

Outcomes

• engineers are projected to save nearly 200 hours per year
• routine data retrieval and analysis time is projected to drop by 10%
• the assistant provides natural-language access to network parameters, troubleshooting, and KPI calculations
• guardrails reduce risk of sensitive-data leakage and malicious prompt handling

The case reports more than 10% availability consumed by some tasks, projected 10% routine-work reduction, nearly 200 hours saved per engineer annually, daily batch ingestion, and operational cost under 1% of generated value.