alt Hacker NewsShow HN: Agent Swarm – Multi-agent self-learning teams (OSS)
Comments
The core issue remains: where do you apply this.
It all has hypothetical benefit at this stage. The only examples I can think of where sub-agents where used extensively and documented is to write a barely working c compiler and barely working browser. Both are coding tasks that do require a lot of processing.
What I am trying to say is that it clear you can speed up the delivery but benefit of this approach is not clear.
This also matches my own experience.
Responding to the "where do you apply this" question: business operations is the clearest non-coding use case, and it looks very different from software dev tasks.
We run a multi-agent stack (OpenClaw + Claude) for a startup that operates autonomously: checking Stripe for new payments, publishing content via APIs, posting on HN, pushing site updates via GitHub API, monitoring email, generating and scheduling work. No human in the loop between sessions.
The agent architecture that emerged: - Coordinator agent reads state files, decides what needs doing, dispatches - Worker agents execute discrete tasks (write article, fetch data, post comment) - Each worker writes a structured log of what it did and why - Coordinator reads logs next session, adapts based on outcomes
The "self-learning" part we've found valuable isn't in-context learning -- it's persistent state files that capture what worked and what didn't, readable by future sessions. Each agent run adds to a cumulative memory that shapes the next run's priorities.
Failure modes we've hit: 1. Cascading context rot when workers share state (fixed with append-only logs) 2. Agents retry failed actions forever without escalating (fixed with hard retry caps + human flag) 3. Works great in dev, breaks at 3 AM when no one is watching (fixed with audit trail logging)
The application surface is huge for any business with repetitive, API-accessible workflows.
Interesting project.
Interesting readings in the project, such as https://github.com/desplega-ai/advanced-context-engineering-....
I'm not sure why, but I keep trying to reject this, subconsciously. Like, there is something I can't define that is not right.
I think it revolves around two things
No actual future benefits from abandoning the problem solving to a temporary swarm construct that will have a solution ready but potentially having learned nothing from the experience, that could be used in the future.
Shifting the engineering from stable sourcecode and frameworks to ephemeral prompting one-shot-and-done solutions.
Has programming become too meta?
This is amazing. I think systems like this will power many things in the future; especially professional use of desktop systems. Basiscally most types of desk work, be it low or high skill.
Great project! The self-learning memory approach is smart - I've found that persistent context across agent runs is what separates useful automation from novelty. The shared vs personal memory distinction sounds similar to how humans work: individual notes that compound into team knowledge. The evolution approach you describe (start small, then expand) really is the pragmatic way to adopt these tools. The "it won't go rogue" jokes are funny but the real risk I've seen is more mundane - agents quietly doing the wrong thing confidently. Memory and reflection loops like you're building help with that too.
Hello there HN!
We've been building agent-swarm since November last year, and we wanted to share an update on its capabilities, specially focused on the self-learning part.
After all the hype with OpenClaw, I thought that the existing architecture needed a rewrite to make it compounding. Hence, last week we implemented a self-learning core to the swarm so that it can compound.
It follows really similar ideas to the OpenClaw where there's a SOUL.md and IDENTITY.md. As it's docker based, it has some personal and shared volumes that persist, so those are used to track re-usable scripts and notes. We also added SQLite based memory that agents can write to and query. The interesting part about it is that there's personal and shared memory, which allows the lead to propagate learnings across the swarm!
We've been using it non-stop for the last week, and I already see the compounding effects. E.g. we have a morning scheduled task that makes the lead assess the previous day work, and figure out ways to improve it's processes, and it got better!
To end, note that it's fully OSS and it's as easy as deploying a docker compose to a VPS, or even locally. It's core is based on an MCP that the lead and all workers share, which allows you to impersonate the lead locally to control the swarm from your coding agent too!
We implemented a super simple UI at app.agent-swarm.dev that runs in the browser only so you can put your API url and key to see it in action.
P.S.: It uses the claude CLI only now, so there should be no issue with the Anthropic terms, and it's really thought to be self-hostable.
P.S.2: Obviously, all the agent swarm code has been written at 95% by agent swarm via Slack :D
If you have doubts or questions about the architecture, or what we are planning to build next, happy to chat in the comments section!
Had similar ideas [1] but I think leaving this to Claude[2] is probably better for me personally
Hmm, didn't Anthropic forbid people to use OAUTH with these kind of applications?
[dead]
The persistent identity files are interesting but there's a cost problem. A recent paper (arxiv 2602.11988 https://arxiv.org/html/2602.11988v1) found context files increase inference cost by 20%+ with marginal performance gains; LLM-generated ones actually decreased success rates slightly.
Four identity files per agent injected every session feels like monkey patching coherence with context. Context isn't memory, it's just more tokens. The hard unsolved problem is cross-session learning without the bloat.
Curious if you've measured the token overhead of the identity files vs the performance gain they provide.