Created applications
open directly in a new tab

Implementing usage examples: Program, Package, and Application

This section specifies management changes. Program is the collective name for callable capabilities; Tools and Workflows retain their definitions. Package is the installation unit containing these capabilities, including the three harnesses. Application is user-openable software with its own interface, version, data, and lifecycle. Package is not a new execution type; Applications no longer live in the Program source catalog.

Management entries and directories

Abilities / Programs                   Applications /applications
  Tools                                  Installed software and installation form
  Workflows                              Source, version, enable/disable, update, uninstall
  Packages                               Open → same application-instance tab
    gui_harness
    research_harness                   New tab
    wiki_agent_harness                   Enabled, visible software buttons

New packages install under openprogram/programs/packages/. Old programs/applications/ is read only for legacy-install compatibility and displayed as Packages; do not move old source into software data directories. Program sources remain in program-sources.json. Software registration uses applications/catalog.json; versions, environments, instance SQLite, run records, and data directories stay in place. Reclassifying source directories grants no execution authority to unregistered directories.

Implementation order and scope

Implement one complete classification migration: establish U1/U6 public-entry failure tests, then source and independent-catalog changes; complete U2/U7 directory/CLI compatibility and U3–U5 management/menu integration; finally verify end-to-end usage examples. Update all shared-directory consumers, sandbox protections, release packaging, product documentation, and contract tests together. After independent specification review, run quality review, the complete test list, and update the default App.

This adds no marketplace, changes no harness algorithms, does not infer software from arbitrary code, and adds neither other-language runners nor independent deployment. Package installation retains existing CLI environment constraints; application forms cannot use package APIs to modify desktop host dependencies.

Implementation status: U1–U7 implemented and accepted. Classification, independent-catalog migration, management page, menu launch, and top-level CLI passed independent specification/quality reviews and complete checks. Default-App acceptance verified three harnesses under Packages, management/menu reuse of a reader instance, preserved notes and project-file analysis results, and menu hiding/restoration. Actual migration preserved three application records, three instances, two data files, and fourteen Program sources. Duplicate historical registrations resolve by identical path; conflicting installation locations remain rejected. Public API, CLI, and real browser tests cover installation, update, disable, reinstall after uninstall, and failures. Controlled integration tests verify model success/failure, not live provider availability. Independent deployment and MCP Apps adapters remain unimplemented.

Manage Application software separately from Program capabilities

OpenProgram applications contain their own UI, business logic, data, and dependencies. The framework handles registration, opening, runtime context, and shared capabilities. Completed, verified applications appear in New tab by name/icon. One click opens them without redescribing requirements or returning to their creation conversation.

Default interfaces use standard Web technology: HTML, CSS, JavaScript, and compiled React/Vue. Applications design their own pages, editors, charts, and interactions rather than assembling only fixed OpenProgram components. Python backends handle business/model tasks. HTML is an interface technology, not a measure of completeness; backend, state, runtime contracts, and deployment dependencies determine software capabilities.

Applications run inside OpenProgram by default. The architecture permits later independent deployment with a minimal runtime, without the full desktop client, while retaining OpenProgram runtime dependencies. Removing every OpenProgram dependency requires replacement model, storage, and execution implementations; arbitrary applications cannot be promised automatic standalone export.

The concrete value is shared business operations for buttons and Agents, model calls in existing execution records, business data independent of chat windows, and upgrades preserving running-task code. This combines product contracts and does not claim these mechanisms are unique. Hermes UI extensions, MCP Apps portable interfaces, and AgentOS runtime services are direct references.[8] Hermes Desktop Plugin SDK [40] MCP Apps [29] Agno / AgentOS

What users see

New tab retains Files, New chat, Browser, and Terminal, adding enabled registered applications in the same area. Application features appear after opening; launch buttons do not show model, port, runtime, or installation paths. Management handles hiding, display-name changes, uninstall, and errors. Hiding preserves data.

This demonstrates only opening existing applications from New tab, without model calls or installation. Four built-ins provide context; the two application buttons and return button are interactive.

The same application/project reuses an open tab by default; separate projects can open independently with explicit data scopes. Without an active project in New tab, reuse the saved binding. If a required project is unbound, select one on first open. Applications must not silently change data directories to follow another chat tab’s cwd.

