THE RESEARCH / OUR INTERPRETATION
OWASP describes prompt injection through both direct instructions and external content. Our design implication is to treat retrieved documents as evidence, never as authority to expand an agent’s permissions.
Define the overnight package
An illustrative refurbishment workflow might start with approved photographs, a brief, supplied dimensions and a selected concept. Overnight work could prepare a candidate model revision, a check report and draft renders. The production model remains untouched until review. Photos do not establish hidden geometry or measured dimensions: the input register must keep those uncertainties visible, and the modelling task must stop where the agreed assumptions run out.
- 01Approved inputs
- 02Candidate workspace
- 03Independent checks
- 04Human release
Illustrative system boundary: scheduled agents prepare candidates; people approve changes to the project.
A job manifest is the agreement between designer and system
For a proposed overnight reception-study workflow, the manifest identifies project P-017, approved brief R06, model source R03, the permitted output folder and the exact deliverable set. It also names the modelling assumptions: supplied dimensions are authoritative; hidden construction remains unresolved; no live project file may be overwritten. Each worker receives a task-specific slice of this context, with a reference to the same immutable manifest. The modelling worker needs geometry constraints and output conventions. The rendering worker needs the candidate revision, camera list and material assignments. Neither needs the entire client correspondence archive. This is context engineering as information design: selecting the smallest sufficient, current and attributable input for a task, while retaining a route back to the source when the worker cannot resolve an ambiguity.
Give each role a smaller context and permission set
The reference role reads approved source folders. The modelling role writes only to a candidate workspace. The checker receives the approved requirements and actual model output, rather than the modeller’s success story. The render role uses a named revision and fixed output locations. Keep the current brief and accepted decisions in shared project context; retain temporary task notes separately. More agents should not mean more copies of confidential project information.
Project memory needs an authority structure
A useful memory design separates approved project facts, accepted decisions, working hypotheses and execution logs. These should not be merged into one evolving summary. A generated note such as “client prefers a wider counter” is a hypothesis until linked to an accepted decision or confirmed instruction. When the budget changes, the new brief can supersede an earlier constraint without deleting the historical decision trail. Retrieval should filter by project, revision and information status before assembling context. A worker’s own conclusion should not become approved memory merely because it was saved. Promotion requires a named review step. The practical failure to prevent is context contamination: yesterday’s rejected option appearing in tomorrow’s prompt as if it were part of the brief. More stored text does not necessarily improve memory.
| Event | System response | Review record |
|---|---|---|
| Source revision changes | Pause release | Revision conflict |
| Model check fails | Keep candidate isolated | Object + rule + evidence |
| Render request times out | Reconcile remote job | Job ID + output status |
| Reviewer rejects candidate | Retain production revision | Reason + next action |
The candidate workspace and the production model have separate write permissions. A review instruction alone does not enforce that boundary.
Plan for a failed run before scheduling one
A cron trigger starts a job; it does not supervise it. Give every run an identifier, a time limit, an iteration budget and a recorded starting revision. Prevent overlapping jobs from editing the same candidate. If a rendering service times out after accepting a request, check whether the job exists before submitting it again. Record source failures, model-check failures and incomplete outputs separately so the morning report cannot confuse “nothing changed” with “nothing worked”.
Recovery is a state machine, not another prompt
A run can move through queued, inputs-validated, modelling, checking, rendering, awaiting-review and closed. Failed and cancelled are explicit states, with the last complete artifact retained. Suppose the model is complete but one render request times out. Restarting the whole agent conversation risks generating a different candidate and duplicating remote render jobs. A safer recovery uses the recorded candidate hash and the render provider’s job reference to reconcile what already exists, then resumes only the incomplete step when possible. External services differ, so duplicate prevention must be designed for the actual interface. The scheduler should also take a project lock, record a heartbeat and release the lock on a controlled failure. A stale lock requires a recovery policy; silently ignoring it can create competing writers.
Make approval a real system boundary
The designer reviews the changed objects, remaining assumptions and check evidence before promoting a candidate. The system should enforce that separation through tool access and write permissions, not only an instruction asking an agent to be careful. Start with one bounded model type and one deliverable. Test recovery from interruption and rejection of a proposed change. An AI atelier earns wider scope by producing understandable, recoverable work that the team can direct.
The morning package should make disagreement easy
The review package should lead with what changed, what did not complete and what remains uncertain. For the reception example, that means a candidate revision, a change list tied to object identifiers, the check coverage, rejected alternatives and draft views. A polished render should not conceal a missing check. Approval should target a specific candidate, not whichever file happens to be newest in a folder. If the source model changes while the overnight run is active, release should pause for reconciliation instead of applying stale work automatically. We would commission such a workflow in stages: one manually triggered run, repeated runs with fixed inputs, deliberate interruptions, then scheduling. The release boundary should remain human-controlled until the studio has evidence that the particular scope is reliable and can maintain the controls.