Microsoft Edge

Ideas & development

emOS Studio

Building a workspace
for product exploration

Meng Li · Edge Mobile · September 2026

Begin with emOS and the original plan, then introduce Studio and its core concepts. Demonstrate the Real Clock experiment before explaining how Studio was built. Its product point of view frames the ideal workflow, the remaining gaps, and the closing learning: “AI is not a tool, AI is a workflow.”

Allow 25 minutes for the presentation, including a five-minute walkthrough, then five minutes for discussion. The product point of view is on slide 11. The ideal complete workflow on slide 12 then connects exploration with the production ecosystem.

Sources: presenter’s revised narrative direction; emOS-deck/index.html; emos-studio/README.md.

Cover image: Majestic Dyson Sphere, Wallpaper Abyss / Alpha Coders. Source lists robokoboto as discoverer and does not identify the artist. Downloaded for this draft on September 10, 2026. The Dyson sphere is a conceptual illustration.

Microsoft Edge

emOS recap

Edge Mobile,
modeled on the web

emOS is an interactive web model of Edge Mobile, with connected pages and interactions.

PMs and designers can try an idea in product context before native implementation begins.

The ambition: approach the native experience while keeping the speed of web iteration.

Static emOS Theme Hub reference for the PDF and offline view — Live emOS · Tap, scroll, exploreemOS · Static reference

Assume some people have not seen the previous talk. Define emOS plainly: an interactive model of Edge Mobile implemented on the web stack. Existing pages, navigation, and behaviors provide a connected product context for new experiments.

Briefly explore the embedded product model. Show how its pages connect, then return to the main point: this is a place to try product ideas before native implementation. Use the reference still if the connection is unavailable.

The original problem was the cost of trying a native-product idea before committing to native engineering. emOS puts an executable experience in front of PMs and designers earlier. They can tap, navigate, and discover what feels wrong while the design is still easy to change.

The long-term ambition is to get arbitrarily close to the appearance and interaction of the native product while keeping web iteration fast. This is an ambition, not a claim of measured native parity today. Performance and platform-specific behavior still need validation in the actual product.

Sources: emOS-deck/index.html, “The Solar Filter,” “The Decision,” and “Fidelity”; live embed: https://emos.tasteful.work?shell=hide, verified reachable September 10, 2026. PDF still: emOS-deck/assets/images/emos-theme.png. Fidelity ambition follows the presenter’s explanation.

Microsoft Edge

The original plan

The original emOS plan

The plan had three parts: fidelity, accessibility, and evaluation.

Fidelity

Keep emOS aligned with the native product so ideas start from a realistic baseline.

The model people build upon

Accessibility

Help PMs and designers explore with agents, design context, and guided workflows.

emOS Studio supports this workflow

Evaluation

Develop ways to assess concepts through scenarios, flows, and interaction comparison.

Evidence to support product judgment

Studio turns the model into a workspace for product exploration.

Recap the original roadmap rather than introducing the production ecosystem yet. Its pillars were Fidelity, Accessibility, and Evaluation. Fidelity concerned keeping the model close to the actual experience. Accessibility meant enabling PMs and designers to work with it through design context, scaffolding, and agents. Evaluation concerned rigorous assessment of the resulting concepts.

The previous deck linked the Accessibility pillar to Studio. Studio is the concrete working environment for that ambition. It also makes comparison possible and can eventually carry evaluation evidence, but this slide describes the original direction, not a claim that all three pillars are complete.

The next slide moves from that plan to what Studio is today.

Source: emOS-deck/index.html, “What’s next for emOS,” pillars Fidelity, Accessibility, Evaluation. The Accessibility pillar links to the local Studio application.

Microsoft Edge

emOS Studio

A workspace for
product exploration

A focused workspace for native product exploration,
powered by the agent and tools on your computer.

DescribeTry & compareSave & continue

emOS

The product model

emOS Studio

The workspace for exploring ideas

Introduce Studio as a focused workspace for native product exploration, powered by the system agent and tools on the user’s computer. The current implementation connects installed coding-agent CLIs to an interactive product preview. emOS is its bundled reference project. Studio organizes describing a change, trying it in context, comparing it with a baseline, and saving the work for another session. The agent performs the work while Studio provides the workflow and preview.

Keep the distinction between model and environment clear. emOS supplies the product experience. Studio manages the work around that experience. Move directly to the Console and Playground map to make this concrete.

