Let your agent cook by giving it the recipe

Source: Mux•

Let your agent cook by giving it the recipe

We've shipped a prompt library to give your agent the exact recipe for common use cases built on Mux. The evals tell the whole story.

Your buddy calls and offers to make you a birthday dinner. Score! (and, happy birthday, you look great for your age)

You're feelin' something with some zing, so you grabbed some curry ingredients from the local specialty shop, half of which your friend has never cooked with before, but you're sure they'll figure out something delicious because they're a good cook.

And they do! But honestly, it only turned out… decent. You're a good, grateful friend, and won't say anything to them about it… but if only the shop owner had tucked their own recipe card in the bag, your friend would have made the shop’s signature dish, guaranteed to blow your mind.

If you're building with Mux these days, there's a good chance you're holding the ingredients and your coding agent is the chef at the stove. You ask it to add protected playback or clip a podcast, and it reads our docs, picks an approach, and gets something working in your codebase.

The trouble is, it has no way of knowing precisely which approach we'd pick, so it might reach for DRM when a signed URL would do, burn through tokens reading pages it didn't need, or ship something that works today and costs you later.

Your agent already knows how to cook! The most useful thing you can do is hand it the recipe. The Mux prompt library is a set of instructions for common video use cases, written for your agent to read, that tell it which parts of Mux to use, in what order, with the defaults we'd choose if you asked us directly.

Below you'll find what agents do with Mux when they have no precise guidance, what changes when they get it, and why a recipe ages better than the old example apps we used to ship. If you'd rather just try one, skip to How do I use one?

LinkLeft alone, your agent takes the long way

We've been running sandboxed experiments with Gauge, handing coding agents a task, letting them work, and having a grader score the result against a rubric of the traps we know about, like Mux Robots reporting milliseconds where our clipping API expects seconds. Most of them use podcast clipping as the test, since it touches Robots, our new AI workflows product, with limited appearances in AI training data as of October 2026.

When we asked agents how they'd build a podcast clipping tool without naming any vendor, Mux was the top pick in only one of six runs. The other five sketched their own pipeline out of FFmpeg, Whisper or Deepgram, and some cloud storage. When we had Claude Code build it with no vendor named, it did exactly that, wiring S3, FFmpeg, and Deepgram together for 69 minutes and 946 credits, and passing one of the six criteria. The Codex run on the same task failed outright.

Naming Mux helps, but agents still have to guess at which parts to use. When asked to build the clipping tool on Mux with no feature named, two of four agents never touched Robots, and one hand-rolled its own moment detection.

However, when we asked the advice question again with a link to the Mux homepage, Mux won 12 of 15 runs, and the grader's notes on five of those wins say agents picked it "for the streaming layer" and kept a homegrown transcription pipeline next to it.

What the agent was told

Mux was the top pick

What the others did

Nothing about Mux

1 of 6 runs

Built their own pipeline from FFmpeg, Whisper or Deepgram, and cloud storage

A link to the Mux homepage

12 of 15 runs

5 of the 12 used Mux only for streaming and built their own transcription

A link to the podcast clipping recipe

15 of 15 runs

All 15 used Mux for the whole workflow, deciding in 46 seconds instead of 82

LinkPrescribe the agent with a path forward

Let’s look at securing a video. Mux gives you a lot of ways to do it, including signed playback URLs, playback restrictions that lock playback to your own domains, DRM, and watermarking, and an agent reading our docs cold will find all of them with no reason to prefer one.

We generally recommend everyone should start with signed playback, since it costs next to nothing and it decides whether a non-paying viewer can start the stream at all. DRM is the special spicy yum yum sauce in the bag, great when your content or your licensing terms call for it, and it also comes with an onboarding process, a per-license cost, and a FairPlay certificate from Apple that can take days to arrive, so we never really want an agent reaching for it first.

The video paywall prompt says as much. It starts your agent on signed playback IDs and a token endpoint that checks entitlement on every request, treats DRM as a layer you add when the content warrants it, and explains the gotchas we'd otherwise have to explain in a support thread, like the fact that a token stays valid until it expires even after someone cancels, or that native iOS apps don't send a Referer header so a domain restriction will lock them out.

Before it writes anything, the prompt has your agent ask you a few questions, the way a cook might ask about allergies before getting to work. How do viewers pay, where does the record of who paid live, do you need a free preview, are you worried about screen recording? The answers change the implementation and the agent skips anything it can already answer by reading your code (something example repos could never offer). You'd normally sort those out in a support ticket or a sales call, or by reading six guides and making your best guess, but now we can meet you where you are.

