Doing Three Things at Once
Ask an agent to check the weather, pull tomorrow’s calendar, and look up a flight status, and there are two ways it can go. It can check the weather, wait for the answer, then check the calendar, wait for that answer, then look up the flight, wait again. Or it can fire all three at once and come back thirty seconds later with everything. Same three answers either way. One route just took three times as long for no reason.
That distinction, one thing after another versus several things at once, sounds like a minor implementation detail. It isn’t. It’s one of the clearer signs of whether an agent actually understands the shape of the task in front of it, or is just working through a checklist one line at a time because that’s the only mode it knows.
Why the slow version happens at all
A chat interface trains a certain rhythm into how people expect AI to work: you ask something, it answers, you ask the next thing. One request, one response, in order. That rhythm makes sense for a conversation. It makes a lot less sense once the “conversation” is actually a set of independent errands with nothing binding them together.
An agent that never breaks out of that rhythm ends up treating every task like a conversation, even when it’s really three unrelated lookups wearing a trench coat. It checks the weather, gets an answer, and only then thinks to check the calendar, as if the calendar result depended on knowing whether it’ll rain. It didn’t. There was never a reason for the second lookup to wait on the first.
The question that actually matters
The right question isn’t “can these run at the same time.” Almost anything can, technically. The right question is whether one step needs something the other step produces. That’s the entire test.
Checking the weather, the calendar, and a flight status: none of them feed each other. The flight status doesn’t change based on what the weather turned out to be. Three independent questions, three independent answers, no reason for any of them to wait in line.
Now compare that to searching for a file and then reading the one that turns up. The read can’t happen until the search finishes, because the read needs the search to say which file it’s even reading. That’s a real dependency, and no amount of batching gets around it. Step two needs step one’s output to exist first.
Mixing these up in either direction is the mistake. Running dependent steps in parallel means guessing at an answer before it exists, like opening a file whose name hasn’t been found yet. Running independent steps one at a time just wastes the time in between for no benefit at all.
What it actually costs to get this wrong
Every tool call is a round trip. Send the request, wait, get the result back. That wait isn’t free, and it doesn’t shrink just because the task felt small. Do that three times in sequence and the person on the other end is sitting through three round trips stacked back to back, watching a task crawl that could have finished in the time of one.
It adds up faster than it looks like it should. A task with eight independent lookups, run one at a time, costs roughly eight times the wait of the same eight run together. Nothing about the answers changes. The only thing that changes is how long someone sat there watching a spinner for information that was ready to hand over the whole time.
What good batching actually looks like
Picture an agent asked to put together a quick briefing: today’s weather, three unread emails, and the top headline in one topic. None of those three things depends on either of the other two. A well-built agent recognizes that up front and sends all three requests in the same breath, then assembles the results into one answer once they’re all back.
Compare that to a research task where the agent first needs to find which document mentions a topic, and only then read that specific document. There, the sequence is real, and forcing it into a single batch would mean reading a document before knowing which one to read. The skill isn’t “always batch” or “always go one at a time.” It’s telling the two situations apart correctly, every time, before doing anything.
The actual signal to watch for
Speed is the visible symptom, but it’s not the real tell. The real tell is whether the agent paused, even briefly, to notice that three things it was about to do have nothing to do with each other, and acted on that instead of just running down a list top to bottom out of habit. That’s a small moment of planning happening before any tool gets touched, and it’s easy to miss because the payoff shows up as “this felt fast” rather than as anything you’d point to directly.
An agent that fires off five unrelated lookups in one turn isn’t just saving you a few seconds. It’s demonstrating that it looked at the shape of the request before acting on it, the same instinct that keeps it from reading a file before finding it or replying to an email before checking whether the thread already exists. Speed is just what that instinct looks like from the outside.
