Enterprise AI budgets are shifting from single models to multi step agent systems, and new research suggests a lot of organizations are structuring those systems in ways that actively hurt performance, which has less to do with GPU shortages than with how the work gets broken down in the first place.

Ask ten IT leaders to define agentic architecture and you'll probably get ten different answers, ranging from a chatbot that can take actions on someone's behalf to a whole swarm of specialized bots working in parallel, and the fact that the definitions are all over the place is starting to matter because it means a lot of organizations are making architecture decisions without a shared sense of what they're actually deciding on.

A

The takeaway is pretty simple even if the implications aren't: throwing more agents at a problem isn't really a strategy so much as a bet that depends entirely on whether the work in front of you can actually be split apart.

That's roughly where

Architecture is the system around the model, not the model itself

Thakker thinks the industry's working definition of agentic architecture has drifted too far toward the model itself and not far enough toward everything that has to exist around it for the model to actually be useful in production.

"Agentic architecture is how you organize AI systems that reason, plan, and act over multiple steps, rather than answer in one shot," Thakker said. "It includes the orchestration layer that decomposes a request, the agents that do the work, and the retrieval and grounding that keep answers tied to real data."

What he sees enterprises consistently underweight isn't the reasoning layer or how many agents they've deployed, but whether the system has any real sense of the limits of what it knows.

"The piece we see organizations underweight is dependability," he said. "A system that knows when it's missing information and keeps searching, instead of guessing, is what separates a demo from production. The model matters, but the surrounding system is the architecture."

That lines up pretty closely with a theme running through both the Google Research findings and the commentary that's followed since, which is that the model itself has become table stakes and the real differentiator is everything wrapped around it, from orchestration to retrieval to the judgment calls about when more agents actually help and when they just get in the way.

The instinct to add more agents is usually the first mistake

Ask Thakker whether he sees organizations struggling to define or deploy agentic systems and he doesn't hesitate.

"Yes, and usually in the same place," he said. "They treat 'more agents' as the goal."

He points directly to the Google Research findings as backing up a pattern he's watched play out repeatedly in the field. "Recent Google Research is clarifying here," Thakker said. "Across 180 configurations, multi-agent coordination helped parallelizable work but degraded strictly sequential work, sometimes sharply. The lesson is to match architecture to the shape of the task, not to add agents reflexively."

That parallelizable versus sequential distinction tracks almost exactly with what the researchers themselves flagged as the core failure mode in their study. On workflows like multi step credit application processing, where a mistake or a dropped piece of context early on corrupts everything that comes after it, splitting the work across several agents tends to fragment the reasoning instead of speeding it up. On workflows where the sub tasks genuinely don't depend on each other, coordinated multi agent systems pulled ahead by a wide margin instead.

Thakker's sense of why this matters so much for whether a deployment actually succeeds has less to do with the technology itself and more to do with the order organizations make their decisions in. "Organizations that start from the work they're trying to do, then choose a structure, deploy far more smoothly than those starting from the technology," he said.

So the sequence that seems to work is defining the shape of the task first, choosing an architecture that fits that shape second, and picking a specific model somewhere near the end of that process rather than the beginning.

Is infrastructure really the constraint, or is that a convenient excuse?

The other big source of CIO anxiety around agentic AI is capacity, meaning whether compute, memory, and system design will end up being the wall that programs run into before they can scale. Thakker doesn't wave that concern away, but he also doesn't think it's where most organizations are actually going to get stuck.

"Infrastructure is a real constraint. Compute, memory, and system design all matter," he said. "But for most organizations it isn't the binding one yet. The platforms are maturing quickly."

Instead he keeps coming back to the dependability problem he raised earlier, which is getting an agentic system to produce answers that are grounded in real data and that hold up under scrutiny consistently rather than just in a polished demo. That's an area where managed platforms have started absorbing work that used to fall entirely on internal engineering teams, since Google's Gemini Enterprise Agent Platform now bundles orchestration, retrieval, and grounding as built in capabilities, including agent to agent task delegation and support for connecting agents to an organization's own data, rather than leaving teams to stitch all of that together on their own.

"That's where a managed platform like Google's Gemini Enterprise Agent Platform helps with the heavy lifting, handling orchestration, retrieval, and grounding so teams can focus on fit," Thakker said.

He does think there's a real split between organizations building their agent stack in house and those leaning on managed infrastructure to get there faster. "In-house builders run into raw infrastructure ceilings sooner, since they own the whole stack," Thakker said. "Either way, the harder problem is dependable system design, not capacity."

What this means heading into the next budget cycle

The research and what Thakker is seeing in the field are landing in roughly the same place from two different directions. Google's own team, summarizing their study, put it plainly: multi agent benefits depend critically on task structure rather than team size alone, and effective system design requires matching coordination topology to the actual characteristics of the problem rather than assuming that scaling up agent count delivers uniform benefits no matter what.

For CIOs walking into planning cycles where agentic AI is likely to show up as its own line item, that's probably a more useful filter to apply before signing off on anything than the usual questions about how many agents a proposed system needs or how much compute it will burn through. The better starting question might just be whether the task in front of you actually breaks apart into independent pieces or depends on one continuous thread of reasoning that can't be split without losing something, since everything else that follows, including architecture, staffing, and eventually infrastructure, tends to fall out of the answer to that one question.

This story was distributed as a release by Jon Stojan under HackerNoon’s Business Blogging Program.