“One-sentence creation” still starts in chat: the Agent writes the application package and dependency declarations, builds and behaviorally verifies it, then registers within the creation task’s authorization. Only successful registration adds a menu button. Failure retains source/errors for repair rather than advertising an unusable application. Later changes produce validated candidate versions before replacement.

First opening may show dependency preparation or startup. Failure stays on the same application page with reasons and Retry. Ordinary page closing closes only the view; user-started background tasks continue, and reopening reads the same task state. Service-process exit and business-task interruption are reported separately.

Survey scope and evaluation method

This report covers the major public Agent harnesses, coding tools, embedded frameworks, application platforms, and interface protocols listed below. Categories describe their role in this question, not market-share rank. Protocols are included to answer UI integration questions, not to misclassify them as harness products.

Relevant DSH distribution, worktable, and OpenProgram code paths were checked. Other projects use current official documentation, public examples, or repository descriptions as evidence. Not every product was installed and end-to-end tested. “Unverified” means insufficient evidence, not absolute absence of support. Cursor/Windsurf internals are unknown. AutoGen and Semantic Kernel are discussed in Microsoft Agent Framework’s evolution, not presented as three separately audited current implementations.

“All market frameworks” has no closed catalog. Commercial products, community forks, and private harnesses are not exhausted. Relevant Qwen Code/Strands pages could not be obtained; Trae, Kimi CLI, and cloud software-generation services are outside the verified matrix. These gaps limit uniqueness claims, not the application runtime requirements below.

For each project ask: what is delivered, who loads/executes it, who renders UI, where business state lives, and whether it can leave the host. Evaluate code generation, code execution, UI, and application installation separately.

Public mechanism comparison

“Official repository description” means reading public descriptions, not auditing the entire repository. Compatibility without measured evidence does not count as accepted.

Mechanisms directly affecting our choices

DSH: host plugins and generated pages are separate paths

The installed worktable plugin uses host services/UI slots and a React split layout; it is not standalone software launched by double-click. Its generated windows read HTML, URLs, or files from artifact manifests. Pages using only their own resources may be hosted separately; pages depending on DSH routes, sessions, or plugin services lose those implementations outside DSH.[2] dsh-worktable

DSH dynamic Cordis plugins are another mechanism. In the inspected distribution, host parts register handlers and client parts run in the host environment and call the backend. They support real logic, not just static display, but remain constrained by supported APIs, loading lifecycle, and dynamic-code formats—not arbitrary code in arbitrary windows. Node vm is not OS-level security isolation.[1] DeepSeek Harness

Hermes and Pi: complex host-extension interaction with explicit dependencies

Hermes Desktop SDK has pane, page, sidebar, status-bar, and palette contributions. Local plugins load directly in the host environment, distinct from isolated HTML previews. Dashboard also supports pages/slots. Adopt explicit contributions/lifecycles without giving ordinary generated applications every host internal object. Pi custom UI uses terminal components, disproving the assumption that all plugin interfaces are HTML.[8] Hermes Desktop Plugin SDK [9] Hermes Dashboard extensions [3] Pi

OpenClaw: display panels and interactive applications differ

Current macOS widget-panel docs explicitly limit it to rendering. Host-integration actions belong to Control UI/session dashboard; A2UI also belongs to dashboard. Sharing the name canvas does not transfer old-documentation or other-interface capabilities onto this panel.[11] OpenClaw Widget panel

MCP Apps, AG-UI, and A2UI solve different problems

MCP Apps provides portable Web resources and host communication; AG-UI describes Agent/UI events; A2UI lets hosts render declarative data from component catalogs. Freely laid-out applications suit Web UI, common forms can use optional declarative rendering, and streaming tasks need event protocols. None automatically supplies installation, data migration, or background-service lifecycles.[40] MCP Apps [41] AG-UI [42] A2UI

Runtime frameworks: independent deployment still has framework dependencies

LangGraph persistence, AgentOS runtime APIs, and OpenHands SDK/Agent Server support Agent capabilities in custom products. Applications can deploy independently while requiring libraries/services. OpenProgram should use this distinction rather than equating leaving the desktop client with removing every OpenProgram dependency.[25] LangGraph [29] Agno / AgentOS [14] OpenHands

Current OpenProgram implementation and boundaries

