Multi-modal agents: predictable images, objective eyes
by the end you can:
- Design images for predictability with spec-first generation
- Explain why the generator must never grade its own work
- Divide interpretation labor: separate perception (inventory) from judgment (audit)
- Run an objective conformance check against an approved spec
Evaluating the final output represents the most complex challenge in multi-modal agent design. A vision model describes pictures as fluently as a language model cites papers, and this linguistic fluency perfectly masks the confabulation we identified in module 01. This module teaches the complete discipline of visual generation. We establish predictability going in by requiring a strict specification before rendering a single pixel. We enforce objectivity coming out by dividing the labor: an observer catalogs the image without knowing the expectation, and a judge evaluates the results without ever seeing the pixels. Every example below, including the failed verification, derives from a single, live production run.
the spec before the pixel
Melchizedek’s Designer agent operates under a strict architectural mandate to refuse generation on the first turn. Phase 1 converts your initial request into a deeply nested JSON payload. This structure defines subjects with exact counts, atmosphere, lighting, medium, camera emulation, composition, aspect ratio, and one synthesized master prompt. It presents this payload and waits. Phase 2 initiates only upon explicit human approval, translating the confirmation gate from module 01 directly into visual architecture. The spec-before-the-image post details this contract completely alongside its own trace. We can compress it to its foundational law here:
### PHASE 1: DESIGN & CONFIRMATION
# NEVER call generate_image. Present the JSON payload and ask approval.
### PHASE 2: GENERATION
# Only generate upon explicit confirmation ("build it", "approve", "go ahead").Predictability requires rigorous specification rather than simple hope. Every field within the payload establishes a concrete claim that the finished image must satisfy. This structure forces a critical architectural question: who holds the authority to check the final result?
the eye that doesn’t know
A robust system completely separates the generator from the evaluation process. The cognitive blind spots responsible for drawing an error will naturally approve that same error during a review. We apply the maker-never-grades law from module 03 directly to visual pixels. Furthermore, we must isolate the reviewer from the initial specification. An observer expecting to find three amphorae will often subconsciously hallucinate the third to fulfill the contract. Expectation bias operates silently and corrupts the entire verification loop.
Therefore, the syndicate utilizes an observer tool whose physical signature makes bias structurally impossible:
tools:
- "generate_image"
- "inspect_image" # accepts ONE parameter: a file path. Nothing else
# can ride along. The spec physically cannot
# prime the inventory.The inspect_image tool reads the saved file and executes a fixed protocol against a vision model. It catalogs subjects with exact counts, composition, light, palette, medium cues, text, and structural artifacts. It performs this task strictly without quality judgments or attempts to infer human intent. We author this protocol once directly in the code, ensuring no orchestrator can accidentally decorate the instruction with expected outcomes.
the judge that doesn’t look
The SpecAuditor functions as a text-only leaf agent. Because it holds the output schema directly, it possesses zero transfer powers, adhering to the strict ADK constraints explored in the critic patterns. It receives the approved payload alongside the blind inventory and actively diffs them field by field. It returns a machine-checkable judgment containing a per-field status of match, mismatch, or unverifiable. It provides a total conformance score and exactly one actionable recommendation. Its core instruction distills the ethic of this entire module into a single directive: judge conformance, never beauty.
We executed this complete loop in a live environment. The user requested exactly three phosphor-green amphorae resting on a stone shelf, set against a dark background with a terminal-glow aesthetic. The system approved the specification, generated the image, and demanded a formal review:
The system returned a conformance score of 57. The generator produced a gorgeous photograph of a CRT monitor displaying the requested graphic. The content matched perfectly, but the physical medium failed the specification entirely. The divided pipeline caught this hallucination with absolute precision. The blind inventory reported dials, cables, and a heavy plastic chassis it had zero reason to expect. The auditor subsequently diffed those raw physical observations against the specification’s demand for a virtual dark terminal space. Now take the observer’s chair yourself. The image below represents the actual output from this run:
Equip yourself with the materials. Download the complete extended syndicate, which contains both phases, the review loop, and the live audit JSON: image-production-syndicate.md. Download the blind protocol and audit schema, designed to be portable across any vision model: visual-inventory-protocol.md. You can run this live by executing npm run syndicate:image. Follow the sequence to describe your concept, approve the contract, and instruct the agent to inspect and audit the image against the approved spec. This requires Node 20+ and a Gemini key, running entirely without a database.
We have examined five specimens to learn one continuous lesson. Ground the model to prevent fabrication. Define the voice to ensure consistency. Gate the output to enforce quality. Maintain the record to guarantee continuity. Separate observation from judgment to protect the truth. Constraint does not oppose these machines; constraint actively transforms them into reliable instruments. One final room remains. We will turn these instruments directly upon the workbench itself. Module 06 places an agent inside your repository and teaches it to build new features strictly under your authored law.