Inspiration
A friend of mine directs teleseryes (Philippine daily television series). The pace is relentless: two or three location shoots in a single day, every day.
I asked him what actually gets in the way. He talked about cameras.
The way they shoot, the cameras are wireless and everything goes back to a main server so the director can check the take in real time. And the thing he kept returning to was that they can't tell, in advance, whether a location will hold that connection. They arrive somewhere outside Manila, often somewhere remote, and they find out by trial and error: set up, test, move things, test again.
What he wanted was to look at a location and know "will this work, and where should the cameras go?"
The second thing, which he described as helpful rather than critical, was knowing mid-shoot when something is going wrong with a camera, before it fails rather than after.
Both problems have the same shape. The information needed to answer them exists in the telemetry. Signal strength, distance, environment, battery, thermal, stream quality — it's all being measured already. Nobody reads it, because reading instruments is not a job anyone on a working set has time to do, and because raw readings don't answer a director's question anyway. "-76 dBm" is not an answer to "where do I put Cam 3?"
So Omnisight isn't more data. It's a reader for the data that already exists, one that answers in the terms a director actually thinks in: before the shoot, during it, and after.
What it does
Omnisight reads wireless camera telemetry and answers a director's questions in a director's language.
The call sheet is the configuration. Every production already distributes one the night before: locations, setups, camera assignments, operators, which battery packs are getting old. Paste it in and Omnisight reads it, then checks it against what the fleet actually recorded. Nobody types anything twice.
Before: will this location hold?
"Here's tomorrow's call sheet. What should I expect?"
You will likely lose your monitor feeds on Cam 3 (Kiko) and Cam 5 (Jorge). Today in the > Ancestral House, the stone walls completely froze Kiko's monitor and turned Jorge's feed into a stuttering mess. Tomorrow they are pushed even further out: 70m and 90m into the far wing. Because they record locally your takes are safe, but expect to shoot blind on those two monitors. Have the utility team set up a relay closer to the far > wing before you block.
Kiko's battery will not survive the block. The call sheet lists his pack as "aging," and our > telemetry confirms it: today it drained at double the rate of the rest of the fleet. It will die about three hours into this four-and-a-half hour block. Swap it before the first setup, or schedule a hard swap no later than 09:30.
Casa Herrera appears nowhere in the telemetry. That answer is the call sheet plus what the cameras actually did in comparable conditions. And it's the question the director named first, because the alternative is trial and error on the clock.
During: what is about to fail?
Omnisight reasons from trend rather than current value: a camera at -76 dBm and falling matters more than one sitting steady at -79. It reports battery in minutes, never percent alone, using each pack's measured drain rate, and flags packs fading faster than the rest of the fleet.
It also checks whether a camera is recording locally before assigning severity, because that single fact decides whether a dropout means "keep rolling, you have lost your monitor" or "cut."
After: what should change tomorrow?
Where and when signal was lost, whether any footage was at risk, which packs underperformed, and what to do differently at that location next time.
The product is the translation. Not "CAM-03 is at 69% battery, draining 0.43%/min" but "About two hours forty on Kiko's camera — but that pack is fading at nearly double the fleet rate, so treat the estimate with caution and swap it at the next break."
And knowing when to stay quiet. When every camera drops offline at once, the unit is in a van between locations. That is a convoy, not five failures. A tool that cries wolf during a planned transit gets switched off by lunch, so the suppression rules are specified as carefully as the alerts.
How we built it
Telemetry flows into Grafana Cloud: signal strength, battery, temperature, link state, bitrate, dropped frames, latency, and whether each camera is recording locally, sampled every 30 seconds across a full shoot day. The fleet roster and the day's setups aren't hardcoded: they're parsed from the production's call sheet.
The agent reaches that data through two MCP servers.
The first is grafana/mcp-grafana, Grafana's official MCP server, deployed to Cloud Run over streamable-HTTP and running read-only against the stack. That's the runtime connection to Grafana.
The second is Omnisight's own, a Cloud Function wrapped in MCP that queries Grafana's /api/ds/query and computes what point readings cannot express: signal trend in dBm per minute, battery drain rate, estimated minutes remaining, and pack-swap detection so a fresh battery isn't mistaken for a fault.
The split is deliberate. The official server gives the agent the Grafana stack. The custom one gives it rates of change, because "26% battery" and "37 minutes left" are the same fact, but only one of them is an answer a director can use.
On top sits a Gemini agent built in Agent Studio on the Gemini Enterprise Agent Platform. Its system prompt carries the actual product thinking: the dBm thresholds, the drain-rate multiplier that marks a pack as fading, the suppression rules for transit and warm-up and brief blips, and the rule that local recording changes everything.
The whole thing runs on a public page anyone can open: no Google account, no console. It's a Cloud Run service running the same ADK agent, with a call sheet panel beside the conversation. That's what makes it usable by an actual director rather than by me.
Challenges we ran into
I built a different thing first. My initial idea was a civic engagement agent, built around frameworks from my own community organizing work: stakeholder mapping, coalition building, local storytelling networks. It was a solution I found interesting in search of a problem someone actually had, and I scrapped it with nine days left when a TV director friend described a problem he lives with every day.
A timezone bug that looked like missing data. For two days the dashboard showed only a fragment of the shoot day and I assumed the generator was truncating. It wasn't. Grafana was parsing naive timestamps as UTC and rendering them in Manila time, pushing the whole day eight hours forward and out of the visible range. What gave it away was a single value: a reading stamped 15:00 that belonged to the 07:00 row. The fix was one setting. Finding it took far longer.
Attaching a custom tool to an agent. Agent Designer has no OpenAPI field, so a plain HTTP function can't be attached. Wrapping it as an MCP server was the route.
Too many tools made the agent worse. Connecting the official Grafana server gave the agent 60+ new tools, and it used them. A single "what's my fleet status?" produced 26 tool calls, wandering through datasources, Prometheus metrics, Loki labels and Grafana's own documentation before answering, and the answer was vaguer for it. Instructing it to stop didn't work. Cutting the exposed tool set down with --enabled-tools did. Capability and usefulness turned out to pull against each other.
Building around a working schedule. My director friend is in the middle of a taping season, shooting daily, so the sit-down interview I'd hoped for wasn't going to happen inside the deadline. He'd already given me the important part: the problem, and the phases of a shoot day where it bites. I built from that and flagged the one assumption I couldn't verify. He sees the working thing next, which is a better use of his time than answering hypotheticals, and a better way to get honest answers, since a director looking at a real tool will tell you in thirty seconds what's wrong with it.
Accomplishments that we're proud of
It answers a question about a place it has never been. Given tomorrow's call sheet for a location that appears nowhere in the telemetry, it works out which monitors will drop, why, and what to do about it — by matching the sheet's distances and wall conditions against what the fleet actually recorded in comparable setups. That's the question the director named first, and it's the one I least expected to get working.
It caught a battery failure by combining two weak signals. The call sheet says Kiko's pack is "aging." The telemetry says it drained at double rate. On their own, neither is alarming. Together they mean the pack dies three hours into a four-and-a-half hour block, so swap it before the first setup. Nobody wrote that rule.
Thirty-one minutes of warning. In the simulated shoot day the warning threshold on CAM-03 is crossed at minute 134. The feed is lost at minute 165. Half an hour is enough to move a relay, reposition, or reorder the shot list.
It knows when not to speak. Asked about the fleet during the convoy window, it doesn't fire five alerts. It recognizes transit and pivots to what's actually useful in a van: battery readiness for the next setup.
Anyone can try it. It's a public URL, not a console demo. A director can open it on his phone between setups, paste tomorrow's call sheet, and ask.
The pipeline is real. Simulated telemetry, but the agent reaches it through Grafana's own grafana/mcp-grafana server running on Cloud Run, plus a custom MCP server doing the rate calculations. Every answer comes from a live query. Nothing about the architecture changes when real hardware replaces the generator.
What we learned
The insight is the product, not the plumbing. The dashboards took an afternoon. The system prompt — the thresholds, the suppression logic, the severity rules — is where the thing actually lives.
Suppression is harder than alerting. Anything can raise an alarm. Knowing when silence is the correct output takes domain knowledge, and it's the difference between a tool people keep and a tool they mute.
One fact can restructure an entire severity model. Whether cameras record locally decides whether a dropout means "keep rolling, you have lost your monitor" or "cut." That single flag re-rates half the alert rules.
Don't ask people to tell you what they've already written down. The call sheet already had the roster, the locations, the distances, the pack conditions. The moment I stopped treating configuration as something a user types and started treating it as a document that already exists, the product got noticeably better — and the pre-shoot question became answerable.
Ask the practitioner first. Every good decision in this project traces back to one conversation with someone who does the work.
What's next for Omnisight
Read the call sheet as it arrives. Right now it has to be structured text. Real call sheets are PDFs and images in a hundred different house formats, sent out the night before by the 2nd AD. Omnisight should accept the file as sent, not a version someone reformatted for it.
Be there at the ocular. The call sheet arrives the night before, when the location is already locked and all that's left is mitigation. The moment that actually matters is weeks earlier, at the recce, when a location manager walks a space with a phone and the decision is still open. That's when moving the base station is free, when a relay can go into the budget, when a room can be ruled out entirely. Omnisight should be in that walk: stand in the doorway, point at the far wing, and be told it won't hold at 70 metres, while there's still time to do something about it.
Per-location memory. A teleserye unit shoots the same locations over and over. Omnisight should remember that the second-floor bedroom at that ancestral house always costs 8 dBm, that the market stalls block the northeast approach, that the rooftop is fine until the neighbouring building's WiFi wakes up at seven. Right now every location assessment reasons from comparable conditions. It should reason from that location's own history.
Sharper pre-shoot input. Location advice currently comes from telemetry alone. Floor plans, an RF site survey, even terrain data for provincial shoots would turn "expect dropouts at 70 metres through thick walls" into "put the relay in the second doorway, not the first."
Speak first, quietly. Right now the director has to ask. The valuable version warns without being asked. But a director watching a take does not want to be talked to. The right form isn't a voice or a notification, it's something glanceable: a strip along the edge of the monitor turning amber, information they can take or ignore without breaking the scene.
Real hardware. Live transmitter telemetry in place of the generator. The transmitters already report their own health to the receiver; the only manual step is a one-time pairing of each device to a camera slot. After that, the call sheet supplies everything else.
Confirm the assumptions with the director. Whether cameras really do record locally on this unit, how severity should be ordered, and whether a mid-take alert is useful or unacceptable. Showing him a working tool will produce better answers than any questionnaire would have.
Built With
- agent-development-kit
- artifact-registry
- broadcast
- cloud-build
- cloud-functions
- cloud-run
- cloud-shell
- flask
- gemini
- gemini-enterprise-agent-platform
- github
- google-cloud
- grafana
- grafana-cloud
- infinity-datasource
- json-rpc
- mcp
- model-context-protocol
- observability
- python
- telemetry
- time-series
Log in or sign up for Devpost to join the conversation.