We use “harness” to mean the software that gives an agent a working environment and controls how work proceeds within it. That can include the model-and-tool loop. It can also include the workspace that hosts several of those loops.
Our position is that harnesses compose. An inner harness can manage an agent’s task while an outer harness manages where it runs, what it can reach, and how its work enters a shared project. Both have a legitimate claim to the name.
Around the model
A model on its own only writes text. To act, it runs in a loop: it reads the conversation, asks for a tool such as reading a file or running a command, sees the result, and continues until the task is done or it needs a person.
Consider a coding task. Someone has to assemble the context, send it to the model, dispatch a requested tool call, and feed the result back into the conversation. The software also needs to decide when to stop or ask the person using it for help. We call that an agent harness.
The model proposes what to do next. The surrounding software turns that proposal into an operation. Its tool definitions, execution rules and session handling shape what the agent can accomplish. That is already a substantial system, and it may still run inside another one.
Around the work
Suppose you give a coding agent a separate copy of your project. You choose the files it may access and keep your own terminal open alongside it. When the work comes back, you inspect the changes before accepting them.
The agent’s harness handles its conversation and tools. The surrounding workspace handles the project copy, the process and the boundaries you established. It may keep records after the agent exits, or let you resume work from another client. Those responsibilities continue beyond a single model turn.
We call this a workspace harness. Calling it an outer harness describes its relationship to the agent harness inside it. It does not imply that the outer layer runs another model, or understands every decision made by the inner one.
Name the scope of control
A useful architecture description should tell you which layer owns a decision. Who can launch a process? Who grants access to a file or a peer? Which system records an attempted change? Who decides whether the result is accepted?
For example, an inner harness may approve a shell command according to its own settings. The process still has to operate within the access available to it. A confinement boundary can limit which files and network destinations it reaches without interpreting each command.
Calls into the workspace are another boundary. cherry π checks the calls it handles against capabilities and policy. Hosting a third-party harness does not mean cherry π intercepts or approves every internal tool call that harness makes.
The records have a scope, too. A workspace receipt can establish what a workspace operation attempted and what outcome was recorded. It cannot, by itself, account for every effect produced inside an independently running agent. We want that distinction visible in both the architecture and the product.
Where cherry π fits
We describe cherry π as a multi-layered harness architecture for Governed Workspace Environments. It brings native agent machinery and third-party agent harnesses into a workspace with terminals, project layers and tools of your own.
Picache uses cherry π’s native machinery. Vendor harnesses such as Claude Code and Codex retain their own loops. cherry π provides the surrounding workspace and controls the operations routed through it. Confinement, scoped permissions and review give that relationship practical boundaries.
Durability belongs in this architecture as well. Before cherry π runs a governed call that changes something, it records what the call intends to do. Afterwards it records the result. If an interruption leaves the outcome uncertain, that has to be settled before anything retries.
An outer harness should be precise about what it can recover. A surviving record is not a guarantee that every process or external effect can be restored.
Across machines, the boundary still matters
cherry π’s P2P foundations extend the workspace across machines. Each machine keeps its own identity and its own authority. Pairing establishes that a peer is trusted. Grants decide what that peer may access, and the receiving workspace still authorizes each remote request.
Nesting harnesses on one machine and connecting workspaces across a network are different relationships. Neither should give the caller all authority by default. We want people to be able to follow a piece of work across those boundaries and understand what each participant was allowed to do.
Building with this view
This is the vocabulary we are adopting for cherry π. It lets us describe the agent loop and the wider workspace without pretending either is the whole system. When we introduce a feature, we should be able to explain which harness owns it, how control passes between layers, and where the operator makes the decision.
More detail: workspace authority and agent confinement.