While building mstudio, I asked a specific question: why was the agent looking at shot 02 when I was changing shot 01?
The records showed that it had not actually modified shot 02. It had brought old tasks from other shots into its reply and expanded a local request into a review of the whole film. A separate problem involved a real extra edit: when changing the description of a particular generation task, it also overwrote the prompt draft saved on the shot.
Those are different failures. One expanded inspection and reporting; the other changed an additional object. Both leave me wondering what else was handled alongside the thing I asked to change.
One shot contains several different objects
mstudio is a desktop video studio I am developing, with agents that can work on scripts, shots, and the timeline. A shot in that project can hold several related things: its design, a prompt draft intended for reuse, the description of a particular generation task, and the video that the task produced.
They are connected, but they are not interchangeable. I may want to try a different description once while keeping the original draft. I may want to revise the draft without spending money on another generation. Existing footage should remain available after a text edit.
If the product interprets all of these as changing the shot, it can easily bundle actions that I intended to keep separate. When someone asks for a small change, they may omit the mechanical steps. They have not thereby granted permission to expand the scope.
I started separating two questions: which object is the person pointing at, and what action are they requesting now? Editing a generation task updates that task description. Editing a reusable draft updates the shot. Generating again is another action; changing text must not silently trigger it.
This can sound like a storage detail. For the person using the product, it determines whether trying a revision feels safe enough to do.
Checking everything again is additional work
Consider a clip that is mostly satisfactory, with one sentence in its description still needing adjustment. If every change requires inspecting the draft, other shots, and existing results, the person has acquired another checking job. A fast agent response does not let them move on immediately.
More context can make this harder. An agent may read a problem discussed earlier and decide to handle it as well. A coordinator may turn a request to fix the spatial relationship in shot 01 into an instruction to check the sequence of the entire film. Each expansion can sound reasonable on its own. Together they change the task.
I narrowed delegation accordingly. A specialist can break down the current task, but should not add tasks on the user's behalf. Reading another shot may help establish continuity. It does not automatically put that shot on the list of things to change.
A conversation also contains statements from different sources: explicit user requirements, tentative assistant proposals, and suggestions from other agents. Treating all of them as obligations lets an old idea resurface during an unrelated edit. The person then has to explain again why it should not be done now.
Explain necessary knock-on changes
Some local changes do affect other parts of a film. For example, making a clip longer may require moving later subtitles. The product should identify those consequences rather than pretending each object is isolated. It should say which subtitles need to move and why, so the person can understand the reach of the operation.
Dragging a clip in an editor usually gives visible feedback about the object being moved. A conversational edit hides much of the operation. That makes it more important to identify the target and describe the actual result.
The completion message should be specific too: which task changed, what changed, whether another generation was submitted, and what remains unfinished. Old issues that were not handled in this turn should not be mixed into the completion report. If a change was not saved, say so. A proposed revision must not be reported as an action that already happened.
Task descriptions, shot drafts, and regeneration are now handled separately. The harder question is whether the system will continue to respect those distinctions in a long conversation, after several agents have passed work between them and older requirements sit beside a new request.
That is what I will keep checking with local revisions. When I ask to change one shot, can the product leave me needing to inspect only that shot?