Choosing a Multi-Model AI Workspace

A workflow-first checklist for deciding when a general chat, a specialized app, a control plane, or local execution fits — using Ethen's stated product boundaries.

Start with the work, not the model list. A multi-model AI workspace works when each kind of work has a clear home: quick questions stay quick, longer projects keep context, and operational controls stay reviewable. This guide uses Ethen's architecture direction dated 2026-09-20 and the repository app registry dated 2026-09-14. Both describe structure and direction. Neither proves that every separation has shipped or that any product is available to you today.

The one rule behind the checklist

Ethen's architecture direction states one operating rule for the whole ecosystem:

One capability can appear on multiple surfaces, but it should have one canonical product owner and one shared backend/state.

That sentence is the most durable selection criterion in this guide. When you evaluate any workspace, ask where the canonical version of each workflow lives and which other surfaces only offer a limited view. A limited view is not a defect. It is a deliberate boundary that keeps simple tasks simple while deeper work moves to a surface built for it.

The same document groups Ethen into five layers:

• Marketing Web for discovery, publishing, models, and docs
• Chat for fast, general-purpose conversation
• Specialized apps for focused professional work: Studio, Research, Designer, and Founder
• Platform for operating intelligence: Auto/Cortex, Code, Computer, Automation, Sentinel, AI Gateway, and GPU Compute
• Desktop for local chat, local code, and local models

Treat this as a design target, not a status report. The document is labeled final architecture direction, and target separation is not proof that every migration has shipped. The checklist below therefore asks what each surface is designed to own, so your decision survives interface changes.

Map your work before you compare tools

Instead of comparing workspaces by model counts, list the workflows you repeat, then match each to the surface designed to own it. Use these five prompts:

1. What do I need to produce: an answer, a draft, a design, a report, a patch, a deployed endpoint, or a verified outcome?
2. How long does the work live: one session, several days, or an ongoing project with history?
3. What context must travel with it: files, sources, branches, components, plans, approvals, or spend?
4. Who reviews or approves an action before it proceeds?
5. Where must execution happen: in a browser conversation, in a dedicated workspace, under operational controls, or on a local machine?

Keep that list beside you. The rest of this guide maps each answer to Ethen's explicit boundaries.

Checklist 1: Does a general chat fit?

Chat is the right starting point when the work is conversational, short-lived, and easy to discard or copy elsewhere. In Ethen's stated direction, Chat remains intentionally limited rather than becoming the full ecosystem.

The canonical Chat scope is explicit:

• Core Chat
• Model selector
• Files
• Artifacts
• Tools
• Memory
• Limited Deep Research
• Limited Studio
• Lightweight Designer
• Lightweight Code

Just as important is what Chat should not contain: the full Computer product, the full Research workspace, the full Studio catalog, or the full autonomous Founder system.

Use Chat when all of these are true:

• The task fits in a thread without projects, versions, or cross-session branches.
• A small set of models or a model selector is enough; you do not need to browse a full catalog.
• Any research needed is fast and conversational, with a prompt, a run, sources, citations, and a final answer.
• Any image, video, or audio need is a single generation, not a project with assets and history.
• Any design need is a quick generation such as a page, card, dashboard, or screenshot-to-UI draft.
• Any coding need is lightweight: explain code, write a function, fix a bug, draft a component, or edit a snippet.

Move on when the work accumulates state. If you re-upload the same files, re-explain project structure, track versions in filenames, or need approvals and evidence, Chat has done its part and a dedicated surface should take over.

The registry records Chat as a separate web product entry with its own path, package, and development port, distinct from Studio, Designer, Founder, and Platform entries. That supports Chat as one surface among several. It does not prove what Chat currently exposes in production.

Checklist 2: When do you need a dedicated app?

Ethen's direction assigns full professional workflows to separate products: Studio, Research, Designer, and Founder. The shared test is whether the work needs its own projects, history, and domain-specific objects. If it does, a thread is the wrong container.

Studio: creative work with a catalog and projects

Chat is designed to include only a curated Studio experience using flagship or recommended models, with simple entries for image, video, audio, and voice. The stated goal is simplicity: a small set of choices plus a path outward labeled in the direction document as more models opening the full Studio.

