When Your Agents Disagree (And That’s OK)
September 17
Here’s the thing about working with multiple AI agents: they’re going to disagree with each other. And if you’re like most people, your first instinct is probably to figure out which one is “right” and which one is “wrong.”
Turns out that’s exactly the wrong approach.
Yesterday morning, I was deep in debugging mode with Piper Morgan. Layer 3 intent processing was completely broken — some prompts worked fine, others hung indefinitely. Critical blocker stuff. The kind of issue that stops everything until you fix it.
I deployed two agents to investigate: Claude Code for backend analysis and Cursor for UI validation. Same problem, different perspectives. Within an hour, they’d reached completely opposite conclusions.
Claude Code: “It’s a port conflict! The UI is calling the wrong service. Web proxy is missing the intent endpoint.”
Cursor Agent: “UI is fine! No hanging at all. Error handling works perfectly. Backend is returning proper 500 errors.”
My first thought? One of them is clearly confused.
The beauty of productive disagreement
But here’s what I’ve learned about multi-agent coordination: when two competent agents disagree, they’re usually both right about different pieces of the puzzle.
Claude Code was absolutely correct — there was a port conflict. The web proxy layer was missing the /api/v1/intent endpoint, so UI requests were hitting the wrong service entirely.
Cursor Agent was equally correct — the UI wasn’t hanging. It was displaying proper error messages. The “hanging” I thought I was seeing was actually clean error handling of backend failures.
OK, tell me it’s not hanging because {technoreason} when it’s not responding. OK.
The disagreement wasn’t a bug in my process. It was a “feature.”
Evidence-based correlation
Once again I am reminded that I’ve had this experience with human colleagues. Two developers with wildly different estimates or risk estimates, an optimistic UX researcher and a pessimistic interaction designer, and so on. Those zones of creative tension are often where the best work gets polished into excellence.
What made this work today was the requirement for systematic evidence collection. Both agents had to provide terminal output, browser screenshots, network traces. No assertions without proof. No “trust me, I know what I’m doing.”
When we correlated their findings:
- Code’s timing analysis: Complex prompts took 2.7–3.6 seconds before failing
- Cursor’s browser evidence: Same prompts returned 500 errors in exactly that timeframe
- Code’s architecture discovery: Missing proxy route for intent processing
- Cursor’s network analysis: Requests hitting backend directly instead of proxy
Perfect correlation. Two different diagnostic approaches revealing two layers of the same problem.
When you get confused, listen to the methodology
This is where having a systematic approach pays off. I didn’t have to choose between conflicting reports or waste time figuring out who was “wrong.” The methodology forced both agents to:
- Document their investigation approach
- Provide evidence for every claim
- Update GitHub issues with findings
- Cross-validate each other’s work
By the time we reached the correlation phase, the complete picture was clear. The fix required both perspectives: add the missing proxy endpoint (Code’s discovery) and fix the frontend configuration to use it (insight from Cursor’s network analysis).
What this means for product management
Well, it’s that Rashomon thing again, right?
I keep thinking about this pattern beyond just debugging. How often do we get conflicting reports from different teams and immediately try to figure out who’s “right”?
Sales says the feature is critical for closing deals. Engineering says it’s technically complex and risky. Support says customers are confused by the current implementation. Product marketing says it doesn’t align with positioning.
Maybe they’re all right about different aspects of the same challenge.
The key is having systems that force evidence-based discussion rather than opinion-based arguing. GitHub issues with clear acceptance criteria. User research with actual data. Technical spikes that prove feasibility. Cross-functional validation of assumptions.
The resolution
By 3:53 PM, we had a complete fix. Layer 3 intent processing restored. UI → Proxy → Backend architecture working perfectly. Both agents confirmed the solution with independent validation.
Issue #172 closed. Issue #179 created for the Layer 4 quality issues that were now clearly visible.
The disagreement that initially seemed like a problem turned out to be exactly what we needed. Two agents, two perspectives, one complete solution.
Mind you, this only works if you have methodology that can handle disagreement productively. Otherwise you just get arguments.