What Live TV Taught Me About Automation

The AI Is the Easy Part

In live television, there is no second take.

When a show goes on air at 7pm, everything either works or it doesn't, in front of everyone, at once. I have spent the last five years in that environment - designing virtual sets and rebuilding studio workflows for LN24, and more recently for BX1 and Fun Radio. It is a demanding place to learn, and it shaped how I think about every system I build today.

This is the first post on this site, so it seems right to start with how Sayeret came to exist.

It started with creative work

AI arrived in my world through the creative side first, as it did for most people in production.

Things that used to take days started taking hours. A 3D sequence that would have required a week of modelling and rendering became an afternoon. Subtitling a full episode, once an entire day of manual timing, collapsed into a process that ran while I worked on something else. For anyone who has spent years watching talented people burn their time on repetitive craft, that shift is impossible to ignore.

So I went further. I started testing, building, breaking things, and learning properly - not as a spectator of a trend, but as someone who needed these tools to hold up under real production pressure.

Then I noticed where the time actually went

Here is what surprised me.

Once the creative bottlenecks started loosening, the remaining delays were not creative at all. They were coordination. Files moving between people. The same information retyped into three different systems. Someone waiting on someone else to confirm something before anything could continue. Work that nobody enjoyed, that required no skill, and that consumed entire afternoons.

The interesting problem was no longer "how do we make this render faster." It was "why does a five-minute task take an hour of someone's day."

That question turned out to have the same answer almost everywhere I looked.

The constraint problem

The most useful thing broadcast taught me is this: generating output is not the hard part.

A model can write a convincing email, propose a schedule, draft a summary, produce an image. That capability is widely available now and it gets better every month. It is not where the difficulty lives.

The difficulty lives in the constraints. Every team that has been operating for a few years carries a set of rules that exist nowhere in writing - or that exist in a document nobody outside the team has ever read. How much equipment is actually available. How long you need between two operations. Which client gets an invoice and which gets a payment link. What you never, ever do on a Friday afternoon.

A system that ignores those rules produces output that looks excellent and is completely unusable. Worse, it produces it confidently, at scale, and someone has to clean up afterwards.

Building something that works means encoding the constraints first and generating second. In a control room, that meant automating the studio to the point where a single director can run an entire live show - sets, graphics, camera moves - from one position, live, with no technician standing by. Not because the automation is clever, but because every constraint of that room was mapped before a single thing was automated.

Why this isn't just a broadcast story

For a long time I assumed this was specific to my industry. It is not.

Over the past two years I have built agents, internal tools and integrations for clients well outside media, and the shape of the problem is identical every time. A team is spending hours on work that follows a pattern. The pattern is known but has never been written down. The tools they use don't talk to each other, so a human becomes the connective tissue between them. And everyone has quietly accepted this as the cost of doing business.

The industry changes. The vocabulary changes. The structure of the problem does not.

That is why Sayeret works across sectors rather than staying in the one I came from. Live broadcast was a good training ground precisely because the tolerance for error is close to zero - but the systems that survive that environment work anywhere.

What we actually do

We start by mapping how a team works today. Not how the process is documented, not how it was designed five years ago, but what people actually do on a Tuesday morning.

From there you get a prioritized list of what can be automated, and you choose the order. Then we agree on a number of days per week or per month, depending on how fast you want to move. Transparent rate, no retainer, and every subscription stays in your name.

We build around the tools you already use. If something in your stack turns out to be unnecessary along the way, we say so.

The point of all of this

Automation gets talked about in terms of efficiency, headcount, and scale. Those are real, but they are not what motivates me.

What motivates me is watching skilled people get their time back. The journalist who can report instead of renaming files. The producer who can think about the show instead of chasing confirmations. The team that stops losing its afternoons to work that should never have been theirs.

The technology is ready. What is still missing, in most organisations, is someone willing to sit down and understand the work before automating it.

That is the job.