Full Studio is the separate dedicated product and the canonical home for the large creative catalog. Its stated scope includes image, video, audio, voice, editing, upscaling, generation, workflows, projects, history, assets, and a model explorer.

Choose the dedicated Studio direction when:

• You need to browse or compare many creative models rather than accept a curated few.
• Generations belong to projects with reusable assets, edit history, and workflows.
• Voice work shifts from live conversation to generation, narration, speech models, and voice projects.

One caveat: the architecture document labels Studio scope with a large catalog figure. That is a scope label, not a verified count of runnable models. The durable criterion is whether you need catalog browsing plus project state, not any specific number.

Research: questions that need sources and branches

Chat Deep Research is described as fast, limited, conversational research. The full Research app is described as a separate dedicated application with its own workspace objects: projects, searches, sources, evidence, branches, research agents, files, notes, citations, reports, research history, model selection, and research workflows.

Choose the dedicated Research direction when:

• A question spans multiple searches and must keep sources attached to claims.
• You need branches to pursue competing interpretations without losing the main line.
• Notes, citations, and reports must persist beyond one conversation.
• Model selection is part of the research method, not just a preference.

The architecture notes the full Research app can eventually use Ethen's own research runtime and multi-model orchestration, with Chat linking outward when more power is needed. Read both as direction, not implementation proof.

Designer: from quick generation to build workspace

Designer is explicitly split into two levels. Chat Designer handles lightweight requests such as designing a page, redesigning UI, improving a card, generating a dashboard, or turning a screenshot into UI. The full Designer app is a design and build workspace with projects, pages, canvas, components, assets, design systems, code, preview, deploy, domains, and version history.

Choose the full Designer direction when:

• Designs need components and a design system, not one-off pages.
• Preview, code, deploy, domains, and version history are part of the job.
• Multiple pages or iterations must stay consistent over time.

If only the first list applies, the lightweight path is the correct fit. That distinction keeps quick visual drafts fast without forcing every request into a full build environment.

Founder: goal-to-outcome jobs with verification

Founder is not described as a chat persona. It is described as the autonomous-jobs product and its own dedicated application, with the purpose of carrying work from goal to verified outcome.

Its stated scope is job-shaped: new job, jobs, runs, plans, tasks, evidence, approvals, files, connections, spend, activity, and results. Execution runs from goal through planning, research, tool and runtime use, approvals, verification, and delivery. Founder can use the missions architecture underneath, while the customer-facing product remains Founder.

Consider the Founder direction only when:

• The unit of work is a job with a goal, plan, tasks, and a reviewable result.
• Approvals, evidence, spend, and activity must be inspectable.
• Verification is part of completion, not an optional summary.
• Browser actions, code actions, or multi-step execution need boundaries and review.

This is the strictest gate. Without jobs, runs, approvals, and evidence, you do not need an autonomous-jobs surface; a Research, Studio, Designer, or Code workspace likely fits better. Treat Founder as a separately owned target product, not proof of availability.

Checklist 3: When do you need a control plane?

Some work is not about producing one artifact. It is about building, running, controlling, deploying, automating, and monitoring intelligence over time. Ethen's direction assigns that operating layer to Platform and summarizes it as operate intelligence, in contrast to Chat's interact with intelligence and Desktop's run intelligence on your own machine.

Platform's stated products are Auto/Cortex, Code, Computer, Automation, Sentinel, AI Gateway, and GPU Compute. The direction also sets an explicit limit: Platform should not become the canonical home for Studio, Research, Designer, Founder, Model Intelligence, or Local Models. Those products may be linked from Platform, but they remain separate applications.

Use this section when your workflow includes operation, not just interaction.

Auto and Cortex: orchestration with review

Auto/Cortex is described as the orchestration and autonomous execution control layer, with agents, runs, plans, models, tools, approvals, policies, budgets, execution, verification, and observability. Founder may use it internally, while Platform gives advanced users the full operating surface.

Select this layer when you need to constrain how agents run: eligible models and tools, policies and budgets, approval points, and verification records. If you only need one job's outcome, the Founder-shaped surface fits better; if you define and monitor the rules, use the control surface.

