When we launched Thursday Night Football on Prime Video, the hard problem was never just getting a feed into the cloud. It was making the entire live workflow dependable when there was no time for ambiguity. I built Oracle Video Edge around the same reality: compute, transport, and operational control have to work together at scale.

That is the test I would apply to AI orchestration at IBC: can an operator understand what the system has built, control what it changes, and recover when something goes wrong?

In my earlier piece on what to expect from IBC, AI, cloud production, and interoperability were the obvious themes. Following the announcements and reporting from this year's show, the interesting detail was where vendors chose to put AI to work. Alongside tools for transcription, translation, search, and clipping, there was a growing ambition to let it coordinate the machinery around a live production.

On Friday, KPN's Just Hut warned that hyperpersonalisation could create an explosion of complexity if its business case and resource demands were poorly controlled. Sky's David Travis made the related point that AI had to become sustainable at the right price. More outputs are only a good business if you can afford to produce and operate them. IBC's report from the panel put that constraint alongside the promises.

AI moved closer to the control plane

One of the clearest examples was abbe, the AI-based broadcast engineer from swXtch.io. Its September launch coverage described an orchestration layer that takes a live-media request in natural language and provisions the infrastructure needed to carry it out.

As CEO Brent Yates put it in Sports Video Group's September 9 report:

“You describe what you want to accomplish, and abbe stands up everything needed to make it work.”

The company identified support for Microsoft Azure, Oracle Cloud Infrastructure, and AWS, with placement taking cost and latency into account. The two announced IBC demonstrations covered SRT ingest, monitoring, and global distribution; and AI audio processing using NVIDIA models. In the latter, abbe would provision the compute, networking, and security, while allowing operators to select, test, chain, or replace models. These are the company's described capabilities, rather than independently measured performance results. TV Tech's launch report sets out the scope.

There is some history here. swXtch was already describing a chat-driven “virtual broadcast engineer” through its AI Router at NAB in April, including integration with NVIDIA NIM and Holoscan for Media. IBC brought the abbe launch into a conversation that was already developing. The earlier product account matters because it gives us a longer period over which to ask what has improved.

And abbe was one example of a broader direction. Imagine's IBC plans put conversational AI into XVR and Aviator playout operations: bulk updates, operational queries, and filling playlist gaps. Its announcement explicitly described a governed Model Context Protocol service layer, with guardrails between the AI and playout automation and human oversight of decisions. It also announced an Appear VX–XVR demonstration exchanging media through MXL in a common cloud computing environment. Imagine's September 8 announcement connected the AI interface to the media infrastructure underneath it.

Dalet approached the problem through the content workflow. Its announced contribution to the AI for Live Sports and Beyond Accelerator combined Dalia, Dalet Flex, and InStream in a planned demonstration spanning ingest, analysis, compliance review, and publishing. The project description emphasised editorial oversight and governance. An Accelerator is a place to test an approach; participation alone does not establish its reliability through a season of live sport.

These systems have different jobs. Provisioning an SRT distribution path, changing a playout schedule, and approving a sports clip are not interchangeable operations. What connects them is that AI is being given access to actions with consequences beyond the chat window.

Natural language does not remove operational complexity

There is real value in describing an outcome rather than configuring every component by hand. A contribution feed for a pop-up event, another regional output, or an audio-processing pipeline can involve a tedious amount of repeated setup. Reducing that work could make teams faster and remove familiar configuration mistakes.

But a request such as “ingest this SRT feed, process the audio, and distribute it globally” leaves a lot unsaid. Which regions? Which credentials? What latency budget? Where can the content legally travel? How much redundancy, and at what cost?

The useful output is a reviewable execution plan. Before deployment, I would want to see the resources, routes, permissions, model versions, and expected spend. Once the workflow is running, I would want to know which decisions the system can make automatically and which require an operator.

Some vendors are already describing parts of this. swXtch's AI Router product page claims monitoring across the pipeline. Imagine explicitly describes oversight and guardrails. The next question is how those controls behave during a failure, including whether they expose the information an engineer needs to act. A monitoring claim tells us where to begin the evaluation; it does not finish it.

Consider a live cricket final with contribution feeds from the venue, several commentary languages, alternate audio mixes, regional rights restrictions, and millions of customers joining during the last five overs. This is a hypothetical workload, but it makes the operational questions quite concrete.

If latency rises, does the system add capacity, change a route, move an inference workload, or leave the path alone? Can the operator override it without disrupting the good outputs? If an audio model misbehaves, can the affected language return to the original commentary while the other versions keep running?

The last five overs are an inconvenient time for a philosophical discussion about what the prompt meant.

An approval process also has to fit the clock. I would expect routine actions inside an agreed operating envelope to proceed automatically, with pre-authorised recovery paths for known failures. Changes to rights, security, or the audience-facing output need different treatment. Requiring a human to approve every step can itself become a failure mode.

During an incident, the operator should be able to see the path from request to plan to actual state, including any partial deployment or failed action. “The AI decided” is not a sufficient incident report. Neither, to be fair, is “someone clicked something.”

Interoperability became more concrete

Support for Azure, OCI, and AWS gives abbe a broad cloud footprint. Moving an entire operational workflow between them still involves more than provisioning compute. Identity, timing, monitoring, contribution equipment, storage, and distribution all have to survive the move with behaviour the operator understands.

