The first checkpoint: what OpenDesign actually owns

OpenDesign now comes into focus as a chain with several owners: a person or surface supplies intent, the daemon resolves context and state, an existing coding agent performs the model-and-tool work, and a project workspace preserves the artifact. The useful judgment is whether those separations create real continuity rather than merely moving complexity between components. Connecting the run and the context stack makes the answer more precise: OpenDesign's strongest contribution is the coordination boundary, while its biggest unresolved tension is how much openness can coexist with predictable execution.

One request, several owners

Consider a request for a branded dashboard. The words in the brief do not by themselves determine the result. The active template may determine the broad shape of the output. A skill may specify how to structure the page and what checks to perform. A design system may set the typography, colors, spacing, and component patterns. Craft references may add universal rules about accessibility, hierarchy, or motion. The daemon resolves those inputs and gives the selected agent a composed context in which to work.

The request then crosses a second boundary. A filesystem-capable agent writes files in the project workspace and emits structured events. A plain or API-based agent returns a complete artifact block that the daemon materializes. The two paths differ in timing and capability, but the project workspace gives them a common destination. From there, preview and export tools can consume the result without requiring the user to understand the agent's internal protocol.

This is more than a tidy diagram. It explains why a failure at one point should not be blamed on every other point. If a design system is missing, the context resolution problem precedes model execution. If the agent is unavailable or unauthenticated, the run cannot start. If a structured runtime finishes without a previewable file, execution may have occurred but the filesystem handoff failed. If a text-only runtime returns prose without a complete supported artifact block, the materialization contract failed. The surface may display all of these as an error, but they imply different remedies.

flowchart LR Brief["Brief and project intent: user or surface"] --> Context["Resolved context: daemon"] Context --> Runtime["Selected agent loop: coding-agent CLI"] Runtime --> Handoff["Handoff: filesystem or text artifact"] Handoff --> Workspace["Project workspace: daemon state"] Workspace --> Preview["Preview and refinement: host"] Workspace --> Export["Export and handoff: host"] Skills["Skills and templates: workflow shape"] --> Context Brand["Design system and craft: visual and universal rules"] --> Context Plugin["Plugin: distribution and workflow envelope"] --> Context

The ownership model also clarifies what “composable” means. It does not mean that every component can be swapped without consequence. It means that the interfaces between components are explicit enough for one part to change while the others retain their role. A team can replace a skill while keeping its design system. A user can select another compatible agent while keeping the project files. A plugin can add typed context and stages without copying the entire design-system body into its manifest. The interfaces reduce unnecessary coupling; they do not eliminate all coupling.

There is a second, less visible interface: the prompt itself. OpenDesign composes execution rules, design context, craft guidance, workflow instructions, plugin blocks, and metadata into the input that the agent sees. The exact composition can vary by execution profile and prompt path, and the repository records that some prompt variants remain separately maintained. That caveat matters because the product is not defined by a single static paragraph.