The problem
Rendering one product is a craft problem. Rendering hundreds across models and upholstery colorways with consistent scale, lighting, framing, and materials is a systems problem. Mixing configuration and production caused decisions to be repeated and output quality to drift.
The engagement
The work began with a production constraint: hundreds of product and upholstery combinations had to pass through one shared Blender instance. I translated the rendering process into explicit responsibilities, handoffs, and failure states, then implemented an agent system that respected the limits of the underlying application instead of assuming unlimited parallel execution.
The solution
I designed four task-scoped agents for configuration, rendering, automated quality control, and event-driven recovery. The system separates decisions that should be made once from work that should repeat safely, using YAML briefs and filesystem inboxes as durable production contracts.
1. Separate configuration from production
Mesh mapping, material categories, scale rules, and model-specific exceptions belong to a one-time configuration step. Once that contract is approved, production runs can reuse it across upholstery sweeps without asking the system to rediscover the same decisions for every render.
2. Make sequential execution an architectural rule
The shared Blender instance cannot support multiple agents changing scene state at the same time. The pipeline therefore processes one render at a time. This is not a performance compromise hidden inside the implementation; it is a visible rule that prevents collisions, corrupted scenes, and nondeterministic output.
3. Use files as explicit handoff contracts
YAML briefs describe requested outputs, while inbox and outbox files record what each agent received and produced. These artifacts make work inspectable between stages, reduce hidden state, and allow a failed task to restart from a known boundary instead of replaying the entire pipeline.
4. Automate mechanical QA before human review
The quality agent checks framing, image fill, file size, transparency, and other measurable conditions. A failed check returns a specific correction request and can retry up to three times before escalation. Human attention is reserved for visual judgment rather than predictable production defects.
Why it worked
The architecture follows the production substrate. Narrow agents make responsibilities easy to reason about, durable handoffs make failures recoverable, and sequential execution protects the shared application. The system gains reliability by making constraints explicit instead of designing around an imaginary environment with unlimited concurrency.
Outcomes
- One approved model configuration can support repeated upholstery and colorway production without repeating setup decisions.
- Mechanical defects are caught before files reach human review.
- Failed tasks return actionable retry instructions and escalate only after three unsuccessful attempts.
- The same configuration, execution, validation, and recovery pattern can transfer to other shared-instance production environments.
Designed and implemented as an independent production-systems initiative.