This is a submission for the OpenClaw Challenge.
What I Built
PlanetLedger is a sustainability finance dashboard that turns your bank s...
For further actions, you may consider blocking this person and/or reporting abuse
Building a custom in-process event bus is a brilliant way to handle agent orchestration without the overhead of heavy infrastructure. The decoupling of the upload logic from the insights and alerts clearly paid off, especially with the "chained pipeline" approach. It's a great example of how a thin abstraction can provide the same mental model as a production queue while remaining entirely replaceable. Excellent work on the PlanetLedger architecture.
Really appreciate that 😊
I wanted the mental model of event-driven systems without pulling in the whole queue + infra story. Just enough structure to decouple things like upload → insights → alerts, but still keep it easy to reason about.
The “chained pipeline” ended up being a nice middle ground. Feels like orchestration, but without committing to it too early.
And yeah, the replaceability is the key part for me. If I ever need retries, replay, or distribution, I’d rather swap the execution layer than unwind the workflows.
Glad that came through 🙌
The part that resonates is the quiet confidence of building something intentionally "not production-grade" and being completely fine with it. The in-process event bus doesn't survive restarts. You can't replay events. It's not distributed. And that's exactly the point. It gives you the mental model of event-driven architecture without the operational weight that usually comes with it.
What's interesting is how this flips the normal advice. We're usually told to build for scale from day one, to use the right infrastructure so you don't have to migrate later. But the migration path here is actually clearer because the abstraction is thin. The registry pattern is the contract. Swapping the implementation from
fireOpenClawEventtoenqueuelater is almost mechanical. The workflows don't need to know.That's the real win of the approach. Not that it's simple, but that it's replaceable. The complexity budget went into the event taxonomy and the payload structure—the things that are hard to change later. The execution layer is deliberately disposable.
The
pseudonymizehabit is one of those things that feels like overkill until it isn't. Did you start with that from day one, or was there a moment where you looked at a log line and thought "yeah, I don't want my user ID sitting in plaintext here"?Glad that it resonates. Didn’t start that way, honestly.
Early on it was just raw IDs and emails everywhere. Faster and easier when you’re building quickly. Then you hit that moment where you look at a log or event payload and think, yeah… this doesn’t really need to be here.
After that it just felt cleaner to pseudonymize. Events don’t need identity, just something consistent. Logs don’t need real data, just something traceable.
It also ended up fitting nicely with the rest of the setup. Same idea as the event bus, keep things loosely coupled and easy to swap out.
So not day one, but once it clicked, it kind of spread everywhere.
I love the intentional minimalism here — an in-process event bus that fits in 60 lines is exactly the right call for a solo project. The moment you outgrow it, you'll know precisely what you need from a real queue. Have you thought about what happens when two events fail in the same workflow chain? That's usually where these lightweight buses start showing their seams.
Appreciate that — that was exactly the intent.
And yeah, that’s the edge I’ve mostly chosen not to solve yet. Right now if two events fail in the same chain, it’s pretty blunt… they just fail independently, no retries, no orchestration, no guarantees. Very “best effort.”
I’ve kept it that way on purpose so the seams stay visible. The moment I start needing things like retries, ordering, or even basic replay, that’s probably the signal to graduate to a real queue.
Until then, I’m kind of treating failures as feedback rather than something to fully abstract away.
I love that you built an entire AI-powered event bus, just so I can upload a PDF and have my bank statement mathematically prove to me that my iced coffee habit is actively melting the ice caps! Decoupling the architecture is brilliant, mostly because, it means the app can judge my carbon footprint asynchronously while I weep. 😅
Haha this is gold 😄
Honestly, the real architecture goal was emotional scalability…so the system can process your transactions and your regrets in parallel.
The event bus just makes sure the judgment is delivered reliably… even if you try to refresh the page and pretend it didn’t happen.
And don’t worry, the iced coffee isn’t melting the ice caps alone.
PlanetLedger just makes sure it gets the credit it deserves ☕🌍
thats awesome!
Thanks Mika ☺️
good good nice
Thanks Fajab ☺️
nice Ujja:)
Thanks Benjamin ☺️