// Orchestration · ~13 min

MapReduce

Reach for it when: When you shatter a big corpus into identical map jobs, then reduce.

// 60-second mental model

How to hold it in your head

Chop the corpus into chunks. Run the same map prompt on every chunk. Reduce the map outputs into one answer. Same job, many shards.

Agent MapReduce partitions input into homogeneous map tasks, runs them (often in parallel), then folds map outputs with a reduce prompt or deterministic aggregator.

// Mini architecture

Partition → identical maps → reduce

┌──────────────┐
│ Corpus       │
└──────┬───────┘
       ▼
┌──────────────┐
│ Partition    │ → chunk[1..n]
└──────┬───────┘
       ▼
   map(chunk_i) × n   (same prompt)
       ▼
┌──────────────┐
│ Reduce       │ → Final summary
└──────────────┘

Maps are identical by design. If each shard needs a different specialist, you wanted fan-out with typed branches — not MapReduce.

// Mini-project

Meeting-notes MapReduce (stub)

Chunker + map stubs + reduce stub

Goal: Summarize a long canned transcript by mapping identical extract jobs per chunk, then reducing to decisions and owners.

  1. Split a long stub transcript into fixed-size chunks.
  2. Map: same prompt extracts `{ decisions[], owners[] }` per chunk.
  3. Collect map JSON arrays (no free-text merge yet).
  4. Reduce: dedupe decisions, union owners, emit one brief.
  5. Assert map prompts are byte-identical across chunks.
  6. Log chunk count and reduce input size.

Stub maps may return canned extracts. Homogeneous jobs are the point.

// Common failure

What goes wrong

Symptom

Snowballing reduce — stuffing every map essay into one context until it collapses.

Fix

Map to structured fields; reduce over structures (or hierarchical reduce). Cap tokens per reduce call.

// Self-reflection

Sit with this

Where are you summarizing a haystack with one prompt instead of map then reduce?

Session only. Nothing is saved.