From brief to artifact: the OpenDesign run
OpenDesign's central behavior is easiest to understand as a run: a brief enters through a web, desktop, or CLI surface, passes through a daemon that resolves project context and runtime, and ends as a file that can be previewed or handed off. The question is not simply how a coding agent answers a prompt, but how OpenDesign turns that answer into durable project state. Tracing this flow shows what the daemon actually contributes, why local-agent and API/BYOK execution require different handoff contracts, and where a successful run can fail.
A useful starting point is to stop imagining the output as a message. The visible response may contain progress, questions, or a short summary, but the product's durable unit is a project workspace. That workspace gives the result a place to be inspected and changed after the process that generated it has ended.
The daemon turns a brief into a running project
A request begins at the surface, but the surface is not the source of truth for the work. OpenDesign's web application and its od command-line interface call the same daemon APIs. The browser provides the collaboration surface—brief input, project selection, preview, settings, and streamed status—while the CLI provides a machine-readable route for a person, script, or another coding agent. Both ask the daemon to create or select a project and start a run.
The daemon then resolves the conditions under which the request will execute. It identifies the project and its current files, the active design system, the primary skill or rendering template, any additional selected context, the chosen runtime, and execution metadata. This is an important distinction from a thin chat proxy. A chat proxy might forward text and wait for text. OpenDesign decides which collection of instructions and files belongs to the run, which agent process should receive them, and which project should receive the result.
The selected runtime is launched with the project workspace as its working directory when it supports filesystem execution. The agent is therefore not writing into an abstract response buffer. It is working in the same project context that the daemon and the user can later inspect. The runtime's output is translated into a shared event vocabulary: thinking or reasoning where available, tool calls and results, text deltas, file writes, errors, and completion. The exact richness depends on the CLI, but the daemon gives the surrounding product a common way to observe what is happening.
That stream is not merely a visual effect. A design task can involve clarification, planning, several file operations, and a preview refresh before it reaches a usable state. Returning only a final paragraph would hide whether the agent had written anything, whether the preview had updated, or where a failure occurred. Streaming lets the interface show progress while the process is alive and lets the file workspace react to writes instead of waiting for a terminal transcript to be copied back by hand. It also gives cancellation and error reporting a defined boundary: the daemon can manage the run's lifecycle even though the selected CLI owns the model-and-tool loop.
The project's data model follows the same division. The daemon owns projects, conversations, messages, project files, run bookkeeping, and preview/import/export routes. The browser is not a second project database. It can remember interface preferences, but the durable work is mediated by the daemon. That makes the project a shared object for the web UI and the CLI rather than a private folder visible only to the terminal process that happened to create it.
The first execution profile is therefore a chain of state transitions:
- A surface submits a brief against a project.
- The daemon resolves the project, active context, runtime definition, and execution profile.
- The daemon launches the selected structured runtime in the project workspace.
- The runtime emits events as the agent reasons, calls tools, and writes files.
- The daemon records those events and updates the project file view.
- A previewable file becomes the rendered deliverable, and export or handoff can consume the same files.
The agent remains the active executor in this chain. It decides how to interpret the brief and how to use its tools. OpenDesign supplies the conditions that make the work continuous: the relevant context is attached, the working directory is known, file events become project state, and a rendered result is visible outside the agent's own terminal.
This also establishes a meaningful success condition. For a filesystem-capable run, a polished final message is not enough. The run has produced something useful only when the expected project file exists, the host can render it or otherwise expose it, and the file remains available for the next action. An agent can say that it created a dashboard while leaving no previewable file behind; in that case, the handoff has failed even if the chat response sounds complete.
The boundary is especially important because OpenDesign supports several kinds of runtime. An adapter describes how to invoke a CLI and how to interpret its stream, while a shared engine performs the common lifecycle. Some runtimes expose structured events and file tools. Others return a plain stream. The daemon can normalize these interfaces, but normalization does not erase the conditions imposed by the underlying process.
The two branches share a destination, not a process. That is the key to understanding the second profile.
Two handoff contracts, one delivery boundary
A structured local runtime can use file operations directly. Its canonical deliverable is the file it writes in the project workspace. The agent's final text is expected to summarize what it did rather than paste the entire source into a special response block. This keeps the chat readable and lets the file viewer, preview renderer, and export tools work from the same source of truth.
Plain-stream and API/BYOK execution work differently. These paths do not expose filesystem tools in the model loop. The host therefore asks for one complete <artifact> block in the response. The block carries an identifier and a supported text type, followed by the source that should become a project file. Once the run ends, the daemon scans the captured output, extracts supported blocks, and writes them through the normal artifact path. HTML, CSS, SVG, and Markdown are among the supported text forms described by the adapter contract.
This is not just a formatting preference. It is a substitute for the missing file tool. In the filesystem profile, the agent can create a file at the moment it performs the work. In the text-artifact profile, the model can only return text, so the host must recognize a complete source block and materialize it after the fact. Asking a filesystem-capable runtime to echo its source in an artifact block would duplicate the canonical file. Asking a text-only runtime to behave as if it had written a file would leave the project empty. Each profile has a different obligation because each crosses the agent-to-workspace boundary differently.
The shared destination does, however, create a useful product invariant. After materialization, both paths can expose a project file, render a preview, and pass the result toward export or handoff. A person does not need to learn two entirely separate ways to inspect the finished artifact. The file workspace becomes the adapter between heterogeneous agents and the rest of OpenDesign.
That common boundary also explains why the system can support both a local agent and a provider-backed run without pretending they are equivalent. A local CLI may stream tool calls and file writes as they happen. A BYOK run may return a complete HTML document only when the provider finishes. The UI can place both results in a project, but the amount of intermediate visibility, the editing affordances, and the failure diagnosis will differ.
Consider a simple request for a responsive landing page. With a filesystem-capable runtime, the agent may read its staged skill, inspect the design-system context, create the HTML file, and trigger a preview update while the run is still visible. If the agent stops after planning, the project may contain no renderable page. If it writes a page under an unexpected name or fails before the file event reaches the daemon, the output boundary is incomplete. The right diagnosis is not “the model gave a bad answer”; it is “the filesystem handoff did not produce the expected project state.”
With a text-artifact runtime, the same request has a different finish line. The response must contain one complete supported artifact block. A prose description of the page, a fenced code fragment without the required artifact envelope, or a truncated block is not the canonical deliverable. The daemon leaves unsupported output unchanged rather than guessing what file should be created. Here the failure is located at parsing or materialization, even if the provider successfully generated a large amount of text.
The distinction helps separate four kinds of failure that are easy to conflate:
- Runtime discovery or launch failure: the selected CLI is unavailable, cannot authenticate, rejects its invocation, or exits before producing a usable stream.
- Execution failure: the agent begins but cannot complete its tool calls, model interaction, or file operations.
- Filesystem handoff failure: the structured run completes without a suitable project file or without the file update becoming visible to the daemon.
- Text-artifact handoff failure: the plain/API response has no complete supported artifact block, so there is nothing safe to materialize.
The preview can introduce another boundary. OpenDesign renders project files in sandboxed iframes, and some host integrations require a particular rendering path. A page that exists on disk may still fail to preview because it is malformed, depends on unavailable resources, or does not satisfy the host's expected artifact contract. Preview success is therefore a useful verification step, not an automatic consequence of file existence.
Exports sit after this boundary. HTML, PDF, PPTX, ZIP, Markdown, and media-specific paths consume the produced project material according to the artifact type. A deck may need navigation and print behavior that a prototype does not. A media generation run may produce an image, video, or audio asset rather than an HTML page. The shared workspace makes these deliverables discoverable, but specialization remains downstream: the host cannot infer every format's semantics from the fact that a file exists.
The practical implication is that OpenDesign's “same place” promise is stronger than its “same experience” promise. The project workspace, preview surface, and handoff routes provide continuity. The selected runtime still determines how much of the run can be observed, which tools are available, how authentication works, and how the agent responds to correction. The daemon can expose a common event and file model, but it cannot manufacture capabilities the upstream CLI does not provide.
That is also why the run should be judged by state, not by conversational fluency. A concise response followed by a valid artifact is more successful than a detailed explanation with no file. Conversely, a page that renders is not necessarily correct, branded, accessible, or ready for production. The run has crossed the materialization boundary; quality and refinement still require the context and review mechanisms that shape what the agent does before and after writing.
OpenDesign's first contribution is thus a common delivery boundary for unlike agents. It takes responsibility for the project, the stream, and the materialized artifact while leaving execution to the selected runtime. The next question is what that runtime is told to do in the first place: how a portable skill, a rendering template, a design-system contract, and universal craft rules are composed before the agent begins.