Sources: emos-studio/README.md, opening description and “Current workflow”; HANDOVER.md, separation of Studio and the emOS project.

Microsoft Edge

Console & Playground

The Studio workspace

Direct the agent in the Console. Experience the result in the Playground.

ConsoleGuide and manage the project

PlaygroundTry the product and compare

Console

Current projectNew / Save / Activity

Conversation & design context

Describe the change

Describe the change and attach Figma context.

Agent activity and approvals stay here.

Describe a change…

Playground

View controls

Baseline

emOSPinned starting
experience

Current project

Your experimentProposed
experience

High-level schematic · Activity spans all projects · The Playground shows one source or a side-by-side comparison

Use this as a map before entering the live app. The product goal is to keep the user’s intent, progress, and results in one place, even when the agent works across many underlying tools. Console is the presenter’s label for the left-hand project controls. The current app deliberately omits an extra Console heading. The repository names the overall environment Workspace and the right-hand surface Playground.

At the top of the Console, select the project and access New, Save, and Activity. Activity is a global run monitor, not one of the four project tabs. Chat contains the conversation, Figma context, and approvals. Review exposes changes and saved revisions. Submit handles sharing a selected revision and bringing feedback back into Chat. Settings covers the project’s agent, baseline, Figma, and Playground configuration.

In the Playground, choose the current project, the pinned baseline, or Side by side. Both previews remain interactive. Device and display controls belong to the Playground view. The diagram’s tab buttons and source menu can be clicked to explain these areas. It is a schematic. Keeping results such as future demo videos in the same workspace is part of the POV, rather than an existing Playground feature.

Sources: emos-studio/docs/product-terminology.md; src/App.tsx; src/workflow/WorkspaceControls.tsx, StudioTabs.tsx, PreviewStage.tsx, PreviewToolbar.tsx; README.md. “Console” follows the presenter’s requested terminology.

Microsoft Edge

Studio in use

The baseline and experiment, together

Actual emOS Studio Real Clock project: conversation on the left, pinned baseline at 12:15 in the center, current clock in the experiment on the right — Actual Studio session · Real Clock project · September 10, 2026

Console

The question and
the conversation

Baseline

A stable point
of comparison

Current project

The change
you can try

This is an actual screenshot of the running Studio application, captured from the existing Real Clock project on September 10, 2026. The presentation clips only browser chrome from the screenshot. The Studio UI itself is unmodified.

Read the screen from left to right. The Console preserves the request and follow-up. The baseline shows the pinned source experience with the static 12:15 clock. The project shows the changed experience with the current clock. Preview labels distinguish the source of each pane.

The screenshot’s Up to date label reports the most recent GitHub freshness check of the emOS baseline branch. It is not proof that emOS matches the latest native Edge product. The next slide explains that separate maintenance responsibility.

Source: live local Studio UI, http://127.0.0.1:4319/?work=224997b9-5be3-4072-82d8-c6b6ea7cb114. Captured through the browser. Product behavior: docs/baseline-settings.md and src/workflow/PreviewStage.tsx.

Microsoft Edge

Baseline & exploration

One source of truth,
many explorations

Improve the baseline

Keep the model
close to production

Reflect the latest native experience.
Review fixes and reusable improvements.
Maintain a trusted starting point.

A durable source of truth for emOS

Explore an idea

Let many temporary
ideas diverge

Pin a known baseline revision.
Give each project its own branch and worktree.
Keep or share the ideas worth revisiting.

Independent work, with no automatic baseline merge

The tension

The baseline must evolve. Existing experiments need a stable reference.

Studio makes baseline updates explicit. Experiments stay separate from reviewed baseline contributions.

This distinction is an example of vertical optimization: Studio encodes the needs of native product exploration. Begin with baseline maintenance. The shared emOS model should track the latest production experience, including changes to native behavior and reusable product capabilities. This is an ongoing product and maintainer responsibility. GitHub freshness checks alone do not establish production fidelity.

Then explain temporary exploration. Many ideas can start from that trusted model and diverge independently. Each project records an exact baseline revision and has its own Git branch and worktree. A successful exploration does not imply that its source should merge into the baseline.

The tension is between a source of truth that must keep evolving and experiments that must remain reproducible. In the current implementation, advancing the locally available baseline does not move existing project branches or pinned comparisons. Updating an existing project is explicit and saves a new revision. The original source baseline and earlier revision identities remain recorded.

