How it works

Five steps, and your staff run four of them

Studio is not a prompt box, and it is not an autonomous business system. It is an operating model your staff run: a named workflow, inputs the workflow defines, an agent team that produces reviewable work, and a person who decides whether the result is used.

Avisual Studio is the visual agent workforce for interior businesses. Your staff choose a defined workflow, supply the inputs that workflow accepts, a specialist agent team produces reviewable work, your staff review and refine it, and your staff decide how the result is used. Studio produces communication visuals for review. It does not talk to your client, approve a design, verify a dimension, or decide that a result is good enough.

Illustration in productionFive stages in a row, with the review stage drawn at the same size as the production stage
explanatory schematicThe operating model, at the size each stage deserves: review is a stage, not a footnote under one.

Most people arrive with one of two wrong pictures

Studio is neither a prompt box nor a system that runs your business for you, and the difference decides whether the rest of this page makes sense.

The first wrong picture is a text box. Type a description, receive an image, hope it resembles the kitchen you are actually building. That version has no idea what your drawing says, no idea which parts of it are not negotiable, and nothing that lets a reviewer check the result against the source. If you have tried something like this before and quietly stopped, that is most likely the version you tried.

The second wrong picture is the opposite: a system that takes the job off your desk, produces the visuals, and sends them onward while you get on with something else. That is not what this is either, and a business that bought it on that basis would be right to be angry.

What is actually here is narrower and more useful than both. A workflow is a named job with defined inputs. An agent team runs that job and hands back work with an account of what it kept from your source and what it had to supply. A person on your side looks at it, and nothing moves until they say so.

The operating model

The same five steps across the published workflows. Four of the five are yours.

  1. Choose a workflow

    Start from the business job rather than from a tool: producing a design visual, running a client review, or showing a product in a customer's room. The workflow you pick decides which specialists run and what the job will accept.

  2. Prepare governed inputs

    Each workflow states what it takes — an elevation, a room photograph, a product or material reference, an unfinished scene — and asks you to say what must survive the run. Inputs are declared, not free-form, which is what makes two runs comparable.

  3. The agent team produces reviewable work

    A specialist agent team runs the job it is defined for and returns work meant to be inspected: the output, and an account of what it preserved from your source and what it inferred where the source was silent.

  4. Your staff review and refine

    Your staff member checks the result against the source, adjusts the direction where it went wrong, and runs it again if it needs it. This step is not optional and it is not a formality — it is where the judgement your client is paying for happens.

  5. Use the result

    The visual goes into the presentation, the review meeting or the showroom conversation, at the point your staff member decides it is right to use. Studio does not put it there.

Three roles, and only one of them is an agent

The operator, the agent team and the reviewer. In a small business the operator and the reviewer are often the same person, which is fine as long as it is a decision rather than an accident.

The operator

The staff member who chooses the workflow, supplies the source material, and says what the run must preserve. Usually a designer, a visualiser or a salesperson — the person who already knows what the job is for.

The agent team

The specialists the chosen workflow runs. Each has a defined function rather than an open-ended one, which is why you pick a job rather than describe a picture. Every workflow page states which team it runs and on what.

Explore workflows

The reviewer

The person who decides the result is fit to show, and who carries the professional responsibility for it in front of the client. Studio does not occupy this role and does not try to: your people remain responsible for professional judgment and final approval.

The words this site uses, defined

Workflow, agent team, Guest Studio, Studio Consultant and Studio Assistant each mean something specific here, and each definition is written limits-first.

Workflow

A named business job with defined inputs and defined outputs — not a prompt and not a mode. If the job you need is not one of the published workflows, Studio does not do it yet, and the workflows page says which three are published.

Agent team

The set of specialists a workflow runs, described by the work they do rather than by the models behind them. A team has one defined function. It does not decide what the job is, and it does not choose whether the result is used.

Guest Studio

The name this site uses for the evaluation entry to Studio: a route to judge whether a relevant workflow does something useful on material like yours. It is an evaluation route, not somewhere to run a week of work for a client. Whether a run is possible before you register, what guest evaluation allows and what it caps are not published on this site yet — those open terms are listed under guest evaluation below.

Studio Consultant

The guidance layer on these public pages. Its question is what your business should do — which workflow fits, what your inputs would need to be, whether a wider evaluation is warranted. It is not a substitute for what these pages state permanently.

Studio Assistant

The help that belongs inside Studio itself rather than on this site. Its question is how to do the job in front of you — preparing an input, resolving a source problem, refining direction, reading an output.

What goes in, what comes back, and what happens to it

The three questions a careful evaluator asks after the diagram: what will it take from us, what happens when a run comes back wrong, and where does our material end up.

Inputs are declared by the workflow

Each workflow states what it accepts and what it needs you to mark as fixed before the run. That declaration is the governed part: it is what lets a reviewer check the result against something rather than against an impression.

Explore workflows

