The Hidden Architecture Making AI Agents Actually

The dinner party analogy is tired, but IBM engineers Katie McDonald and Brianne Zavala use it anyway in their recent explainer on agentic AI systems. One cooks from scratch. The other orders takeout. Both end up with a meal.

The metaphor works not because it's clever, but because it surfaces the actual question teams face when implementing AI agents: build custom components, integrate pre-built ones, or mix both approaches? What McDonald and Zavala spend most of their six-minute video explaining, though, isn't the choice itself—it's the infrastructure layer that makes any choice viable.

That layer is orchestration. And if you're not thinking about it, your agents are probably just expensive chatbots.

What Agentic AI Actually Means

First, definitions. "When we talk about agentic AI, we mean systems that plan, act, use tools, make decisions, and move tasks forward across your stack, not just generate text," McDonald explains.

This matters because the term "AI agent" has become marketing slush. A chatbot that can query a database isn't necessarily agentic. A system that can break down a complex request, route subtasks to appropriate tools, manage handoffs between different models, and coordinate outputs across your infrastructure—that's agentic.

The distinction isn't academic. It determines whether you're automating discrete tasks or enabling genuine workflow automation. One saves minutes. The other potentially restructures how work gets done.

The Three Paths

McDonald's team leans toward building custom. "You want to build when your workflows are specialized, you want deep control, or you're integrating tools that pre-built patterns just simply cannot handle," she says.

Building means defining everything: planning logic, tooling interfaces, guardrails, evaluation criteria. It requires sustained engineering capacity and long-term ownership. The questions to ask: Is this workflow truly unique to your business? Do you have engineers who can build and maintain it? Can you accept a longer ramp-up before seeing value?

Zavala prefers reusing pre-built components. "This gives you working patterns that you can work with quickly," she notes. But here's where the video gets more interesting than most vendor content: they acknowledge that reuse still requires engineering. You're integrating with data sources, aligning identity models, fitting components into your orchestration layer.

The questions shift: Does a pre-built component cover most of what you need? Is its behavior predictable enough? Does it fit your governance model?

Most organizations will land somewhere between these poles—the hybrid approach. Custom logic where you need differentiation, off-the-shelf components where commodity solutions work fine.

Why Orchestration Is the Actual Story

Here's what makes this video more useful than typical build-versus-buy content: McDonald and Zavala keep returning to orchestration regardless of which path you choose.

The orchestration layer, as they describe it, "manages task routing, applies policies, enforces identity, handles tool invocation, and coordinates handoffs between the agents and the systems. It is the timing, the sequencing, and the flow."

Without orchestration, even good components become isolated point solutions. You end up with what one of them calls "boxes operating independently"—individual agents that can't work together, can't share context, can't hand off tasks cleanly.

The orchestration layer holds shared prompts, governance rules, tooling standards, routing logic, and evaluation methods. Critically, it lets you swap out models or tools without breaking downstream experiences. This is less sexy than talking about agent capabilities, but it's what determines whether your agentic system is maintainable or becomes technical debt.

"One control plane across build, reuse, and hybrid. Consistent governance, consistent performance, and consistent safety," Zavala summarizes.

The Security Question Nobody Wants to Answer

Buried in the middle of the video is a point that deserves more attention: "As you're integrating tools, it's important to always think about that security side of the solution around that orchestration. You know, what guard rails and monitoring are you going to put in place to make sure that system is operating as you would expect?"

This is where enterprise AI implementations often faceplant. An agent that can invoke tools, access data sources, and make decisions across systems is also an agent that can make expensive mistakes or expose sensitive information. The orchestration layer is where you enforce who can access what, which actions require approval, what guardrails constrain behavior.

The video doesn't drill into specifics here—this is IBM marketing content, not a security whitepaper—but the question matters more as these systems move from pilots to production. A chatbot that occasionally hallucinates is annoying. An agentic system that routes customer data to the wrong endpoint or auto-approves transactions outside policy parameters is a compliance incident.

The Checklist That Actually Helps

Their four-step process is basic but grounded: List your use cases. Determine your approach (build, reuse, or hybrid). Establish your orchestration layer. Pilot and measure.

The order matters. Too many teams start with technology selection before clarifying what problems they're solving. Others pilot without establishing orchestration, then struggle to scale because they've built point solutions that can't coordinate.

What the checklist doesn't address: how to think about vendor lock-in when choosing orchestration platforms, or how to evaluate whether pre-built components are actually solving the problems they claim to solve, or what "measure" means when your agentic system's value is diffuse across multiple workflows.

Those questions probably exceed the scope of a six-minute explainer video. But they're the questions that determine whether your agentic AI investment becomes genuinely useful infrastructure or just another layer of complexity.

Underneath the Abstraction

The dinner party metaphor returns at the end. One orders takeout. One bakes dessert. "But the meal only works when the timing and coordination come together. And that's orchestration."

What makes this framing work—barely—is that it acknowledges coordination as distinct from component quality. You can have excellent individual dishes that don't combine into a coherent meal. You can have capable AI agents that don't combine into a coherent system.

The real question isn't whether to build or buy. It's whether you're building the connective tissue that makes components—however sourced—work as a system. Most organizations focus on agent capabilities while treating orchestration as plumbing. Then they wonder why their agentic AI projects feel fragile and hard to extend.

McDonald and Zavala's contribution here isn't novel architecture thinking. It's making explicit what often stays implicit: the infrastructure layer that nobody wants to build but everyone needs if they want agents to do more than party tricks.

—Marcus Chen-Ramirez, Senior Technology Correspondent