MWS removes noise from calls inside the carrier network, with 20 ms to process each packet

The phrase “let's plug in a neural network” sounds simple until you hit milliseconds, tokens and a poorly defined goal. At the eleventh MWS meetup, three talks dealt with exactly these obstacles: in calls, in architecture documentation and in strategic planning. Here is what practitioners should take away.

Noise is removed in the network, not on the phone

Maxim Maslennikov, Cluster lead Architect at MWS, described a noise suppression system that runs on the carrier side. It works without apps and without any involvement from the smartphone: the voice is cleaned before it reaches the other party. The idea came from an incident on the subway, when a company executive could not have a proper conversation because of the noise.

Implementation turned out to be the hard part. In 2G and 3G, voice travels over a dedicated channel, and there the team considered routing the call through a special prefix. In LTE, calls go through IMS, meaning IP packets, and the team built its own media service into that path so the voice stream passes through it. The phone number does not need to change.

The main constraint is time. Each packet has to be received, converted into a format the neural network can use, cleaned and sent on within roughly 20 ms. If the system misses that window, callers hear clicks and dropouts. The model also works on a continuous conversation rather than on separate recordings, so the team had to adapt it to keep state between fragments.

Off-the-shelf open speech enhancement models did not work without modification. The team fine-tuned them on recordings of real-world noise, including a running compressor. To avoid burning GPU on every conversation, they added a small observer model that decides when heavy cleaning is needed and when a lightweight algorithm is enough. There is also a geographic catch: the farther the processing node is from the subscriber, the harder it is to stay within the latency budget.

There are downsides too: the voice changes slightly after processing, though it stays intelligible. The solution is already in production, but MWS does not plan to disclose the model weights. The next task is to restore voice that is lost in transmission over the network.

Agents that fix documentation

Evgeny Artemyev, Stream lead Architect at MWS, showed a tool that tackles a classic problem: the code has moved on, while the architecture documents are stuck in the past. New microservices and changed APIs never make it into the system description, and it stops matching reality.

The tool pulls data from repositories, DevOps, Jira and Confluence. One agent analyzes changes and selects relevant materials, and a second consolidates them and drafts update proposals. An orchestrator manages the work, and a separate layer strips confidential information before anything is sent to the model. The output is YAML and Markdown files, which can be used to look for outdated technologies, trace links between systems and assess risks. The architect decides which edits to make.

The most useful part of the talk was a comparison of two modes. In the deterministic mode, developers define the steps and tools in advance. In the non-deterministic mode, the agent decides what to do on its own. In an experiment with Claude, the second option performed worse: the model spent more tokens, took unnecessary actions and held the structure less well. So the team chose LangGraph, where the stages and allowed transitions are fixed, and several agents can work in parallel. The price is harder debugging: you have to track the state of each agent and save intermediate results.

Another trap is checking data before it goes to the model. You can do this with regular expressions or with a classifier model. But in one project, a classifier on CPU took three to four seconds against a 500 ms limit.

The “Hypothesis Map”: a human still sets the goal

Alexander Byndyu presented a methodology that links a company's goals, its resources and external conditions to strategic bets. It is built on a linked SWOT analysis. His main thesis: speeding up individual operations does not guarantee business growth. If an email takes five minutes to write instead of two hours, that saves time, but it does not necessarily add revenue.

In a practical case, AI built a map from a small PDF and landed close to reality. But everything hinges on how the goal is worded: an error there leads to wrong metrics, and it shows immediately when compared against a reference. In the second demonstration, a model with skills from GitHub asked clarifying questions and produced a map with an interface prototype.

It got the subject wrong, and that had to be fixed by hand. When it turned out that one of the trends did not exist, the data was replaced and a new version was ready in about ten minutes. The value of the prototype here lies in the speed of feedback, not in the quality of the implementation.

The limitations are stated plainly: some links are configured manually, and the user has to know the methodology in order to steer the model and evaluate its answers.

What to take away in practice

At the end, participants brainstormed services built on MWS technologies: a manager's assistant, a voice concierge, a translator and an assistant for getting through to government agencies. For scenarios such as recording agreements, the question of the legal validity of the result remains open.

The takeaways boil down to three rules. For real-time systems, first calculate the latency budget and GPU cost, and use a cascade of a light model and a heavy one. For agents, start with a rigid graph and loosen it only where justified, measuring the cost of safeguard checks in advance. For strategic tasks, spend time on wording the goal, because the quality of everything else depends on it.

A caveat: this is a retelling of the developers' own talks. No independent measurements of noise suppression quality or agent accuracy are provided.