2/12/2026 at 3:10:19 AM
by nycdatasci
2/12/2026 at 6:36:24 AM
I've tried to replicate the real world, so I give my agents backstories, triabl loyalties, and deep-seated character flaws. my agents try to dominate and manipulate each other. they make sure to take credit for every line code. I have manager agents that promote based on shared hobbies. so far it's going well.by drsalt
2/12/2026 at 11:58:08 PM
Absolutely https://github.com/ra0x3/systemg/tree/main/examples/orchestr...Things are time bound by instruction creation - at some point you still need a human to dictate the instructions that the orchestrated agents use. From there I've found that -- (1) derive a goal from the instructions (2) break that goal into tasks (3) order those tasks into a DAG (5) spawn the agents to work via the DAG -- seems to be doing everything I want it to do.
by ra0x3
2/12/2026 at 2:21:37 PM
I think the key to really "unlock" these things is to separate as much as possible from where it can do harm (no important credentials, no shared identify, etc) then just give it its own home folder, its own credentials and let it rip.You could technically instruct the agent to pilot local ollama and launch minions for "dumb" tasks in parallel, but i don't know if it could break out and modify the file system this way... but then, if it resides say in its own VPS, the damage will be contained.
by dormento
2/12/2026 at 7:14:43 AM
I'm working on something like this. Specifically, I'm doing recursive self-improvement via autocatalysis -but predominantly in writing/research / search tasks. It's very early, but shows some very interesting signs.The purely code part you described is a bit of an "extra steps" -you can just... vscode open target repo, "claude what does this do, how does it do it, spec it out for me" then paste into claude code for your repo "okay claude implement this". This sidesteps the security issue, the deadly trifecta, and the accumulation of unused cruft.
by sdrinf
2/12/2026 at 8:45:21 AM
I do a fun orchestration system for long running loops on exe.dev (small write up docs.coey.dev) and I feel like I have super powers.Self healing, I try two ways:
1) use a memory tool to store learnings for next iteration (Deja.coey.dev) and have the loop system instructions tell how to use it. One orchestrator, and sequential worker agents who run til their context is full and then hand off to the next run with learnings
2) the agent Shelley on exe can search past convos when promoted too for continuation.
I’ve been doing this with great success just “falling” into the implementation after proper guardrails are placed
by acoyfellow
2/12/2026 at 10:31:33 AM
Any released projects yet?by haute_cuisine
2/12/2026 at 10:51:18 AM
I release stuff all the time, so yes I suppose? Not trying to spam but you can find a mix of open source, b2b saas i own, and client saas I manage on my personal website.by acoyfellow
2/12/2026 at 11:06:13 AM
I checked your website, it's quite impressive to release 1-3 opensource projects per day.by haute_cuisine
2/12/2026 at 2:26:16 PM
Thank you - take each one with a grain of salt, and heavily ask your AI agent (or your brain) to vet everything. I'm honestly newer to open source, I've been lurking at my desk alone for too longby acoyfellow
2/12/2026 at 1:49:34 PM
I’ve experimented with semi-recursive loops where agents review outputs and refine prompts or workflows, but fully autonomous self-improvement still feels fragile. Most gains come from structured feedback and constraints rather than open-ended recursion. Stability becomes the real challenge.by allinonetools_
2/13/2026 at 8:12:49 AM
I mean you just described OpenClaw. The problem is LLMs suck at "learning" things not trained into them. They will always make mistakes, if the "learning" is just RAG (stuffing new data into the prompt/context, or looking it up in a vector DB and stuffing that into prompt/context).Your agent will basically never get good at learning. The only ways to get closer to that are 1) fine-tuning (expensive, slow and inaccurate), and 2) reinforcement learning (slow and inaccurate). So you can't just build an agent that automatically, incrementally gets better, without waiting for 10+ years for the process to iterate sufficiently. (ask AI researchers, this has been the case for a long time)
However, you can build an agent that can iterate on one specific problem so much that it becomes amazingly good at it, and then do that on another specific problem, and another, until you have a whole bunch of mini-experts. Then you can use those together. To get better than that... use a new model, new prompting techniques, etc.
by 0xbadcafebee
2/12/2026 at 3:12:10 AM
To head off the semantics debate: I don't mean a model rewriting its own source code. I'm asking about 'process recursion'—systems that analyze completed work to autonomously generate new agents or heuristics for future tasks.by nycdatasci
2/12/2026 at 3:21:06 AM
-ish. I often keep md files around and after a successful task. I ask Codex to write the important bits down. Then, when I come around to a similar task in the future, I have it start at the md file. It's like context that grows and is very localized. It helps when I'm going through multiple repos at multiple levels.by jvalencia
2/12/2026 at 6:39:08 AM
I’m also doing similar with fairly decent results. AGENTS.md grows after each session that resulted in worthwhile knowledge that future sessions can take advantage of. At some point I assume it will be too big, then it’s back to the Stone Age for the new agents, in order to release some context for the actual work.by marc_g