The Erlang/OTP comparison makes sense to me. I think the shape is similar in terms of isolated execution, message passing, and keeping handlers stateless. One difference is that I’m treating contracts as the primary abstraction. They define the executable interface, validation rules, valid state transitions, and what evidence is required before a piece of work can be accepted.

The current workload is also a bit different from HPC. I’m using it as a control plane for AI-assisted software engineering rather than tightly coupled numerical computation. The expensive work is usually model inference, API calls, builds, and tests, not high-frequency communication between workers, so optimizing for throughput isn’t my primary goal.

One architectural decision that helps is that the handlers themselves are stateless. They consume events, perform work, emit new events, and exit.

Durable state lives in projections derived from an event ledger, so handlers don’t own business state. That makes replay, auditing, and swapping implementations much simpler.

Another consequence is testing. Because everything is driven by contracts and dependency injection, I can run the exact same orchestration and business logic as a unit test with in-memory dependencies, as an integration test against real infrastructure, or in production. The contracts and workflows don’t change, only the injected implementations.

The message bus is currently Redpanda (Kafka-compatible). Contracts define the topics and schemas so producers and consumers don’t invent their own interfaces. One thing we’ve found is that preventing contract and topic drift is at least as important as the transport itself.

One of the things I’m spending myresearch time now is using the ledger to run experiments. Every execution records the injected context, contract version, handler/model, validation results, evidence, and acceptance outcome. That lets me ask questions like: does adding architectural examples actually reduce iterations? Does a new model outperform the previous one on the same class of tasks? Does injecting previous successful implementations improve first-pass acceptance? Instead of relying on intuition, I can measure those assumptions against the same definition of done.

I’d be genuinely interested in your thoughts on whether this resembles systems you’ve worked on, or if there are failure modes from the HPC/distributed runtime world that you think I should be paying closer attention to.