Idea: /rm — Resource Manager skill for parallel computation patterns

[kumaakh]

What this is

A reference pattern showing how to build parallel computation products on top of fleet. This is not a feature being added to fleet — it is a library of orchestration patterns (MapReduce, pipeline, scatter-gather, etc.) implemented as a skill, designed to be forked and wired into a real workload.

Fleet members are workers. The RM is the coordinator. Fleet already has all the primitives needed; this skill makes the patterns explicit and reusable so builders don't re-implement the plumbing each time.

The patterns

Pattern	How it works
MapReduce	RM splits a corpus into N shards, dispatches one member per shard (map), collects results and aggregates (reduce)
Divide and Conquer	RM recursively splits a problem until pieces are small enough for one member, combines results bottom-up
Scatter-Gather	RM sends the same question to N members with different inputs; synthesizes all answers into one
Pipeline	Members chained in sequence — output of member A feeds into member B feeds into member C
Ensemble	Same task on multiple members (possibly different models); a judge member picks the best or synthesizes

Reference implementations

Legal contract review (MapReduce)

You have 500 contracts and need a consolidated risk report. RM splits into 10 batches of 50. Each member reads its batch, flags risk clauses with severity scores, returns structured JSON. RM aggregates and sorts by severity. Wall time: roughly the time to review 50 contracts, not 500. Fork point: swap the risk-clause prompt for your document type and extraction schema.

Competitive intelligence (Scatter-Gather)

You want a comparison matrix across 8 competitors. RM assigns one competitor per member. Each extracts pricing, differentiators, weaknesses. RM synthesizes into a single table. Fork point: change the extraction prompt and the list of targets.

Data processing (Pipeline)

Stage 1 fetches raw data from an API. Stage 2 cleans and normalizes. Stage 3 runs analysis. Stage 4 formats the report. Each stage is a fleet member; RM wires the chain and retries failed stages. Fork point: replace each stage's command with your own ETL logic.

Customer review analysis (Divide and Conquer)

10,000 reviews. RM splits recursively until each leaf batch fits a single member's context. Each member summarizes its batch. RM merges summaries up the tree. Fork point: swap the summarization prompt for your extraction goal (sentiment, feature requests, bugs).

High-stakes decision (Ensemble)

Same prompt sent to 3 members, possibly on different models (Claude, Gemini, GPT). A fourth member acts as judge, reviews all three answers, picks the best or writes a synthesis. Fork point: tune the judge prompt and the voting threshold.

What you need to adapt when you fork this

• Shard size — how large is each worker's input? Depends on context window, task complexity, and desired parallelism.
• Failure handling — what happens when a worker fails mid-map? Retry on a different member, skip and flag, or abort?
• Aggregation logic — the reduce/gather step is a prompt; tune it to your output schema.
• Member count — how many parallel workers do you need? Fleet members can be local or remote; scale horizontally by registering more.
• Streaming vs batch — does each pipeline stage wait for the previous to fully complete, or can it start on partial output?

Why fleet is the right substrate

Classical MapReduce needed a cluster. Fleet's version needs only registered members (laptop, VM, cloud instance) and a skill file. The same execute_prompt call that runs a code review runs a contract analysis run a competitor scrape. The RM skill is the thin coordination layer on top — it handles splitting, dispatching, collecting, and combining. Builders get parallelism without infrastructure.