Part One: The Remote Producer is a Network Problem

The first livestream kits were not glamorous. They were yellow hard cases, foam inserts, cables, adapters, a MacBook, an ATEM Mini Pro, and a laminated setup diagram that looked more like field medic instructions than a media production plan. In 2022, as conferences were returning in person after the long, warped tail of the COVID pandemic, we still needed to offer an online option for the scientific community. The audience had changed. The expectations had changed. A scientific conference could no longer be only for people in the room. Somewhere out there were researchers who could not travel, institutions with limited budgets, speakers with complicated schedules, and entire communities that had learned, sometimes grudgingly and sometimes gratefully, that a conference could reach beyond its walls.

So we built kits.

The original kits were extremely basic by design. They did not include cameras. They were built to be scalable, repeatable, and understandable by local AV technicians who might encounter them in a hotel ballroom, a university auditorium, or some venue closet where all cables go to be spiritually tested. The job was simple: capture the presentation feed, route it through a small livestream system, and make sure a remote audience could see the slides and hear the talk. It was not television. It was not cinema. It was infrastructure.

I remember sitting in the main conference room cutting foam for exactly six kits. No more, no less. Literally cutting and gluing foam by hand, carving little gray rectangles for laptops, switchers, power supplies, cables, adapters, and all the other electronic barnacles that cling to portable production systems until my head ached from the fumes. It was tedious in the way only necessary work can be tedious. Measure, cut, test fit, swear quietly, cut again. By the end, the room looked like a raccoon had attacked a soundproofing panel. But it was also a labor of love. There is a strange satisfaction in turning an operational headache into something that can be packed, shipped, opened, understood, and used.

We made laminated setup diagrams too. That detail matters. A kit is not just hardware. A kit is a set of assumptions made physical. The diagram said: plug this into that, send this signal here, connect the laptop there, check this before you start. It translated a production workflow into something portable. The goal was not to make every AV tech a livestream engineer. The goal was to make the correct setup more obvious than the wrong one.

That was the first version: a scalable livestream kit for scientific conferences at the awkward hinge between pandemic-era virtual events and the return of in-person meetings.

But systems age in public.

What begins as a clever workaround becomes infrastructure. What begins as "good enough for now" becomes the thing people depend on. And once a workflow becomes dependable, the next problems appear. The kits improved. Cameras entered the picture. Remote producers began connecting to the livestream laptop to operate OBS and ATEM Software Control directly. The show format became familiar: open on the speaker or the chair, display a lower third, cut to slides for the talk, return to camera for Q&A, show a slate during breaks, repeat.

This is where the problem changed shape.

At first, the hard part was making livestreaming portable. Later, the hard part became operating the portable system reliably at scale. A remote producer connecting over RDP can absolutely run a show. We did it for hundreds of conferences. It works. Until the venue network is bad. Until the person operating the show does not really understand the production grammar. Until the system depends on a human being somewhere else clicking around a laptop they cannot physically touch.

That is when I started to see the remote producer less as a person and more as a network dependency.

That sounds colder than I mean it. The point is not that the people are unnecessary. The point is that the job we were asking them to do had become surprisingly narrow. For many of these sessions, the production pattern is not especially creative. It is almost ritualistic:

Intro = camera
Talk = slides
Q&A = camera
Lower third = first 8-12 seconds of speaker camera intro
Break = slate

That is not a full television control room. That is a grammar. And grammars can be encoded.

The obvious version of this idea is: "Can AI replace the remote producer?" But I think that framing is too broad, too theatrical, and honestly too misleading. It makes the problem sound like general intelligence when the more interesting problem is local competence. I do not need an AI that can direct the Oscars. I need a local system that understands a formulaic scientific session well enough to switch between camera, slides, and slate without requiring someone to remote-control the laptop.

The goal is not to create a digital auteur. The goal is to move production intelligence onto the machine that is already sitting in the room.

That distinction matters. A general-purpose computer-using agent clicking around OBS would be fragile. It would inherit every risk of the interface: window focus, screen resolution, accidental dialogs, latency, changed layouts, and the thousand paper cuts of GUI automation. A better system should not "use the computer" the way a remote producer does. It should operate the production stack through explicit controls.

Guess what? OBS has an API. ATEM switchers can be controlled through structured commands. A run of show can describe the session. Audio can be transcribed. Video sources can be sampled. Frames can be checked for black, frozen, slide-like, camera-like, or text-heavy content. A lightweight vision model can classify ambiguous shots. OCR can read slide titles or visible graphics. A policy layer can decide whether to hold, cut, preview, or alert. And every recommendation, command, confirmation, rejection, and state change can be logged.

That is the shape of the thing I have been calling Autonomous Producer.

Not because it should immediately be trusted to run everything by itself. It should not. At least not at first. The first useful version is probably much more modest: a local command relay that lets a staff member type cam, slides, l3, or slate while watching a multiview. The agent validates the command, executes it locally, and logs the state before and after. That alone reduces the need for full remote desktop control. It turns the remote operator from a producer into a cue caller.

The second version watches too. It observes the current OBS/ATEM state, samples the camera and slide feeds, listens to the transcript, checks the run of show, and recommends actions. "Q&A likely. Switch to camera?" A human confirms. The system logs the recommendation and the decision. Over time, those moments become evaluation data. The agent is not being trained on vague memories of mediocre switching. It is being tested against a clear production standard.

Only after that does autopilot become interesting.

And even then, autonomy should be narrow. Formulaic moments first. Slides to camera at Q&A. Camera to slides when the presentation begins. Lower third timing during a speaker introduction. Break slate when the session ends. Hold when the source is black or confidence is low. Alert when the run of show and live evidence disagree. In other words: not artificial creativity, but disciplined routine.

The longer I sit with this idea, the more I think the important word is not "autonomous." It is "producer."

A producer, in this context, is not merely a switch operator. It is the layer that knows what is supposed to happen, what is currently happening, what tools are available, and what action is safe to take next. The old laminated setup diagrams did a primitive version of that. They carried knowledge from the person who designed the kit to the person setting it up in the field. Autonomous Producer is the same instinct pushed further: take the operational knowledge that lives in people, diagrams, habits, and frantic Slack messages, and encode it into a local system that can help run the show.

The foam-cutting mattered because it made the kit portable.

The diagrams mattered because they made the setup teachable.

The next step is making the production itself legible to the machine.

That is the real project. Not replacing human judgment with a black box, but turning a repeatable livestream workflow into something observable, explainable, and eventually executable by the system already sitting at the center of it. A yellow case full of cables was the first container. Now the container is a local agent with a run of show, a pair of eyes, a set of ears, and a very small list of things it is allowed to do.