Build your own AI platform

You can use MIOSA to build your own product in the same category as Genspark, Emergent, Blackbox AI, Lovable, Replit Agent, Polsia, Cofounder, or Nebula.

Your product owns the brand, customer experience, prompts, model routing, billing, and workflow. MIOSA supplies the execution layer: sandboxes, computers, files, commands, previews, artifacts, snapshots, connectors, events, data services, and immutable deployments.

Reference products and repos

These are useful external patterns to study when deciding what to build on top of MIOSA:

Do not copy their UI literally. Copy the system lesson: a product in this category needs a persistent execution workspace, a visible work stream, a permission model, and a way to ship results.

What these products have in common

The common requirement is not “chat.” It is durable action in a controlled workspace.

What requires a device

Not every agent needs a sandbox or computer. Use the smallest runtime that can complete the task safely.

The product should choose the runtime automatically, but users should see which device is doing the work.

Reference architecture

The orchestrator is your product layer. It decides which agent runs, what model or harness powers it, which device it can use, which credentials are available, when to ask for approval, and how progress appears to the user.

MIOSA is the runtime layer. It executes the work and records the outputs.

Implementation checklist

Start with one workspace and one agent before scaling to teams or thousands of workers.

The important rule is that agent identity, runtime profile, device, credentials, and artifacts are separate records. That separation is what lets you swap OSA for Claude Code, move a task from sandbox to computer, or give one workspace a different provider key without rewriting the product.

This is the smallest working version of a Polsia-style operator, a Cofounder-style department agent, or a Nebula-style virtual device.

E2E runtime profile to artifact export

This is the concrete end-to-end lane to implement first for a Polsia, Cofounder, Nebula, Heuresis, BusinessOS, Lovable, Replit, Genspark, Emergent, or Blackbox AI-style product:

create runtime profile
  -> create or resume sandbox/computer
  -> dispatch Agent Run with profile id
  -> agent writes files in /workspace
  -> export approved artifact paths
  -> store download URL on your product run record

Use a sandbox for generated files, reports, code, previews, and app bundles. Add a computer step only when the run needs browser interaction, screenshots, or visual QA. Use Files, exec, and artifacts to promote approved paths into downloads, and Agent Runtime Profiles for the reusable profile contract.

Prompt-to-device flow

Use one product-level run model whether the user is building an app, generating a report, or asking an operator to complete a business task.

prompt
  -> resolve workspace and agent
  -> select runtime profile
  -> select sandbox, computer, or BYOC/OpenComputer target
  -> inject scoped env and secrets
  -> stream events while the device works
  -> save files, screenshots, artifacts, preview URLs, and deploy outputs

For Lovable, Replit, Genspark, Emergent, or Blackbox AI-style app builders, the default target should be a persistent sandbox. The agent writes files into /workspace, runs install and build commands there, starts a preview server, fixes errors in place, exports deliverables, and publishes only after the user or browser QA approves the result.

For Polsia or cofounder.co-style company operators, the same flow starts from a business task instead of an app prompt. The orchestrator may use a sandbox for documents and code, a computer for browser work, and BYOC/OpenComputer when the task must run on customer-owned infrastructure.

Runtime profiles and env inheritance

Runtime profiles keep the agent harness separate from the device. A profile answers: which runtime starts, which tools are allowed, which non-secret env defaults are present, and which connectors or secret groups can be requested.

Recommended resolution order:

Environment and secrets should be inherited narrowly:

If a value can spend money, access customer data, publish externally, or call a provider API, treat it as a secret or connector grant instead of plain profile env.

Artifacts and downloads

Every agent run should end with named outputs, not just terminal text. Use exports for files users should download and store the returned descriptor on your product’s run, task, or project record.

See Files, exec, and artifacts for the export API shape.

Backend module shape

Keep these modules separate in your product backend. Combining them too early is what makes agent products hard to debug.

