Brain

Shared memory, multi-agent coordination, and infra judgement — native to Zerops.

Any MCP-compatible coding agent (Claude Code, Cursor, Codex) gets three things no single agent session has on its own:

1. Persistent shared memory — facts and decisions survive a session and are visible to every agent, not only the one that learned them.

2. Multi-agent coordination — a single-writer lock so two agents acting on the same Zerops project don't collide. Plus the Observatory, a live dashboard so coordination can be watched rather than taken on trust.

Why this and not ZCP

ZCP already does the end-to-end infra work, and does it well — its own docs describe the loop as "the agent reads live state, chooses the app runtime and dependencies, changes the app, deploys through Zerops, verifies real behavior, and returns proof or a blocker." The ZCP container ships zcli and a Zerops MCP server, so anything inside it can already deploy, scale and inspect the project. Brain does not reimplement any of that. An earlier draft of this README promised an infra.provision / infra.deploy / infra.scale tool surface; that was a duplicate of the toggle, and it was cut.

What ZCP does not have is the layer this builds, and Zerops' own product makes the gap concrete rather than theoretical:

No memory. The documented recovery from an interrupted session is "Chat history is not the source of truth… Read current project status and tell me where this project stands before changing anything." Live state tells an agent that Redis exists. It cannot tell it why Redis and not Valkey, or that Valkey was tried and rejected — the decisions and dead ends that are most expensive to re-derive.

No coordination between agents. The project-creation screen offers to install Claude Code, Codex, Antigravity, Grok Build and Cursor CLI into the same ZCP container, and gives them nothing to share memory with or to keep them off each other's work. Two agents in that one container are strangers. Across projects it is stronger still: ZCP access is "sealed inside the project's own VXLAN", so an agent in my-project-johnd and one in my-project-janed are on different private networks and can only meet through a GitHub pull request — which carries a diff, not the reasoning behind it.

Related MCP server: Memclaw

Built for The Zerops Challenge, Aug 8–9 2026

Prior work vs. work built during the event

The rules permit reusing code the builder already owns, provided it's clear which is which. So it is stated plainly, and checkably:

Prior work — four files from a previous personal project (Notch), kept verbatim in prior-art/notch/ and excluded from the build so they can be diffed against what replaced them:

1,257 lines of prior art. Nothing else was carried across. Notch is a ~20,000-line multi-agent orchestrator with six ADE adapters, a mobile app and a desktop shell; none of that is here, because none of it is Brain.

Built during the event — everything under src/, starting with the one change that matters most:

prior-art/notch/baton.ts arbitrates its lock by reading a JSON file, checking the holder, and writing it back. On one laptop that's fine — single writer, microsecond window. On Zerops it's a real bug: the MCP service can run several containers behind a load balancer against one Postgres, so two agents served by two containers can both read holder = NULL and both write themselves in, and both get a success. src/core/lock.ts replaces it with a single INSERT … ON CONFLICT DO UPDATE … WHERE, so Postgres decides under the row lock it already takes. It also adds a TTL, because a dead container leaves a lock no human can delete.

Status

This README will not claim a service is wired up before it is. Current state:

• Repo, types, Postgres schema

• src/core/lock.ts — atomic single-writer lock, ported and re-platformed

• Memory tools (brain.remember / brain.recall) — Postgres + Qdrant

• MCP server exposing the tool surface

• Credential broker + Zerops REST client

• Doctor

• Observatory dashboard

• Deployed live on Zerops — blocked, see below

Blocked on one credential

Nothing that touches the real Zerops API can be built or verified without a Zerops account-level Personal Access Token (Zerops GUI → Access Token management). That gates provisioning, deploying, scaling, doctor.audit, and the live URL the rules require.

It will be held only as a Zerops envSecret on the backend service, never committed, never logged in full, and never handed to an agent — agents get short-lived scoped tickets and the broker makes the call itself.

Until that token exists, this repo will not pretend otherwise: no mocked Zerops responses, no fake project ids, no simulated deploys.