Hot take: The speed claims don't account for LLM thinking time. It's still slow.

Been playing with CrewAI for a few weeks now, building out some multi-agent workflows. The docs and examples make a big deal about the orchestration speed, the "parallel task execution," and how it's faster than doing things manually.

Here's the thing: that speed is purely about the framework's overhead. Which, fine, it's negligible. But the clock everyone actually cares about—the wall-clock time from "run" to usable output—is dominated by the LLM calls. CrewAI doesn't magically make GPT-4 or Claude think faster. If you have a chain of five agents, each making a reasoning call and then a task call, you're still sitting through ten LLM round-trips. The parallelization helps if tasks are truly independent, but so many workflows are sequential because agent B needs agent A's output.

The real bottleneck isn't the framework's coordination; it's the cumulative "thinking" time. You can see this when you run a crew with verbose on. It flies through the system prompts and the hand-offs, then spends 90% of its runtime waiting for API responses. Until that changes, the speed claims feel a bit like boasting about how quickly you can hand off a baton in a relay race where the runners are all moving at the same fixed, slow jog.

I want to see more discussion about optimizing *that* part. Caching, smarter prompt design to reduce token use, or even batching. Otherwise, we're just polishing the hinges on a very slow door.