How to send a long brief in parts and control when it starts

Last updated 2026-09-04 · 7 min read

What is the short version?

A detailed brief does not fit in one message, and pasting it in halves means the job starts on the first half. The fix is to say so: number the blocks, say not to execute, and say what the acknowledgement should look like.

1. Go to Vizard Agent and say how many blocks are coming.
2. Say to store everything and execute nothing until you say so.
3. Release it a phase at a time, asking for the plan first.

What do you need before you start?

A brief that is actually worth this treatment. The protocol costs you a few messages, and it pays for itself on a job with measured coordinates, a QA checklist and several deliverables — not on a thirty-second reel.

• The brief. Split into logical blocks.
• The block count. So it knows when you are done.
• The reply you want. "ok, block 1 received."
• The phases. What runs first, and what waits.
• The material. Sent last, as the release signal.

What do you type into Vizard Agent?

Put the protocol in the first message, before any content. The instruction has to arrive before the thing it governs, or the first block is already being worked on by the time you explain that it should not have been.

Prompt

Variants worth knowing:

• "Reply only X." Stops it from starting work in its answer.
• "Run phase 1, then bring me the phase 2 plan." Gate the render.
• "Don't render anything yet." Worth repeating at each gate.

What does Vizard Agent actually do?

Here is the order Vizard Agent worked in on a real multi-deliverable job briefed across four blocks — a long-form master, a vertical cut and a trailer, with the client's own QA checklist supplied in advance and run against the finished render at the end.

1. Acknowledges each block and executes nothing.
2. Runs the first phase only when the material arrives.
3. Returns a plan for the next phase instead of a render.
4. Builds the master once the plan is approved.
5. Assembles the trailer structure and renders it.
6. Extracts frames from the trailer and the vertical cut to check both.
7. Checks the overlays in the final render.
8. Verifies a badge does not touch the speaker's face.
9. Rebuilds the badge without its black background.
10. Measures music against speech and the word attacks.
11. Measures the music under the quietest passages specifically.
12. Measures the zoom stability and the background shake during zooms.
13. Reads the captions at three points and investigates one mid-video.
14. Checks the logo at native resolution inside the punch-in.
15. Calculates the chapters against the render's own timings.
16. Verifies three chapters by hand and corrects one.
17. Writes the text deliverables and lists everything produced.
18. Publishes all the deliverables and watches the renders back.

Steps ten to fourteen are the user's QA checklist being run — supplied in block four, before any footage existed, and executed against the final render. That is the real payoff of briefing this way: the acceptance criteria are agreed before the work starts, so the review is a checklist rather than an argument.

Step three is the other half. Asking for the plan rather than the render turns the expensive part of the job into something you approve rather than something you receive.

What does the result look like?

Every deliverable the brief named, produced against acceptance criteria that were written down before anything was made — and a filled-in QA report from Vizard Agent saying which checks passed, with the numbers measured rather than simply asserted.

The number of correction rounds is the visible difference. Most rounds exist because the brief and the interpretation diverged early and nobody noticed until the render; a plan approved before the render is where that gets caught.

When does this not work well?

The protocol is overhead, and overhead only pays for itself on a job big enough to carry it. There is also a hard limit to how much a brief can usefully specify before the specification itself becomes the thing standing between you and a good video.

• Small jobs. The protocol costs more than it saves.
• Contradictory blocks. Long briefs disagree with themselves.
• Coordinates from a different framing. Say which frame they were measured in.
• Over-specification. A brief with no room left has no room to be good.
• Changing the plan mid-run. Release a new block rather than editing an old one.

How do you fix a result that came back wrong?

Point at the block that was wrong rather than at the render. Vizard Agent holds the whole brief as separate stored blocks rather than as one merged instruction, so correcting a single rule means replacing that one block instead of restating the entire specification from the beginning.

• "Block 3 was wrong." Replaced; the others stand.
• "That check failed." Re-run against the named criterion.
• "Stop before rendering." The next phase gated again.
• "Add a rule." A fifth block, appended.

How does Vizard Agent compare to doing it yourself?

Working with a human editor, this is just how a proper brief works — you send the document, you agree the plan, you approve before the expensive part. The difference is that here you have to say so explicitly, because otherwise a message that looks like a brief is treated as a start signal.

Common questions

Will it really wait? Yes, if you say so plainly. Vizard Agent acknowledges and holds.

How many blocks can I send? As many as the brief needs. Number them so Vizard Agent knows the end.

Can I ask for a plan before any render? Yes, and it is the most useful part of this. Vizard Agent returns the plan.

Does it remember block one by block four? Yes. Vizard Agent holds the whole brief in the conversation.

Can I include a QA checklist? Yes. Vizard Agent runs it against the final render and reports.

What if two blocks conflict? Vizard Agent asks rather than picking. Long briefs contradict themselves often.

Can I supply measured coordinates? Yes — tell Vizard Agent which framing you measured them in.

Does this reduce the cost? Usually, by reducing rounds. Ask Vizard Agent for an estimate at the plan stage.

Can I change my mind mid-job? Yes. Send a new block rather than editing an old one.

What should the acknowledgement be? Whatever you name. Short is best, so Vizard Agent cannot start work inside its reply.

Does it work for several deliverables? Yes. That is the case where Vizard Agent earns its keep on this protocol.

Can I gate every phase? Yes. Vizard Agent stops wherever you tell it to stop.

Is this the same as a standing spec? No. A standing spec is what Vizard Agent reuses every episode; this controls one job.

Why not just send one long message? Because a long message is both the brief and the start signal, and separating those two is the entire point.