Apparel Design → Print-Ready Kit
Turns a one-line t-shirt or marketing-visual request into 1–4 on-brand, printable variants, garment mockups and a print-kit ZIP a print shop can use directly, with brand rules enforced in code.
Workflow
From “Design request in chat (routed to the Graphic Designer agent)” to result
- 1. Trigger
Design request
The user asks in chat, e.g. a tee for the summer drop. The orchestrator routes it to the Graphic Designer agent, or an earlier workflow step hands over a visual brief.
- 2. Action
Purpose → Template → Subject
The Designer follows its PTS protocol and asks at most 2 clarifying questions. Slots already filled by an earlier step are not asked again.
- 3. Action
Template pre-fill
One of 8 templates (tshirt_design, instagram_story, hero_banner and others) fills aspect ratio, style, composition, lighting, tone, palette source and negative constraints. The user only supplies the subject.
- 4. Action
Compose the prompt
For apparel, the apparel prompt composer adds an explicit isolation directive so the result is a flat printable graphic, not a photo of a shirt. The brand kit is filled in automatically.
- 5. Action
Inject brand chrome
Logo and brand elements are appended to the prompt server-side, so brand consistency holds even if the model forgets.
- 6. Action
Generate 1–4 variants
OpenAI image generation, with a different layout style per variant from ten curated aesthetics.
- 7. Action
Garment mockups
Previews on a t-shirt, heavyweight tee, hoodie, polo, oxford and performance shirt.
- 8. Output
Print-kit ZIP
Master artwork, print-guide.json with standard placements and per-size print dimensions, and a README.txt, ready for the print shop.
Templates and brand chrome, explained
THE CONCEPT
Image templates + brand kit + brand chrome
THINK OF IT LIKE
A print shop's order form
Image templates + brand kit + brand chrome is like A print shop's order form
- Template pre-fills ratio, style and constraintsis like The form's size and paper boxes are already ticked
- User supplies only the subjectis like The customer just writes what to print
- Brand kit auto-filled into every promptis like The shop keeps the customer's colours on file
- Brand chrome appended server-sideis like The shop stamps its label on every order
Problem
For a founder-led apparel brand, every t-shirt design meant briefing a designer, waiting for drafts and re-briefing, and the brand drifted from one design to the next. Every channel and size of marketing visual was a separate request. Print placement and size were then specified by hand for each garment, which made the hand-off to print shops error-prone.
Architecture
This pipeline is the image half of a larger multi-agent system (linked below). The Graphic Designer agent runs on Claude Haiku 4.5 at temperature 0.3 and emits image-prompt directive blocks, which the server parses before anything is generated. Brand consistency comes from three layers that don't depend on the model remembering: a brand canon document (identity, ideology, voice, palette and logo rules) that every agent references, a workspace brand kit that is auto-filled into every prompt so the system never asks for brand details it already has, and brand chrome that the server appends to every image prompt. Variety is designed in rather than left to chance. Within a 4-variant batch, each variant gets a different look from ten curated poster aesthetics (editorial, vintage flyer, minimalist and others). Regenerating picks from twelve orthogonal variation hints (angle, time of day, focal length, medium, framing and others), so each re-roll gives a genuinely new direction instead of a near-duplicate. An existing image can also be edited with a text instruction.
Where the brand rules come from
flowchart TD
S([User: the subject]) --> P[Designer: Purpose, Template, Subject]
T[Template: ratio, style, lighting, constraints] --> C
K[Brand kit: palette, fonts, voice, logo rules] --> C
P --> C[Prompt composer]
C --> A{Apparel?}
A -- yes --> I[Add isolation directive: flat printable graphic]
A -- no --> B
I --> B[Server appends brand chrome]
B --> G[OpenAI gpt-image: 1-4 variants]
G --> M[Garment mockups]
M --> Z[(Print-kit ZIP)]Input
A short request with a subject, for example a "statement" marker-print tee, a block-print glyph tee, a summer-drop Instagram tile or a weekend workshop poster. Purpose, template and brand details are filled in by the agent and the brand kit.
Output
1–4 brand-consistent variants in the template's format, garment mockups for apparel, and a print-kit ZIP. The ZIP's print guide covers standard placements (left chest, centre chest, full front, oversized front, back collar, upper back, vertical side and others) and print dimensions for each garment size.
Integrations
Limitations
The Designer doesn't check its own image against the brief: there is no self-verification loop yet, so a weak result needs a manual regenerate. Generation is triggered by code and parsed directives; the agent doesn't choose tools itself. The planned next step is a vision-based QA agent that checks each image for brand palette, printability and legible text, and automatically rejects and regenerates failures within a budget cap.
Security Notes
API keys live only in environment variables, never in the database or the UI. A cost estimator holds a price table per model and fails loudly on an unknown model, so the cost gate is never silently skipped. Every database row is scoped to the signed-in user's Google account.
Learnings
Enforce brand rules in code, not only in prompts. Templates plus server-side brand chrome mean the user only has to describe the subject, and the brand holds whatever the model does. Asking the model for a flat, isolated graphic, explicitly, is what makes the output printable rather than a picture of a shirt.