Computer: supervised execution with a clear owner

Computer belongs in Platform and should not be a Chat surface. Its stated scope includes sessions, browser, machines, screens, actions, permissions, takeover, history, credentials, logs, and execution state. Other products such as Founder or Auto may use the computer runtime behind the scenes, for example a Founder job performing a website action through the runtime, but the full management interface remains Platform-only.

Ask where sessions, permissions, takeover, credentials, and logs are managed. If those controls are missing or scattered across threads, the workspace lacks a reviewable computer-use boundary. In Ethen's direction, that boundary has exactly one home.

Automation and Sentinel: repeatable work under policy

Automation belongs in Platform, with workflows, triggers, schedules, runs, logs, connections, errors, retries, secrets, and status. Founder and Auto can create or invoke automations, but configuration and management belong in Platform.

Sentinel is the operational security, policy, governance, and monitoring system, with security, policies, guardrails, audit, risk, alerts, governance, compliance, and AI safety controls. Other applications can consume Sentinel policy decisions, while the full management interface remains in Platform.

Choose these surfaces when repetition or risk is the point: schedules, triggers, retries, secrets, audit, and cross-app policy. A thread can start such work, but triggers, secrets, and governance should not live there.

AI Gateway and GPU Compute: access and deployment paths

AI Gateway belongs in Platform. Its stated scope covers providers, models, API keys, routing, fallbacks, rate limits, usage, logs, costs, latency, caching, health, quotas, policies, and analytics. Marketing and Model Library surfaces can offer a use-through-Gateway path, but configuration and operation stay in Platform.

GPU Compute also belongs in Platform, with its strongest product connection to the Model Library. The core flow is stated as Model Library to open-source model to deploy to GPU Compute. The compute layer is expected to handle deployment, scheduling, routing, capacity, health, runtime, scaling, endpoints, usage, and cost.

Two limits apply. The infrastructure-source list and deploy-any-open-model phrasing are positioning in the architecture document, not verified deployment evidence. Gateway and compute choices still need concrete eligibility, health, quota, and cost records for each model and route. Ask whether the workspace exposes those records in one surface or leaves you to reconstruct them.

Checklist 4: Where should code live?

Code is the deliberate exception to one-surface thinking. The architecture says Code intentionally exists in multiple surfaces as one system exposed through different experience levels.

• Chat Code is lightweight and conversational: explain code, write a function, fix a bug, draft a component, or edit a snippet.
• Platform Code is the full cloud engineering workspace: repositories, branches, agents, terminal, multi-file editing, pull requests, builds, tests, deployments, and environments.
• Desktop Code is the local coding-agent environment: local repositories, local terminal, local models, cloud models, git, agents, file editing, and commands.

All three are expected to share architecture and project state where appropriate.

Match the code surface to repository reality:

• Stay in lightweight chat when there is no repository lifecycle.
• Move to the cloud workspace direction when branches, pull requests, builds, tests, deployments, or environments define done.
• Move to the local direction when the repository, terminal, and execution must stay on your machine.

The registry records Code as a separate heavy-client entry with an editor-workspace profile, distinct from Chat, Platform, and Desktop entries. That matches one Code system with distinct levels. It does not establish which levels are usable.

Checklist 5: Where should models be found and run?

Model choice lasts longer when discovery, comparison, and execution are separated. Ethen's direction puts discovery on the Marketing Web, keeps Model Intelligence behind the Model Library, and routes execution to Chat, Studio, Desktop, Gateway, or GPU Compute.

The Model Library is described as the canonical home for model discovery, with sections for model groups, providers, benchmarks, comparisons, pricing, capabilities, and model pages. Model Intelligence is the intelligence and data system behind it, not a Platform product. The user-facing term is primarily Model Library.

Each model page is designed to route users through up to five paths: try in Chat, open in Studio, run locally, deploy on GPU, or use through Gateway. That list is a design target, not evidence every path works for every model. For each model, verify which paths are actually eligible.

Then apply location rules from the same direction:

