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
Build Lovable, Bolt, v0, or Replit-style products where an agent creates a web app inside a sandbox, opens a live preview, fixes errors, and publishes.
Let end-users generate intake forms, landing pages, dashboards, automations, and workflow apps inside your branded platform.
Generate proposals, PDFs, DOCX files, slides, HTML reports, CSV exports, charts, SVGs, ZIPs, and downloadable client deliverables.
Use computers for browser sessions, login flows, screenshots, form testing, visual QA, and human handoff.
Run Python or Node jobs that clean data, call APIs, generate charts, produce reports, and store results.
Host agent loops that use MIOSA sandboxes, computers, MCP tools, secrets, files, previews, and deployments.
Build Nebula-style virtual-device products where agents share persistent devices, files, browsers, jobs, and app connections.
Build agents that research, browse, code, generate artifacts, use connected apps, and execute multi-step work for customers.
Attribute usage to your workspaces, users, and projects while keeping MIOSA behind your own product.
Promote generated work from a sandbox into versioned deployments, rollbackable releases, custom domains, or Docker Deploy.
Product primitives
| Primitive | Use it for | Not for |
|---|---|---|
| Sandbox | Code, files, commands, package installs, builds, tests, generated artifacts, preview servers | GUI/browser interaction |
| Computer | Browser automation, screenshots, mouse/keyboard, desktop apps, visual QA, user handoff | Headless code builds that do not need a desktop |
| Deployment | Stable public app/site/API URLs, versions, releases, rollback | Active development iteration |
| Docker Deploy | Many small customer apps running as containers inside one workspace appliance VM | Generic sandbox development |
| Artifacts | Files created by agents: PDFs, docs, images, reports, exports, screenshots | Hidden temporary state |
| Events | Real-time UI updates: tool calls, stdout, file writes, preview readiness, deployment status | Long-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 shape | MIOSA primitives |
|---|---|
| Always-on virtual device | Persistent sandbox or computer, primary device policy, snapshots, jobs |
| Agent team | Orchestrator, child sandboxes, child computers, shared artifacts, event stream |
| Mini-app builder | Next.js sandbox, preview URL, artifact panel, publish flow |
| Cofounder/operator agent | Browser computer, connected apps, schedules, approvals, memory |
| Design/research agent | Web research, Refero managed connector, files, browser screenshots |
| 24/7 monitoring job | Scheduled 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
| Template | Intended job |
|---|---|
miosa-sandbox | General Python and Node command execution |
nextjs | Generated web apps, landing pages, dashboards, previews |
python-data | Reports, charts, files, analysis, automation |
browser-agent | Browser testing and Playwright-style automation |
artifact-lab | PDF, DOCX, image, diagram, and HTML artifact generation |
agent-node | Node agent runtimes, AI SDK harnesses, MCP clients |
agent-python | Python agent runtimes, data tools, backend orchestration |
postgres-15 | Managed 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.”