Recent submissions

Comment · 7 months ago
I had a look and I understand that maybe you also use flicknote.app for agent context management.
Comment · 7 months ago
Yeah, with a 2 plane topology you are able to inherit concurrency as you for instance just hand off work from a designer agent to the plan-review-leader that spawns any number of reviewers in a star topology.
Comment · 7 months ago
I like your 2-plane mesh setup with multiple top-level agents and 'you' on the manager plane mesh that are able to communicate via a daemon mediated communication.

The daemon is the Telegram bridge, the tmux router, the CI status deliverer, and the cleanup coordinator all in one process. It allows for cross star topology communication unlike MoMa that basically just corresponds to a single manager and is similar to your plan-review-leader agent living in the manager plane if that one was isolated.

My previous concern was that maybe you would face a timeout in case user input was needed during a pipeline run, and in a case where the user was too slow to provide an answer through telegram (I imagine during the night), but maybe even github pipelines can be set to wait unlimited.

I really like the setup, and exactly I also faced the no nested agent spawning limit by Anthropic for Claude Code built-in agent tooling, that dictates the star topology in the first place.

I use the git worktree as well for every MoMa agent and they all live in Linux screen session. Maybe I should consider going to tmux myself instead of screen as I understand all your agents in top-level manager plane also are just tmux sessions.

Comment · 7 months ago
Comment · 7 months ago
A lot of people coming up with these tools to orchestrate agents to do a one-shot implementation in a sandbox (in a server/container/pipeline).

I also have a similar - yet different approach - with a Mother Agent (MoMa) planner-reviewer-implementer multi agent pattern that orchestrates a feedback loop using Claude memory between agents.

https://news.ycombinator.com/item?id=47437012#47437013

I understood that you have a Judge agent that evaluates independent subagent solo executions and chooses best solution based on ralph algorithm. Did you play with limits on how many solo agents it is sufficient to spawn vs. not getting a better solution? and what is the limit of soloagent solutions that the Judge can compare? (obviously must depend on the complexity and context cost of a solution)

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton