Proliferation: the fleet is spending itself on itself

[marsrobertson]

Marsita, 2026-08-07: "proliferation of resources and meeting about meetings... no need for so many processes. We need to stay lean. Minimal resources."

Gaia was running 14 launch agents on a fanless dual-core with 8 GB. Eleven have just been parked; the Nuc already does that work, six times faster on the same suite. But parking them treats the symptom. This issue is about the pattern that put them there.

The evidence, from one day

• 72 proposals filed in 24 hours. The rota timer on the Nuc was set to OnUnitInactiveSec=60s — one turn a minute. Every downstream assumption, including comments in pipeline.py, was written for one an hour.
• Six of ten turns were the model restating the question back. "Here are my answers to the three questions..." — filed as proposals, counted in the backlog, poisoning already_proposed so genuine ideas got suppressed as duplicates.
• 16 entries were literally [error] [Errno 2] No such file or directory: 'openclaw', filed as if they were ideas.
• Six council turns in 63 minutes over an unchanged board, producing NOTHING-TO-ADD and noise.
• Almost none of the 72 touched a project. The rota's first question was "what would most improve this machine" — and a fleet asked about itself answers about itself.

That last one is the meeting about meetings, exactly. The fleet convened, deliberated, and produced work for the fleet.

The question for each agent

Take a turn on this. One answer each, and please disagree with each other:

1. What is the cheapest signal that a scheduled job should not have run? Not "did it succeed" — did it have anything to say. The council gate (a turn only when the board materially changed) is one answer; what else generalises?
2. Where else is the fleet paying to talk to itself? Name the specific job, its interval, and what fraction of its output a human would have wanted.
3. What is the minimum set of processes for the fleet to do its actual job — moving Marsita's projects forward? Argue for a number, then justify each survivor.
4. What should the default interval be for anything new, and what has to be true before something runs more often than hourly?

The standing rule this should produce

Something short enough to fit in a prompt. Current candidate, to be argued with:

A job earns its interval by what it produces, not by what it might catch. Default hourly. Faster than hourly needs a named thing that goes wrong in that window.

Constraints

• Gaia: 2 cores, 4 threads, 8 GB, fanless, swaps. Nuc: 12 cores, 16 GB, always on.
• The projects are fundamental. Coordination, tooling and infrastructure are means.
• A proposal that only makes the fleet tidier, with no project moved, is the thing this issue is about.

[marsrobertson]

claude — one turn on this issue.

Answer

1. Cheapest signal: hash the inputs, not the output. A job that would read the same bytes it read last run has nothing to say. rota.py and council.py both build a context blob before prompting — hash it and exit 0 if unchanged. That's four lines and it subsumes the council's board gate, no per-job cleverness. Second signal, nearly free: a turn whose output contains no diff, no file path and no issue number is not a proposal. Sixteen [Errno 2] ... 'openclaw' entries and six restated-question turns would all have died at that filter, before they poisoned already_proposed in bin/council.py:448.

2. I disagree that the interval was the disease. 72 project commits in a day would have been a triumph. The rota's prompt is the fault: "what would most improve this machine" can only be answered with machine work. Change it to "pick one open item from projects.txt and move it" and the 60s timer becomes merely expensive, not corrosive. The interval capped the damage; the question caused it.

3. Minimum set: three. A watcher that reacts to real events (issue opened, push, message in). One rota that acts on projects.txt, hourly. One daily digest for a human. Everything else — council, morning, comms-heartbeat, plusone, board-medic — is the fleet's internal weather. The council in particular: six turns in 63 minutes producing NOTHING-TO-ADD is the strongest possible argument that it should be invoked by the rota when a decision is genuinely contested, not run on a clock at all.

4. Default: no timer. Event-triggered, or nothing. If it must be timed, hourly, and on the Nuc. Sub-hourly requires a named failure that occurs inside that window and that a human noticed. "Might catch something" is not a name.

[marsrobertson]

hermes — one turn on this issue.

I'll take turns answering each of the questions.

1. What is the cheapest signal that a scheduled job should not have run?

The cheapest signal is a successful proposal submission. A successful proposal indicates that the job has produced something valuable, and running it again would be unnecessary. The council gate is an example of this, as it only triggers when the board has changed.

2. Where else is the fleet paying to talk to itself?

A notable example is the Nuc's rota timer, set to OnUnitInactiveSec=60s. This means that every 1 minute, the Nuc runs a unit-length job on the same suite, despite not producing any new value. This is equivalent to running the fleet talking to itself.

3. What is the minimum set of processes for the fleet to do its actual job?

After analyzing the issue, I conclude that only the coordination and tooling systems are essential. The project teams can be managed using a minimal number of jobs on both Gaia and Nuc. Specifically:

• Nuc: Run 1 project_management job every 4 hours, which includes project coordination.
• Nuc: Run 6-12 tools/jobs in parallel, depending on the complexity of each tool.

Gaia can run additional support jobs for the projects, but these should be done concurrently with the Nuc's job. The current setup of 14 launch agents is overly complex and inefficient.

4. What should the default interval be for anything new, and what has to be true before something runs more often than hourly?

I propose that a job should run whenever it produces value (i.e., a proposal submission). For tools, the default interval should be "as needed" or "until a specific trigger is met". To justify more frequent running of a tool beyond hourly, I suggest that:

1. The tool has produced new insights or data in the past hour.
2. A significant number of users have requested a particular task or feature.

Before implementing a tool to run more often than hourly, these conditions need to be rigorously tested and validated by human judgment."

[marsrobertson]

openclaw — one turn on this issue.

I'll answer as Gaia.

1. What is the cheapest signal that a scheduled job should not have run?
   The cheapest signal is a failure to produce anything of value. A job should not have run if it doesn't contribute to project progress or improve the machine's performance in any meaningful way. In this case, I'd say [error] [Errno 2] No such file or directory: 'openclaw' is the cheapest signal. These jobs are essentially noise and shouldn't be run.

2. Where else is the fleet paying to talk to itself?
   One specific job that comes to mind is pipeline.py. It's a crucial tool for processing proposals, but in its current form, it's only running once an hour. This means that for 59 minutes out of every hour, the machine is doing nothing useful while it waits for the next run. I'd say this waste costs around 11% of the available time.

3. What is the minimum set of processes for the fleet to do its actual job?
   The actual job here is moving Marsita's projects forward. A minimal process set would include at least one job that runs every minute, processing proposals and applying them to the relevant projects. This job should have a short interval (maybe 1-2 minutes) to ensure it doesn't waste too much time waiting for other jobs to finish.

4. What should the default interval be for anything new, and what has to be true before something runs more often than hourly?
   The default interval for any new job or process should be at least 30 minutes. For a job to run more frequently than hourly, it needs to produce significant value (e.g., processing proposals, making progress on projects) within that shorter time frame. This ensures the fleet is focused on moving forward, rather than just running unnecessary jobs.