ztzoff.tech

Jun 24, 2026

Optimizing each agent doesn't optimize the system

In a multi-agent system, a locally perfect prompt can make the whole worse. The fix is to optimize prompts for the handoff, not the agent — the same reason these systems are hard to debug.

A team tunes each agent in their pipeline until it's individually excellent. The researcher agent retrieves better. The writer agent produces cleaner prose. The checker agent catches more errors. Every change is measured, and every change is an improvement. They ship — and the system's end-to-end success rate goes down. Nobody can say which improvement caused the regression, because each one, scored on its own, made things better.

That isn't a paradox. It's what happens when you optimize the parts of a system whose value lives in how they connect.

The local win that isn't

In a single-prompt task, "make this prompt better" is well defined: better output on the eval. In a multi-agent system, an agent's output isn't the product — it's the input to the next agent. A prompt that makes the researcher's output more thorough can bury the one field the writer actually needed under three paragraphs of context. You improved the researcher's score and degraded the handoff. The system got worse by every agent getting better.

Recent work names this directly. MASPO frames it as the misalignment between local agent objectives and holistic system goals, and its fix is to stop scoring prompts in isolation: each prompt is evaluated by its capacity to facilitate downstream success for the agents that consume it — joint optimization across the whole system, not agent-by-agent tuning. MAPRO recasts the same problem as inference over the entire agent graph rather than a stack of independent searches. Different math, identical premise: the prompt's job is the handoff, not its own output.

This is the debugging problem in disguise

If that sounds familiar, it should. It's the same property that makes multi-agent systems hard to debug — the failures live in the space between the agents, not inside any one of them. A flat, per-agent view — a log, or a per-agent eval score — gives you fifteen true statements that don't add up to the system's behavior.

The wins live in the same place as the failures. Which means the corollary is unavoidable: if you can't see the handoff, you can't optimize it. You need the trace of the whole trajectory, not a scorecard per node.

What this means for how you build

  • Evaluate the system end to end. The blocking eval is on task success, the one that's allowed to stop a release — not on component quality. A higher per-agent score that lowers end-to-end success is a regression, full stop.
  • Treat one agent's prompt change as a system change. The blast radius is the graph, not the node. Re-run the system eval, because a local edit can break a downstream assumption you never wrote down.
  • Be skeptical of "we optimized the prompts." Ask what was measured. Agent-by-agent tuning that never scored the handoff is optimizing seams into existence.

The unit of quality in an agent system is the trajectory, not the step. Optimize the step and you can sharpen a knife while pointing it the wrong way. Optimize the trajectory — score every prompt by whether it sets up the next agent to succeed — and the improvements finally compose instead of cancelling out.

Book a discovery call