The Flawed Example That Won’t Die

Every month, without fail, I see another trip-planning demo—usually the same cut-out of hotel, flight, and rental car “agents” chattering away in some slide deck or blog. I’ll admit, it’s starting to grate on me. It’s everywhere because it feels familiar and clever at first glance. But if you’ve built serious agentic systems (or watched enough half-baked ones stagger across the finish line), you notice the pattern. This demo keeps skating by without ever really clarifying what’s hard about building truly intelligent agents.

On the surface, the trip-planning demo sells you a neat trick. Break up the work, hand it off to specialized bots, and look—automatic delegation. But delegation isn’t the same thing as intelligence. It’s just coordination. The whole model relies on a single outcome, your trip itinerary, so orchestrating step-by-step tasks may look dynamic, but it’s not actual cognition.

Here’s where it gets tricky. Booking a hotel and reserving a flight are just tasks—they’re not behaviors that involve weighing tradeoffs or conflicting goals. If you’ve ever tried to build or extend one of these systems, it’s easy to fall into the trap. I know because I’ve conflated the steps with real thinking before, and it burned hours I’ll never get back. The system isn’t deciding between competing values. It’s just following instructions, one after the other.

What Actually Makes a System Agentic?

If a single planner with tool access can solve what you’re working on, you’re not building a multi-agent system. You’re wiring up a tool-using one. With just one planner calling APIs, there’s never any genuine negotiation or internal argument. It’s just a single thread ticking through a checklist. By contrast, real agentic systems exist because tradeoffs emerge. Agents with distinct objectives end up needing to resolve actual conflicts, not just split up chores. If there’s never a decision that requires one part of the system to give something up for another, you’re just dividing labor, not architecting intelligence.

Here’s the key. Structure matters more than stack. It’s tempting to assign every objective or subgoal its own “agent,” but casting each objective as a separate agent builds confusion, not intelligence—objectives aren’t agents, and wrapping them as such misses the point. Intelligence isn’t an accident of wiring. It’s about how those objectives interact, what happens when they pull against each other, and how you resolve that tension. That means having explicit value functions for each agent, and a clear arbitration mechanism to settle disputes—not just chaining tools and calling it a day.

The real signal that you need agents is the presence of genuine conflict. Think budget versus experience: spend less, enjoy less. Or wellness against schedule density: more meetings, less sleep. Or safety versus speed: every time you push for one, you could be sacrificing the other. When user preferences drive multi-objective decisions, tradeoff reasoning in LLMs is supported by fuzzy AHP methods, which prove effective for weighing tradeoffs, moving beyond basic orchestration. If you can feel the tension—if your system has to make choices, not just execute steps—you’re in agentic territory.

I get why people hesitate to define value functions. It feels fuzzy, sometimes like busywork—until a bug crops up that you can’t trace, because nobody wrote down what the tradeoffs were supposed to be. I’ve postponed value definitions and paid for it later in bugs. This is no different from skipping an annual household budget; it’s easy to defer, but the mess compounds. Whether you do it up front or not, you’ll face the cost. Better to be clear before your system surprises you.

Six months ago I thought the main resistance was technical—just tooling or integration. Now, I see it’s almost always conceptual. Most teams have the skills, but they lack the upfront discipline to clarify what’s actually supposed to be in conflict. That shift saves enormous rework.

In a minute I’ll lay out the simple framework for deciding if you need multi-agent structure. But first, let’s ground this in a concrete example so it’s not all theory.

Real Multi-Agent Tradeoffs: When Goals Actually Collide

Picture three agents involved in planning the same trip: a Budget Agent, an Aspirational Agent, and a Wellness Agent. Each is built with its own context, keeps a record of its own decisions, and runs on a different set of priorities. The Budget Agent’s value function is all about keeping costs under control without dipping into reserve funds. The Aspirational Agent acts like the “dream big” voice—chasing bucket-list destinations, rare experiences, or stretch goals. Meanwhile, the Wellness Agent keeps tabs on sleep, stress, and mental load, favoring options that allow rest and avoid burnout.

Structurally, these aren’t just wrappers for the same plan; they embody conflicting objectives in agents. They have actual policy differences and historical memory, and they score options based on criteria that won’t naturally align. If you’ve ever run a multi-agent simulation and seen agents talking past each other, this is why. True agency starts with explicit value functions, not just packaging up steps. The friction isn’t a bug; it’s a feature that forces reasoning.

