Multi-Agent Framework for Automated Telecom Change Request Processing

totogi · Telecommunications · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (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: Telecom business support systems

Totogi needed to automate telecom BSS change requests that traditionally required specialized engineering talent, multiple development stages, and about seven days of work.

Constraints:

• Telecom BSS platforms contain hundreds of applications from multiple vendors.
• Change requests need telecom-domain correctness, production-grade code, tests, and auditability.
• Agent handoffs must preserve state across requirements, design, development, QA, and testing.
• The platform has telecom-grade reliability, security, and scalability requirements.

Architecture

Totogi built BSS Magic with a telco ontology, Anthropic Claude models on Amazon Bedrock, and five specialized agents: Business Analyst, Technical Architect, Developer, QA, and Tester. AWS Step Functions manage state and workflow progression, Lambda functions execute stages, and RAG plus few-shot prompting help agents produce domain-specific requirements, designs, code, and tests.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  aws-step-functions["AWS Step Functions"] --> business-analyst-agent["Business Analyst Agent"]
  business-analyst-agent --> technical-architect-agent["Technical Architect Agent"]
  technical-architect-agent --> developer-agent["Developer Agent"]
  developer-agent --> qa-agent["QA Agent"]
  qa-agent --> tester-agent["Tester Agent"]
  telco-ontology["Telco Ontology"] --> business-analyst-agent
  aws-step-functions --> technical-architect-agent
  aws-step-functions --> developer-agent
  aws-step-functions --> qa-agent
  aws-step-functions --> tester-agent

Components

Data flow

A change request enters BSS Magic, where the Business Analyst interprets requirements using the telco ontology. Step Functions advance the workflow through technical design, code generation, QA, and testing agents. Each agent uses RAG/few-shot context and passes outputs downstream until the framework produces tested telecom-grade code for review and deployment.

Why this architecture

Totogi used a telco ontology so agents could reason over domain relationships rather than generic code tasks. Step Functions gave state management, error handling, audit trails, and visible workflow progression across a multi-agent SDLC pipeline.

Models used: Anthropic Claude on Amazon Bedrock

Scale

• Traditional change requests took about seven days.
  “Traditional change requests could take seven days to complete, involving multiple rounds of coding, testing, and reconfiguration.”summary, stated
• BSS Magic reduced change processing from seven days to a few hours.
  “reducing change request processing time from 7 days to a few hours, achieving 76% code coverage in automated testing”summary, stated
• Automated tests achieved 76% code coverage.
  “achieving 76% code coverage in automated testing”summary, stated

Alternatives considered (roads not taken)

Keep traditional specialized-engineer change processing

Rejected because: It took about seven days and increased operational expense.

Use generic LLM code generation without telecom ontology

Rejected because: BSS changes require semantic understanding of telecom systems and relationships.

Coordinate agents without durable workflow state

Rejected because: Step Functions provide state management, error handling, audit trails, and workflow monitoring.

Patterns

multi-agent-orchestration (architecture)

Five specialized SDLC agents move change requests from analysis through testing.

durable-execution (operations)

AWS Step Functions manage workflow state, transitions, errors, and visual monitoring.

rag-retrieval (knowledge)

Agents use RAG and few-shot prompting to maintain domain-specific context.

Tradeoffs

Use AWS Step Functions for orchestration

Chose Durable workflow state and Lambda execution over Ad hoc agent handoffs.

Rationale: Telecom-grade workflows need state management, error handling, monitoring, and auditability.

Ground agents in a telecom ontology

Chose Ontology-driven domain knowledge over Prompt-only telecom context.

Rationale: The ontology turns siloed BSS knowledge into reusable relationships agents can reason over.

Gotchas (what bit them)

Telecom BSS customization is too domain-specific for generic generation.

Root cause: BSS platforms span hundreds of vendor applications and complex relationships.

Resolution: Totogi built a telco ontology to ground agent reasoning in reusable domain concepts.

Agent SDLC workflows need auditable state transitions.

Root cause: Generated requirements, designs, code, QA, and tests depend on reliable handoffs.

Resolution: Step Functions provide state management, error handling, visual monitoring, and audit trails.

Evaluation

The case reports elapsed change-request time and automated test coverage as quality and productivity metrics.

Metrics: 7 days to a few hours · 76% code coverage · five specialized agents

Outcomes

• Totogi automated telecom BSS change-request processing from requirements through code and tests.
• The reported processing time dropped from seven days to a few hours.
• The system produced production-ready telecom-grade code with minimal human intervention according to the case.

The case reports five agents, seven days to a few hours, and 76% code coverage.