Hand an agent the production work whose answer is already known and whose cost is the typing: setup passes, variants, blockouts, export preparation and validation. Keep the decisions. The method below is the order to introduce it in, and where it goes wrong.
List the work that has a known answer
Before configuring anything, spend twenty minutes writing down every task in your week where you already know what the result should be and the only cost is doing it. In most pipelines this list is longer than people expect:
Scene and shot setup you have built dozens of times.
Variant generation for props, materials and layouts.
Blockouts an artist then takes over.
Export variants, playblasts and colour-management checks.
Rigging and material boilerplate.
Then write a second list: the tasks where the interesting part is a choice. Silhouettes. Composition. Feel. Anything where two competent people would disagree. That second list is not a backlog for later, it is the work you are keeping.
Start with one repeatable setup, not with a hero task
The failure pattern is handing an agent the hardest, least specified job first, watching it produce something unusable, and concluding the whole approach is noise. Start at the other end. Pick one task from the first list that you will run twenty times this month, and get that working well.
A tightly specified repetitive task is where the economics land too: it runs in a short session, it lands on the first or second attempt, and you can tell immediately whether the output is right.
Keep the scene editable and review every pass
The reason agent control of an application is more useful than asset generation is that what comes back is a native editable scene rather than a finished export. Preserve that. If a step in your process bakes the result, you have converted a collaborator into a vending machine.
Review every pass before it goes downstream. The first pass is reliably a rough draft with proportions that are off, and the pass that makes it good is yours. Treat it as a junior's output that you are responsible for, because that is exactly what it is on the way to the build.
If you cannot tell within a minute whether a pass is right, the task was underspecified. Rewrite the brief rather than rerunning it; a rerun costs the same as the first attempt.
Decide what the agent never touches, and write it down
This is a team agreement rather than a technical control. Name the parts of the project the agent is not pointed at: final art, signature mechanics, anything shipping under a specific person's credit, anything covered by a client agreement about how work is produced.
Write it in the same place as the rest of your pipeline documentation, because the question comes up again the first time somebody is behind schedule. Having decided it in advance is the difference between a policy and an argument.
Write the brief the way the agent will read it
Most of what people describe as a bad result is a brief that did not say the thing the person had in their head. An agent working inside an application is running a loop against your description, and every ambiguity in it becomes an iteration you pay for.
Four things belong in every brief: what the result has to satisfy, what it must not change, which existing file or node graph it starts from, and how you will judge it. That last one is the one people leave out, and it is the one that makes the difference, because an agent that knows what it will be checked against can check itself before handing anything back.
Keep the briefs that worked. A short library of task briefs is worth more after a month than any single configuration change, and it is what lets somebody else on the team run the same job without learning it from scratch.
Measure what it cost, per task
Track cost by task rather than in total. The number you want is what one run of a given job costs, because that is the number that tells you whether to keep doing it that way, and it is also the number you need if you ever put the work on a campaign page.
Prices for the models we serve are on the models page. Use the cheaper model for the parts of the loop that do not need the expensive one; for most repetitive setup work that is the whole loop. Turning those per-task figures into a round is covered in working out the AI budget for your next milestone.
Say what the agent did
Whatever you eventually publish on, being able to state which tasks were done this way and which were not is worth having, and it is much easier to state if you wrote it down as you went rather than reconstructing it at the end.
On PowerHub it is required: a campaign lists the AI work as named tasks with a cost against each, and describes the creator as the author. What any storefront you publish on separately requires is between you and that storefront.
Questions
Does this replace a technical artist?
Everything published so far points the other way: the work being handed over is the part that had a known answer, and the work left is the part that needed a person. What changes is the ratio, which is a real change and worth being honest about rather than reassuring about.
What if the agent produces something I would not have made?
Throw it away and rewrite the brief. A discarded pass is part of the method and should be in your budget. A pass you keep because it is already paid for is how a pipeline fills with work nobody chose.
How do I fund this if it is a new cost?
That is what PowerHub is for: backers pledge to a creator's AI budget, we hold the money and buy the provider access, and the creator receives an API key rather than cash. The steps for opening a campaign are in how to fund your studio's AI budget on PowerHub.
