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?
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.
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.
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.
Currently at my startup (and in the past when I worked on a bigger company) I have ton of random tasks I need to tackle during the day: from Sentry issues, to analytics on usage, roadmap implementation, customer support. Some of them required deep focus, some of them don't.
Since we have the swarm running for our company my day to day hasn't changed that much in terms of the work I do locally. What it changed is that I can start delegating a lot of my backlog and chores to the swarm. It will do it, iterate, delegate, review, and finally send me a PR or report to check. I check those in the morning and night, and that's it.
I added it to our customer channels, were it has scoped access to the customer setup, and help me debug the issues, and offer a frontline ultra-personalized support.
I see it as a team of interns that just do stuff for you. And good thing: they learn from their mistakes to (hopefully) do not make them again (compounds).
As a random bonus: given the swarm knows what we do and how we work, I just ask them to go out there and figure out any relevant news or posts I should check each morning, and I get a personalized digest to read while I make coffee.
In the context of coding assistants sub-agents are mostly useful to breakdown a more complex tasks in smaller chunks so that refactoring can be done without loosing context. But this is a completely different problem domain that requires burning through a lot of tokens.
In theory I get why it might be useful but what I am trying to say that applications at the moment are limited due to the fact that it is just overkill for most AI interactions.
https://news.ycombinator.com/item?id=46110024
The two "this is an example reply" and "another" comments you made seem like some sort of automation test there.
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.
With a “context file” you’re almost guaranteed to add bloat without useful behavior change because it’s just a pre-set list of things that could be good to know about.
So the results of the study don’t generalize to every text file used for instruction or even most.
1. Agents update those files themselves, but currently with my oversight and guidelines (from the UI you can even see it's contents)
2. Measuring this is extremely hard, if not impossible. One of the goals of the swarm is to help me on random tasks that can span a lot of different pieces, not just implementing a feature.
Before last week, we did not have the memory and identity files. And, from an empirical pov, I can say that the general feel improved a lot. I see that in similar situations it does not perform the same mistakes. Also, what is stored in those files generally is something that the agent CAN NOT find using it's tools (like the paper suggest to avoid) which actually helps.
In any case, the swarm created a research on this topic a few days ago https://github.com/desplega-ai/agent-swarm/pull/86 maybe I'll iterate on it and see what we can get :D
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!
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
funny you found that XD
I think you focused on the bonus point, rather than the first part (which is the relevant one).
https://github.com/desplega-ai/agent-swarm/pulls?q=is%3Apr+i...
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'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.
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...
It sounds like sharpening the knife before cooking is not cooking... But definitely will help make better food...