type AgentRuntime =
  | "osa"
  | "codex"
  | "claude-code"
  | "pi"
  | "hermes"
  | "gemini-cli"
  | "opencode"
  | "custom";

type AgentDevice =
  | { type: "sandbox"; id: string; cwd: "/workspace" | string }
  | { type: "computer"; id: string }
  | { type: "local"; id: string };

type AgentRunRequest = {
  workspaceId: string;
  agentId: string;
  runtime: AgentRuntime;
  device: AgentDevice;
  prompt: string;
  connectors: string[];
  approvalPolicy: "auto" | "confirm-risky" | "manual";
};

The frontend should never special-case every runtime. It should render the same event contract regardless of whether the backend used OSA, Codex, Claude Code, Pi, Hermes, or a customer-owned harness.

Product mapping

Build your own Polsia-style operator

Use this when the product promise is: “Describe the business. Agents keep building, researching, selling, and improving it.”

Use this MIOSA shape:

Example task flow:

User: Build a landing page and start outbound research.
Orchestrator:
  1. Resume the company workspace sandbox.
  2. Agent writes Next.js files in /workspace.
  3. Agent starts preview on port 3000.
  4. Computer agent opens the preview and captures screenshots.
  5. Research agent writes lead notes and campaign copy.
  6. User approves publish.
  7. Deploy agent publishes the app and stores the URL.

Build your own Cofounder / Co-Founder AI-style company OS

Use this when the product promise is: “Run company departments with specialized agents and human approval.”

Start with this agent roster:

Human approval belongs at the orchestrator layer for:

• publish production app
• send external messages
• buy domains or spend credits
• create high-cost child devices
• delete data, snapshots, deployments, or customer files
• use admin-level credentials

Build your own Nebula-style virtual device

Use this when the product promise is: “Agents and humans share a persistent workspace with files, code, browser, jobs, and connected apps.”

Use this MIOSA device model:

The key design decision is the primary device policy. Each workspace should know which sandbox, computer, or local device agents reach for by default.

Build Heuresis-style encoded workspaces

Use this when the product promise is: “Turn a company’s operating knowledge into a folder that any agent runtime can execute.”

Use this workspace folder contract:

/workspace
  SYSTEM.md
  company.yaml
  agents/
    founder.md
    engineering.md
    marketing.md
    sales.md
    support.md
  skills/
    write-proposal/
      SKILL.md
      references/
    qualify-lead/
      SKILL.md
    build-landing-page/
      SKILL.md
  runbooks/
  artifacts/
  receipts/

MIOSA is where this workspace can actually run. The encoded company lives in a persistent sandbox. The selected runtime, such as OSA, Codex, Claude Code, Gemini CLI, OpenCode, Cursor, Aider, Windsurf, OpenClaw, Qwen Code, Kimi Code, or a custom harness, reads the workspace and executes inside /workspace.

This gives customers a portable company operating system while MIOSA still owns the secure execution, persistence, events, quotas, connectors, and deployment path.

Implementation path

1. Choose the runtime shape

Do not hard-code one agent runtime into the platform. Make runtime a setting on the agent or workspace.

The runtime should receive the same workspace contract: scoped MIOSA token, assigned device, allowed connectors, and /workspace files.

2. Dispatch prompts into the device

The product must be able to send a prompt into the assigned runtime and keep the agent working there. This is the core workflow.

prompt
  -> route to agent runtime
  -> run inside assigned sandbox/computer/local device
  -> stream events back to product UI
  -> persist files, artifacts, screenshots, previews, and deployment records

Use a sandbox prompt when the agent should code, generate artifacts, or run commands inside /workspace:

miosa sandbox prompt <sandbox-id> 
  --provider claude 
  --cwd /workspace 
  --json 
  -- "Build the landing page, run tests, start the preview, and leave the files in /workspace"

Use a computer agent prompt when the task needs a desktop or browser:

