Your model returns a file. Production needs an asset.

Your agent calls an AI image or video model (OpenAI, Google, Runway, fal) and, a few seconds later, gets back a URL or a blob of base64. Feels like the job is done. It isn't. That raw output will probably expire, it's the wrong size and format for wherever it's headed, it carries no record of what made it, and nobody has checked it against your brand. And because it's an agent, there's no human standing by to fix any of that.

The disappearing URL gets all the attention, but it's only the first of several steps between "the model responded" and "I can ship this." Here's the whole path.

What this covers: what happens when generated media expires across the major APIs, what "production-ready" actually requires (persist, transform, deliver, brand, find), and how to collapse that pipeline into one step.

Step zero: the output is built to disappear

Generated media is ephemeral by default, and the details vary more than you'd expect:

• OpenAI: image models like gpt-image-2 return base64 bytes, no hosted URL at all, so you own storage from the first response. Sora video files last ~48 hours (download URLs ~1 hour), and the Sora video API is being sunset in September 2026.
• Google: the current image models, Nano Banana 2 (Gemini 3.1 Flash Image) and Nano Banana Pro (Gemini 3 Pro Image), return bytes inline through the Gemini API. For video, Veo 3.1 output is kept two days behind the Files API, then deleted.
• Runway: Gen-4 image and video output URLs expire in roughly 24–48 hours; the docs tell you plainly to download and self-host.

This isn't a bug. These are inference platforms, not asset hosts, and serving files forever is expensive. The trap is that "save it before it vanishes" quietly became your job, and most teams only find out when a link 404s in production.

Persistence alone isn't the finish line

The landscape is shifting, to be fair. fal.ai now offers fal Assets, where generations persist instead of expiring, and platforms like Leonardo keep outputs indefinitely. Even routing layers like OpenRouter's Unified Image API give you one endpoint across dozens of models, though as a router it stores nothing, so persistence is still yours to solve.

But solving expiry only solves step zero. A file that lives forever in one vendor's library is still unoptimised, unbranded, scattered across whichever providers you happen to use, and only as findable as that vendor's UI. The hard part was never just keeping the bytes.

Why autonomous agents make media persistence harder

When a person generates an image in a web UI, they're right there to download it, crop it, eyeball the brand, and drop it where it belongs. Agentic workflows delete that entire safety net.

An agent runs in the background. It calls a model, gets a result, and moves on: the output lands in a state object or a database row, and nobody looks until much later. Good agent-state design even says to store large artifacts as files and keep only the path in state. Sound advice, but it assumes the file is somewhere permanent and usable. A raw model URL is neither. So every step a human would have done by hand now has to happen automatically, at generation time. That's the actual job.

What "production-ready" actually means

Strip it back to what has to be true before generated media can ship:

1. Persisted: captured the instant it's created, so nothing depends on an expiring URL.
2. Optimised & transformed: the right format and size for each destination. A 4 MB PNG becomes a 40 KB WebP thumbnail, a social crop, an AVIF for modern browsers. Video is harder: transcoding to MP4/WebM, an adaptive HLS/DASH stream, a poster frame, often a trimmed cut, all from one master.
3. Delivered: served fast from a CDN, video streamed adaptively rather than shipped whole from one region.
4. On-brand: checked against brand rules before a customer sees it. An agent generating customer-facing media with no brand guardrail is a real risk, not a hypothetical.
5. Findable: stored with its metadata: prompt, model, use-case, tags, and for video things like duration and captions. An agent that can't search its own output regenerates the same thing twice.

Miss any one of these and you don't have an asset; you have a raw output and a to-do list.

This is really an asset pipeline

Every one of those requirements already exists in traditional media workflows. AI generation hasn't removed the pipeline, it has simply automated the first step. Agents make that more obvious because there's no human left to bridge the gap manually.

Building the media pipeline yourself

The pattern everyone reaches for looks simple:

generate → download the bytes → push to your object store → serve from there

The store is usually S3, Cloudflare R2, or Supabase, and the mechanics are well-trodden. But persisting the bytes is the easy ~60%. What's left on your plate:

• Glue code on every generation path, with retries for when the URL expires mid-download (worse for large video files).
• A transformation service (Lambda + sharp, imgix) and, for video, a transcoding pipeline (FFmpeg or managed) for streamable renditions and poster frames.
• A CDN in front, with adaptive streaming for video.
• A brand check, which most pipelines just skip.
• A metadata store you build and maintain so assets stay findable.