Application runtime reuses Program source management, model Runtime, execution records, and tabs. This document follows Programs code structure; broader comparison is in Framework comparison. Independent review, complete acceptance, and local-App delivery status are consolidated at the end.

Applications and host plugins are managed separately. Existing plugins extend host behavior; applications use their own pages/instance APIs. Existing plugin loaders do not guarantee this design’s application isolation. Automatic plugin-to-Application adaptation remains a future extension.

Application architecture and responsibilities

Application is a Program package extending existing source registration. Plugin is an installation unit extending host behavior, such as tools/themes; automatically adapting plugin-contributed Application definitions remains an extension. Not every plugin appears in New tab, and not every Application changes host UI. Keep one application definition per package; later adapters reference it.

Ordinary applications render only in their tabs. Global toolbars, chat editors, themes, and system services are trusted host extensions using plugin permissions. Expose a small stable API, not React stores, global session managers, or internal framework modules. Appearance components are optional; standard HTML and independent frontend builds are valid.

Phase one supports static Web applications and Web applications with Python business operations. Browser-executable JavaScript, Canvas, WebGL, and WASM are available; system GUI, GPU drivers, arbitrary binaries, and arbitrary-language services are not native browser capabilities. Add explicit runtime adapters/dependency contracts for later Node/other-language backends; do not claim arbitrary-program support in the first version.

Packages retain dependency files, tests, and release boundaries. Published UI uses build artifacts, without starting dev servers, installing latest dependencies, or regenerating code per click. Applications without backend operations start no Python process; operations start runners on demand. Runner denotes an application execution role; process isolation and security sandboxing require separate implementations and labels.

Minimum application contract

The first version references a Python entrypoint and built static directory from the manifest. Fields below match current application.json; public commands/SDK are in product docs. Operation names address UI/process boundaries only. Python internals retain ordinary imports/calls without a second string-based Workflow dispatcher.

{
  "id": "local.paper-reader",
  "title": "Paper reader",
  "version": "1.0.0",
  "ui": { "root": "web/dist", "entry": "index.html" },
  "backend": { "kind": "python", "entry": "paper_reader.app:operations" },
  "scope": "project",
  "capabilities": ["model.invoke", "storage.app", "files.project.read"],
  "dataSchema": 1,
  "operations": { "summarize": { "agent": true, "input": { "type": "object" }, "output": { "type": "string" } } }
}

Static applications omit backend and may have empty capabilities. id is stable package identity, not title, absolute path, or creation-chat ID. Installation records bind owner, source, content digest, and selected version. Instances use app ID, owner, and explicit project scope. Hidden/order preferences belong to users, not release packages.

Cross-process operations have input/output schemas. Clients cannot choose arbitrary import paths, source paths, or owners; servers resolve installed records. Trusted identity comes from authenticated connections, not a JSON appId. Events have increasing sequences; clients resume by cursor after disconnect. Results and errors persist.

Business state uses per-instance SQLite databases; attachment APIs remain future work. Data lives under the current profile state directory, located by host-generated instance keys. Default profile is ~/.openprogram. Never store user data in source-version directories. Project-path changes update bindings without changing instance identity. Existing Runtime databases hold execution facts; application state references run IDs rather than duplicating Agent session databases. localStorage caches disposable view preferences only.

Python runners use pinned application dependency environments, never installing directly into the main worker. The host launches allowed entries from selected installation records, rejecting arbitrary browser launch commands. Each operation starts a runner and cleans its owned process tree on completion. Closing views does not cancel operations; reopening reads persisted state without requiring a resident app service.

Combining models and business operations

The first paper-reader sample accepts paper text and supports Generate summary and Save annotation. Saving is deterministic code; summaries enter OpenProgram Runtime and call existing llm(). PDF import requires separate application implementation. Models handle reasoning steps, not an obligatory chat before every button click.

User Generate summary and Agent summarize calls share input validation, permissions, and implementation. Applications explicitly declare Agent exposure; internal database methods never automatically become tools. Agent calls bind instances and cannot switch project data because chat selection changed.

The runner creates Runtime using the manifest’s model name or host defaults, binding application run records. Context contains operation inputs and explicitly supplied app data, independent of active chat. Explicit current-conversation import remains future work. Model configuration resolves at Runtime creation; running operations pin content versions.

