L4Before You Add Another Agent, Decide Who Has the Final Say

On an e-commerce platform, the copy for a sale-event product page usually has to clear several gates before it goes live. Marketing wants the selling points to hit harder. Legal cuts every absolute or risky claim. Customer service worries the page promises things nobody can deliver. And the team running each overseas storefront needs a version that works locally. Every side has a point, and they often pull against each other.

The last post ended on exactly this: hand a task like this to a single L3 Agent, and it has to speak for every side at once inside one prompt. The conflict gets absorbed quietly, and you never see who gave way.

L3 gets one thing done. L4 has to answer a different question: when several things conflict, who has the final say, and when do you stop? If you can’t answer those two questions, adding more Agents only makes the disagreement harder to see.

When you need L4

You need L4 only when a task holds several conflicting goals that need different views to check each other, and someone has to make the final call. Calling tools in parallel, or across several systems, is something L3 can do too.

Draw that line strictly, because L4 is expensive. Every extra Agent means more model calls, more waiting, and one more place to look when something goes wrong. So I climb one level at a time. Routing intent goes to L2. Tasks with a clear goal, like pulling data and writing a report, go to L3. Only the kind of conflict above earns L4.

Hold the opening example up to that line. Marketing, Legal and Customer service pull in different directions, and in the end someone has to decide: that’s L4 work. If all you need is to pull figures from three systems into one report, L3 is enough.

Split by concern, not by job title

Many teams start L4 by mirroring the org chart: a Sales Agent, a Marketing Agent, a Finance Agent. It feels natural. What usually happens is that each Agent handles a bit of everything and turns into a smaller L3, and what they are actually arguing about gets harder to tell.

A sturdier split gives each Agent one goal to speak for. On the product page, instead of a “copywriting Agent” that handles everything, you have two: one that only checks compliance, reading every sentence against advertising rules and the platform’s policies, and one that only checks whether the page’s promises can be kept (delivery times, price protection, returns) by after-sales and the warehouse. Stocking works the same way. Procurement doesn’t need a “buyer Agent”; it needs one Agent watching inventory levels and another watching cash flow. Those two goals conflict by nature, and that conflict is exactly the information a person should see.

Job titles are how an organization divides labor, and one job often holds several goals at once. What actually pulls against each other in a decision is those goals.

Who decides, and when to stop

Several Agents each saying their piece is not yet a system. Before they can reach a conclusion reliably, you need to settle at least three things.

First, everyone edits the same thing. The Agents don’t hand work over by relaying chat history to each other; they all work from one shared file: the current draft of the copy, each side’s comments, and what changed this round. Decide in advance who can change which part. Otherwise anyone can change anything, and soon no one knows which version is right. Keep a record of every round, too, so you can go back to the last stable version when something breaks.¹

Second, there is a reviewer that doesn’t write. Its only job is to judge whether this version passes. The reviewer doesn’t have to be a model; often the best reviewer is a fixed set of rules, such as a list of banned advertising terms, the platform’s rules, or the after-sales policy. Whatever rules can judge, don’t leave to a model’s guess.

Third, decide in advance when to stop. The easiest trap for a group of Agents is endless back-and-forth: you change mine, I change it back. Three stopping rules are common: when the round limit is reached, move to a summary; when each side’s changes shrink below a threshold, call it agreement; when a key trade-off comes up, hand it straight to a person.

graph TD
  A[A task: copy for a sale-event product page] --> B{Orchestrator}
  B --> C[View A: Marketing]
  B --> D[View B: Can we keep the promise]
  B --> E[View C: Compliance]
  C <--> F[Shared working file]
  D <--> F
  E <--> F
  F --> G[Evaluator]
  G -- Not passed --> B
  G -- Passed, or a trade-off --> H[A person decides]

Let people see the pull

An L4 interface shouldn’t just hand over an answer. Users need to see how the sides pulled against each other, for example: “Compliance removed ‘lowest price anywhere’ from the title under the platform’s rules; Marketing disagreed and offered a rewrite.” People can only make the call when they can see the reasons.

Another useful control is letting users adjust how much weight each side carries: compliance first this quarter, efficiency first the next. It doesn’t change often, but each change is a real business decision.

Three common failures

These three names are my own; the literature has no single term for them.

• Resonant hallucination: A draws a conclusion from a wrong assumption, B builds on A’s output, and you end up with a conclusion that is coherent, highly specific and completely wrong. Because the Agents back each other up, the error looks more credible, not less.
• Compromise consensus: to balance conflicting demands, the system produces a conclusion nobody objects to and nobody can act on. The conflict wasn’t decided; it was smoothed over.
• State drift: as the rounds add up, the original goal gets buried under back-and-forth over details, and the final output wanders off topic. It roughly matches “task derailment” in MAST, a taxonomy of multi-agent failures.²

What to build it with

As of October 2026, LangGraph and CrewAI are common frameworks for building multi-agent systems.³ Microsoft’s AutoGen has been archived and is no longer maintained; for new projects, Microsoft recommends Microsoft Agent Framework.⁴

Frameworks change fast. Get the three things above clear first: one shared file, one reviewer, one set of stopping rules. Then changing frameworks means much less to redo.

Closing

Back to the product page from the start. Marketing wants it to hit hard, Legal wants it safe, Customer service wants every promise kept. L4 won’t make that pull go away for you. What it can do is put the pull on the table, make every side’s reasons visible, and leave the final call to a person.

The next post, the last in the series, is about evaluation: however fast agents change, first ask what problem you’re solving.