Delegate Trust
Trust.
It’s at the heart of the current growth phase of agentic development.
We trust agents far more than we did even one year ago, but there’s still ground to be gained.
Each month, I continue to delegate greater amounts of autonomy to my agents as they, and my workflows, improve. Today, I wanted to define them so they can be of reference in later posts. I refer to these collections of agents as clusters, and they representing different stages in my agent stack’s maturity, while also enabling different kinds of workflows entirely.
The Pleiades Cluster - Parallelization Workflow##
In the beginning, my focus was on parallelizing work. In the case of the Pleiades agent cluster, this took the form of setting up a ticket dispatcher with some downstream implementation agents. My focus was to build my ticket backlog, and then open an interactive sessions with a dispatcher that kept a certain number of tickets running in parallel at any given time. I kept this amount to a manageable number (3-4 at a time), and all tickets were dispatched via a single shell process thread with my dispatcher.
The Hyades Cluster - Orchestration Workflow
My current phase. I manage 2-3 simultaneous agents per project, and 2-3 projects at once, for a maximum of around 10 tasks in parallel at any given time. I’ve found this to be an ideal range to properly manage the capacity limit of working memory via chunking tasks into manageable sizes.
Work items can have many different stages, but generally the flow in my case involved ideation -> scoping -> refinement -> execution - > testing -> MR. Only the first two of these stages have humans-in-the-loop; while everything after requires escalation. The Orchestrators in this structure are the Executors, while I have agents autonomously spawn specialized agents for each of the ideation and scoping stages as necessary.
The Orion Cluster - Pipeline Workflow
My next goal is to make agent orchestration feel more like a pipeline that you “fire off”, and which intelligently prompts you for required information via a web dashboard as humans are required in the loop. In essence, I want the dashboard to serve as an extension wrapper for the claude code sdk. Webhooks will fire to my listener services, which will instantiate claude orchestration agents to oversee the execution of the contents passed by the webhook. It’s possible that the Webook must integrate some kind of task management tool - such as a beads display dashboard - to manage the prioritization of parallelizing work threads. The precise implementation is still open-ended, and so I’ll go into detail on it at a later time. For now, my focus is on ensuring I bring over the good parts from Hyades cluster by generating robust documentation and ensuring I have a solid grasp on what I am loving about the cluster and what I am wishing was better (spending too much time linking out to MRs I don’t need to, or determining if sessions can be closed yet, or telling them to “clean up” because I merged). I suppose that’s not as much about Orion as it is about problems with Hyades, but - like I said - more on this one another time.
And that’s a rough outline of the stack’s history. I think I may try keeping these posts shorter in the future. Still exploring how I’d like to author this journey. But for now, I just wanted something out there. I think it’s a wonderful place to be exploring - full of possibility and open questions. Very excited about Google’s Open Knowledge Format that just dropped this week - will be posting about that as well.
Till then!