Baseline contributions use draft PRs into the configured emOS baseline branch. Experiments use feedback Issues. Backlog, fork, archive, and preview-resource management remain areas of follow-on work for handling many temporary explorations.

Sources: emOS-deck/index.html, Fidelity roadmap; emos-studio/docs/baseline-settings.md; docs/vnext-plan-of-record.md, sections 8–9; docs/workflow-delivery-plan.md; daemon/lib/workspaces.mjs.

Microsoft Edge

Engineering foundations

The tools beneath
the Studio workflow

Studio concept	Underlying tool	Studio’s role
Agent conversation	Coding-agent CLIs	Connect context, runs, and approvals
Independent project	Git branch + worktree	Isolate each idea and pin its baseline
Saved revision	Git commit + durable reference	Record an exact checkpoint
Design context	Figma API + local snapshot	Attach the design inputs to the work
Submit & feedback	GitHub branch + Issue or draft PR	Review and coordinate sharing

Studio owns the tooling shell

The UI directs and presents the work. SQLite preserves local workflow state.

Show how the current implementation composes existing tools. These are the engineering foundations for the product POV that follows the case study and development history. The installed coding-agent CLIs do the agent work. Git owns source history and worktree isolation. Figma supplies design context. GitHub owns deliberately shared revisions and collaboration records.

Saved revisions really are based on Git commits. Verified in daemon/lib/workspaces.mjs: save checks for dirty files, runs git add --all and git commit -m when needed, then records the current HEAD SHA. If the agent has already committed, Studio can save that existing HEAD instead of making a redundant commit. It creates a content-addressed refs/studio/revisions reference so the checkpoint stays reachable, and stores revision metadata and design-input references locally.

Studio owns the tooling shell: Console and Playground, selecting and recovering project state, coordinating previews and runs, and exposing deliberate actions. SQLite is the durable store for one local installation. Its database is never synchronized as a shared application database.

Studio’s responsibilities are coordination, state recovery, and clear controls around agent actions. The product POV builds on this division of responsibility.

Verified sources: emos-studio/daemon/lib/workspaces.mjs, save(), lines 120–140; daemon/lib/local-store.mjs; docs/adr/0001-local-and-shared-state.md; docs/figma-context.md; docs/sharing-workflow.md; README.md.

Microsoft Edge

Case study & demo

The Real Clock experiment

“Change clock on the top left to a real clock”

Initial request

Replace the static time with a live clock.

Reported issue

The clock appeared static after reopening.

Agent follow-up

Investigate startup and resume behavior.

Open the Real Clock project

Actual Real Clock conversation: agent describes a startup dependency and a change to refresh the clock independently when the browser resumes — Actual project and follow-up conversation

Use the existing Real Clock project to demonstrate a complete iteration loop. Its actual opening request is “Change clock on the top left to a real clock.” The later user turn reports that the clock appeared static on reopening. The saved conversation records the investigation and follow-up.

Five-minute demo: 0:00–1:00, open the project and show the original prompt. 1:00–2:00, show the pinned baseline’s static 12:15 beside the project’s clock. 2:00–3:30, inspect the reopening report and the follow-up conversation. 3:30–5:00, inspect Review and the saved revisions, and discuss what evidence would establish correct startup and resume behavior.

The agent reports a dependency on the main app finishing startup and describes making the clock start independently and refresh on browser resume. The same reply explicitly says it could not verify this caused the exact freeze. Preserve that uncertainty. During capture, the current clock advanced from 9:49 through later minutes while the pinned baseline remained 12:15, which demonstrates current updating behavior but does not prove the entire restart lifecycle.

The button opens the actual local project and requires Studio to be running on this computer. The screenshot preserves the actual conversation as a fallback. The recorded conversation and saved source provide the evidence for this case study.

Transition: we can now express and refine a working product behavior. Next, explain how Studio was built and the product POV behind it. That POV will frame the ideal workflow and the integrations still needed.

Source: observed local Studio Real Clock project, work ID 224997b9-5be3-4072-82d8-c6b6ea7cb114, September 10, 2026. Screenshots captured from the real application.

Microsoft Edge

Development

How emOS Studio was built

The first editing loop grew into a persistent workspace around existing tools.

June

The first working loop

Chat drives an agent.
Changes appear in the preview.

Studio becomes its own repository.
emOS becomes its reference project.

Early September

Work that survives a session

