I love the idea of using a shared event log for coordination. Smart!
I have a Symphony-style[1] factory, which keeps all the context in a single session, but I want to start splitting into stations with separate sessions, and I hadn’t worked out how to do communication between sessions.
Personally, I’ve had "maintenance" and "auditing" sessions successfully drop notes in a my loop’s "inbox" directory (even though it was intended for my use).
I’d say that works as a simple initial approach. Second step is clarifying the "return address" and protocol, but what’s nice is that the message can actually contain those, meaning the protocol itself can evolve seamlessly over time.
I'm going to check this out. I’ve been working on my end-to-end development method and these types of holistic pipelines I think are the future. (or the present!)
I've decided to start with concept capture, which then builds out strategy docs, which feed into specs, etc ... might be time for me to share, but I'm in the process of battle testing myself!
Looking at your post again, I guess I could script a concepting agent to help hone the idea?
Currently looking for a good solution for exactly this. Druid looks very cool and thought-through. Two major blockers for me to use it in my workflow:
- Sandbox-only environment. For certian workflows I may want to run agents directly on my machine.
- No Cursor agent support. Cursor supports ACP, so should in principle plug-in neatly in the existing framework.
Interesting. I like it. Now let's say I currently use the OS process as my primitive for agents, just spawning `claude "foo bar baz"`, and orchestrating this way, using perhaps Unix style of files for intermediate data and piping for transformations. What would you are some good use cases of Druid for someone like me?
The multi-agent coordination problem is real. i've been running claude code solo all week and even that gets messy. Spinning up 5 agents that actually talk to each other cleanly sounds hard to get right. Curious how the environment isolation holds up at scale?
Can you expand on your approach of defining things around state transitions? Are you thinking of it as the state of a task (built, validated, integrated, etc)? Or something else entirely? I'm not sure I followed that part and it seemed rather key.
Yeah, I guess we have sandboxes qwith our various code environemnts, and then we've been developing programs that run agents to do various things, which we iterated on to make them better at the task.
For example, one spawns copies of the env with a PR and runs agents in the dev env to verify by running and demonstrating functionality and then comments on github
another one is just a generic software factory that spawns a bunch of agents to coordinate on some repo, others do a redteaming flow, etc...
yes, you can read the logs, and see full actions, the agents can send messages to each other, and I am also about to make it possible for them to optionally read each other's traces
I love the idea of using a shared event log for coordination. Smart!
I have a Symphony-style[1] factory, which keeps all the context in a single session, but I want to start splitting into stations with separate sessions, and I hadn’t worked out how to do communication between sessions.
[1] https://github.com/openai/symphony
Personally, I’ve had "maintenance" and "auditing" sessions successfully drop notes in a my loop’s "inbox" directory (even though it was intended for my use).
I’d say that works as a simple initial approach. Second step is clarifying the "return address" and protocol, but what’s nice is that the message can actually contain those, meaning the protocol itself can evolve seamlessly over time.
Which can also cause drift, though :/
I'm going to check this out. I’ve been working on my end-to-end development method and these types of holistic pipelines I think are the future. (or the present!)
I've decided to start with concept capture, which then builds out strategy docs, which feed into specs, etc ... might be time for me to share, but I'm in the process of battle testing myself!
Looking at your post again, I guess I could script a concepting agent to help hone the idea?
Currently looking for a good solution for exactly this. Druid looks very cool and thought-through. Two major blockers for me to use it in my workflow:
- Sandbox-only environment. For certian workflows I may want to run agents directly on my machine. - No Cursor agent support. Cursor supports ACP, so should in principle plug-in neatly in the existing framework.
Interesting. I like it. Now let's say I currently use the OS process as my primitive for agents, just spawning `claude "foo bar baz"`, and orchestrating this way, using perhaps Unix style of files for intermediate data and piping for transformations. What would you are some good use cases of Druid for someone like me?
What do you do with those agents? It's useful if you want to iterate on a flow and have more control over the orchestration/environment
The multi-agent coordination problem is real. i've been running claude code solo all week and even that gets messy. Spinning up 5 agents that actually talk to each other cleanly sounds hard to get right. Curious how the environment isolation holds up at scale?
Can you expand on your approach of defining things around state transitions? Are you thinking of it as the state of a task (built, validated, integrated, etc)? Or something else entirely? I'm not sure I followed that part and it seemed rather key.
> - building custom automated software pipelines for eg code review, pentesting, large-scale migrations, etc...
I'd be interested in hearing more about how you did this, sounds super valuable
Yeah, I guess we have sandboxes qwith our various code environemnts, and then we've been developing programs that run agents to do various things, which we iterated on to make them better at the task.
For example, one spawns copies of the env with a PR and runs agents in the dev env to verify by running and demonstrating functionality and then comments on github
another one is just a generic software factory that spawns a bunch of agents to coordinate on some repo, others do a redteaming flow, etc...
Seems like a powerful concept, and I'm excited to try it, but yikes does the code snippet seem like a textbook example of primitive obsession.
Very cool!
really cool,learned a lot from your project
Great idea
[flagged]
yes, you can read the logs, and see full actions, the agents can send messages to each other, and I am also about to make it possible for them to optionally read each other's traces