Take a cooking class decision. Do you splurge for a Michelin-star experience, or hold the line and keep a healthy cash buffer? The Budget Agent will flag the high price, maybe veto it outright unless offset by savings elsewhere. The Aspirational Agent scores this as a lifetime memory, bumping it to the top. The interesting part is how each agent assigns weights—even if the option “passes,” the score it gets depends on each value function, not just a box-tick. You see why slapping “agents” on coordinated tasks isn’t enough; the moment you chase one agent’s criteria, you risk dropping another’s.

Now picture the classic trade: shorten the trip to afford an upgraded stay in a bucket-list property. You know the tension here by feel, even if you’re not tracking it numerically—less time at the destination versus a singular, memorable lodging experience. The Budget Agent checks whether the upgrade’s cost justifies losing an extra day. The Aspirational Agent argues that bucket-list experiences only come around so often, and missing out is a bigger loss than a slightly shorter trip. The Wellness Agent reminds you that fewer days mean potentially tighter schedules—risking higher stress, lower sleep, and, down the road, compromised enjoyment.

I’ve watched teams debate this for hours, only to realize later the system they built never actually forced the issue; without formalized arbitration, you lose the logic to navigate these tradeoffs. When you run these scenarios with temporal anchors (a decision today echoing into tomorrow’s stress levels, or factoring the impact on long-term savings and upcoming medical expenses), it’s clear why “just delegate the decision” always misses deeper conflicts.

Bringing it together, agent arbitration mechanisms aren’t some abstract committee. It’s a cycle that scores each option, adjusts for how each agent’s criteria dominate or recede, and then weights those scores before picking a path. Swing weighting is what lets you dig into how each option performs across criteria, not just tally scores—it’s the critical element for deep trade-off exploration UK Gov. This is what turns a group of specialized “agents” from simple step-takers into a system that can actually reconcile real conflicts. True agency comes from resolving goals, not just completing steps. That’s the line between orchestration and intelligence.

There’s still an open question for me about how much historical memory each agent should carry. In practice, too much context muddies decisions; too little, and you repeat mistakes. I haven’t landed on the right balance yet.

A Checklist for When to Use Multi-Agent LLMs—Structure, Not Orchestration

Arbitration is simple at its core. Each agent evaluates its preferred plan against its value function. The arbitration loop compares those scores, then selects a compromise or triggers negotiation if no clear winner emerges.

Here’s the uncomfortable truth. Complex orchestration isn’t innovation, and it doesn’t mean intelligence. Don’t let FOMO drive your roadmap. I’ve chased shiny stacks and regretted the detour. Clarity in objectives outpaces headline features every time. You only miss out by muddling what your system is supposed to decide, not by resisting the hype.

If you’re building, start by documenting the multi-agent decision criteria—writing down objectives, quantifying value functions, simulating conflicts—and instrumenting every arbitration. Map the structure up front and everything else falls into place.

From Trip Demo to Real Decisions

Let’s snap back to that trip-planning demo. Once you realize there aren’t any actual conflicts—just a sequence of forms to fill out—the whole multi-agent setup collapses into overengineering. In the single vs multi-agent LLM comparison, you don’t need three agents for hotel, flight, and car when a single planner can call each API directly. That “agent sprawl” adds indirection, not intelligence. It’s just more scaffolding to maintain, obscuring what’s actually happening.

But there’s a point where understanding when to use multi-agent LLMs makes agentic design necessary. Say you’re balancing a strict budget, someone’s dream to see a new city, and a hard limit on jet lag. Suddenly, choosing between a budget red-eye and a slightly pricier direct flight isn’t just a task chain—it’s a negotiation. Each part of the system pulls for a different “best” outcome. Here, structuring the agents with real value functions, so they can argue about priorities, finally makes sense.

Clear structure pays you back. When you filter out pointless layering and choose robust architecture, you get systems that explain their own reasoning and don’t surprise you in production. You’ll ship faster, debug more easily, and outputs will behave the way you can actually predict. Not because you played it safe, but because you chose structure over showmanship.

Back to that well-worn demo, there’s a reason it keeps cropping up. It’s easy to build, looks impressive for five minutes, then leaves everyone with the same unanswered questions about actual intelligence. I still see teams deploying it year after year, even as better agentic systems move into view.

So next time you’re architecting, use this bar. Deploy arbitration and multiple agents only when you’re actually resolving conflicts between value functions. If all you need is a workflow runner, let one planner do the job. Make this your rule, and you’ll build sharper, cleaner systems every time.