Independent projects.
Saved revisions and recovery.

Explicit approvals and sharing.
Separate experiment and contribution workflows.

September 7–9

A clearer everyday workflow

Concurrent runs and comparison.
Figma context and focused tabs.

Chat, Review, Submit, Settings.
More room for the Playground.

The shell grew around the work: context, comparison, revisions, and recovery.

Return to the development story after the audience has seen the workflow. This chronology is grounded in the local repository. June 14 established Studio as its own repository with emOS as a submodule. June 15 added launch, agent selection, and preview work. The September commits introduced architecture guardrails, tool approvals, durable local workflows, reviewed GitHub sharing, concurrent runs, baseline controls, and interface refinement.

The September work also introduced Figma snapshots and the local Product Definition contract. The product grew from a single editing loop into a workspace where independent projects and their revisions could persist.

The first visible success was the editing loop. Continued use required explicit work identity and durable state. Interface refinement then organized those capabilities around the user’s current task. Use this history to establish the current foundation. The next slide abstracts Studio’s product point of view from these choices.

Sources: emos-studio/HANDOVER.md; local Git history through 01df933 (2026-09-09), including 02616b8, 0e4fbd6, 7c66b37, 3021aad, dc48854, a93ee0e; docs/figma-context.md.

Microsoft Edge

Product point of view

Studio’s product point of view

A lightweight shell around a system agent

Studio owns the workflow and presentation. The agent uses existing tools and skills to do the work.

Deep focus on one scenario

Optimize for native product exploration on emOS, with its product context and review loop.

One place to work

Keep intent, progress, results, and refinement in the Console and Playground.

Design assumption

Abundant tokens. An always-available agent.

New capabilities can come through agent tools and skills while Studio stays focused on the workflow.

Present these as Studio’s product point of view. They explain both the current architecture and the intended direction. A lightweight shell manages workflow, context, state, and presentation around a general system agent. The current adapters connect installed coding-agent CLIs. A system agent works with the user’s local environment, tools, and skills.

Delegating capabilities includes tasks such as creating assets, testing an interaction, or producing a demo video. Studio can collect intent, start and observe the work, show the result, and support refinement while the agent uses suitable existing tools. The design does not require a bespoke execution engine for every new capability.

Evaluation should follow the same modular approach as Git and GitHub: connect to a dedicated system, request an assessment of a known revision, and present its evidence in Studio. No evaluation system has yet been selected and validated for this role. FSQ is a possible candidate, not an established solution for evaluating Studio experiments.

Vertical focus means native product exploration on emOS. The baseline, independent experiments, design context, and comparison encode knowledge of that scenario. Studio specializes the workflow around a broadly capable agent.

One place to work means preserving continuity for the user. Users should be able to direct the work, inspect progress, experience results, and continue without manually coordinating many windows. This is a product goal; current external links and the future production integration are not claimed to have disappeared.

The explicit design assumption is abundant enough tokens and an agent available whenever the workflow needs it. Treat this as a forward-looking premise, not a measured statement about current cost or reliability. Under that premise, human attention and confidence in the result become central design concerns.

Product POV and token/availability premise supplied by the presenter. Current implementation examples: emos-studio/README.md; docs/product-terminology.md; docs/adr/0001-local-and-shared-state.md; agent adapter and workflow modules.

Microsoft Edge

The ideal workflow

The ideal complete workflow

Studio’s workflow would connect exploration with implementation and verification.

Product explorationProduction delivery

Product exploration01
Explore
emOS + Studio
Try ideas in context.
Compare and refine.
Figma, worktrees, GitHub
02
Define
Evaluation and agreed intent
Assess the result.
Agree acceptance criteria.
Dedicated eval system TBD
Production delivery03
Implement
Dragon (Edge-agents)
Build the chosen behavior
in Edge codebases.
ADO, Chromium, Edge skills
04
Verify
FSQ
Check native Edge against
the approved behavior.
Production test automation

Production changes feed back into the emOS baseline for the next experiment.

Target workflow · Experiment evaluation is unvalidated. The production handoff and baseline feedback loop remain open.

Apply the product POV to the ideal complete workflow before discussing the gaps. Studio focuses on the exploration scenario and should preserve the user’s context as specialist agents and tools perform the work. Start with the product question and relevant Figma context. Studio supports exploration on emOS, comparison, and saving the chosen result. The team agrees what the experience should do and records the exact revision, decisions, and acceptance criteria.

