Moonbase: from an agent office to a persistent workbench

The first version of Moonbase gave my agents a place to work. It had a lunar habitat, original Blender-made alien dinosaurs, real terminals and a careful distinction between an agent I had registered and work I had actually observed. That was a useful beginning, but it left a larger question unanswered: where should I go to give a specialist a job, leave it running, come back with direction and decide whether the result is good enough?

The new goal is to make Moonbase that working interface. The room is still there, but it is no longer the entrance fee. A persistent Workbench now sits in front of it, with project workstreams, versioned specialists, selected knowledge, an owner decision inbox, artifacts and reviewable memory. The important change is not another animation. It is a durable connection between what I asked for, what the agent was allowed to use, what it actually did and what I accepted.

This is a follow-up to the original Moonbase build. The project hub links the two stages, and the technical specification describes the current contracts in more detail. The application itself remains private and requires sign-in.

The goal changed from seeing work to directing it

A room can show me where people are sitting. It cannot, by itself, explain which instructions a specialist is using, which documents it has seen or whether the file on its desk is the one I reviewed yesterday. Those questions matter more once I want to depend on the same specialist across a project.

I want to give a coding specialist a deliverable, check in without keeping a browser open, steer the next turn and review a concrete artifact. I want a teaching or research specialist to use the practices and evidence I choose, not whatever happens to be discoverable on my machine. And I want useful lessons to survive a task without silently becoming global instructions.

That is a more demanding goal than an agent dashboard. It needs continuity, but it also needs boundaries. Persistent does not mean endlessly spending tokens in the background. Dedicated does not mean a new model trained on all my files. Familiar does not mean an existing personal bot’s memory or desktop conversation has been copied into another system.

Moonbase’s first Workbench slice makes those distinctions explicit.

Three records replace the idea of a single endless chat

The central model is a profile, a workstream and a run.

A profile is a stable specialist definition: purpose, instructions, style, examples, selected tools, completion criteria and knowledge grants. Saving an edit creates a version. Engineering, Teaching, Research and Content are the initial generic templates, not four activated personal agents.

A workstream belongs to a registered project. It holds a goal, selected sources, verification presets and an owner-approved backlog. It gives the specialist a place to work without turning every brief into a new identity.

A run is one execution with its own worktree, native session and pinned profile/context snapshot. Editing a profile does not quietly change an already queued task. That makes it possible to ask what a result was produced from, rather than reconstructing the answer from whichever settings happen to be visible now.

Leave the page, not the job

The supervisor lives on the server. Closing the Workbench page closes an observation stream, not the run. Returning gives me a current snapshot and since-visit summary rather than a guess based on the last browser session. The 2D entrance works without WebGL, character selection or the habitat’s WebSocket.

That separation also makes failure more honest. A disconnected browser is not a cancelled job. A requested Stop is not confirmed cleanup. A model finishing a turn is not an accepted deliverable. If cleanup cannot be established, Moonbase retains the uncertainty instead of launching a replacement and calling the result seamless.

Background work is still work I explicitly approved. There are no paid idle loops, automatic reminders or unsolicited specialist schedules in this release. The local host also still needs to be available: moving control out of a browser did not turn my Mac into an always-on cloud service.

Knowledge is a grant, not a folder-shaped invitation

A specialist should know why it is allowed to read a source. The Workbench lets me select individual UTF-8 Markdown or text files from registered projects or explicitly allowed document roots. It records source versions and hashes, and retrieves bounded passages with line-level citations.

There are two deliberate checks on inclusion: the profile and the workstream must both select the grant. Registering a document is not the same as sending it to every future task. Refreshing, revoking or detecting a changed source also cannot silently substitute new evidence inside an old native context.

This is not whole-vault ingestion. It does not add PDF parsing, embeddings, a public index or access to personal conversations. The private vault connector is off by default. The useful first step is a small, inspectable set of documents, not the largest possible context window.

The same principle applies to memory. A model can propose a lesson, but that lesson remains excluded until I approve its displayed version. It has an originating run and profile/workstream scope. I can edit, revoke or delete it, and an old queued task keeps its earlier snapshot.