Iteration is a step, not a failure

A run that comes back wrong is information about the direction, and adjusting and running again is the normal shape of the work. Any page that shows you one result and implies it arrived first time is not showing you the job.

The result is yours to place

What comes back is a file your staff member takes into a presentation, a review or a conversation. Studio does not send, publish or share anything on your behalf. Your people remain responsible for final approval and for what a client is shown.

The fourth question — what happens to the material you upload — is deliberately not answered on this page. A data practice summarised in passing is where an unverified claim gets made, so that answer belongs on the one page that carries the verified wording, and nowhere else.

What repeat use needs, and what is not published yet

Running a workflow once is an evaluation. Running it every week across a team is an operation, and an operation needs more than a good first result.

Two things about repeat use are true today and worth saying plainly. The first is that a workflow defines what a run needs, so two staff members running the same job supply the same kinds of input and their results can be compared rather than merely admired. The second is that the review step does not become optional at volume: Studio does not send, publish or share anything on your behalf, so a result reaches a client because a person on your side decided it should.

Everything else that a team deployment eventually wants — shared projects, approved assets, roles, history, measurement — is not published on this site, and this page will not describe it as though it were. Those items are listed below as what they are: named, and not yet published. If a team evaluation is what you are actually here for, ask the Consultant and it will tell you the same thing rather than a better-sounding version of it.

Shared projects and run history
Not published yet. Nothing on this site describes how work is grouped, revisited or handed between staff in a team workspace, and this page will not invent it.
Approved brand, product and material assets
Not published yet. What a business can register as an approved asset, and what a run would do with it, is not stated anywhere on this site.
Team roles and permissions
Not published yet. Who can run what, and who signs off before a result leaves, is a real question for a team deployment and it has no published answer here.
Measurement of a deployed workflow
Not published yet. Any figure for your own business would have to come from your own evaluation on your own material, and this page will not supply one in advance of it.

Guest evaluation and business use are not the same thing

One answers whether this is worth more of your time. The other is how work actually gets run, and confusing them wastes both.

Guest evaluation

Open a relevant workflow, run it, and inspect the result properly against what went in. It is meant to settle one question: whether this does something useful on the kind of material you have.

Set up a run from a prepared workflow

Business use

Your own material, your own staff, and the same workflow run repeatedly until it is part of how the work gets done. This is where a wider team or process evaluation belongs, and it starts as a conversation about your process rather than as a button on this page, and Ask Studio Consultant is the route to that conversation on this site.

Plan a team/process evaluation
Whether a run is possible before you register, and what guest access allows
Not published yet. Whether a run is possible without an account, and what an anonymous session would carry over if you later registered, is not stated anywhere on this site.
Complimentary run allowance and session limits
Not published yet. Any allowance, resolution limit, expiry or rate limit on guest use is undecided, so this page states none rather than a comfortable-sounding one.

The parts of your process Studio stays out of

Stated here, in the open, rather than discovered later by someone relying on it.

Studio does not talk to your client. It does not send, publish or share anything on your behalf. Every result reaches a client because a person on your side put it there.

Studio does not approve a design, verify a dimension, or produce construction documentation. A visual is a communication artefact, and no visual on this site establishes dimensional accuracy, technical approval or a colour-calibrated match against a physical product.

Studio does not carry technical or regulatory responsibility for what is built. That sits where it already sits: with the professionals whose names are on the work.

Studio does not decide whether a result is good enough. That judgement belongs to the person who owns the client relationship, and it is the reason the review step is a stage in the model rather than a note underneath one.

Where to start, depending on what you have in front of you

Three routes. The right one depends on whether you have nothing to hand, a specific job in mind, or a question about what counts as evidence.

You have nothing to upload yet

Start from a prepared workflow rather than from a file of your own. It is the shortest route to an opinion about whether any of this is worth your time.

Set up a run from a prepared workflow

You have a specific job in mind

Go to the workflow that matches it. Each of the three published workflow pages states what it accepts, what it returns, what it preserves and where your staff have to look before anything reaches a client.

Explore workflows

You want to see the evidence standard first

The Examples page publishes the standard every example has to meet before it goes public — the source, the direction given, the agent team, the result, and what it does not establish. No example is published there yet, and the page says so rather than filling the space.

See the evidence standard

What Studio does not do

The limits are part of the product. Read them before you plan work around Studio.

  • Studio produces communication visuals for review. It does not publish, send or share anything to your client.
  • Studio does not approve designs, verify dimensions, or produce construction documentation, and no Studio visual establishes a colour-calibrated match to a physical product.
  • Guest evaluation is for evaluation, not for production work. Whether a run is possible before you register, what guest access allows and what it caps are not published yet.
  • Team workspace and governance features are not published on this site. Nothing on this page describes one as available.
  • This page does not answer data-handling questions. They belong on Trust, and only in wording that has been verified.

Choose your next step

Each route below produces something you can look at and judge.