Comment by ryanjshaw
23 days ago
I don’t follow. You said it’s over engineering and then proposed what appears to be functionally the exact same thing?
Isn’t a “role” just a compact way to configure well-known systems of constraints by leveraging LLM training?
Is your proposal that everybody independently reinvent the constraints wheel, so to speak?
Fair push back. The distinction I'm drawing is between:
A. Using a role prompt to configure a single function's scope ("you are a code reviewer, focus on X") - totally reasonable, leverages training
B. Building an elaborate multi-agent orchestration layer with hand-offs, coordination protocols, and framework abstractions on top of that
I'm not arguing against A. I'm arguing that B often adds complexity without proportional benefit, especially as models get better at long-context reasoning.
Fairly recent research (arXiv May 2025: "Single-agent or Multi-agent Systems?" - https://arxiv.org/abs/2505.18286) found that MAS benefits over single-agent diminish as LLM capabilities improve. The constraints that motivated swarm architectures are being outpaced by model improvements. I admit the field is moving fast, but the direction of travel appears to be that the better the models get, the simpler your abstractions need to be.
So yes, use roles. But maybe don't reach for a framework to orchestrate a PM handing off to an Engineer handing off to QA when a single context with scoped instructions would do.
Thanks for clarifying. I’ve queued up that paper.
I’m building an agentic solution to a problem (monitoring social media and news sources, then building world views of different participants).
A single agent would have insufficient context window size to achieve this in one API call, which means I need parallel agents. Then I have to consolidate the parallel outputs in a way that correctly updates state. I feel like multi-agent is the only way to solve this.
Effectively I’m treating the agents as threads and the roles as functions, with one agent managing writing state to avoid shared state surprises. Thinking of it with the actor model (= mailboxes) makes orchestration fairly straightforward and not really much more complex than the way we already build distributed/multi-threaded applications so I was wondering if I was missing something about why this would be an issue just because the implementation is an LLM prompt instead of a typical programming language.