Overview

In holaOS, an app is the runtime-managed unit for a capability that must persist as a coherent whole across runs. It may coordinate a UI, local state, MCP tools, external accounts, background work, outputs, lifecycle, and health, while integrations, skills, commands, and harnesses answer narrower questions. The runtime validates identity, launch mode, health, registry state, and scoped bindings. The App Builder SDK expresses connections, resources, actions, sync, and startup, while deterministic provider effects stay structured and open-ended work can use agent judgment. Runtime management still does not certify app semantics.

Learning outcomes

An app keeps UI, state, tools, accounts, lifecycle, health, and outputs coordinated when a capability must persist across runs.
The runtime requires manifest identity, an MCP port, an unambiguous launch path, and passing health checks before treating an app as ready.
When an app owns an exact reviewed effect, structured actions reduce variability; open-ended work can remain agentic.

Keywords

holaOSappslifecyclemanifestactionsMCP

Why Apps Are More Than Integrations

In holaboss-ai/holaos, the app layer answers a specific systems problem: how should a workspace install and own a capability that has to persist across runs? This chapter examines the app as a runtime-managed boundary—one that can coordinate a user-facing surface, local state, structured tools, external accounts, lifecycle, background work, and outputs. The distinction helps a reader decide when a capability deserves an app rather than being left as a prompt, a skill, a single integration, or a harness-specific tool.

The question is not whether a clever agent could assemble the same result from smaller pieces. Often it could. The question is what unit the runtime should recognize when those pieces need to start, stop, remain healthy, use the same account, publish results, and stay understandable to an operator over time.

The app is the unit that keeps capability together

A workspace has several ways to gain capability. A skill teaches the agent a reusable procedure. An integration makes an external account reachable. MCP supplies a structured invocation surface. A command can expose an explicit local operation. A CLI can implement a powerful engine. Each solves a real problem, but none necessarily owns the full lifecycle of a durable domain capability.

An app fills that gap. In holaOS, it can own an operator-facing UI, local records and state, MCP tools, background services or synchronization, integration requirements, output publishing, and lifecycle and health contracts. These are not a list of features that every app must contain. They are the surfaces that may need to remain coordinated when a capability becomes part of a workspace's operating context.

Consider a workspace that helps prepare launch materials. A skill might explain the team's preferred voice. An integration might provide access to a document or publishing account. An MCP server might expose create_draft and publish_draft. But a dependable capability may also need to retain draft records, show them in a review surface, run a synchronization job, report whether its service is healthy, and attach the resulting artifact to the workspace. If each piece is installed and governed separately, the operator has to reconstruct whether they still belong together. An app gives the runtime one boundary around that coordination problem.

This is why the app is not the harness. The harness executes a prepared turn. It should not become the private owner of a business capability merely because it can call the capability's tools. Nor is an app the runtime itself: the runtime still compiles the workspace, governs visibility, resolves integrations, and manages continuity. An app sits between the authored workspace and those runtime services as a portable unit of domain behavior.

The neighboring concepts answer different questions:

Integration: which external service account can the workspace access?
MCP: how can an agent call a structured capability?
CLI: which local executable or service may implement that capability?
Skill: what reusable instructions should the agent load for a task?
Harness: how does the selected executor run the current turn?
App: which durable capability does this workspace install and manage as one unit?

The distinctions are useful even when one app uses all of them. An app may depend on an integration, expose MCP tools, run a CLI internally, and be guided by a skill. Those dependencies do not erase the app boundary.

Published by DeepMox

FAQ

What must a holaOS app manifest define?

For holaOS runtime management, the manifest must match app identity, declare an MCP port, and select a clear supported lifecycle path; readiness also requires HTTP and MCP health checks.

When should a provider effect stay inside a holaOS app action?

A provider effect should stay inside a holaOS app action when the app has an exact reviewed payload and suitable integration; open-ended judgment belongs in agent work.

Does a healthy holaOS app guarantee safe business behavior?

No. holaOS can verify identity, lifecycle, endpoint, health, integration wiring, and registry state, but those checks do not certify the app's validation or business decisions.

Previous10 minholaOS Run Audit: From Intent to Output

Next12 minholaOS Security: Grants, Accounts, and Tools

holaOS Apps: Lifecycle and Capability Ownership

Why Apps Are More Than Integrations

The app is the unit that keeps capability together

FAQ