This is where the work around the Dynamic Media Facility, and its Media eXchange Layer, becomes relevant. MXL is an open-source SDK for exchanging media between software functions. Its implementation specifies how video, audio, and data are represented in shared memory, including their timing. It is a concrete interface engineers can build against. The MXL repository also makes the implementation available for inspection.

The EBU/AMWA IBC showcase description set out a production pipeline in an on-premises cloud, with ST 2110 streams entering and leaving the cluster. The design used MXL to exchange media between functions and NMOS to handle their connections, with Matrox, NVIDIA, Sony, TAG, and Wavelet Beam named as partners. That division of responsibilities is worth keeping straight: media exchange, connection control, and AI orchestration solve different parts of the workflow. AMWA's showcase description explains the arrangement.

NVIDIA's own IBC announcement connected MXL to Holoscan for Media, its reference architecture and developer toolkit for software-based live production. It also described a localisation reference workflow combining captions, translated audio, dubbing, synchronised video, and regional graphics. These are precisely the combinations that make timing and common interfaces important: a correct translation can still make a poor broadcast if it arrives after the picture it describes. NVIDIA's IBC update provides the technical context.

By Sunday, interoperability was also part of the awards story. MXL won IBC's Content Creation Innovation Award; the organiser's account identified CBC/Radio-Canada as a deployment. Reuters won Content Distribution for its move to event-driven, API-orchestrated news distribution using TVU Networks' MediaMesh. Those were useful developments for anyone trying to connect the architecture discussions to operational use. IBC's September 13 awards report records both.

An award does not establish a recovery-time guarantee, and MXL does not by itself make a complete workflow portable between clouds. But an implemented interface, participating vendors, and a named deployment give engineers something substantial to evaluate. CBC/Radio-Canada has also published hands-on MXL exercises, including audio and video applications, so the discussion can continue after the stands come down.

The less glamorous monitoring work deserves attention too. AMWA's IBC programme included multi-vendor demonstrations of NMOS BCP-008 minimum status reporting. Consistent equipment status is useful to both an operator and any agent acting on that operator's behalf. Before asking AI to interpret the whole facility, getting its components to agree on what is unhealthy seems a reasonable place to start.

Edge and cloud remain one design problem

A useful deployment announcement ahead of IBC came from Lithuania's LNK Group. Grass Valley reported that its five national networks had moved playout and media management to AMPP, with primary operations running locally in Vilnius. For LNK and BTV, the announcement specified a separate disaster-recovery deployment on AWS with Wasabi storage. The distinction matters: five networks migrated, but the release names two for that cloud recovery arrangement. Grass Valley's deployment account includes statements from LNK's technology leadership.

That is a practical example of local and cloud resources serving different operational needs. It provides evidence of deployed software-based broadcasting, while leaving the separate question of autonomous AI control open.

Placement becomes more complicated when inference joins the workflow. Archive analysis may tolerate a distant region and a longer queue. Live audio processing has to stay within the programme's timing budget. Redundant processing in two locations offers limited protection if both depend on the same failing contribution path.

There was an interesting additional direction in the work V-Nova described with swXtch: supplying a model with only the resolution or image region its task requires. If several models analyse the same feed, moving and decoding the full picture for each may spend bandwidth and compute unnecessarily.

The status is important. V-Nova's September 11 account said VC-6 integration into abbe was under way, targeted for the end of October, with pilot partners being recruited at IBC. It distinguished existing component work from the full workflow results still to be published. This belongs in the post-IBC watch list. V-Nova's account is refreshingly specific about what remains to be demonstrated.

For an operator, the eventual question is whether that selective processing saves money while preserving the accuracy and response time the production needs. A cheaper model path that misses the decisive moment is going to be difficult to explain to the rights holder.

What I would measure after IBC

The announcements establish an ambition, and the named deployments show that parts of the underlying software infrastructure are already doing useful work. In the abbe launch material, I did not find published live-event measurements for recovery time, placement overrides, or rollback under failure. That leaves a set of questions to test, rather than grounds to declare those capabilities absent.

I would start with five measurements:

  1. Time to deploy: Compare an approved, redundant, monitored workflow with the same workflow built manually. Include configuration review and validation, not just the moment a resource starts.
  2. Time to recover: Introduce a failed contribution path, unavailable model, or lost region. Measure the audience-visible interruption and whether the operator can recover the affected output without breaking the others.
  3. Operator visibility: Trace a request through its plan, resources, routes, permissions, and model versions. Check whether the displayed state stays accurate when deployment only partly succeeds.
  4. Change safety: Exercise approval policies, audit history, and rollback. Verify that a return to the last known good configuration also restores working media, timing, and access.
  5. Cost accuracy: Compare the estimate with the bill at the required quality and latency. Include bandwidth, egress, standby capacity, and inference; repeat the exercise during failover.

What I take from IBC 2026 is a more specific version of the question I started with. AI is being connected to provisioning, playout, and publishing, while MXL and NMOS work on the interfaces those operations depend on. There is enough substance here to justify serious trials.

For an abbe evaluation, I would build the SRT and audio workflow, establish that it meets the production requirements, and then deliberately break a dependency. I would want the operator to explain what changed, take control, and restore the output from the information the system provides. That would tell me much more about its readiness for a live match than a successful prompt alone.