It's a few hours before a delivery deadline and the work has piled up. Somewhere in that pile is a piece of work that's about to miss its deadline, unless someone pushes a different piece back to make room. That's the exact moment I built this for.
Three out of five. That's how often Shot-Delivery Guardian, the system I built for Google's Agentic Cinema hackathon, picks the right answer when it's the one making that call, in real tests against the actual running system, not just on my laptop. But here's the number that matters more: zero broken rules. It never once picked a piece of work the client had already signed off on. It never once picked something other work was waiting on. It never once touched anything the director had flagged as important.
The AI never got an important decision wrong, because I never let it make one.
Picture a movie or TV show going through its last steps: editing, effects, color, quality checks, then handoff to the streaming service. If one of those steps backs up, something is now going to miss its deadline unless a person delays something else to make room. That choice has to happen fast, and it can't touch anything the client already approved, can't hold up something else that's waiting on it, can't be the one thing the director cared about most. Right now, a person does this by hand, checking a bunch of screens at once, usually in a hurry.
So I built a system that watches the work as it moves through each step, notices when a deadline is about to be missed, figures out why, and says which piece of work is safe to push back.
Here's the part I care about most: an AI can be great at figuring out what's going on. It shouldn't be the thing that makes the final call on something with real money or a real contract riding on it.
It's tempting to just hand the AI everything: here's what's happening, tell me what to delay, go. I didn't do that. The actual choice comes from a short, fixed list of rules, written as plain code, not from the AI's own judgment:
def score_bump_candidates(shots):
eligible = [
s for s in shots
if not s["client_approved"]
and not s["director_flagged"]
and not has_downstream_dependents(s, shots)
]
return sorted(eligible, key=lambda s: slack_hours(s), reverse=True)
In plain words: it throws out anything the client already signed off on, anything the director cared about, and anything other work is waiting on, then picks whichever of what's left has the most spare time before its own deadline. The AI runs this rule and reports the answer back, word for word. It doesn't get to argue with it or dress it up to sound more sure of itself than it is.
I split the system into eight small pieces, one each for intake, rendering, color, quality checks, delivery, scheduling, a test generator, and the AI itself, instead of one giant program, so a slowdown in one place can't take down everything else with it. Between them sits something like a waiting line, because work moves at different speeds in different places, and a slow spot shouldn't block everything behind it.
Every one of those eight pieces reports what it's doing the same way, so I didn't have to build a different reporting system for every tool watching it.
I used three different kinds of monitoring, because one wasn't enough. One tells me how bad the backlog is overall. Another tells me which specific pieces of work are involved and what I know about them, like who approved it and when it's due. A third tells me exactly where, inside one piece of work's journey, the time got lost. No single one answers the whole question.
To let the AI ask all three of these tools questions, and write its answer back onto the same dashboard a person already watches, I used one shared connector instead of building three separate ones by hand. It also logs in on its own, with no person needed to click anything, so the whole thing can kick off automatically the moment something looks wrong.
The AI is doing the part it's actually good at. If it's not making the final call, why have it at all? Turning "the queue is packed and barely clearing" into something a person can act on in five seconds, that's explaining, not deciding. It's also doing the legwork: check the first tool, then the second, then the third, run the rule, write it up. A plain script could do that same sequence in order. It just couldn't explain itself in plain English while doing it.
The answer shows up as a note right on the dashboard the person on call is already looking at. No new place to check.
The cleanest demo isn't always the most convincing one. During one real test, the system hit a real problem reaching one of its three tools halfway through. It said so, plainly, in its own words. It didn't hide the gap, and it didn't guess. It used what it could still get from the other tools, and still gave one clear answer: this exact piece of work, with about an hour of spare time before its deadline, safe to push back.
That's a better proof than a clean run would've been. The fixed rule didn't need the AI to get everything right. It just needed whatever real information made it through.
So, the honest numbers: 3 of 5 real tests matched what the fixed rule alone would've picked. About 44 seconds on average to look into a problem and respond, timed against the real live system. Zero broken rules across every single test.
60% isn't a number I'd normally want to lead with. But it's real, it came from a live system doing real work, and I didn't round it up. I'd rather show an honest 60% than a demo that only ever shows the one time it worked.
Let the AI look into things, explain them, and handle the steps. Keep the piece that actually decides, the one touching money or contracts, as a fixed rule the AI can't talk its way around. It doesn't need to be trusted with the decision to be useful. It just needs to be trusted to explain one.
Code's at github.com/dannwaneri/shot-delivery-guardian, MIT licensed.
Top comments (2)
Zero broken rules is the number I trust, and the 60 percent match is almost beside the point. If the rule is the only thing allowed to pick a shot, the model only has to fetch evidence and not talk itself around the filter. The two misses sound like missing inputs, not a bad decision. The demo where one tool died mid run is the one I would show a producer, because it still named one safe bump instead of guessing.
That's exactly it. The 2 misses trace back to the agent's own output ending before it wrote the final answer not the scoring function picking wrong. The filter never saw a bad candidate, it just didn't get handed one in time.
And yeah, the mid-run recovery is the one I'd lead with too. It shows the design holding up when something real actually broke, not just a clean run going right.