Design goals for the agents

The image system is not designed to maximize one visual-quality score. The presenters define six goals that must hold at the same time: preserve authenticity and trust, improve images selectively, optimize the marketplace globally without cannibalizing particular merchants, ship safely, learn continuously, and operate at scale with cost efficiency.

Core idea: A production image agent is successful only when its improvements are useful, faithful, safe, measurable, and affordable. A polished image that damages trust or merchant outcomes is not a successful result.

Six objectives in one design

The slide below presents the goals as a group. This matters because the goals can pull in different directions. More editing may increase apparent polish, for example, but it can also increase cost or change an image that was already good. The source does not give a formula for combining the objectives. It presents them as simultaneous requirements for the system.

Click to enlarge

Visual at 248.3 seconds — A slide titled “Our Goals” presents six simultaneous objectives for the image agent.

The visible slide combines authenticity, selective quality improvement, marketplace-wide optimization with merchant diversity, safety, continuous learning, and scalable cost efficiency. It does not provide numeric thresholds or a priority order among these goals.

1. Preserve authenticity and trust

The first goal is to make the result look authentic and trustworthy. Authenticity here means that the enhanced image should still look like a real representation of the food, rather than like generic or obviously AI-generated food photography.

This goal includes more than visual style:

• the result should remain faithful to the source image;
• the merchant's visual identity should not disappear; and
• the system should avoid changes that make customers distrust what they see.

The important distinction is between enhancement and unconstrained generation. Enhancement starts from a merchant's existing photo and improves it selectively. It is not permission to invent an idealized dish that the source does not support. The presenters therefore treat trust and resemblance to the original as part of quality, not as optional policy checks added after quality has been optimized.

2. Improve quality selectively

Selective improvement means deciding whether an image should be enhanced at all. The system should not automatically send every image to an expensive editing model.

There are two basic cases:

1. An image has a defect that the enhancement system can usefully address. The system sends it down the enhancement path.
2. An image is already good enough, or enhancement is unlikely to help. The system keeps the original rather than processing it unnecessarily.

This decision protects several things at once. It can avoid spending compute when there is no expected quality lift. It can also avoid degrading a strong original through an unnecessary edit. In this design, keeping the original is not a failure to use AI. It is a deliberate outcome of routing.

The distinction is useful when interpreting later metrics. A system that edits more images is not automatically better. It must improve the right images while avoiding needless processing and avoidable changes.

3. Optimize the whole marketplace, not one slice

The third goal is global optimization. The target is the health of the marketplace as a whole, not only the average quality of one image category or one merchant group.

The presenters specifically warn against improving one part of the marketplace by cannibalizing certain merchants. In this context, cannibalization means that a change may help one segment while taking attention or business away from other merchants. An aggregate improvement could therefore hide a harmful distributional effect.

This creates a constraint on optimization:

Narrow optimization	Marketplace-wide optimization
Maximize a local image or segment metric.	Check whether the broader marketplace remains healthy.
Treat a higher average as sufficient evidence.	Look for harm to particular merchants or segments.
Make different inputs follow one generic visual target.	Preserve merchant identity and marketplace diversity.

This is also why diversity appears beside quality on the goals slide. If every merchant's photos are pushed toward the same visual style, the marketplace can become less distinctive even if the images look uniformly polished. The source frames this as a system-design concern, not as a claim about a measured amount of cannibalization.

4. Ship safely

The agent must be safe to put into production. Safe shipping means that a proposed improvement passes checks before it is exposed to customers and merchants. Those checks need to protect against more than a visibly unattractive result. They also need to catch unfaithful edits, policy problems, and other failures that could damage trust.

This goal explains why the later workflow contains explicit eval gates. The agent is allowed to be flexible, but it is not allowed to treat its own generated image as automatically acceptable. A failed check should lead to correction, retention of the original, or withholding publication rather than a forced release.

The source does not specify all guardrails or their thresholds in this chapter. It does establish the design direction: safety is a first-class objective, and shipping must be controlled by evaluation rather than by generation alone.

5. Learn continuously

The system must continue learning after its initial launch. Real marketplace inputs change, and new failures can appear even when an offline evaluation looked good. Continuous learning therefore means building a recurring feedback process that can find failures, improve the agent's configuration, and check the proposed change before release.

A useful teaching model is:

production cases and feedback
          ↓
      inspect outcomes
          ↓
 diagnose a mismatch
          ↓
   tune the agent/configuration
          ↓
    evaluate and guardrail
          ├─ pass → ship
          └─ fail → revise

This is a teaching model of the direction described in the talk, not a complete implementation. The later chapters make the loop concrete with logging, human-aligned labels, drift checks, and rollback. The key point for this chapter is that learning is part of the initial design goal. It is not an emergency repair process added only after the system fails.

6. Work at scale with cost efficiency

Finally, the agents must operate at marketplace scale without making every request unnecessarily expensive. Cost efficiency includes the resources and operational burden required to process a large and varied stream of images. It is therefore connected to selective routing, model choice, latency, and the number of enhancement attempts.

Cost efficiency does not mean choosing the cheapest model in every case. A cheaper route may produce lower quality, while a more capable editor may be justified for a difficult image. The system needs to spend more effort where it is useful and avoid spending that effort where it is not.

This makes scale a design requirement, not merely an infrastructure detail. A workflow that looks good on a few examples may still be unsuitable if it processes too much content, takes too long, or repeatedly retries low-value cases.

How the goals constrain one another

These objectives are best understood as a set of gates around the agent:

flowchart LR
    I[Marketplace image] --> R{Worth enhancing?}
    R -->|No| O[Keep original]
    R -->|Yes| E[Enhance selectively]
    E --> Q{Pass quality, faithfulness,
    policy, and safety checks?}
    Q -->|No| H[Reject, revise, or withhold]
    Q -->|Yes| P[Publish]
    O --> M[Observe marketplace outcomes]
    P --> M
    M --> L[Learn and tune continuously]
    L --> R

Teaching model: This diagram connects the six goals into one system view. The source establishes selective routing, safety, continuous learning, marketplace health, and cost efficiency as design concerns; the exact branch names and diagram are explanatory additions.

The main tradeoffs are easier to see in this form:

• Quality versus authenticity: an edit can look more polished while becoming less faithful or less trustworthy.
• Coverage versus cost: enhancing more images may increase coverage, but it also consumes more compute and can expose more images to degradation.
• Local gain versus marketplace health: one segment can improve while another is harmed.
• Flexibility versus safety: an agent can adapt to varied images, but its freedom must be bounded by evaluation gates.
• Immediate release versus learning: shipping quickly is not enough if the system cannot observe failures and correct drift.

These are not presented as a numerical optimization problem in the source. They are practical criteria for deciding whether an agent is ready to operate in production.

Why these goals shape the rest of the talk

The goals predict the architecture that follows. Selective improvement requires a router. Authenticity and trust require checks that compare the result with the source and its description. Safe shipping requires QA gates and a way to withhold failures. Continuous learning requires logs, human-aligned feedback, and a tuning loop. Marketplace-wide optimization requires monitoring outcomes by relevant segments. Cost-efficient scale requires that the system avoid unnecessary edits and retries.

The next chapter addresses the central design tension: a rules-based system is controllable but can be brittle, while a highly agentic system is flexible but needs guardrails. The six goals in this chapter are the criteria for choosing a useful balance between those two extremes.

Source boundary

The presenters name these six objectives but do not disclose their exact scoring formula, thresholds, model configuration, cost targets, or marketplace experiment results here. The examples above explain why the goals matter; they are not claims that the talk reports a particular metric improvement or a guaranteed absence of merchant harm.