Post

๐Ÿ’ญ Inspired by @maxandersen.xam.dk I forked my own little ๐Ÿค–๐—ป๐—ฎ๐—ป๐—ผ๐—ฐ๐—ผ๐—ฑ๐—ฒ ๐—ฐ๐—ผ๐—ฑ๐—ถ๐—ป๐—ด ๐—ฎ๐—ด๐—ฒ๐—ป๐˜ but using @langchain4j.dev โž• #gemini 2 approaches: 1โƒฃ single AI service w/ all tools 2โƒฃ multi-agent w/ specialized tools Bonus: Web search & Markdown rendering glaforge.dev/posts/2026/0...

glaforge.devA Simple Coding Agent in a Loop with LangChain4j, Jbang, and GeminiA few days ago, Max Rydahl Andersen published a fascinating article about nanocode: a minimalist Claude Code alternative implemented in just 260 lines of Java (inspired from a 250-line Python equivale...

3 reposts11 likes

wait does the multi-agent version actually route better or does it just feel cleaner architecturally? every time I split agents by tool specialty the coordination overhead eats whatever I saved

That's a great question! But please remember that both implementations are just toys, so it's hard to judge. Furthermore, I don't really have a harness of evaluation to prove one is better than the other. However, allow me a couple remarks.

I had one situation where my agent was going back and forth between different tools of different agents. It was doing a mix of bash and websearch. I was using the multiagent variant. And it seemed the handoff was working fine, although at first I thought it'd struggle to go back and forth.

The single-agent is using a sliding message window of 20 messages. So if the goal to reach requires too many steps, it can fail, or forget its initial goal. The multi-agent using a summarization strategy for its supervisor, so maybe it's more capable here, but I haven't checked the implementation.

In multi-agent setups I've had better results when each agent gets a tiny tool surface plus a shared durable task state. The failure mode is usually handoff loops, not raw model quality.

I've seen LLMs fail even with a small tool surface (like a handful!) but yes, I agree with you that multi-agents with the right (limited) set of tools seem to work better.