Build an agent-company platform

Products like Polsia, Cofounder / Co-Founder AI, Nebula, and Heuresis-style encoded workspaces package the same core idea: agents need persistent workspaces, connected apps, browser or desktop access, generated files, live progress, approvals, and deployment targets.

MIOSA is the infrastructure layer for building that category inside your own product. You bring the product opinion, prompts, model routing, UI, and customer workflow. MIOSA provides the execution substrate: sandboxes, computers, files, exec, previews, artifacts, snapshots, connectors, events, and 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.

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.”

Recommended shape:

Example 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.”

Recommended agent roster:

Human approval belongs at the orchestrator layer:

• 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.”

Recommended 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.”

Recommended 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 Docker Deploy. 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 Docker Deploy.
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