On this page

What you can build with MIOSA

MIOSA is a runtime platform for AI products. It gives your application persistent cloud workspaces where agents can write files, run commands, preview web apps, create artifacts, use browser desktops, and publish durable deployments.

The core product idea is simple:

User request
  -> agent plans work
  -> sandbox does code, files, builds, tests, artifacts
  -> computer does browser, desktop, screenshots, manual-style tasks
  -> MIOSA streams events and previews
  -> deployment ships the finished app

MIOSA is not just a remote shell. It is the execution layer underneath products that need AI agents to do real work safely.


Common product categories


Product primitives

PrimitiveUse it forNot for
SandboxCode, files, commands, package installs, builds, tests, generated artifacts, preview serversGUI/browser interaction
ComputerBrowser automation, screenshots, mouse/keyboard, desktop apps, visual QA, user handoffHeadless code builds that do not need a desktop
DeploymentStable public app/site/API URLs, versions, releases, rollbackActive development iteration
Docker DeployMany small customer apps running as containers inside one workspace appliance VMGeneric sandbox development
ArtifactsFiles created by agents: PDFs, docs, images, reports, exports, screenshotsHidden temporary state
EventsReal-time UI updates: tool calls, stdout, file writes, preview readiness, deployment statusLong-term storage

Build an agent-company product

Several modern AI products package the same high-level pattern: an agent, a persistent workspace, connected apps, a browser or cloud device, jobs, files, and generated deliverables. MIOSA exposes those primitives directly so you can build your own version inside your product.

Your product UI
  -> agent configuration
  -> device policy
  -> sandbox/computer/local device
  -> connected accounts and managed connectors
  -> streamed tool calls and events
  -> files, artifacts, previews, jobs, and deployments
Product shapeMIOSA primitives
Always-on virtual devicePersistent sandbox or computer, primary device policy, snapshots, jobs
Agent teamOrchestrator, child sandboxes, child computers, shared artifacts, event stream
Mini-app builderNext.js sandbox, preview URL, artifact panel, publish flow
Cofounder/operator agentBrowser computer, connected apps, schedules, approvals, memory
Design/research agentWeb research, Refero managed connector, files, browser screenshots
24/7 monitoring jobScheduled trigger, persistent device, app connector, notifications

The important architecture point is that the agent should work in a MIOSA device. The local CLI, MCP client, or your backend orchestrates, but files, commands, browser actions, previews, and artifacts live in the assigned runtime.

See What MIOSA agents can do, Agent devices, and Agent orchestration for the full model.


Example: generated app builder

Your frontend can show the same work stream users expect from modern AI builders: tool calls, command output, generated files, preview links, screenshots, and final deployment URLs.


Example: artifact workspace

Use a sandbox when the output is a file, not a deployed app.

User asks for a proposal
  -> agent writes Python or Node generator
  -> sandbox creates proposal.html
  -> sandbox renders proposal.pdf
  -> sandbox creates proposal.docx
  -> product shows artifacts in a side panel
  -> user downloads or asks for edits

Good artifact outputs:

  • client proposals
  • pitch decks
  • data reports
  • PDF invoices
  • SVG diagrams
  • PNG charts
  • HTML previews
  • ZIP bundles
  • code archives

Example: browser plus code workflow

Use both runtimes when the work crosses code and browser verification.

Sandbox agent:
  writes Next.js files
  starts dev server
  exposes preview

Computer agent:
  opens preview URL
  takes screenshots
  clicks through signup
  reports visual or functional issues

Sandbox agent:
  patches code
  reruns tests
  publishes

This is how you build products that feel like a coding agent, QA agent, and deployment agent are working together.


Sandbox templates should map to product jobs

TemplateIntended job
miosa-sandboxGeneral Python and Node command execution
nextjsGenerated web apps, landing pages, dashboards, previews
python-dataReports, charts, files, analysis, automation
browser-agentBrowser testing and Playwright-style automation
artifact-labPDF, DOCX, image, diagram, and HTML artifact generation
agent-nodeNode agent runtimes, AI SDK harnesses, MCP clients
agent-pythonPython agent runtimes, data tools, backend orchestration
postgres-15Managed database or database-backed generated apps

Some templates may be private or roadmap depending on your account. The product shape should remain the same: choose the template that matches the job, then let the agent work inside the sandbox.


What to show users in your product

Users should not have to understand VM internals. Show them useful work:

  • current task and plan
  • tool calls
  • command output
  • files created or edited
  • artifacts generated
  • preview URL
  • screenshots from browser checks
  • deployment URL
  • rollback/version history
  • credits and runtime usage

The message should be: “Your agent is working in a real cloud workspace. You can watch it, inspect the files, preview the result, and ship when ready.”


See also

Was this helpful?