Yeah, saw that paper. And I have the following notes on it:
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.
100%. I believe the best thing to do now is find ways to push the limits of what works and what not, which will help find the following limits, and keep going
I use this a lot for multi-tasking, let me explain.
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.
Yah. You are describing basically every youtube I have seen on openclaw use-cases: news digests, morning debriefs, etc. I am sure this is useful but not something that you specifically need sub-agents for.
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.
I mean you can check the closed PRs in the repo, 95% of them were done by the swarm. And a similar pattern is happening for our customer facing products.
I think you focused on the bonus point, rather than the first part (which is the relevant one).
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.
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
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 think this progressive/gentic vide coding would work better if the tools were better and storing the history in a good immutable way, kind of like an email program. I have very valuable sessions where I give the agent a good ephemeral spec, something not sensible to persist in the codebase, but important enough to track it somewhere. Throwing away history is a big no no. Bad GUIs/TUIs discourage from relying on the history. When I close a session, I feel I'm throwing away the history. I keep many terminals open, but eventually have to close them. Tools will get way, way better to facilitate this "general on the frontlines commanding the agents" style of work.
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.
reply