miosa agent start <computer-id> 
  "Open the preview, test signup, capture screenshots, and report visual issues"

Send follow-up work into the same running computer-agent session:

miosa agent task <computer-id> <session-id> 
  "Re-check the mobile nav after the sandbox agent patches it"

In a product backend, model this as one dispatch contract:

type DevicePromptDispatch = {
  deviceType: "sandbox" | "computer" | "local";
  deviceId: string;
  runtime: "osa" | "codex" | "claude-code" | "gemini-cli" | "opencode" | "custom";
  prompt: string;
  cwd?: string;
  connectors?: string[];
  approvalPolicy?: "auto" | "confirm-risky" | "manual";
};

The UI should not care whether the prompt ran through OSA, Codex, Claude Code, Hermes, OpenCode, or a custom harness. It should display the same run stream: tool calls, command output, file writes, screenshots, artifacts, approvals, and final URLs.

3. Create or resume the workspace runtime

Use a persistent sandbox for code and files. Use a computer only when the task requires a real browser, desktop, or screenshot loop.

miosa sandbox create 
  --template nextjs 
  --name customer-workspace 
  --timeout 1h 
  --wait 
  --json

Then run work inside the sandbox:

miosa sandbox exec <sandbox-id> -- sh -lc "cd /workspace && npm install"
miosa sandbox exec <sandbox-id> -- sh -lc "cd /workspace && npm run build"

4. Make the agent write inside the device

The agent should edit files in /workspace, not build everything locally and upload a finished repo at the end.

bad:
  local agent builds repo on laptop
  upload after the fact
  remote sandbox only previews the result

good:
  agent writes files into sandbox
  sandbox installs dependencies
  sandbox runs tests/builds
  sandbox serves preview
  user sees events and artifacts as work happens

5. Stream progress into the product UI

Show users the work surface:

• plan created
• device created or resumed
• file written
• command started
• stdout/stderr chunk
• preview ready
• screenshot captured
• artifact generated
• approval required
• deployment ready

This is the difference between “the agent disappeared” and “the agent is working in a real machine.”

6. Attach connectors and secrets safely

Use managed connectors, scoped tokens, and runtime variables. Do not paste provider keys into chat.

Tenant key
  -> stays server-side
  -> mints scoped runtime token
  -> sandbox receives only the scoped token
  -> managed provider token is brokered only to the allowed provider endpoint

This is how a platform can provide a managed design-research connector while still preventing arbitrary token exfiltration.

7. Save checkpoints and publish

Use snapshots and versioned deployments:

checkpoint after dependencies install
checkpoint after first working preview
checkpoint before risky refactor
publish after tests and browser QA
rollback through deployment versions

For many small customer apps in one workspace, publish to App Engine. For normal production apps, publish through MIOSA Deploy.

What your frontend should show

This is how to make MIOSA feel like an agent workspace, not just an API.

Architecture rules

1. Do not merge sandboxes and computers into one vague concept. Sandboxes are for headless code, files, previews, and artifacts. Computers are for GUI and browser automation.
2. Make persistence the default for agent work. Idle compute can stop, but the workspace state should survive through snapshots or persistent storage.
3. Use scoped runtime credentials. Tenant admin keys stay server-side.
4. Treat the orchestrator as your product. MIOSA executes; your product decides roles, prompts, permissions, retries, approvals, and UI.
5. Expose run events. Users need to see code, commands, files, previews, artifacts, screenshots, and deploys as they happen.
6. Dispatch prompts into assigned devices. A user prompt should become a sandbox/computer/local-device run, not a detached local-only script.
7. Separate development from hosting. Agents build in sandboxes and computers. Finished apps run on deployments or App Engine.
8. Keep runtimes replaceable. A workspace should be executable by OSA, Codex, Claude Code, OpenCode, Aider, OpenClaw, or a custom runtime without rewriting the customer’s company knowledge.

See also