Dragon then consumes that intent to support implementation in the actual Edge codebases, using ADO, Chromium, and Edge-specific knowledge and skills. FSQ verifies the production result. Production changes should feed back into the emOS model so the next experiment starts from a current, trustworthy baseline.

Evaluation during product exploration is a separate unresolved step. The intended approach is to delegate it to a dedicated evaluation system. No provider or method has been validated for Studio yet. FSQ’s stated role in production test automation makes it a candidate to investigate, but does not establish its suitability for evaluating emOS experiments.

An Executable Product Definition is one proposed format for the handoff. Studio already supports a local immutable draft, but export does not imply approval, publication, Dragon integration, or executed FSQ verification. The native implementation translates the intended behavior into the production stack.

Studio should present the relevant state and results as the work moves through these tools. This is the target workflow, not a claim that the stages and return loop already connect automatically. The following slide identifies what is missing today, including capabilities that improve exploration and communication within this larger workflow.

Sources: presenter’s desired workflow; emos-studio/docs/vnext-plan-of-record.md, sections 1, 5, and 12; docs/product-definition-contract.md; docs/adr/0002-product-definition-boundary.md. Production tooling roles follow the presenter’s framing.

Microsoft Edge

Current gaps

Workflows still to connect

Studio should connect agents and dedicated systems to a clear workflow.

Workflow	Proposed external execution	Studio workflow to build
EvaluationNo validated system yet	Dedicated system TBD. FSQ is an unvalidated candidate.	Choose the revision and criteria. Present evaluation evidence.
Keep the baseline current	Inspect production drift and propose updates.	Schedule checks and review proposed baseline updates.
Precise UI refinement	Apply a focused change to a selected element.	Select the target and present the change for review.
Production handoff	Implement with Dragon. Verify with FSQ.	Package approved intent and track delivery.
Demo productionValue-add workflow	Record and edit a journey with media tools.	Choose a revision and review the resulting video.

Studio provides the controls and review surfaces around the agent’s work.

Use the POV to explain these gaps as workflows and interfaces to build. The middle column describes work that could be delegated to agents or specialist systems. The right column describes Studio’s missing role in making that work concrete and reviewable. These are proposed directions, not delivered integrations or feature dates.

Evaluation is a weak point today. The product preference is to offload assessment to a dedicated evaluation system, just as Studio uses Git and GitHub for source history and collaboration. Studio would select a revision and scenario, request an assessment, and show the evidence. The presenter has not found and validated a system for this role yet. FSQ is one candidate to investigate. Its production automation capabilities do not by themselves validate it for evaluating emOS product experiments.

Baseline maintenance: Studio currently supports explicit GitHub freshness checks and reviewed local updates. It does not detect changes in the actual native Edge experience automatically. The proposed workflow asks an agent to inspect production drift and prepare fidelity updates, then gives the user evidence and review controls. Existing experiments retain their pinned references until deliberately updated.

Fine-grained UI control: the user selects a product element and expresses a precise adjustment. The agent performs focused edits with the necessary context, and Studio presents the result. Current device, font, background, and zoom controls change the preview presentation; they do not provide this product-element editing workflow.

Production handoff: local Product Definition drafts exist, but approved intent still needs to connect to Dragon implementation and FSQ verification. Studio owns the handoff’s identity, state, and presentation while those specialist tools own production execution.

Demo production is the clearest example of the POV. The user chooses a journey, a saved revision, and presentation preferences. Studio asks the agent to run the experience and use suitable recording or editing tools. Studio then presents the video and accepts revision requests. This does not require Studio to implement a complete video-generation engine. The orchestration, result presentation, and review workflow remain to be built.

Evaluation preference, unvalidated status, and FSQ candidacy are supplied by the presenter. Other proposed workflows follow the presenter’s product POV. Current foundations: emos-studio/docs/baseline-settings.md; docs/workflow-delivery-plan.md; docs/product-definition-contract.md; README.md.

Microsoft Edge

Top learnings

What building Studio taught us

Power can stay behind
the interface

Like the circuitry inside a device, powerful agent capabilities can sit behind a simple user experience.

Building the tool
clarifies the work

It forces a deeper understanding of the workflow, its abstractions, and its information architecture.

A specific workflow
is easier to build

A concrete scenario makes the goals and gaps easier to identify.

How to generalize beyond it remains uncertain.

