Core orchestration: understand, route, edit, and gate

The image-enhancement system is not one undifferentiated agent. It is an orchestration of separate responsibilities:

1. Understand the image and route it.
2. Enhance the image only when routing says to do so.
3. Use QA feedback to correct a failed edit.
4. Run a final post-processing QA gate before publication.

This separation matters because each stage answers a different question. The router asks, “Should this image be enhanced?” The editor asks, “How should it be changed?” QA asks, “Did the result satisfy the required checks?” The final gate asks, “Is the item safe and ready to publish?”

1. Understand first, then make a route

The first stage uses multimodal image understanding. In this context, multimodal means that the system reasons about an image together with related textual information, rather than treating the pixels as the only input.

The image-understanding and routing agent produces a description of the photo with an LLM. It then turns that description into a structured output. A structured output is an organized representation that downstream software can inspect consistently. The source does not specify the exact schema or fields. The important design is the sequence:

photo
  ↓
multimodal understanding
  ↓
structured description
  ↓
enhance or skip?

The structured result supports a routing decision. The image is sent either to the enhancement path or to the skip path. This is different from asking the editor to process every image. Selective routing avoids unnecessary work and reduces the risk of changing an image that is already suitable.

Skipping is a deliberate safe outcome

If the router decides that enhancement is not needed, the system keeps the original image. That is not a failed enhancement. It is a successful decision to preserve the existing image.

Keeping the original protects two things:

• Fidelity: the published image remains tied to the merchant's source material.
• Safety: the image is not exposed to an editing step that could introduce an unwanted change.

The router therefore has its own quality requirement. It must not only find images that need help. It must also avoid sending good images into a process that may add cost without improving them or may degrade them.

2. Edit, check, and self-correct

Images that take the enhancement route are passed to an editing agent. The editor does not have to accept its first output as final. It can use QA feedback to revise the result and try again.

The basic loop is:

edit image → QA check
     ↑          │
     └─ feedback┘  (when the check fails)

QA feedback gives the editor information about what went wrong. The editor can then self-correct instead of producing an unrelated second attempt. This makes the loop more than repeated generation: the result of one check becomes an input to the next editing attempt.

The loop is bounded in the production design. The presenters explain that the editor can run through a number of loops, but this chapter's source does not state the numeric limit. If the output continues to fail, the system does not force a bad image through merely because it has spent compute on it. The failed case is withheld from publication.

This is a fail-closed choice. When the system cannot produce an acceptable result, it takes the conservative path of not publishing the enhanced output. In other words, the system prefers withholding a failed result to releasing it merely because the editor has already spent compute on it.

Click to enlarge

Source visual at 5:55 — The diagram shows image input moving through quality understanding and routing, then splitting into enhancement or skip. It also shows generation and QA feedback. The visible diagram does not show an editing-agent label, a no-publication branch, or a menu endpoint; those parts come from the spoken workflow rather than from the visible labels.

3. The final gate is a separate defense

Passing the editing-stage QA loop is not the same as being ready for the menu. After enhancement and the earlier QA checks, the system performs final post-processing and QA. This final gate controls whether the result can be published.

It helps to distinguish the two gates:

Check	Main question	Position in the flow
Enhancement-stage QA	Can this edit be corrected or accepted?	Inside the edit-and-feedback loop
Final post-processing QA	Is the resulting item ready for publication?	After the enhancement path, before the menu

The second check is important because an earlier stage may miss a problem, or a later post-processing step may create one. A final gate gives the system one more explicit decision point before the image reaches customers.

The whole orchestration can therefore be summarized as follows:

understand photo
      ↓
route: enhance or keep original
      ├── keep original ───────────────┐
      └── enhance → edit → QA          │
                       ├─ fail → feedback → edit again
                       ├─ repeated failure → withhold
                       └─ pass ─────────┘
                                      ↓
                         final post-processing QA
                                      ↓
                              publish to the menu

The diagram is a teaching summary of the sequence described in the talk. It should not be read as a complete implementation specification. The source does not disclose the exact structured schema, QA criteria, or loop limit.

The central idea

Agentic flexibility is placed inside explicit decision boundaries. Understanding and routing decide whether editing is appropriate. Editing may use feedback to improve its own result. Failed outputs can be withheld. Final post-processing QA makes publication a separate, deliberate gate.

This design keeps “the model produced an image” separate from “the system is willing to publish the image.” That distinction is the foundation for the later evaluation, logging, and closed-loop tuning discussed in the lesson.