AI image and video production for agencies

An agency rarely decides to adopt generative image and video tools. They arrive one at a time: a designer subscribes to an image app for a pitch, a producer tries a video model for an animatic, someone finds a better lip-sync tool for a localisation job. A year later the agency has a dozen accounts on a dozen invoices, and nobody can say what a given campaign cost to make, which model made the hero shot, or where last month's approved take is stored.

This guide is for the people who end up owning that: operations leads, heads of production and creative directors. It covers the decisions that hold regardless of tooling, and then how INFRO Studio, released on 12 October 2026, handles them.

Whose contract is the job running on?

Every generative tool sits on a model provider. Some let you bring your own provider account; many bundle the provider inside their subscription, so the tool is the one with the contract and the agency only has the tool's terms. That distinction decides three things an agency cares about:

• The rate. A provider account in the agency's name can carry a negotiated rate. A bundled tool sets its own.
• The terms. Data handling, retention and the licence for what a model makes are set by the provider's contract with whoever holds the account. Your legal team should read the terms that actually apply to each job; this guide makes no claim about them.
• The invoice. When a client asks what a job cost, an agency can answer from its own provider invoices only if the work ran on its own accounts.

The practical rule is to move production work, as opposed to quick experiments, onto provider accounts the agency controls, and to choose tools that run on those accounts rather than in place of them.

Price the job before it runs

Media models do not bill in tokens. On Google's Gemini API, images are priced per image by resolution tier, Veo 3.1 video per second of output by resolution and model tier, and Lyria music per song¹. Runway's API prices video per second too, and its Veo 3.1 rate differs with audio on or off². That makes a job estimate a calculation over settings: how many keyframes at which resolution, how many seconds of video per take, how many takes per shot.

Split every estimate into two parts. Exploration is the many cheap attempts that find the look: keyframes, takes on a fast model tier, alternate music. Finals are the few renders on the best model at the delivery resolution. The ratio between them is a creative decision, but it should be a visible one.

The absolute numbers in that example are small, which is exactly why they go untracked. Multiply by revisions, by the second and third creative routes, by every shot a director asks to see again at 4K, and by every client running at once, and the total becomes a line in the job's margin that nobody planned. An estimate shown before each run, at the rate the provider will actually bill, is the cheapest control available.

Compare takes across models, with the settings recorded

Agencies compare models constantly, usually informally: someone renders the same prompt on two tools, drops the results in a deck, and the team picks one. The trouble starts when the client asks for "the same again, but warmer": nobody recorded the model version, the seed, the reference images or the duration, and the second tool may not even take the same settings.

Settings differ by model and by provider. Veo 3.1 on the Gemini API takes up to three reference images, but not on its Lite tier, and its lastFrame works only together with a first image³. The same model through another host may expose a different subset. A fair comparison therefore needs:

1. The same shot description and references, sent to each model in the form that model takes.
2. A record per take of model, provider, settings, seed where supported, and the estimated cost.
3. Side-by-side playback, with videos scrubbing together, because a difference in motion is invisible in two separate browser tabs.
4. A pick that is stored, not a filename in a chat thread.

Review: comments in the frame, decisions per shot

Video review tools already solved commenting at a timecode. What generative work adds is that every frame has an upstream: a prompt, a model, a set of references. A reviewer's note ("the hand is wrong at 0:03") needs to land on the shot and take that produced it, so the next run starts from the right place.

Two rules keep review clean. First, review decisions belong to shots, not files: approve or request changes on a shot, and keep the history, newest first. Second, what the client sees should be the picture, not the machinery. A client reviewing a cut does not need the prompts, the model names or the agency's costs, and in most agencies should not see them.

Model churn: build for the model going away

Media models are retired on short notice. OpenAI's deprecations page lists its Videos API, sora-2 and sora-2-pro as shut down on 24 September 2026, with no replacement listed⁴. On Google's Gemini API, veo-3.1-generate-preview, veo-3.1-fast-generate-preview and veo-3.1-lite-generate-preview are listed for shutdown on 22 October 2026, with gemini-omni-1.1-flash as the replacement; Google calls these the earliest possible retirement dates⁵. OpenAI also lists gpt-image-1 for shutdown on 23 October 2026, recommending gpt-image-2.5-sunburst or gpt-image-2.5-flare instead⁴.

For an agency, a retirement is a continuity problem more than a technical one. A campaign with a recurring character, a look built across twenty shots, or a series that runs for six months depends on being able to make one more shot that matches. Four habits reduce the exposure:

