Rescuing a Multi-AI Content Platform: From Disconnected Integrations to One Working System

The client came to us for a software rescue service with an already-built product: a platform where a user submits their own text – a script, a message, a piece of written content – selects an AI avatar, and gets back a finished video of that avatar delivering it. By the time we were brought in, the individual pieces existed – a large language model to process and refine the submitted text, a text-to-speech service to generate the audio, and an AI avatar provider to generate the on-screen delivery.

Each of these had been integrated and tested in isolation. None of them, run together, reliably produced a finished video.

The problem wasn’t missing AI functionality; it was the absence of anything that prepared and moved data between the services that already existed.

A successful call to one API only confirms that a single service can take an input and return a response. It says nothing about whether that response is usable by the next stage. In this platform, the LLM’s output was too large and unstructured to hand directly to the text-to-speech service, which needed a short, clean script and an instruction about delivery tone – not a wall of raw analysis. Nothing in the system did that translation.

The integrations weren’t broken. They were disconnected. And the previous implementation had also accumulated unnecessary complexity around them, making the actual break in the chain harder to see.

We reviewed each integration individually – what it received, what it returned, and where its output was supposed to go next. This made the actual failure points visible: not the AI calls themselves, but the handoffs between them.

We designed and implemented the orchestration logic that the platform never had – code responsible for taking the output of one AI service, transforming it, and preparing it for the next. Concretely, this meant: cleaning and structuring the user’s submitted text before it reached the LLM, so the response stayed focused and cost-efficient; extracting a short, delivery-ready script and a detected tone from the LLM’s output; and passing both to the text-to-speech stage so the generated voice matched the tone of the content, with the user able to review or override both the script and the tone before final generation.

Some of the existing logic worked and stayed untouched. Other parts existed only because the missing connection layer forced earlier workarounds. We removed that accumulated complexity component by component rather than rewriting the platform from scratch – reducing the system to a clear, traceable sequence: user text in, processed script and tone out, audio out, combined audio-and-avatar video out.

Testing each service in isolation had not caught how they behaved as part of the complete process. Once the pipeline was connected end to end, some of the originally selected text-to-speech and AI avatar providers proved unstable – failing to return audio, stalling mid-process, or producing outputs that couldn’t be reliably combined. We tested alternatives against the same full sequence and replaced the providers that couldn’t complete their part of the process consistently, not just the ones with the weakest isolated demo.

The initial estimate was that the pipeline could be stabilized in around three months, as general API integration/stabilization. It took four to five months to reach a version that ran consistently end to end.

Two things drove the difference. First, part of the existing implementation – the avatar-generation stage in particular – was less complete than it had looked from the outside, and had to be built out further before it could be connected to the rest of the sequence. Second, replacing a provider mid-pipeline is not a like-for-like swap: a new text-to-speech or avatar service means a new API shape, new response format, and new integration and testing work, done against the full sequence rather than in isolation.

The extra time went into work that made the difference between a demo and a production system: a pipeline that holds up for every user, every time, without depending on someone checking each stage manually.

Several of the original providers performed well during manual, one-off tests. That wasn’t the bar this platform needed to clear. Every video is generated on request, by a different user, with different text and a different avatar – which meant every tool in the pipeline had to be evaluated against a different question: not “does this produce a good result once,” but “does this consistently accept the input the previous stage prepared, return what the next stage needs, and complete without getting stuck – for every request, not just the test cases.”

That question is what ultimately determined which providers stayed and which were replaced.

Multiple working AI integrations are not the same thing as a working AI product. The client already had the individual pieces – an LLM, a text-to-speech service, an AI avatar tool – each capable of doing its job. What was missing was the layer between them: the code that decides what one service actually needs from the last one, transforms the data accordingly, and keeps the sequence reliable for every video a user creates.

That connection layer, not any single AI call, is what turned four disconnected integrations into one working platform.