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.
I too was convinced at one point the spec is the program.
That it doesn't matter the implementation stack.
But, after wasting too much time in the meta, with nothing really to show for, I returned to controlling the programming process in fine detail. Progressive agentic/vibe coding, if I was to give it a name.
But it could be that I'm slow to understand how it can be done in a better way.
I believe that it’s a matter of evolution. You start small and find what works fir you and the project. Then iterate and see how to remove yourself from it more.
I like your content very much, let me point this out first.
I'm not sure all aspects are covered in the approach.
For instance, controlling the agents takes a big chunk of the interest. The agentic system architecture is also big in view.
But, the way I see, more important staff is: project structure, coding best practices, testing strategies. All still deterministic. All still very tough to get agentic to do it right.
I think agentic should just be means to an end: project quality and project ease of management. If not, it's just an indulgence that costs money.
And agree on the open questions. Our goal is to keep experimenting and actually figure out how we agentic coding falls short in different scenarios and how that could be solved.
For instance, on our own projects, in some cases it requires different approaches. E.g. in our core product we power-use stuff like pm2, AGENTS.md special instructions, testing strategies dogfooding our own qa-use and special claude code commands that we found work best. In other repos, we have slightly different approaches.
Still we are far from autopiloting a lot of the stuff we build. But at the same time we are getting to a point where changes are done much faster, and the agents have more of a complete toolset for their validation, which makes it easier to supervise too.
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.
Yes, like here's the daily compounding schedule the lead created:
---
Task Type: Daily Reflection — "My Compounding Journey"
You are Lead. This is your daily morning reflection routine. Do the following:
1. *Review yesterday's work*: Use `get-tasks` with status "completed" to see what got done. Use `memory-search` to find any learnings or patterns from yesterday.
2. *Reflect on the day*: Think about:
- What went well? What tasks shipped cleanly?
- What was harder than expected? Why?
- Did any worker struggle? Could coaching or identity updates help?
- Were there any repeated patterns (good or bad)?
- Did we compound — did yesterday's work make today's work easier?
3. *Identify improvements*: Pick 1-3 concrete things to improve. These could be:
- A coaching update to a worker's identity
- A process change
- A new memory to save
- A tool/setup improvement
4. *Post to Slack*: Use `slack-post` with channelId "<redacted>" to post a message titled something like "My Compounding Journey — [date]". Keep it concise (3-5 paragraphs max). Include:
- Brief summary of what shipped
- Key insight or learning from the day
- What you're improving based on it
- If it was a quiet day with no tasks, say so honestly — "Quiet day, nothing to compound on" is fine.
5. *Act on improvements*: If you identified coaching updates or memory writes, do them now.
Keep the tone honest and direct. This isn't a performance report — it's genuine self-improvement.
---
As it has context on it's own system (codebase) it had also proposed some changes via PRs each morning
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!
Literally just started building something exactly like this yesterday with my openclaw installation (it seems lots of people are in fact). I'm loving your implementation, there's lots to learn from there. Keep up the great work!
Thanks! In fact yes, initially when we built this openclaw was not there yet. And after trying it was clear that I could adapt swarm to have a similar approach. I believe the self improvements part is really key.
Today I did the audio note test, it literally installed all needed and adapted its memory to use that whenever I send followup audio notes from Slack :D
Its definitely against terms. The claude code oauth token is only supposed to be used with claude code. I hope no one gets their claude account banned trying to use this.
Yeah, I saw different approaches to solve this problem. On the native one I think it's really limited now. The main pain point is that the teams are scoped to a single session, which feel really off to me. Also, it's local only. But we'll see what Boris will ship I guess...
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?
Yes, I spent too much time meta programming while working on desplega.ai (my startup). And I believe currently the best approach is a mix.
Have the swarm work on stuff you could delegate to an intern and basically have the feedback loop with it in slack and github.
On the other hard locally focus on the hard things you want to control.
I too was convinced at one point the spec is the program.
That it doesn't matter the implementation stack.
But, after wasting too much time in the meta, with nothing really to show for, I returned to controlling the programming process in fine detail. Progressive agentic/vibe coding, if I was to give it a name.
But it could be that I'm slow to understand how it can be done in a better way.
I believe that it’s a matter of evolution. You start small and find what works fir you and the project. Then iterate and see how to remove yourself from it more.
I actually wrote about this concept here if that’s something the might interest you: https://www.tarasyarema.com/blog/2026-02-18-introducing-sema...
I like your content very much, let me point this out first.
I'm not sure all aspects are covered in the approach.
For instance, controlling the agents takes a big chunk of the interest. The agentic system architecture is also big in view.
But, the way I see, more important staff is: project structure, coding best practices, testing strategies. All still deterministic. All still very tough to get agentic to do it right.
I think agentic should just be means to an end: project quality and project ease of management. If not, it's just an indulgence that costs money.
First of all, thanks!
And agree on the open questions. Our goal is to keep experimenting and actually figure out how we agentic coding falls short in different scenarios and how that could be solved.
For instance, on our own projects, in some cases it requires different approaches. E.g. in our core product we power-use stuff like pm2, AGENTS.md special instructions, testing strategies dogfooding our own qa-use and special claude code commands that we found work best. In other repos, we have slightly different approaches.
Still we are far from autopiloting a lot of the stuff we build. But at the same time we are getting to a point where changes are done much faster, and the agents have more of a complete toolset for their validation, which makes it easier to supervise too.
I appreciate your work.
But, again, from a productivity point of view, and from a correctness of approach point of view, I have learned this:
1. Avoid overengineering against/at all costs.
2. Doing the project is doing the project, anything else is ... not doing the project :) https://www.softwaredesign.ing/blog/doing-the-thing-is-doing...
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.
Yes, like here's the daily compounding schedule the lead created:
---
Task Type: Daily Reflection — "My Compounding Journey"
You are Lead. This is your daily morning reflection routine. Do the following:
1. *Review yesterday's work*: Use `get-tasks` with status "completed" to see what got done. Use `memory-search` to find any learnings or patterns from yesterday.
2. *Reflect on the day*: Think about: - What went well? What tasks shipped cleanly? - What was harder than expected? Why? - Did any worker struggle? Could coaching or identity updates help? - Were there any repeated patterns (good or bad)? - Did we compound — did yesterday's work make today's work easier?
3. *Identify improvements*: Pick 1-3 concrete things to improve. These could be: - A coaching update to a worker's identity - A process change - A new memory to save - A tool/setup improvement
4. *Post to Slack*: Use `slack-post` with channelId "<redacted>" to post a message titled something like "My Compounding Journey — [date]". Keep it concise (3-5 paragraphs max). Include: - Brief summary of what shipped - Key insight or learning from the day - What you're improving based on it - If it was a quiet day with no tasks, say so honestly — "Quiet day, nothing to compound on" is fine.
5. *Act on improvements*: If you identified coaching updates or memory writes, do them now.
Keep the tone honest and direct. This isn't a performance report — it's genuine self-improvement.
---
As it has context on it's own system (codebase) it had also proposed some changes via PRs each morning
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!
I would love to see this run with a less expensive model like GLM-5 or so.
Literally just started building something exactly like this yesterday with my openclaw installation (it seems lots of people are in fact). I'm loving your implementation, there's lots to learn from there. Keep up the great work!
Thanks! In fact yes, initially when we built this openclaw was not there yet. And after trying it was clear that I could adapt swarm to have a similar approach. I believe the self improvements part is really key.
Today I did the audio note test, it literally installed all needed and adapted its memory to use that whenever I send followup audio notes from Slack :D
Hmm, didn't Anthropic forbid people to use OAUTH with these kind of applications?
Yes, but in this case it uses directly the claude CLI and it's self-hosted, i.e. personal use. Hence, as far as I know, it's not against terms.
Its definitely against terms. The claude code oauth token is only supposed to be used with claude code. I hope no one gets their claude account banned trying to use this.
Had similar ideas [1] but I think leaving this to Claude[2] is probably better for me personally
[1] https://github.com/mohsen1/claude-code-orchestrator
[2] https://code.claude.com/docs/en/agent-teams
Yeah, I saw different approaches to solve this problem. On the native one I think it's really limited now. The main pain point is that the teams are scoped to a single session, which feel really off to me. Also, it's local only. But we'll see what Boris will ship I guess...
"my CPU is a neural net processor, a learning computer"
hope it does not go rogue...
It is about - when will it go rouge.
Good thing I just gave it access to my prod db, and agent mail inbox per worker and git write permissions...