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!
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.
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 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.
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.
16 comments
[ 4.2 ms ] story [ 48.1 ms ] threadWe'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!
[1] https://github.com/mohsen1/claude-code-orchestrator
[2] https://code.claude.com/docs/en/agent-teams
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?
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.
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.