This is what I mean by teaching a durable specialist in the current release: instructions, examples, selected evidence and reviewed lessons. It is not model-weight fine-tuning, and it is not an automatic guarantee that the specialist will be right.

Review is more than a thumbs-up

The decision inbox separates exact tool permissions, semantic questions and outcome acceptance. Telling a specialist to try a different approach cannot approve a file write, network action or publication. An approval applies to one bound action, not every tool call that resembles it later.

The outcome carries artifacts, changed-file hashes, a captured diff, verification receipts and the relevant source/session/profile provenance. Accepting it rechecks the actual workspace and artifact bytes. A passing whitespace check is not presented as a passing project test.

Project verification also has a clear limit: it executes approved project code with a sanitized environment and private home directory. That is not an operating-system sandbox. Approving a check on untrusted project code still requires judgment.

Moonbase itself does not gain a publish, push or merge tool in this release. Publishing this article is a separate, explicitly requested operation. That distinction keeps a useful coding interface from quietly becoming a general authorization layer.

The new equipment belongs to the workflow

The visual side grew with the working model. Three original Blender station types now represent the task console, knowledge archive and review station. Their authored screen mounts, interaction bounds and materials are part of the runtime asset contract, not decorative stand-ins.

The Workbench uses their icons without waiting for GLB loading or a 3D scene. In the optional habitat, the stations can project current owned work, sources and decisions. Losing freshness produces an unavailable state; an animated console is not evidence that a model is running.

The existing alien-dinosaur residents, real PTY workers, project floors, queues, meetings and whiteboard were not replaced by SDK-shaped imitations. Moonbase-owned SDK sessions produce structured events. An existing terminal worker still has its real terminal. A Neural Bridge specialist observed from another runtime is still read-only observation, not an adopted desktop chat.

Maintenance should not own every terminal on the Mac

One operational problem exposed a broader design issue. The conservative maintenance observer originally rejected any unrelated terminal activity. That made an embedded shell in another application’s process tree enough to block a Moonbase configuration operation.

The answer is not a special exception for an application named Claude. Names, ownership and an apparently idle process are not proof that a resource is unrelated. The reviewed correction adds an explicit Moonbase operation scope: look for actual conflicts in owned lineage/groups, protected directories and files, PTY claims, controllers and sockets, while leaving unrelated terminals alone.

The correction is merged and checked. An owned neutral terminal survived the guarded lifecycle in controlled tests, while the same terminal holding a protected directory or file caused refusal. Global/launchd/bootstrap observations in those tests are labeled synthetic rather than passed off as a live production maintenance demonstration.

There is an important deployment boundary here. The scoped correction is merged source, not a newly installed helper or a new live-admission profile for the restarted application. Future scoped maintenance still needs that reviewed release/profile step. Normal Workbench use does not require unrelated Claude work to be stopped.

What is live, and what the evidence means

The Workbench application and authenticated desktop/mobile layouts are live. The configuration update preserved all 570 protected file bytes and modes, including retained mission history, rather than resetting the workspace to make a rollout easier. The existing mission records and Ready mission were left intact.

Separate isolated native checks exercised real Copilot artifacts, a file diff, outcome review and an approved-memory follow-up. Four submissions included one retained initial failure and three successful tasks. That is evidence for those specific workflows, not a production load test or a claim that the four template profiles have all been run.

Those limits are part of the product, not fine print hiding behind the screenshots. The next useful step is explicitly binding a specialist to a project and choosing the evidence and checks it should use. It is not starting every profile merely to make the office look busy.

The new goal is straightforward: a place to leave meaningful work, return with direction and retain what was actually learned. The lunar habitat gives that work a memorable home. The Workbench gives it a contract.

References

• Original Moonbase build, including the pinned MIT-licensed Agent Office foundation.
• Moonbase project and technical specification.
• GitHub Copilot SDK and its authentication documentation.
• Claude Agent SDK overview and authentication boundary.