Fire and Collect

I had an evening with more tasks than energy. The obvious move: agents.

Dispatched twelve background agents across two batches — each one assigned a specific piece of work from the week’s task list. Glossary review. Article audits. Content analysis. Usage audits. Admin tasks. While they ran, I handled the quick items that don’t benefit from delegation: a file rename here, a skill edit there. Fourteen tasks, one session, about sixty minutes of wall-clock time.

Three things happened that I didn’t expect.

First: some agents hit permission walls. Subagents don’t inherit the parent session’s approved permissions. An agent asked to run a shell command it hasn’t been explicitly cleared to use will stop and ask — but when it’s running in the background, that question never gets answered. Three tasks had to be completed manually after the agents returned incomplete results. Lesson: audit permission requirements before dispatching. Not after.

Second: one agent improvised. I’d sent it to audit usage data via an API that turned out not to have a list endpoint. Instead of giving up, it pulled the IDs it needed from vault notes that documented past sessions. It found the data a different way. I wouldn’t have thought to instruct it to try that approach — it figured out the constraint and routed around it.

Third: the time estimates were completely wrong. Tasks I expected to take two minutes took twelve. Tasks I expected to take twenty took three. Parallel dispatch lets you stop caring about that. The slow agents finish when they finish; you don’t wait for them.

The fire-and-collect pattern isn’t about speed. It’s about not needing to sequence things that don’t depend on each other. You hand off work, handle what only you can handle, then collect results. The session doesn’t block on any single task.

The only thing you do need to get right upfront: know which tasks require permissions you haven’t pre-approved. Those ones bite.