After Three Months of Multi-Agent Collaboration, I’ve Identified 5 Pain Points and 2 Takeaways

I’ve been using multi-agent collaboration for quite a while now, and the pros and cons are clear. Below are five pitfalls you can check against your own situation to see if you have similar issues, plus two insights that might give you something to think about.

Pain Point 1: Conflicts Between Agents Become Harder to Merge Over Time

• Launched three agents simultaneously—Product, Backend, and Frontend each working independently.
• After they ran, I found that the Product agent and the Backend agent made different assumptions about the same feature.
• One assumed the user configures the webhook themselves; the other assumed the system manages it uniformly. Neither was wrong, but when merging, you have to pick one.
• The cause isn’t the agent—it’s the requirement. The requirement said “handle webhook,” which was too vague. Each agent filled in its own assumption within its context.

Solution:

• Lock down constraints before launching each agent.
• Not “handle webhook.”
• But “the webhook is configured by the user; the agent only checks if it’s set up and notifies the user to configure it if there’s an issue.”
• Once you exceed three agents, these conflicts increase noticeably. Vague requirements get amplified, and the agents are just surfacing problems earlier.

Pain Point 2: Agents Systematically Skip Edge Cases

• An agent’s goal is to complete a feature, not to figure out when the feature shouldn’t run.
• Ask it to write a detection loop, and the happy path gets done quickly.
• But it won’t proactively think about:
  • What if a colleague is on leave and there’s no commit history?
  • What if a private channel can’t be read?
  • How to handle weekends with no data?

This isn’t an ability issue—it’s that the agent’s design goal makes it look forward, not toward edges.

Solution: Add a dedicated “Edge Cases” section in the requirements.

• Be specific, not generic.
  • “If no commit in the last 24 hours, skip this check and mark it as an empty day.”
  • “If a channel is marked private, skip it and log the reason.”
  • “Messages between 22:00–08:00 local time are not included in the auto report.”
• Don’t write “handle errors properly”—the agent won’t understand that.

Pain Point 3: Self-Review Is No Review at All

• Same model writes the code, same model reviews the code.
• The assumptions and blind spots ignored during writing are still ignored during reviewing.
• I’ve tried multiple rounds; never caught a substantive issue.
• Not because the model is bad—it’s that it won’t challenge its own assumptions.

Solution:

• Spin up a separate review agent,
• tools: Read, Grep,
• Read-only, no write permissions.
• Its only task: find problems in the output. No solutions, no code changes. It doesn’t know your original intent.
• That’s exactly its strength. Any implicit assumption not in the documentation gets flagged.
• It has helped me catch data gaps that weren’t handled, restricted channels that weren’t skipped, and internal messages that almost got auto-sent. After three months, this is the only agent I’ve kept running.

Pain Point 4: Merging Decisions Must Be Made by Humans

• Two agents produce conflicting outputs.
• One leans toward full automation; the other leans toward manual review. Both are right and both can justify their reasoning.
• Agents can list pros and cons—automation saves time but introduces more risk, manual is safer but slower—but choosing one isn’t a technical problem.
• That decision involves what you value more: speed or stability? Coverage or accuracy?

Solution:

• There’s no automation for this. Look at the trade-offs clearly, then choose.
• If two agents conflict, it means the decision point itself involves something that needs weighing. The agents just surfaced it earlier. That’s not a bad thing.

Pain Point 5: Agents Compress Execution, but Expose Harder Things

• In the past, drafting, competitive research, layout adjustments—these took up most of the time.
• By evening, I felt like I’d done a lot.
• Now, an agent finishes all that in an afternoon. By 3 PM, I’m faced with two or three judgment calls, edge-case designs the agent can’t handle, go-to-market strategies, and directional questions.
• These things were always there—just buried under the busywork of execution. Agents compress execution, and the harder stuff gets pushed to you sooner.

Solution:

• Spend the saved time on things agents can’t touch:
  • Merging decisions, product direction, boundary definitions, customer acquisition.
• What agents can do will only get cheaper. What they can’t do is where your time should go.

Two Takeaways

1. The Most Valuable Agent Doesn’t Write Code.

• The read-only review agent is the only one I’ve never throttled down.
• It owes no favor to any other agent, doesn’t care about any goal—it just says, “There’s a problem here.”
• Over a few months, it has blocked more issues than all the coding agents combined.

2. Conflicts Between Agents Are Not a Bug.

• I used to think that agents not sharing context was a limitation.
• Now I realize the reason they diverge is valuable—it reveals parts of the requirements that weren’t spelled out.
• Two agents make different assumptions about the same requirement; go back and fix the requirement, and it won’t happen again. Agents helping you find what you didn’t say clearly is useful in itself.