Case Study 01 · Real System

Designing the orchestration layer for a multi-tool AI creative pipeline

Directing Claude, Blender, UE5, Figma, and ComfyUI through one agentic interface — instead of five disconnected tools.

Role

Sole designer & builder

Duration

2–4 weeks

Tools

Claude, MCP, Blender, UE5, Figma, ComfyUI

Status

Live pipeline capture in progress

Where this case study stands

This case study documents a real, currently-running pipeline — not a mockup. Screenshots, system diagrams, and before/after timing data are being captured live by actually running end-to-end jobs through the real setup (e.g. reference image → TRELLIS2 mesh → UE5 import, or a Figma component → UMG/Widget Blueprint), rather than reconstructed after the fact. The framing below is locked; the Solution and Reflection sections will be completed once that capture is run.

Problem / Context

Solo creators and small studios face fragmented, disconnected AI creative tooling. Designers prototype in one tool while assets move through another, losing context and reproducibility at every handoff — a reference image becomes a 3D mesh in one app, gets imported into an engine in another, and the reasoning that connected those steps rarely survives the trip.

Constraints

What makes this hard is not any single tool — it's the orchestration layer between them:

Each tool (Blender, UE5, Figma, ComfyUI) has its own object model, file format, and automation surface; MCP standardizes the interface but not the underlying semantics.
Irreversible or expensive steps (mesh generation, engine import) need approval gates rather than silent automation — a single agentic interface can't be allowed to run unattended through every step.
Reproducibility matters: a job that worked once needs to be re-runnable, not a one-off manual sequence.

This pipeline is built on infrastructure other teams are also converging on — Siddharth Ahuja's open-source blender-mcp, Chong-U Lim's unreal-mcp, Epic's UE 5.8 MCP plugin, Figma's official MCP server, and Comfy.org's Comfy MCP — which is part of what makes this worth documenting as a system rather than a personal hack.

Process

Scope for this write-up: document the pipeline as a system diagram plus annotated interaction flows, define 1–2 concrete end-to-end jobs, capture real before/after friction from actual use, and design/annotate the control & safety layer — approval gates, guardrails, and what makes a job reproducible.

Rejected direction

To be documented once the live capture session runs and an actual alternative approach is tested and set aside — this section will name the specific rejected approach and why, not a generic placeholder.

Solution

Pending live capture

Real screenshots, the system diagram, and the annotated interaction flow for the chosen end-to-end job(s) go here once the pipeline run is captured. Nothing in this section is populated with placeholder or invented visuals, per the no-fabrication requirement for this case study.

Reflection

Pending live capture

What to test next, honest limitations of the current pipeline, and any friction metrics will be written up from the real capture session — not estimated in advance.