My Agent Was Never Slow. My Tasks Were Serial.

I spent a week trying to make my agent faster. I profiled the model, switched inference backends, cut the context size. It got maybe 15% faster and my day did not change.

Then I looked at where the wall clock actually went, and the answer was embarrassing: the agent was waiting, and I had queued everything one after another.

Where the time actually went

Over a week of instrumented runs, roughly:

• 10% generating tokens
• 45% waiting on something external (a build, a download, a page load, a service restart)
• 25% waiting on me (an approval, a decision, a password)
• 20% re-doing steps that failed because of state

Only the first row is a model problem. I had been optimising the smallest slice and calling the rest "the agent being slow".

The fix was concurrency, not speed

Two things changed the picture:

1. Independent tasks run in parallel. Three tasks that touch different repos and different services do not need to be sequenced. The constraint is not the model, it is whether they share state - and most of the time they do not.
2. Approvals get batched. Instead of stopping at every decision, the agent collects the pending questions with their payloads and asks once. Ten interruptions became one, and the 25% waiting on me mostly disappeared.

The cost is that you now need the pre-flight checks I wrote about earlier, because parallel tasks are exactly where shared state bites you - a port, a lock file, one database.

What I deliberately kept serial

Anything that writes to the same resource. Two agents editing the same branch is not parallelism, it is a merge conflict with extra steps. Same for anything with an approval attached: a queue of approvals that all depend on each other is not a queue, it is a conversation.

The rule I use: parallelise by resource, not by task type. If two tasks touch the same file, port, table or account, they go in the same lane.

The honest result

Same model. Same prompts. Wall time for a day of work dropped by more than a third, almost entirely from removing waits rather than from anything getting faster.

Which is a slightly annoying conclusion if you like optimising models: the biggest speedup I found was in my own scheduling.

If you run more than one agent, how do you decide what can run at the same time? Mine is a hand-written list of resources and I suspect it should be a lock file.