You can absolutely assemble this, and if storage cost dominates and your transform needs are light, R2-plus-a-Worker is a sensible call. Just be honest that you're now operating a small media pipeline, not a bucket.

Two pipelines, one call

The model step is identical either way. What differs is everything after it.

The generation call below is deliberately abstracted: whether generateMedia() wraps OpenAI, Google, Runway, fal, or an OpenRouter route, you're left holding the same thing: an ephemeral URL you now have to productionise.

The DIY way: download, race the expiry, persist, then start the rest of the pipeline.

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
const s3 = new S3Client({ region: process.env.AWS_REGION });

const modelOutputUrl = await generateMedia(prompt); // any provider; ephemeral

const res = await fetch(modelOutputUrl);            // race the clock
if (!res.ok) throw new Error(`Model URL expired: ${res.status}`);
const bytes = Buffer.from(await res.arrayBuffer());

await s3.send(new PutObjectCommand({
  Bucket: process.env.S3_BUCKET,
  Key: `generations/${Date.now()}.png`,
  Body: bytes,
  ContentType: "image/png",
}));

// Still TODO, separately: transform/transcode, CDN, brand check, metadata store…

The pluggable way: hand the same URL to a media pipeline and get a production asset back in one call. (This example uses Cloudinary, but the shape is what matters.)

import { v2 as cloudinary } from "cloudinary"; // configured from CLOUDINARY_URL

const asset = await cloudinary.uploader.upload(await generateMedia(prompt), {
  folder: "agent-generations",
  context: { prompt, model: modelName },            // searchable metadata
  eager: [{ width: 400, height: 400, crop: "fill",
            fetch_format: "auto", quality: "auto" }], // optimised derivative
});

asset.secure_url;          // permanent original, CDN-delivered
asset.eager[0].secure_url; // optimised WebP thumbnail

It fetches the bytes (no expiry race in your code), stores a permanent original, derives renditions on demand, and tags it with its metadata. Pass resource_type: "video" and the eager transforms become an adaptive stream and a poster frame instead of image crops. Same call for an image from one provider or a clip from another, and the agent ends up holding one stable, branded, findable URL, no per-model recipe required.

Or generate straight into your asset platform

If the generator and the asset platform are the same system, there's no ephemeral URL to rescue in the first place. That's the idea behind Cloudinary's new Image Generation API: a single text_to_image endpoint across best-in-class model families (FLUX.2, Nano Banana, GPT Image, Recraft, Ideogram), much like the routing layer from earlier, except the output lands as a managed asset rather than a disappearing link.

curl -X POST https://api.cloudinary.com/v2/generate/<CLOUD_NAME>/text_to_image \
  -u "<API_KEY>:<API_SECRET>" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "a golden retriever wearing a tiny astronaut helmet",
    "model":  { "family": "flux", "tier": "premium" },
    "target": { "target_type": "managed_asset" }
  }'

The response is a permanent secure_url plus the asset_id and public_id you use everywhere else in Cloudinary. The image is born persisted, optimisable, and ready to deliver; generation and production collapse into one step. (Omit model for the Nano Banana default; target defaults to a short-lived temporary asset if you'd rather not persist.)

The takeaway

The honest version: if all you need is the cheapest bucket, R2 wins on raw storage cost, and Supabase now bundles basic transforms and a CDN. Reach for a full media platform when the whole job matters (persist, transform, deliver, keep on-brand, organise) and you'd rather make one call than orchestrate five.

But the broader lesson outlives any product choice. In an agentic system, a generated file is an intermediate value, not a deliverable. The model is a component, not the finish line. Treat the path from raw output to production asset as a real pipeline (whether you build it from buckets, workers, transcoders and a metadata table, or hand it to something that does all five) and your agents stop storing links to nothing.

---

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

Comments

[Armorer Labs]

This is a useful way to frame it: the agent output is not the asset; the asset is the output plus persistence, policy, provenance, and delivery metadata.

One extra thing I would add for autonomous agents is a run-level receipt around the asset handoff. The media pipeline should not just return a CDN URL; it should return something the agent runtime can later explain: source model/provider, prompt or prompt hash, transformation chain, brand/policy verdict, destination, retry/refund state if the external effect failed, and the operator or policy scope that allowed the generation in the first place.

That matters because a lot of "agent generated an image" bugs show up later as accountability bugs: nobody can answer which model produced this, whether the brand check actually ran, whether the URL was replaced after a failed retry, or why the agent regenerated instead of reusing an existing asset. The metadata store you describe becomes much more valuable when it is tied back to the run record, not only to the file.

Disclosure: I work on Armorer Labs.