How we modernized a legacy AI voice call platform

Client and business challenge

Our client is a US-based software provider serving consumer-focused law firms. Its platform handles the initial intake of potential clients by answering incoming calls, collecting information, classifying inquiries, transferring callers when necessary, and creating cases in the CRM.

Although the voice-processing core remained operational, its architecture made further development increasingly expensive and difficult to manage. Each law firm required a dedicated AWS Lex bot, with its case structure translated into intents, slots, data-capture rules, and conditional dialogue branches, followed by bot generation, versioning, deployment, and validation.

Some transcription and data-enrichment tasks depended on a separate post-call workflow. Lex stored audio fragments during the conversation, while Whisper or Deepgram processed them after the call. A significant share of the configuration logic was concentrated in complex components that only a limited number of specialists could safely modify.

The modernization had five main business and technology drivers:

• reduce long-term operating and maintenance costs;

• remove dependence on the aging voice stack;

• make the embedded business logic easier to understand and manage;

• accelerate scenario configuration for individual firms;

• strengthen security and support compliance requirements.

The key challenge before designing the target architecture was to determine which behavior remained critical to the business, which branches had become dead code, and which rules had to be preserved. These decisions affected call classification, legal-case mapping, caller identification, intake flows, transfers, call state, and CRM integration.

Paradigm: validate first, modernize second

The platform’s rules had accumulated across source code, database structures, configurations, feature flags, logs, and infrastructure services. Comments and earlier documentation did not always reflect the behavior of the running system.

The project therefore began with the reconstruction of the actual call flows. The WaveAccess team compared code with operational data, separated active behavior from obsolete paths, formalized critical rules, and reviewed the findings with architects and product owners.

The validated logic became the foundation for the target architecture by clarifying which processes had to remain intact, where the system could be simplified, and which legacy mechanisms should be retired.

How the work was organized

The analysis followed a controlled seven-step workflow. AI accelerated navigation, analysis, and documentation, while specialists remained responsible for validating the findings and making architectural decisions.

Step 1. Establish persistent project context

The team recorded architectural constraints, logging conventions, implementation patterns, and codebase rules at both project and module level.

A semantic index covered 10,395 code and documentation fragments across four repositories. It enabled the team to locate related functions, dependencies, and business rules without repeatedly loading large parts of the system into the model’s context.

Step 2. Define templates before generating documentation

Technical artifacts were prepared in a consistent structure rather than as free-form summaries. The specification covered user stories, acceptance scenarios, edge cases, technology research, the data model, implementation planning, task decomposition, integration contracts, and requirements verification. Its total volume was approximately 3,172 lines, and the team verified 38 functional requirements.

Step 3. Analyze more than the source code

The review combined application code with PostgreSQL schemas and migrations, DynamoDB records, stored audio, application logs, configuration, and feature flags.

Comparing these sources showed which execution paths were active, which belonged to earlier versions of the system, and where documentation had diverged from the implementation.

Step 4. Use structured analysis requests

Each AI-assisted task defined the component under review, the expected output, and the evidence required to support the conclusions.

Instead of requesting general summaries, the team analyzed entry points, component responsibilities, dependencies, data flows, function contracts, error paths, and complete call sequences. This made the resulting documentation directly reviewable against the implementation.

Step 5. Use AI as a codebase explorer

AI tools navigated the repository structure and semantic index, traced connections across modules, and prepared initial technical artifacts.

Architects and product owners checked the findings against code, databases, logs, and active execution paths. This prevented inactive code from being documented as current behavior and corrected plausible interpretations that did not match the running system.

Step 6. Decompose large areas early

Call orchestration, audio processing, telephony streaming, conversational functions, and session management were analyzed as separate functional areas.

The team began with concise module overviews and added detail where necessary. This reduced context pressure and allowed independent parts of the voice-processing stack to be reviewed in parallel.

Step 7. Visualize hidden behavior

Sequence and flow diagrams captured the call lifecycle, the post-call transcription path, audio-format handling, and the target real-time architecture. The diagrams made processes that had previously been distributed across code, configuration, and infrastructure easier for engineering and product teams to review together.

What the analysis revealed

The analysis made several important architectural constraints explicit.

The legacy Lex and Connect subsystem contained approximately 4,225 lines. Its largest component, LexCustomBotService.cs, was a 2,090-line service responsible for generating firm-specific intents, slots, capture settings, conditional branches, and code hooks.

Full transcription and data enrichment relied on stored audio processed after the call. Onboarding a new firm required another Lex bot to be generated, locked, versioned, and deployed.

The team also formalized the actual scope of the business logic: five call types, more than 22 legal-case categories, structured intake flows, six conversational functions, and 60 backend API entry points.

These findings determined which capabilities had to be preserved, including call classification, case mapping, caller recognition, intake logic, and transfers. They also identified mechanisms that could be simplified or removed, such as per-firm bot generation and the separate post-call transcription workflow.

From the legacy stack to the target architecture

The validated requirements shaped a new call-processing architecture covering telephony, speech processing, dialogue orchestration, firm-specific configuration, and call-state management.

How the target architecture works

The new LCX.CallHandler service replaces the bot-per-firm model with a shared call-processing layer.

When an incoming-call event arrives, the service identifies the firm and checks whether the caller is already known. Once the call is answered, Telnyx starts bidirectional media streaming, while the call handler opens a WebSocket connection to OpenAI Realtime and configures the session with firm-specific instructions and available functions.

Telnyx and OpenAI use the same G.711 μ-law audio format, allowing the audio stream to pass through without an additional transcoding stage. Server-side voice activity detection manages turn-taking during the conversation.

Firm-specific instructions guide the intake flow, while structured functions allow the system to:

• classify the call type;

• determine the relevant legal-case category;

• check whether a caller’s question can be handled;

• provide simple information;

• request a transfer;

• complete the conversation.

After the call, the service prepares the resulting data and sends it through MassTransit so that a case can be created in the CRM.

Firm-specific behavior is controlled through prompt templates and database configuration. Updating a call scenario no longer requires the generation, versioning, and deployment of another voice bot.

The target architecture also includes guarded call states, echo suppression, personal-data masking in logs, webhook-signature verification, encryption for stored recordings, externalized secrets, and retry policies for temporary integration failures.

Business outcome

WaveAccess modernized the platform’s voice-processing core by moving it to a scalable architecture with real-time conversations, more natural interaction, automatic call classification, and integration with business systems.

The shared configuration model reduced the effort required to onboard firms and adapt their call scenarios. Changes can now be introduced through templates and database settings instead of a dedicated bot-generation, versioning, and deployment cycle.

Recovering and validating the existing logic before implementation helped preserve critical intake and routing processes, exclude obsolete functionality, and reduce migration risk. It also gave the client a clearer and more manageable representation of the business rules embedded in the platform.

The voice-processing stack is now easier to maintain and extend, less dependent on the previous technology, and ready for further AI-driven capabilities. Removing repeated bot builds and simplifying scenario management also supports the client’s goal of reducing long-term operating costs, while the embedded security mechanisms provide stronger control over personal data and integrations.

Methodology efficiency

WaveAccess uses a broader methodology benchmark under which a comparable discovery phase may take only 7 to 8 working days, compared with 3 to 4 weeks of manual analysis. The same benchmark estimates an acceleration of roughly 3 to 4 times and model API costs of approximately $80–150 for a similar volume of work.