Hacker News: etherio

New comment by etherio in "Show HN: Druids – Build your own software factory"

etherio — Fri, 10 Apr 2026 07:19:58 +0000

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

New comment by etherio in "Show HN: Druids – Build your own software factory"

etherio — Fri, 10 Apr 2026 07:19:14 +0000

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...

New comment by etherio in "Show HN: Druids – Build your own software factory"

etherio — Fri, 10 Apr 2026 02:55:06 +0000

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

Show HN: Druids – Build your own software factory

etherio — Wed, 08 Apr 2026 20:12:38 +0000

Hi HN!

Druids (https://github.com/fulcrumresearch/druids) is an open-source library for structuring and running multi-agent coding workflows. Druids makes it easy to do this by abstracting away all the VM infrastructure, agent provisioning, and communication. You can watch our demo video here (https://www.youtube.com/watch?v=EVJqW-tvSy4) to see what it looks like.

At a high level:

- Users can write Python programs that define what roles the agents take on and how they interact with each other.

- A program is made of events - clear state transitions that the agents or clients can call to modify state. Each event gets exposed as an agent tool.

- Druids provisions full VMs so that the agents can run continuously and communicate effectively.

We made Druids because we were making lots of internal coding tools using agents and found it annoying to have to rearrange the wiring every time.

As we were building Druids, we realized a lot of our internal tools were easier to express as an event-driven architecture – separating deterministic control flow from agent behavior – and this design also made it possible to have many agents work reliably.

We had issues with scaling the number of concurrent agents within a run, so we decided to have each program run in an isolated sandbox program runtime, kind of the same way you run a Modal function. Each agent then calls the runtime with an agent token, which checks who can talk to who or send files across VMs, and then applies the tool call.

Our early users have found the library useful for:

- running many agents to do performance optimization

- building custom automated software pipelines for eg code review, pentesting, large-scale migrations, etc...

We've heard that the frontier labs have the infrastructure to quickly spin up 100 agents and have them coordinate with each other smoothly in various ways. We're hoping that Druids can be a starting point to make that infrastructure more accessible.

Comments URL: https://news.ycombinator.com/item?id=47695666

Points: 64

# Comments: 15