A Run You Can Audit: Follow One Request Across the Boundary

For holaOS, the useful question is not only whether an agent returned a good answer. It is whether the request moved through the environment with the right state, authority, and evidence at each transition. This checkpoint treats one run as an auditable chain—from authored workspace intent to runtime projection, harness execution, and persisted result—so the reader can locate a missing capability or wrong outcome without treating “the agent” as one indivisible component.

The audit model is deliberately practical. It does not ask the reader to memorize every internal object. It asks who owned the relevant decision, what crossed the next boundary, and what evidence should exist afterward. That is enough to connect the workspace contract with the runtime–harness split and to expose why durable capability needs its own owner.

One request, several ownership transitions

Imagine a product-launch workspace whose operator asks the agent to prepare a brief from newly supplied notes and save the result for review. The request sounds like one action to the operator. In holaOS, it becomes a sequence of state transitions, each of which can succeed or fail independently.

The first state is authored intent. The workspace supplies standing instructions, the active agent and model settings, the relevant skill or app declarations, and the MCP policy that describes possible structured tools. The runtime-owned state around the workspace may contain recent session information, staged attachments, or durable memory, but those records do not silently become new standing policy. At this point, the question is whether the workspace expresses a coherent environment for the request at all.

The second state is compiled run state. The runtime reads the workspace plan and the selected references, validates the configuration, resolves application manifests and MCP servers, and computes the structured plan and configuration checksum. It then loads context that belongs to this run: session-resume state, scratchpad metadata, recalled memory, profile context, or operator-surface context when appropriate. The output is not a copy of every workspace file. It is an interpretation of the authored environment plus the current execution context.

The third state is projected execution state. The runtime decides which tools, skills, commands, attachments, MCP servers, and app capabilities should be visible for this session. A main coordination session may need to plan, retrieve memory, delegate, and produce an output, while a delegated execution session may need a browser, shell, or file tools. The same workspace can therefore lead to different capability surfaces without changing its underlying identity. The model's hot context is assembled from the selected prompt layers and relevant evidence, not from every cold artifact the workspace contains.

Only then does the reduced package cross into the harness host. The host creates an executor-native session, serializes the prepared prompt and context, wires the allowed tools, and starts the loop. The executor may think, call a tool, wait for input, retry, or stop.