Frontend receives progress/results, not provider keys. Model calls reuse Runtime recording/error handling. context.ask() emits question events; answers bind run ID/request ID and apply only to the currently pending question in that run. Application questions add no second ExecutionStatus.

Ordinary code validates model outputs before transactional data commits. Natural-language “saved” is not evidence of persistence. For non-idempotent external effects, retries must inspect existing operation records or require user handling; network timeout must not automatically repeat execution.

Opening, background execution, recovery, and upgrades

Opening path

New tab reads verified definitions → user selects app → resolve instance/project → reuse/create tab → load pinned resources → establish capability connection → read state/active runs. Registration/listing reads manifests only, without importing business code or making model requests.

Task path

Persist input, idempotency key, and accepted event, then existing Attempt manages running. Persist questions when input is needed; finish completed/failed/cancelled. Closing views never creates cancelled. Stop terminates owned process trees and returns cancelled only after cleanup; late results cannot overwrite terminal states. Concurrent business-object writes need database transactions/version checks, not merely disabled frontend buttons.

Restart path

Reopening restores view/state. After worker restart, incomplete runs follow existing owner-loss rules, becoming interrupted or completing requested cancellation. Retain inputs, saved progress, and results, and show interruption clearly. First version does not automatically resume Python operations; applications may read saved state and explicitly submit new operations.

Upgrade path

Build candidate → static/schema checks → dependency preparation → startup/behavior validation → data compatibility → atomic installation-record switch. Existing operations retain old versions; new operations use new versions. Old views/new backends must match versions; static-file updates cannot silently change loaded-page contracts.

First version rejects incompatible dataSchema/scope replacements without automatic migrations. Future migrations need backup, validation, and explicit recovery. Uninstall stops runs and hides the app, retaining source, schema, scope, snapshots, and data. Reinstallation obeys the same compatibility checks. No business-data deletion API exists.

Isolation and portability

Browser isolation enables freely authored interfaces. Ordinary applications use sandbox iframes/restricted CSP; existing unsandboxed same-origin plugin pages cannot prove isolation. Opaque origins communicate through validated MessageChannel/window handshakes. Future separate origins must still isolate host cookies, storage, and management APIs. CORS is not authentication; iframes are not safe by default.

