cherry π is a place to build, run and share your work. It has its own editors, a terminal desktop, a browser GUI, native agent machinery and an app platform. You can start there and do a substantial amount of work without assembling another environment around it.
“Cherry on Top” is about what happens when that environment becomes part of your work. A project can have its code, running programs, agent conversations and review decisions together. The same workspace can reach into another project or a paired machine, with explicit boundaries around what crosses over.
You can bring a favorite editor or terminal tool. You can also use cherry π's editor pane, editor.pi in the Web GUI and Picache's workspace tools. Those are choices inside the environment. The larger ambition is a workspace where you can carry a piece of work from an idea through execution, review and use.
The glue is work
Consider an ordinary handoff. An agent has changed a branch. Another agent needs to review it. You find the result, identify the branch, copy enough context into another conversation and check later to see whether the reviewer responded.
That sequence contains decisions worth preserving. Which result did you send? Who received it? Was it a request for an opinion or permission to change something? If the receiver was busy, is the request still waiting?
The workspace gives the handoff an address, a reference to the work and a recorded lifecycle. In cherry π, agents can send typed questions, answers and handoffs to particular agent panes. Picache can participate using the workspace tools. The agents retain their own conversations.
The point is to make less of the coordination depend on what you happen to remember from the last terminal you looked at.
Composition has boundaries
We use “harness” at more than one level. A vendor harness controls its model loop and tools. cherry π provides the workspace around it, including confinement and checks on operations routed through the workspace. We explain that position in What is a harness?.
This matters when work moves between projects. Asking the API layer a question should not give the caller permission to edit the API. Sending a proposed patch should not apply it. Linking workspaces should not merge their authority.
Those are different interactions in cherry π. An ask runs in a separate, read-only thread. An offered patch reaches the destination Inbox for the operator to accept. A task needs acceptance before it runs there. Conduit carries these interactions across layers and linked workspaces, and on to paired machines, with receipts and authorization at the destination.
Integration is useful when it makes the next step easier to perform and easier to inspect. If it quietly broadens access, it has changed the workflow in a much less welcome way.
From an idea to something you can use
Suppose you need a small tool for a project. You can write it in the built-in editor or give the software factory a schematic and an order. A builder works in a product layer, with checks and a review gate around the result. Try the candidate on its own data before deciding what to accept and package.
The result can live in the environment where you made it. A .pi app packages code, assets and data in one file, and the host grants the capabilities it needs. Open its page in Cherrytop or use a supported pane contribution in the terminal desk. Building the tool and using it belong to the same workspace.
Picache has access to the surrounding workspace machinery, including pane arrangement and the Inbox. Vendor agents can work alongside it in their own harnesses. A question can go to another layer's agent; a proposed change can arrive in that layer's Inbox. You retain the decision about what becomes part of the project.
That environment has two working surfaces. In the TUI, split and zoom panes or drag floating windows into place. In Cherrytop, arrange windows over a canvas with terminals, apps and chat. Use the native editors, or open a tool you already know. The workspace can accommodate that preference without making it a prerequisite.
Keep your way back
The workspace also has to hold up when you leave and return. A branch reference attached to a handoff, an Inbox item awaiting acceptance and a record of an interrupted operation help you recover the state of the work after the conversation has moved on.
Durability is part of that legibility. A client disappearing is different from an operation failing. cherry π records intent before governed changing operations and records their results afterward. An uncertain outcome goes to Recovery for a decision before another attempt. That distinction becomes especially important when several tools or machines are involved.
A project can begin in cherry π, grow its own tools and involve agents or peers as the work demands. You can bring an existing stack into it, too. In either case, the workspace gives that work somewhere to run, accumulate history and move forward under your control.