How can a design practice use AI visual agents without losing design control?

Assign AI to defined, repeatable visual jobs with governed inputs and a named reviewer, and keep design decisions, specification and client commitments with your designers. Treated as production capacity for work a practice has already specified, an agent team gives its specialists their time back. Treated as a stand-in for a designer, it produces work the practice cannot defend.

Visual production in a practice is not one job. It is a resolved design that has to be made legible to a client, plus a stream of small requests — one more finish, one more angle, one more option — arriving while someone is mid-project.

The second stream is what breaks the week. It is repetitive, it is urgent, and it lands on whoever is most skilled at producing visuals, and that is the person you least want interrupted.

So the question is not whether AI can produce an interior image. It is which of these two streams you would hand to it, and what has to be true before you can.

By visual production we mean work that turns an existing design decision into something a client can look at. It does not include making the design decision.

By agent team we mean a specialist unit configured for one job — reading a drawing into a room view, applying an approved finish, preparing a presentation-ready set — rather than a general image generator taking free-form instructions.

By governed inputs we mean sources the practice controls: your drawing, your approved product references, your standards. A workflow running on whatever the operator happens to upload is not governed, and its output cannot be held to a standard.

A task is a candidate when it repeats, when its inputs are already specified, and when a competent reviewer can tell in under a minute whether the output is acceptable.

A task is not a candidate when the answer depends on judgment the practice is paid for: proportion, specification, code compliance, or anything a client will treat as a commitment.

The rule that decides whether a visual job is safe to assign is a property of the workflow rather than an opinion about AI. What the source states, the workflow preserves. What the source omits, the workflow infers, and a person has to check the inferred part before the work leaves the practice.

That split is published rather than asserted here. The Design Visual Production page sets it out three ways for its own workflow — what comes from your drawing, what the agent team supplies, and what your staff have to review — and each agent-team page states the same for the job it does.

It follows that source quality is the variable a practice actually controls. A drawing that carries layout, divisions and heights constrains the output. A drawing that omits material, light and anything outside its drawn extent hands those decisions to inference, and inference varies between runs unless it is specified.

This guide publishes no worked example of that sequence. The Examples hub states what a published example has to carry before it goes on this site, which is the standard any example of this workflow will be held to.

The practices this works for do three things. They define the two or three visual jobs that repeat weekly and set them up once. They give a named person responsibility for reviewing output before it leaves the practice. And they keep design decisions where they were.

In that arrangement a junior or an administrator can run the routine requests, and the senior designer moves from producing visuals to approving them, which does not fragment their project work.

If your visual requests are rare or each one is genuinely bespoke, there is no repeatable job to assign and the setup will not repay itself.

If your output must be dimensionally accurate, technically resolved or construction-ready, this is the wrong tool. The workflow pages state that limit on their own face, in the section that describes what the output is, and each agent-team page states the boundary that applies to the job it does.

If nobody in the practice owns the review step, quality drifts and the practice ends up defending work it never checked. That failure is organisational, and no configuration fixes it.

Traditional rendering remains the right answer when the output has to be technically controlled: exact geometry, verified dimensions, specified luminaires, or material behaviour that has to be physically credible rather than plausible.

Traditional rendering is also right when the image itself is the deliverable being paid for, and the client's expectation is a controlled, art-directed result produced to a brief.

The two are different jobs rather than two answers to one question, and a practice can run both: agent teams for the weekly stream of client-communication work, traditional rendering for the small number of outputs that have to be technically controlled. Treating it as a choice between them is the mistake.

Start by counting. For two weeks, record every visual request: what was asked, who did it, how long it took, and what it interrupted. The total is the entire business case, and it does not exist until someone counts it.

Then pick the single most common request and run it as a defined workflow with a named reviewer for a set period, comparing against what you recorded. That is a process pilot, and it is the evidence your own people will believe.

If the pilot shows the change does not survive contact with your actual week, stop. That is a legitimate result, and it is cheaper to find now.