Note · Agent-composed TV
Watch It in the Chat: Agent-Composed Storytelling over Live TV
Type "play KEYE Austin" into ChatGPT or Claude, and the local CBS station in Austin starts playing right in the conversation. Underneath it sit San Antonio, El Paso and the rest of STIRR's local news stations, nearest first. Then the assistant tells you what's on, and offers to switch.
The player is the part people screenshot. It isn't the part that matters. What matters is that nobody designed that screen. The assistant assembled it on the spot, around one viewer and one question, from live television. That is a different idea of what a streaming interface is, and live broadcast TV turns out to be the best place to try it.
Past discovery, past the paywall
Bitmovin's read on OpenAI's DevDay gets the direction right. Assistants are becoming where people decide what to watch, and "a player that survives beyond a single exchange, and fills the screen when you want it to, is the difference between a preview and something a person actually watches." We started from the same open pattern Bitmovin published with its Bitflix demo, and we're glad they did.
Where we part ways is the sequence. Their path runs discovery first, then a preview, then a handoff to the service, with in-assistant playback later, once identity and entitlements are solved. That sequence makes sense for a subscription service, because the hard problem there is the paywall.
Free, ad-supported TV doesn't have that problem. There's no account to link and no entitlement to check, so playback can happen in the conversation today. That moves the interesting question from "how do we get the viewer to our app" to "what should the screen be, now that the viewer never has to leave?"
Live TV is already structured
Most talk about AI and video is about generating it. We think the more useful near-term job is composing it: taking video that already exists and building the experience around it for each viewer. Live local news is the best raw material for that, for three reasons.
- It's live. "What's on right now" is a question an assistant can answer and a catalog can't.
- It's local. It's tied to a place, so "near me" and "near there" mean something, and the next station is a real suggestion, not a generic one.
- It's already built from parts. A newscast is a run of discrete stories, each with its own headline on screen, its own start and its own end. The structure an agent needs is sitting in the broadcast. Nobody has to invent it.
That last point is the one people miss. Television has always been composed. It's just been composed once, in a control room, for everyone watching.
Reframe or recompose
There are two ways to take a broadcast somewhere new. You can reframe it: carry the whole frame across, graphics and all, and fit it to the new screen. That's cheap, it works on any source, and it's the right call for archive and long-tail content.
Or you can recompose it: keep only what can't be rebuilt (the people, the place, the footage) and rebuild everything else as interface. The headline across the bottom of a newscast is data drawn as pixels. Recomposed, it becomes something you can tap. The ticker becomes a rail. The score in the corner becomes live state.
Recomposing is what makes a broadcast feel native on a phone or in a chat, instead of shrunk onto it. It's also why the hard part isn't cropping video. The hard part is getting the data back out of the picture, story by story.
Pull, not push
The obvious way to add AI to TV is to add more on top of it: overlays, pop-ups, autoplaying clips. We suspect that's the wrong default, and there's some evidence for it. In the EU's LinkedTV research on linking television to the web, which I worked on as an industrial partner, the single most-disliked element across every participant was motion on screen that they hadn't asked for.
So our working thesis is pull, not push. The broadcast plays, and depth (the story behind a headline, the other stations covering it, the clip you missed) waits until the viewer reaches for it. A chat is a natural place to test that, because the viewer is already asking, and every question is a pull. We'll find out where it holds and where a well-timed push earns its place. That's what testing is for.
Build the browser, not the OS
A fair question is whether the endgame is a new TV platform. We don't think so. The moat in streaming platforms is the marketplace, not the operating system, and the world doesn't need another one.
What it could use is a composition layer: one engine that decides what the screen should be, around live video, for one viewer, and renders it on whatever screen is in front of them. A phone, a TV, a browser, and now a chat window. ChatGPT and Claude aren't the destination for us. They're two display surfaces where the idea can be tried in public today, by anyone, with nothing to install.
What's live, and what's next
Here's what works today. You can ask for a station, a city, a genre or a title, and STIRR plays in the conversation, free, with no account. Local stations come with their neighbors, nearest first. Where a station publishes a program guide, the assistant knows what's on now and what's next.
Next is the depth layer: turning each newscast into a timeline of its stories as they air, so you can ask about the story you just saw and pull up the rest of it. That's the part we're building now, and it's where agent-composed storytelling stops being a phrase and becomes a product.
If you're a broadcaster, a station group or a builder working on the same problem, I'd like to compare notes.
Try it: STIRR in ChatGPT and Claude ↗ · Questions and ideas: info@stirr.com
Sources
Gozde Sahin, What OpenAI's DevDay Means for Video in ChatGPT, Bitmovin, 8 October 2026.