AI is not a tool, AI is a workflow

Frame these as lessons from building Studio. The first is that AI has become powerful enough for much of its machinery to sit behind the product interface. An electronic device gives people useful capabilities without requiring them to operate its circuit board. In the same way, Studio can make the agent’s capabilities available through a focused workflow rather than exposing every underlying mechanism.

The second learning comes from building a workflow application. Implementation forces a deeper understanding of the work itself: which stages exist, which concepts deserve their own identity, how those concepts relate, and where information belongs. In Studio, baseline maintenance and exploration needed different lifecycles. Chat, Review, Submit, and Settings then gave that model an information architecture.

The third learning is the advantage of specificity. For native product exploration on emOS, the scenario, goals, and gaps are concrete enough to identify and design around. A general workflow product has more uncertainty: which abstractions travel across scenarios, which details should stay specialized, and how much flexibility belongs in the UI. Studio’s success in one scenario does not yet answer how to generalize it.

Keep the phrase “AI is not a tool, AI is a workflow” as the closing connection between these observations. Invite the audience to challenge them with real examples, and to discuss the still-open evaluation question.

These three learnings, the circuit-board analogy, and the uncertainty about generalization are supplied by the presenter. Studio examples draw on the previously inspected workflow, lifecycle decisions, and UI.

Microsoft Edge

Discussion

Where do you agree
or disagree?

Which Studio POVs would you keep, change, or reject?

What real scenario supports or challenges those POVs?

Which evaluation systems have you used that Studio could build on?

Reserve five minutes. Invite agreement and disagreement with the three Studio POVs: a lightweight shell around a system agent, deep focus on one scenario, and one place for the user to work. Ask which POV someone would keep, change, or reject, and why. The assumption of abundant tokens and always-available agents is also open to challenge.

Ask for a real scenario from the person’s own work. What were they trying to do? Which tools and windows did they coordinate? Where would a specialized agent workflow help, and where would it get in the way? Use one concrete example to test the POV rather than trying to cover every principle.

Evaluation is an explicit open question. Does the audience agree that Studio should delegate it to a dedicated system? What have they actually used or validated? What evidence would make an assessment trustworthy? FSQ is a possible candidate, but no system has yet been validated for Studio. Seek experience and validation criteria rather than assuming a tool choice is settled.

Discussion direction follows the presenter’s requests to debate Studio’s POV, bring real-life scenarios, and explore the unresolved evaluation-system choice.

emOS Studio

Edge Mobile,
modeled on the web

The original emOS plan

Fidelity

Accessibility

Evaluation

A workspace for
product exploration

The Studio workspace

Console

Describe the change

Playground

The baseline and experiment, together

One source of truth,
many explorations

Keep the model
close to production

Let many temporary
ideas diverge

The tools beneath
the Studio workflow

The Real Clock experiment

How emOS Studio was built

The first working loop

Work that survives a session

A clearer everyday workflow

Studio’s product point of view

A lightweight shell around a system agent

Deep focus on one scenario

One place to work

The ideal complete workflow

Explore

Define

Implement

Verify

Workflows still to connect

What building Studio taught us

Power can stay behind
the interface

Building the tool
clarifies the work

A specific workflow
is easier to build

Where do you agree
or disagree?

Speaker notes

The story

emOS Studio

Edge Mobile,modeled on the web

The original emOS plan

Fidelity

Accessibility

Evaluation

A workspace forproduct exploration

The Studio workspace

Console

Describe the change

Playground

The baseline and experiment, together

One source of truth,many explorations

Keep the modelclose to production

Let many temporaryideas diverge

The tools beneaththe Studio workflow

The Real Clock experiment

How emOS Studio was built

The first working loop

Work that survives a session

A clearer everyday workflow

Studio’s product point of view

A lightweight shell around a system agent

Deep focus on one scenario

One place to work

The ideal complete workflow

Explore

Define

Implement

Verify

Workflows still to connect

What building Studio taught us

Power can stay behind the interface

Building the tool clarifies the work

A specific workflow is easier to build

Where do you agreeor disagree?

Edge Mobile,
modeled on the web

A workspace for
product exploration

One source of truth,
many explorations

Keep the model
close to production

Let many temporary
ideas diverge

The tools beneath
the Studio workflow

Power can stay behind
the interface

Building the tool
clarifies the work

A specific workflow
is easier to build

Where do you agree
or disagree?