Superintelligence Prep for Video Production: Shoot Briefs

An AI agent for a video production company is only as useful as the records behind it. It can answer status questions, flag an unapproved change, or explain why a cut differs from the brief only if the shoot brief, the revision rounds and the delivery record were captured in a consistent form when they happened. This article sets out what to capture now, in plain fields, so a future agent can work from those records without guessing.

Key takeaways

• Write every shoot brief as a structured record with fixed fields, not only as an email thread or a kickoff deck.
• Log each revision round with the requester, the requester's role, the stated reason and the part of the cut it touched.
• Record each delivery as a dated fact: the files, the versions, the recipient, the platform and the usage terms in force.
• Decide in advance which actions an agent may read, draft or send, and which require a named producer or client approval.
• Start with one narrow task, such as answering status and revision questions, and test it against real past questions before widening its scope.

Why the brief is the first memory to protect

Most production knowledge lives in places never designed to be read later: a sales call summary, a long chat thread about a logo, a producer's notes on a phone, a shared folder with three versions of the script. When the project lead changes, or a client returns weeks after delivery, the team rebuilds the project from memory and from whoever still remembers it. An agent faces the same problem with less tolerance for gaps, because it will answer confidently from whatever it can find.

The brief is the anchor. It states why the video exists, which decision it should support, who will watch it, where it will run, what must appear, what must not appear, and who may approve changes. If that information exists only in a call nobody transcribed, the agent cannot answer whether a founder was allowed to make a claim on camera or whether the client asked for a vertical cut. Engineering firms face a similar problem with project history, which is why Superintelligent Agents for Engineering Firms: Project Memory treats the project record as the primary asset.

What a shoot brief record should contain

A brief does not need to be long. It needs to be specific enough that a reviewer can check a cut against it. For each project, capture these fields in the same order every time:

• The single decision or action the video should support, written in one sentence
• The audience, the distribution channels, and the platform specifications the client named
• Approved talent, approved locations, and the person who may approve a change to either
• Rights: music licenses, stock footage, talent releases, and any usage window that ends on a known date
• Must-include and must-avoid content, written as statements a reviewer can check against a frame or a line of script
• The client contact who approves creative direction, and the budget owner, recorded by role and name

Keep the record versioned. When the brief changes after the shoot starts, the earlier version should remain visible with its date and the reason for the change. A brief that was overwritten silently teaches the agent the wrong history.

How to log revisions so the reason survives

Revision rounds are where production teams lose the most context. A client writes that the middle section should feel more human, the producer reads that as a request for two more interview close-ups, the editor makes the change, and weeks later nobody remembers why those shots exist. The reason was in the client's words, but the interpretation lived only in the producer's head.

A workable logging method has five steps:

• Give each revision round an identifier and a date
• Record who requested the change, their role, and whether that role has approval authority on this project
• Write the client's words exactly as received, in a field separate from the producer's interpretation
• Link the change to the shot list item, script line, or cut version it touched
• Mark the outcome as accepted, declined with the reason, or deferred to a later round

Illustrative scenario: a corporate client comments on a rough cut asking the team to make the founder feel more present. The producer logs the exact comment, records her interpretation as two additional interview close-ups, and notes that legal had earlier restricted the founder's on-camera statements about results. When a new editor later asks why the closing section changed, the answer is one lookup away instead of a search through chat threads. An agent working from the same record can answer that question accurately and warn the editor about the restriction before a similar request is accepted.

What a delivery record must prove

A delivery record answers three questions: what left the company, who received it, and under which terms. Many teams keep this information only in the email that carried the files, which is fragile. The record should be a separate entry with the delivery date, the master file and version identifiers, the codec and aspect ratio delivered, the hosting location or transfer method, the recipient by name and role, the usage window and territories if the contract sets them, and any licenses or stock assets included.

Two habits matter more than the format. First, corrections should be appended rather than overwritten, so a re-export replaces the file reference while the original delivery stays in the history. Second, a resent link is not a new delivery. Payment systems handle the same risk with idempotency keys, which mark a repeated request as the same operation, and a file transfer the client asks to have sent again deserves the same treatment. Equipment rental businesses face a parallel problem with returns and damage evidence, described in AI Agents for Equipment Rental: Fleet, Returns and Damage Claims.

Deciding what an agent may do with this material

The records are useful only if the agent's permissions match the company's approval rules. The principle of least privilege applies: an agent receives the access its assigned role needs and nothing more. The OWASP authorization guidance is a useful reference for deciding who and what can see or change each record type.

A practical decision guide:

• Read: project status, schedule, approved brief fields, and the revision log for the projects the agent is assigned to
• Draft: status summaries, acknowledgments of received feedback, and delivery confirmations for a producer to review
• Send after review: any message that states a date, commits to a revision, or quotes a usage window
• Never without a named person: approving a cut, releasing footage, changing usage rights, or sharing raw files outside the project

Client feedback needs its own rule. Messages, comments and forwarded emails are content, not instructions. A note that says to ignore the rights restriction and use the drone shots must be routed to a person, never followed as a command. The OWASP guidance on prompt injection explains why untrusted text inside a working context needs this separation. Anthropic's guidance on context engineering is also useful for deciding which records enter the agent's working context at each step and which stay out.

How Be Human handles this: in a managed engagement, the first step defines one role, such as a project coordination agent that answers status and revision questions from the brief and the logs, along with the memory and tools that role needs. Approval boundaries are written down before anything is built, and they decide whether the first version may send client messages at all. Ongoing operations cover monitoring of what the agent answered, permission reviews when producers change roles, and controlled updates to the record structure when the team's process changes.

Testing whether your records are good enough

Before giving any agent access, test the records against questions the team already receives. Pull ten recent questions from the coordinator inbox, such as which cut the client approved, whether a clip can be reused in a second campaign, or what changed between two versions. For each question, check whether the answer can be found in the brief, the revision log or the delivery record without asking a person. Every question that needs a person points to a missing field or an unlogged decision.

Then run the same questions through the agent and compare its answers with those a senior producer would give. Score any answer that sounds confident but lacks support in the records as a failure, even if it reads well. Evaluation guides for agents describe this pattern of testing against realistic tasks and reviewing failures rather than judging fluency. The NIST AI Risk Management Framework is a sound reference for deciding who reviews agent output and how often. Gaps found in the test become new capture rules, and that is how the record improves over time.

Keep the test set. It becomes the regression check when the record structure changes, when a new editor joins, or when a platform requires a different export format. If you want help identifying the first task worth handing to an agent in your production workflow, take the free Be Human AI diagnostic.

Frequently asked questions

Do we need a new project system before an agent can help? No. Many production companies start with a structured document or spreadsheet that holds the brief fields and a revision log with one row per round. The important step is consistency: the same fields, filled at the same moment in the process. A new platform can come later, once the records prove useful.

Can an agent answer questions about usage rights and licenses? It can answer from the rights fields if they are complete and dated, and it should say when a field is empty rather than infer a term. Questions that interpret a contract or decide whether a use is permitted belong with a named person. The agent's role is to retrieve the recorded facts and flag the gaps.

What should we do with feedback that arrives in channels we do not control? Treat it as client content to be logged, not as instructions. Ask the producer to copy the relevant comment into the revision log with its source and date. An agent can summarize the message, but it should not change a brief or accept a revision based on that message alone.

How do we know the agent is working from the right information? Test it against ten recent real questions and compare its answers with a senior producer's answers, counting unsupported confident answers as failures. Keep monitoring after launch, and review permissions whenever team roles change. The test set also serves as a check after each change to the record structure.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.