• Keep files, not links. Veo videos stay on Google's server for two days before they are removed³; Replicate deletes API inputs and outputs after an hour⁶. Every approved take and every keyframe should live in storage the agency controls.
• Record lineage. For each delivered file: the model, provider, prompt, references and settings that made it. Without it, a successor model has nothing to match against.
• Keep the references separate from the prompts. A character sheet or a style frame is portable across models; a prompt tuned to one model often is not.
• Hold a second provider. If the same shot can run on a second model from a second provider account, a shutdown becomes a re-run and a review rather than a reshoot.

Running agency production in INFRO Studio

INFRO is a control plane that sits between an organization's applications and the AI providers it already pays. INFRO Studio, at studio.infro.io, is its workspace for image, video and audio, included in every INFRO plan with no add-on. The points above map onto it as follows.

The agency's own provider accounts. Studio runs every generation as a gateway request on one of the organization's own provider connections, so the provider bills the agency's account directly at its own rate; INFRO charges its subscription only, with 0% markup on model spend. An agency whose clients supply their own provider accounts can keep a client in a separate INFRO organization: each organization has its own connections and its own subscription.

An estimate before every run. Studio shows the plan and the estimated provider cost of every step before anything runs, using the agency's negotiated rate where one has been entered and the vendor's list rate otherwise; a step with no known rate is shown as unpriced, never as $0. Run all on a storyboard plans every waiting shot, shows how many steps are reused from identical earlier work, and gives the total first. The same estimate is available to the agency's own tools as POST /v1/estimates.

Limits per person and per organization. Finance or an admin can set a monthly limit per member and a budget for the organization in the INFRO console; Studio shows a creator both beside a large run and says when a run may stop at a limit. Budgets and member limits are enforced on Studio's requests exactly as on any other request. Model allowlists apply too, so an agency can restrict which models a team uses.

Cost per client and per job. Work in Studio is organized in projects; a sensible convention is one project per client job. Every Studio request is recorded with feature set to studio, the run id as its trace, and the Studio project's id as the tag studio_project. In the request log the tag can be filtered directly. To group cost by it, promote studio_project as a tag dimension in the console (up to five promoted keys, on every plan), then group usage by it with GET /v1/usage?group_by=tag:studio_project. Grouping starts with requests made after the key is promoted, so promote it before production starts. Cost centers and monthly statements, for booking that spend to departments or clients, are included from the Team plan. Studio projects are not yet tied to the console's gateway projects, and Studio is organization-wide in this version: a member confined to some projects in the console cannot open it.

Comparing takes. Compare shows up to eight takes side by side; videos play and scrub together, two images get an A/B wipe, and every tile names its model, provider and cost. Studio only offers models the organization's connections serve and only the settings each model takes on that provider, and a request a target cannot take is refused before any call. A shot's stages (keyframe, animate, sound, finish) are each a step on a model of the creator's choice, so one shot can be made on one model and finished on another.

Review and handoff. Members comment at a moment in a video or on a region of an image, and approve or request changes on a shot; every decision is kept. Analyst and finance members can view and review without generating, which suits account managers. View-only share links expire within 30 days, can be revoked, and show titles and pictures, never a prompt, model, provider or cost. Export produces a package with the chosen takes, keyframes, sound and captions, timelines for Final Cut Pro (FCPXML), DaVinci Resolve (EDL) and Premiere Pro (XML), and a manifest.json recording the model, provider, prompt, settings, estimated provider cost and lineage of every file.

Storage and retention. Studio keeps nothing until an owner or admin turns its storage on, then keeps uploads and generated media for the plan's window: 30 days on Developer, Startup and Team, 90 days on Business, a year on an Enterprise agreement. Each item shows the date it is kept until, and the people who made items leaving within a week get an email. For an agency, that window is a working store, not an archive: export approved work into the agency's own asset system before it lapses.

Seats. Seats are per plan: one on Developer, three on Startup, ten on Team, unlimited on Business. Owners, admins and developers generate; analysts and finance view and review.

A checklist for the first client job

• Connect the provider accounts the job will use, in the agency's name, and enter any negotiated rates.
• Turn on Studio storage, and decide where approved work is archived after the retention window.
• Create one Studio project for the job and promote the studio_project tag before the first run.
• Set a monthly limit for each member working on it and an organization budget.
• Agree the exploration and finals split with the creative lead, and check it against the estimate before Run all.
• Review per shot, share with the client by link, and export with the manifest when every shot is approved.
• Note which models the job depends on, and check the vendors' deprecation pages before the next phase.

For the APIs underneath all of this (billing units, async jobs and retention windows), see INFRO Studio: image, video and audio on your own providers. For choosing between video models, see the video model comparison.