Spawn every agent with a spec, a plan, and the same workspace
A NanoClaw skill that sets up every persistent agent the way a coding agent works: a spec, a saved plan, and one workspace layout, so I can rely on any agent I spawn before I read a line of its output.
As an analyst I spawn persistent agents in my NanoClaw harness with one command, one per recurring task. Coding agents taught me what they need to be reliable: a spec before code, a plan before work, and a repo laid out the same way every time. So I wrote create-persistent-agent, a skill that gives every agent all three before it exists.
An agent that improvises is an agent I cannot trust
Every spawn leaves a topic and an agent group behind, and nothing cleans them up. The wasted container barely matters. What costs me is an agent that runs for a month against a purpose nobody wrote down, picks a new shape for the same report each cycle, and leaves its files wherever it likes. I cannot tell if it is working, and with several agents running I cannot check them all by hand. I kept hitting that after the OpenClaw experiment: capable agents that drifted because "done" was never defined.
Borrow the coding agent's spec and plan
Coding agents already solved this. OpenSpec writes a proposal, specs, and a task list before any code. Superpowers brainstorms, writes the plan to a file, executes against it, and verifies before it claims done. I apply both to agents instead of code.
The spec says what done looks like
The skill interviews me and fills in six sections: Problem, Objective, Success criteria, Non-goals, Constraints, and Open questions. Spec tools call the success criteria acceptance criteria. The test for each one: by the deadline, could two reasonable people disagree about whether it was met? If yes, it is still an activity. The spec becomes the agent's standing instructions, its system prompt (instructions in NanoClaw), re-read every turn like a CLAUDE.md. Today's ask goes in as the initial prompt, delivered once. Anything I could not settle becomes an Open question, logged as intent debt instead of a quiet guess.
The plan lives in a file, and the file is the gate
Before real work the agent runs a planner subagent on the objective and success criteria and saves the plan verbatim. Like a Superpowers plan or an OpenSpec tasks.md, it states the goal and success criteria and breaks the work into tasks that each end in a checkable result. Mine adds what a coding plan leaves to the runner, starting with the orchestration design: whether the work stays inline, goes to one subagent, or fans out, which subagent takes each task, and what runs in parallel. It also covers how the results assemble into the deliverable, how each criterion gets verified, and the schedule, the state carried between runs, and the risks. A recurring deliverable gets one plan at a fixed path, plans/<deliverable>.md, and every cycle checks it: if it is absent, plan first. If it is present, follow it. It replans only when scope changes. Without that fixed file I saw agents skip the planner and improvise a different shape every run, with plans/ left empty.
Every agent gets the same workspace
NanoClaw already gives every agent group its own container, memory (CLAUDE.md), sessions, mounts and model. On top of that, each agent preloads one layout on its first turn: plans/ for plans, outputs/ for deliverables, outputs/.verify/ for the evidence that the done check passed, and .templates/ for a starting skeleton matched to the deliverable (report, presentation, infographic, HTML), and scripts/ for code the agent writes once and reruns, on a schedule or ad hoc. The script is idempotent and never touches existing files. There is no separate spec folder, because the spec already lives in instructions and a copy would drift. This is the part I lean on most: I can open any agent I spawned and know where the plan, the output and the proof are.
What it does not do
It does not decide the agent's shape; that is a later step. It will not invent a metric to look impressive, so a standing beat gets service levels (coverage, latency, cadence) instead of a fake deadline. And it never blocks: if I will not sharpen something, it becomes an Open question and the agent spawns anyway.
The bottom line
Treat a persistent agent like a coding task: spec first, plan in a file, the same workspace every time. Reliability comes from the setup the agent starts in. It is the same instinct as giving a loop a criterion it cannot renegotiate.