The podcast clipping prompt walks your agent through preparing captions, using Robots to find the moments worth clipping, converting Robots' milliseconds into the seconds our clipping API expects, and creating the clips as real assets with downloadable MP4s. In our build test, the agent given the recipe read it first and then asked five targeted questions before it wrote any code.

On the build test, when told to use Mux Video and Robots with only our public docs, Claude Code and Codex both scored five out of five, in a median of 22.7 minutes and 269 credits. With the recipe, they scored six out of six, in 18.9 minutes and 165 credits, about 39% cheaper. On the advice question, linking the recipe instead of our homepage got Mux picked in 15 of 15 runs, every one of them for the whole workflow, and the agents decided in a median of 46 seconds instead of 82 at about half the model spend (lower is better).

Setup

Score

Median time

Credits

No vendor named (Claude Code)

1 of 6 criteria

946

"Use Mux Video and Robots", public docs only

5 of 5

22.7 min

269

The podcast clipping recipe

6 of 6

18.9 min

165

These were admittedly small samples. We conducted a single run per agent on the build test and three per model on the advice question, and that sandbox had no Mux credentials, so its grader was judging code without ever seeing a working implementation. Not enough!

So we ran the recipes ourselves against a real Mux account. A fresh Claude Code agent started in an empty folder with nothing but the copied prompt, and built a Next.js paywall that Mux itself enforced: a request with no token, an expired token, or a thumbnail token used for the stream came back 403, and a valid one played. The podcast recipe took a public domain NASA interview to four reviewed clips with captions and downloadable MP4s. To the moon!

LinkNo more meal kits

For as long as there's been developer experience work, the job has been to educate and inspire with compelling demos, example apps, tutorials, and code samples in every language our customers might use. Somebody has to keep restocking these meal kits with dependency upgrades, they spoil when a framework ships a new major version, and they're portioned for a kitchen that probably isn't the same size or shape as yours. For a small docs team like ours, that's a lot of the year spent keeping old code alive and not thinking about the future of agentic experience.

A recipe describes the decisions and the API calls and leaves the cooking to your agent already in your kitchen. It can read how you handle auth, see that billing goes through Stripe, notice you already have a job queue, and write the integration in your conventions and your language, in a single conversation. You no longer have to translate our expertise into your product, your stack etc. because the agent does that translation for you.

The recipes still have to stay current, so we plan to check the example requests in our docs and prompts against the API spec in CI and a weekly review has Claude read each prompt against the guides it links to and flag anything that's gone stale.

While we were getting the library ready, we caught our own podcast clipping prompt telling agents to use a caption parameter we'd since deprecated and the checker now catches that kind of mistake on every push. Its first run turned up fifteen more across our guides. Whoops. Bet you have this problem too.

Our first paywall recipe offered visitors a 30-second preview, but the demo video the agent uploaded was 25 seconds long so the preview was the whole video. Another run noticed that a signed URL with an extra query parameter tacked onto it still played, which our own secure playback guide says shouldn't happen. Both went back into the recipe, and the guide got a correction. Prompt-driven development?

The evals also showed us how agents are lazy cats and skip instructions. Our first paywall run asked three of the six questions on the card and quietly decided the rest, so every recipe now opens with a checklist the agent copies into its plan, marks off as it goes, and hands back in its final report, with a reason next to anything it skipped. One podcast run still built five clips before asking which ones we wanted, after we'd said we'd pick the clips ourselves, so now that is its own item on the checklist.

LinkIsn't this what llms.txt and MCP are for?

I think those help with a different part of the job. We already ship llms.txt, Markdown versions of every docs page, and an MCP server that lets your agent act on your Mux account. The prompt tells it what to make, and it uses whatever tools you've connected: the MCP server if it's set up, and otherwise the Mux CLI, which signs in through your browser so nobody has to create or paste an access token. When we ran the same podcast task with each tool, they came out about even on time and tokens.

LinkHow do I use one?

Find your use case at mux.com/docs/prompts, copy the one-line prompt, and paste it into your agent. It fetches the current instructions and asks you about anything it still needs. If you'll do it more than once, install the skill version and your agent will know the workflow in every project.

If there's a dish you want us to write a recipe for, tell us and we'll put it on the list!

What this article says