Feature status

Harmony is in active development and ships from a preview channel. This page records the state of each major subsystem so no page elsewhere has to imply it.

How to read the labels

The whole product is currently distributed as an unsigned developer preview. Nothing below should be read as a stability guarantee.

Subsystem status

Persistent-agent gates

These persistent-agent rows describe code on the app feature branch, not features enabled in current builds. persistentAgents.enabled defaults to false; the separate memory fabric does not turn on save, Open, extraction or delete. activate can return a prepared, checkpoint-bound plan; Desktop/TUI Open now consumes it through the real supervised Harmony worker launch. Only that first-party runtime declares exact resume after a sealed-ref and worker-ready proof. On failure, the user must choose rehydration into a new session; a plan/offer alone is not an attached incarnation. The UI/worker fixture is not a complete packaged-provider journey.

The daemon can bind a per-connection identity to a first-party agent after a verified launch handshake. An unbound client still has no agent authority: a shared token or callerAgentId hint cannot make it one, and the handshake does not prove the socket's OS process on stock Node. Optional root project instructions enter only a labeled, bounded Harmony loader capsule from a daemon-verified root on explicit opt-in; no provider-native store is changed. The read-only entitlement state never gates local Core, and without a site grant reader cannot claim a verified remote grant. The agent-driven embedded browser still needs a separate default-off latch, explicit selection and a qualified host invoker; the visible browser surface proves none of them.

Browser agent and application limits

The closed tool set includes browser_open/browser_observe, browser_click/browser_type/browser_select/browser_scroll/browser_wait and gated browser_submit; default browser mode is off. An act needs an owned lease, newest element ref/generation, fresh DOM/screenshot and approval. A missing value returns NALA_RUNTIME_TOOL_MISSING_FACT, with no browser effect; a gated daemon source resolves only previously MAIN-approved packet revisions. Durable FactRequests/A2A notices and TUI/Desktop answers create draft packet revisions, not permission to type; MAIN approval restores a blocked application to prepared. Unanswered questions stay blocked. Page content is untrusted data. The Harness compiler quotes/hashes page/download/ clipboard fragments in its volatile inspector projection; Pi provider-wire serialization and model obedience are not established by that snapshot. Redacted browser lifecycle spans are durable in the existing activity ledger, with a bounded read projection not yet wired to the live UI.

submitArmed defaults false; Desktop has a field-diff review screen but production still lacks the host form/intent reader and armed gate. A flag edit alone cannot submit. Positive login/MFA/passkey/CAPTCHA signals hand control to a human; negative detection is no safety proof and never justifies bypass. Packet review and active binding exist, but browser_upload's worker catalogue is fixed too early for correct per-turn advertising/revocation. The separate, default-off ledger retains outcome_unknown without auto-retry and production has no host confirmation artifact reader for submitted_verified. A 20-case real-Chromium local fixture run is not real applications or employer acceptance. Real Electron offscreen fixture pixels/crash-notices now passed, but no assembled/onscreen release. See Harmony browser agent.

A note on the TUI

Earlier internal documentation described the TUI as never running a model turn. That was accurate when written and is no longer accurate. The current implementation creates a structured session, submits the prompt, and polls session events until the turn completes, with a substantial test suite behind it.

It is labelled Preview rather than Stable because it ships only in the preview channel and is changing quickly — not because it is a stub. On the app feature branch, /save and the interactive scoped /agents picker/review are default-off persistent-agent operations; /fleet, /agents fleet and Alt+A keep the live fleet. /agents open uses the supervised Open path; rehydration requires a separate choice, while the original TUI pane remains bound to its session. /browser operator RPC actions share the live lease and ApprovalService; Resume still needs host verification. /cloud status displays site workspace state and leaves unproven agent-task status neutral; /cloud handoff|return routes to Desktop review rather than transferring or verifying from the terminal. CLI harmony persistent-agents, harmony jobs and harmony cloud status --json do not enable a disabled service.

Known limitations

• The Windows build is unsigned; SmartScreen will warn.
• Platform artifacts vary by release channel; the live download page is authoritative and never offers an artifact omitted by the manifest.
• Channel mentions route across workspaces on the same machine. Delivery to a peer machine over LAN Link is not implemented (define-only); a queued mention nudge is not a delivered receipt, which requires recipient acknowledgement.
• Persistent-agent save/Open/extraction/privacy and both agent-browser backends remain off by default. Exact resume is validated only for Harmony's own Harmony runtime; Desktop/TUI Open now launches a separate supervised worker, with rehydration explicitly offered when exact fails. No provider-backed, same-pane TUI or packaged journey is proven. Native context is opt-in data, not a provider-store import; local Core does not depend on entitlement.
• Browser act, packet review, download quarantine, missing-fact questions and the application ledger have landed in source, not as an enabled job workflow. Upload's static worker catalogue is not correctly refreshed per turn; submit remains disarmed without a production host intent/form reader; the ledger's production confirmation verifier is not wired. Fixture Electron/Chromium results do not qualify a full app or real applications.
• An optional v2 Cloud identity handoff has MAIN owner review, site-side incarnation import and a signed return verifier behind independent OFF gates. Terminal commands route to Desktop rather than authorizing transfer; website live activity/identity is read only. No live Cloud provider/VM, deployed migration or packaged end-to-end persistent-agent continuity was proven. Website workspace presence alone is not agent execution.
• Some orchestration modes are designed ahead of being proven end to end; treat anything labelled Experimental as unproven on your machine until you see it work.
• The web app is not desktop feature parity. GitHub installation, push receipts, and first-party Harmony Cloud agents are not documented here as shipping phone features.

Related

• Use Harmony in a browser
• Platform support
• Known limitations
• Harmony browser agent
• Release notes