holaOS: Durable Agent Environments

Overview

This series explains how holaOS turns a recurring agent responsibility into a governed operating context rather than a prompt or executor alone. Authored workspace policy is compiled into a bounded, session-specific run; the harness executes it, apps keep domain capability coherent, grants and MCP policy separate account access from tool visibility, and continuity plus selective memory carry work forward while allowing freshness checks. The result is an auditable way to place tools, state, outputs, and operator approval. The repository supports this architecture, but not automatic reliability, safe app semantics, local-only execution, equal harness maturity, or complete learning and marketplace features.

Learning outcomes

holaOS treats the workspace as durable operating context, not an all-purpose prompt or passive folder.
The runtime compiles authored state into a bounded run; the harness executes it without owning the environment.
Apps, grants, MCP policy, and approvals separate capability ownership, account access, tool visibility, and human consent.
Continuity resumes active work, while selective memory and live verification keep recalled knowledge from becoming automatic truth.
The architecture makes boundaries auditable, but persistence does not prove reliability, secure app behavior, or provider correctness.

Keywords

holaOSruntimeworkspacememoryappscontinuityharnessMCPgrantsbroker

Chapters

holaOS Agent Environment vs Prompt

Why recurring roles need durable context across runs

9 min · Why recurring roles need durable context across runs

9 min

holaOS Workspace to a Controlled Run

How authored state becomes a bounded execution package

10 min · How authored state becomes a bounded execution package

10 min

holaOS Harness Boundary and Tool Visibility

What executor swaps preserve—and what they do not

10 min · What executor swaps preserve—and what they do not

10 min

holaOS Run Audit: From Intent to Output

Trace state, authority, and evidence across each transition

10 min · Trace state, authority, and evidence across each transition

10 min

holaOS Apps: Lifecycle and Capability Ownership

When a durable capability needs more than a tool

11 min · When a durable capability needs more than a tool

11 min

holaOS Security: Grants, Accounts, and Tools

How authority, approval, and network routes stay distinct

12 min · How authority, approval, and network routes stay distinct

12 min

holaOS Memory: Resume, Recall, Verify

How continuity and durable recall serve different jobs

11 min · How continuity and durable recall serve different jobs

11 min

holaOS Durability and Its Limits

What persists across runs, and what operators must verify

11 min · What persists across runs, and what operators must verify

11 min

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-8 Premium

FAQ

Why does holaOS need an environment instead of a prompt?

holaOS needs an environment because recurring responsibilities span runs, changing inputs, capabilities, memory, and outputs; a prompt alone does not own that context.

How does holaOS turn a workspace into a bounded agent run?

holaOS reads selected workspace references, validates and compiles them, stages permitted capabilities and context, then sends a reduced package to the harness.

What makes an app different from an integration or tool in holaOS?

In holaOS, an app owns a durable capability that may coordinate UI, state, tools, integrations, lifecycle, health, and outputs; an integration or tool answers a narrower question.

Does holaOS keep all agent data local?

No. holaOS keeps key workspace state under local control, but models, search, remote MCP, integrations, and providers may receive data over the network.

How does holaOS distinguish continuity from durable memory?

holaOS uses continuity to resume recent work and durable memory to retain reusable knowledge; recalled facts may still need live verification when freshness matters.