Resources are addressed by installed-content digest and restricted to published static directories. The host delivers MessagePort only to its own iframe and validates operations against the bound instance, rejecting page-supplied owners, arbitrary URLs, or other-instance runs. Frontends cannot access all /api/* by default. Network, project-file, and device access need explicit capabilities rechecked per operation; disable/uninstall revokes connections.

Separate Python processes isolate dependencies/crashes but do not stop direct host-file reads or networking. First-version backends allow only explicitly authorized local code, never advertising manifest capabilities as a malicious-Python sandbox. Untrusted remote code requires platform file/network restrictions or container sandboxing, including child processes, package install scripts, and inherited environments. High-trust host plugins remain separately labeled.

Adopted, adapted, and deferred

Implementation breakdown and acceptance

This is approved implementation scope. Phases 1–4 passed independent reviews, complete checks, and default-App acceptance; phase 5 is unimplemented. Verify every step through public entries, not registry unit tests alone. Run existing Programs/plugin compatibility tests with affected changes.

Phases 1–4 together constitute first-version complete application support; phase 2 alone is a static application entry. Three acceptance apps are a non-model local calculator, a paper reader saving annotations/generating summaries, and batch file analysis showing progress/restart interruption. Acceptance includes reopen, restart, repeated clicks, and model failures.

Performance targets are measurable: listing New tab starts no business process; repeated opening creates no second same-scope instance; opening triggers neither code generation nor model requests; large outputs use references rather than embedding in every event. Measure latency/resources in the first complete sample. Without current benchmarks, make no unmeasured millisecond or week commitments.

Implementation status and evidence limits

Phases 1–4 are implemented: registration/pinned versions, New tab entries, independent UI/capability bridge, Python operations, instance data, execution records. Independent reviews and complete checks passed. Default-App acceptance verified calculator launch, note persistence after reopening, Python file analysis, and tabs/results restored after restart. Integration tests cover model success/failure, cancellation, duplicate submission, and interruption; offline tests do not guarantee live model availability. Independent deployment/MCP Apps adaptation remain unimplemented.

Operation status uses ExecutionStore; model records use SessionNodeWriter in application run directories. UI accesses instance-scoped APIs through MessagePort. Opaque-origin pages load relative modules with single-version resource credentials permitting UI reads only. Python content versions have separate environments depending on the host framework. context.ask() handles questions; worker loss reports interrupted without resuming Python stacks. JSON state limit is 4 MiB, events 1 MiB. Attachments, automatic schema migration, conversation-context selection, and manual menu order remain unimplemented. Product APIs: Application documentation.

DSH details use installed distribution 0.1.5-rc.1; worktable source is 0.3.3. Neither received full compatibility acceptance, and current GitHub default branches may evolve. Dynamic plugin loading and worktable artifact pages are cited separately, without using one version’s demo as evidence for another’s capabilities.

Source index

Framework facts use official docs/repositories or local public distributions. Links support nearby claims, not endorsements of entire implementations. OpenProgram file links target main; inspected local revisions are in separate delivery records.

1. DeepSeek Harnesshttps://github.com/deepseek-ai/deepseek-harness
2. dsh-worktablehttps://github.com/Aisland-SJL/dsh-worktable
3. Pihttps://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/extensions.md
4. OpenCodehttps://opencode.ai/docs/plugins/
5. Codex App Serverhttps://learn.chatgpt.com/docs/app-server
6. Claude Codehttps://code.claude.com/docs/en/plugins-reference
7. Hermeshttps://hermes-agent.nousresearch.com/docs/developer-guide/plugins/
8. Hermes Desktop Plugin SDKhttps://hermes-agent.nousresearch.com/docs/developer-guide/desktop-plugin-sdk
9. Hermes Dashboard extensionshttps://hermes-agent.nousresearch.com/docs/user-guide/features/extending-the-dashboard
10. OpenClawhttps://docs.openclaw.ai/tools/plugin
11. OpenClaw Widget panelhttps://docs.openclaw.ai/platforms/mac/canvas
12. Gemini CLIhttps://geminicli.com/docs/extensions/
13. goosehttps://block.github.io/goose/index.html
14. OpenHandshttps://docs.openhands.dev/sdk
15. DeerFlowhttps://github.com/bytedance/deer-flow
16. Aiderhttps://aider.chat/docs/
17. mini-SWE-agenthttps://github.com/SWE-agent/mini-swe-agent
18. Mistral Vibehttps://github.com/mistralai/mistral-vibe
19. Clinehttps://docs.cline.bot/mcp/mcp-overview
20. Roo Codehttps://roocodeinc.github.io/Roo-Code/features/mcp/using-mcp-in-roo/
21. Continuehttps://docs.continue.dev/customize/deep-dives/mcp
22. Cursorhttps://cursor.com/docs
23. Windsurf / Devin Desktophttps://docs.devin.ai/desktop/cascade/mcp
24. Claude Agent SDKhttps://code.claude.com/docs/en/agent-sdk/overview
25. LangGraphhttps://docs.langchain.com/oss/python/langgraph/overview
26. Deep Agentshttps://docs.langchain.com/oss/python/deepagents/overview
27. Google ADKhttps://adk.dev/
28. Microsoft Agent Frameworkhttps://learn.microsoft.com/en-us/agent-framework/overview/
29. Agno / AgentOShttps://docs.agno.com/agent-os/introduction
30. CrewAIhttps://docs.crewai.com/en/concepts/flows
31. PydanticAIhttps://pydantic.dev/docs/ai/integrations/ui/overview/
32. Mastrahttps://mastra.ai/docs
33. NeMo Agent Toolkithttps://github.com/NVIDIA/NeMo-Agent-Toolkit
34. smolagentshttps://github.com/huggingface/smolagents
35. Difyhttps://github.com/langgenius/dify-plugin-daemon
36. Open WebUIhttps://docs.openwebui.com/features/extensibility/plugin/
37. Chainlithttps://docs.chainlit.io/api-reference/elements/custom
38. Chainlit custom React frontendhttps://docs.chainlit.io/deploy/react/overview
39. OpenAI Plugins (formerly Apps SDK path)https://developers.openai.com/plugins/build/chatgpt-ui
40. MCP Appshttps://modelcontextprotocol.io/extensions/apps/overview
41. AG-UIhttps://docs.ag-ui.com/introduction
42. A2UIhttps://a2ui.org/