The brief an agent needs to shoot a season

An agent that shoots a season for a brand needs four decisions. Cast the model, name the pieces, choose the ground, approve one reference frame. Everything after that is a job id and something to listen on. There is no field where an agent types a description of the picture, for the same reason there is none for a person.

Some of the briefs arriving here are written by software. A brand's own agent reads the season plan, finds four hundred pieces with no imagery against them, and starts work. That reader gets the same document a studio manager gets: what to decide, in what order, and what to leave alone.

The key will belong to the organization

Not to the person who made it. Keys are designed and not yet built, so today a call authenticates with the session of somebody who signed in and anything you automate runs under a seat. Plan for that and keep the seat boring.

The design is settled. Each key has its own name, its own permissions and its own visible spend, which means you can tell at a glance which integration is spending what, and revoking someone's seat never silently kills a nightly job. When they land, give an agent its own key rather than sharing a human's. Not for security theatre, but because a key with a name is a key you can turn off on a Friday afternoon without a meeting.

Four decisions, most constraining first

The order is the order a physical shoot is planned in, and it is not decoration. Each step narrows the one after it.

1. The models: who is wearing it.
2. The pieces, pulled from a collection that already exists in the house.
3. The ground, which is the set it happens on, chosen once and held across every frame.
4. The lock. The house develops one reference frame and somebody approves it.

Then the variations, which are chosen from a list rather than described, and then the run, which no longer needs anyone.

An agent can drive steps one to three and start the develop that produces the lock. Step four is where it should stop and show its work. The house's own rule for every automation in it applies exactly as well to yours: do all the work, then show it, then wait. Never file silently. That rule is why intake proposes rather than merges, and it is the right shape for an agent too.

The lock is the one thing an agent should not approve

A lock is a signature. It carries the model's identity, the ground, the light, the framing register, the camera language and the realism clauses into every frame developed after it, which means approving a nearly-right reference is the most expensive mistake available. A fourth attempt at the lock costs a handful of frames. Forty variations of a stiff stance costs the set.

So build the loop with a human in it at exactly one point. Everything before the lock is logistics and an agent should own it. Everything after the lock is a queue and an agent should own that too. The approval in the middle is thirty seconds of somebody's eye, and it is the only thirty seconds that cannot be delegated.

Send the collage last

References are a sequence, not a bag. The first is inspiration; the last is the model. A model in the house is a collage of several views of the same person in one image, and attaching it last is what holds a face across forty frames. Send two collages and you weaken both.

This is the single most load-bearing line in an API call and the easiest to get wrong, because an array looks unordered when you are writing the request. It is not. The craft argument behind it is the same model, every frame.

Do not poll

Long work is asynchronous. You submit, you take the job id, and you listen rather than asking every four seconds. Today you listen on a socket. It is addressed to your organization rather than to a seat, so a run one person started is watchable from another, and a client that was away asks once for what it missed.

Outbound webhooks are designed and not yet built. The events, so you can build around the shape:

| Event | When | | ------------------- | ------------------------------------------------------- | | run.started | A run was accepted and has capacity | | run.frame.settled | One frame finished and was charged | | run.settled | Every frame in the run finished | | run.failed | The run ended without completing | | purchase.granted | A payment completed and something pre-made became yours |

Signed and retried when they arrive. The MCP server is designed the same way, over streamable HTTP, so a developing lookbook reports progress as it happens instead of going quiet for four minutes and leaving an agent to invent a timeout. Whichever of the three you end up on, an idle integration should make no requests at all.

One line in that table matters before any of it exists. A browser returning from a checkout page is not evidence that money moved, and the house does not treat it as such. The payment provider's own signed delivery is the only thing that writes an entitlement. If your agent buys a model, it reads the entitlement rather than the redirect.

What the surface promises

Every route is described in OpenAPI and carries a matching request in the collection that ships with the repo, checked in CI rather than promised in a README. A route nobody can call is a promise nobody can keep, so the rule is that a route which is not described and not callable does not exist.

The honest limit: this is a door into a house with opinions. Your agent cannot ask for a different aspect of the craft by describing it, cannot invent a ground that is not in the library, and cannot skip the lock. If what you want is a machine that takes a sentence and returns a picture, that exists elsewhere and it is not what we built.

The routes, the events and the MCP tools are in the API docs, and what shipped with them is in what the house has shipped. Before you write the first call, read what arrives in a box: an agent's first job is the collection, and everything above assumes one already exists.