Environment Engineering
This page explains the core technical thesis behind holaOS: long-horizon agent systems should be designed through environment engineering, not only harness engineering.
The point is not that the harness stops mattering. The point is that workspace structure, memory, continuity, capability boundaries, and portability need to be treated as first-class system design concerns rather than follow-on implementation details.
Harness engineering is not enough
Harness engineering focuses on the execution loop:
- provider/model wiring
- tool schemas
- streaming
- retries
- transport and executor behavior
That is necessary, but insufficient for long-horizon work. A harness-centric system tends to leave the most important questions under-specified:
- where standing instructions live
- what memory is durable vs volatile
- how the next run restores continuity
- what the agent is actually allowed to see and call
- how the system evolves after repeated work
- what makes the whole unit portable
What environment engineering means in holaOS
In holaOS, the environment is the primary technical artifact. That environment defines the operating context the harness runs inside.
| Concern | Harness-Centric Framing | holaOS Environment Framing |
|---|---|---|
| Instructions | prompt text | authored files such as AGENTS.md and workspace.yaml |
| Memory | retrieval attached after the fact | explicit durable and volatile memory surfaces |
| Continuity | replay more transcript | compaction boundaries, request snapshots, and session-memory |
| Capability surface | inferred from code or prompt | projected per run as a capability manifest |
| Evolution | mostly manual | queued evolve flow for durable memory and candidate skills |
| Portability | export chats or hidden backend state | package the workspace as a stable operating unit |
The environment contract
The holaOS environment currently defines:
- workspace structure
- the authored workspace root and its app/skill surfaces
- memory surfaces
- durable markdown memory plus runtime-owned volatile projections
- continuity artifacts
turn_results, compaction boundaries, request snapshots, andsession-memory
- capability projection
- the visible and callable surface passed to the harness for each run
- self-evolving behavior
- queued follow-up work for durable-memory promotion and candidate skill review
- harness boundary
- the reduced execution package that the harness receives
- packaging and portability
- what a workspace carries with it and what runtime residue gets omitted
Why this matters for developers
If you are building on holaOS, you are not just writing tools for a harness.
You are building against an environment contract:
- apps are packaged into workspace-local
apps/<app-id>/ - skills are packaged into workspace-local
skills/ - memory has explicit storage and governance rules
- the runtime decides capability visibility per run
- the desktop app is one operator shell, not the only surface
That shift is what makes the system easier to inspect, package, resume, and extend.