• Local Models belongs primarily in Desktop, not as a Platform web product. Its stated scope includes discover, download, installed, running, updates, storage, quantization, GPU, CPU, RAM, and local API endpoints. A Model Library run-locally path is designed to open Desktop, download, and run.
• GPU deployment belongs in Platform GPU Compute, entered from the Model Library.
• Programmatic access belongs through the Gateway, configured in Platform.
• Creative execution belongs in Studio, with only flagship paths in Chat.
• Conversational use belongs in Chat.

For every model decision, ask three questions. Where do I compare it: which library, benchmark, pricing, and capability records can I inspect? Where does it run: local machine, hosted deployment, gateway route, or product workspace? What survives the run: history, assets, evidence, logs, usage, or cost records? A missing answer marks the workspace boundary.

What the repository structure adds

The app registry records engineering separation without marketing language. It describes itself as repository truth at a point in time, with classifications verified against a census and runtime metadata re-verified by a discovery script.

First, it lists separately deployable applications with distinct paths, package names, frameworks, route classes, shell families, authentication providers, lifecycle profiles, and development ports. Chat, Studio, Designer, Founder, Code, Computer, Voice, Platform, infrastructure, Desktop, local runtime, missions components, workers, and the public web app each have their own entry.

Second, it distinguishes product shapes. Studio and Designer are heavy clients with media and design workspace profiles. Code is a heavy client with an editor-workspace profile. Computer and Voice are interactive services with session profiles. Founder is a web product with a provisional autonomy shell assignment. Desktop is an installable client. The public web app uses a different framework and public route classes.

Third, it records limits. Every application has a certification state of registered, and the header states certified is never hand-set. Maturity varies across production, beta, preview, and skeleton. Several entries show no deploy signal, null origins, or skeleton notes. Structural separation must not be read as shipment: the registry supports boundaries, not availability.

Evidence and limits you should keep

This guide stays useful only if its limits stay visible.

• Architecture direction is not implementation evidence. The 2026-09-20 document defines canonical homes and relationships. It does not prove what is deployed.
• Registry separation is not release evidence. Distinct applications, ports, and profiles show intended ownership. Registered state, mixed maturity, missing deploy signals, and skeleton notes show why availability needs separate proof.
• No vendor ranking is attempted. Nothing here compares third-party models, providers, prices, latency, or quality. Model decisions need fresh, task-specific evidence from the model record, gateway route, runtime, or deployment receipt that applies to your run.
• No Ethen availability is claimed. Dedicated apps, Platform products, Desktop behavior, gateway routes, and GPU deployment paths are described as assigned homes and design targets. Confirm the actual supported workflow and access conditions before relying on them.
• Large catalog and universal deployment phrases are scope language. Treat the Studio catalog figure as an architecture label rather than a runnable-model count, and treat broad deployment phrasing as positioning rather than a compatibility guarantee.
• Implemented web routes are narrower than the full product map. The inspected web route file exposes docs, model library, model intelligence, model detail, health, sitemap, and legal paths, with other requests falling to a catch-all. Product and platform destinations in marketing copy describe intended information architecture. Verify any specific product destination before publication or reliance.

Those limits do not weaken the checklist. They are the reason the checklist works over time. Workflow shape, state, review, and execution location change more slowly than model names and interface labels.

A concise decision pass

When you evaluate a multi-model AI workspace, run this short pass and write down where each answer points:

1. Can this stay a conversation? If the work needs only a thread, files, artifacts, and lightweight help, Chat is the right home.
2. Does the work need its own objects? Projects plus history plus domain state point to Studio, Research, Designer, or a job-shaped Founder direction.
3. Does the work need operation? Repositories, runtimes, triggers, policies, approvals, gateway routes, or deployments point to Platform surfaces.
4. Does execution need to stay local? Download, install, storage, quantization, device resources, and local endpoints point to Desktop.
5. Where is the evidence? Sources, citations, versions, logs, usage, cost, approvals, and verification records should live in the surface that owns the workflow, not in scattered threads.

Choose the workspace that gives every repeated workflow a canonical home and a reviewable path between homes. That is what makes a multi-model setup feel like one ecosystem with specialized surfaces rather than one oversized chatbox or several disconnected copies of the same capability.