// 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.
- Split a long stub transcript into fixed-size chunks.
- Map: same prompt extracts `{ decisions[], owners[] }` per chunk.
- Collect map JSON arrays (no free-text merge yet).
- Reduce: dedupe decisions, union owners, emit one brief.
- Assert map prompts are byte-identical across chunks.
- 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.