Introduce an agent to select and start the next task #73
Replies: 1 comment
-
|
thx for the detailed proposal and for thinking about this. I looked at it carefully, but I don't think this belongs in ralphex. a few thoughts: most of the use cases are already covered:
the fundamental part — AI orchestrating sub-AIs — is a different system: ralphex is deliberately built as a deterministic Go loop on top of Claude Code with a clear two-model architecture: a single primary solver (claude) and a secondary reviewer (codex by default, but configurable to any tool). the runner picks tasks, runs them, checks signals — all in Go code, no tokens spent on orchestration. replacing that with an LLM making dispatch decisions adds cost, latency, and non-determinism for unclear benefit. what you're describing (multi-provider dispatch, adversarial scoring, parallel independent agents) sounds like a multi-agent workflow engine. that's a fundamentally different tool with different design goals. trying to bolt it onto ralphex would either gut the core design or create a parallel system that shares almost nothing with the existing architecture. btw, what you're describing is very close to Claude Code's agent teams — a lead agent orchestrating multiple sub-agents with task dispatch, parallel execution, independent context windows, and inter-agent messaging. might be worth checking out directly, as it's a native feature with proper process management, shared task lists, etc. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Umputun, thanks for Ralphex. Neat and concise implementation of the Ralph concept.
The idea is to add a level of indirection via a proxy agent that would start like the current Runner, takeover part of the current task agent work: pick a task using logic similar to the
task.txtprompt, infer custom CLI params from the task guidance (!), launch a sub-process, update the plan checkboxes, commit.Use cases I’d like to cover:
Code using different CLI agents and model providers.
I don’t have Claude Max for personal projects, only cheaper subscriptions + OpenRouter credits. Sometimes I may use odd proxies. I don’t mind occasionally trying my personal project with Qwen / Kimi CLIs. I’d like to be able to prompt Ralphex to fall back to different providers when Claude reaches its limit.
I want the sub-agent to not know the big plan.
a. My plans are large, with many steps and milestones, and I’m conscious of extra context contamination. For example, I’d like to add steps like “run a retrospective based on {{PROGRESS_FILE}} and add a few more tasks to address systemic issues” — and I don’t want coding agents to know about such retrospectives.
b. Or, when I’m using Multi-LLM orchestration for scoring proposals and strategies to mitigate groupthink bias, I want to launch independent agents to research something (from different providers, or at least in different attempts), have independent reviewers (of different roles), and let them adversarially fuse and score proposals (via rubrics, voting, prediction markets). Such tasks must not contaminate an agent’s context with the work of others.
My plans are often not code -> review.
I use agents for triaging prod incidents, running data analytics, updating runbooks, manual ETLs. I'd like to define a complex and custom plans for Ralphex, not constained to coding.
Hope it makes sense and is aligned with your vision. WDYT?
I appreciate it adds a level of non-determinism to the program and has diminishing returns for more standard feature coding tasks.
I was thinking of requirements for such feature, and came up with
--mode lead, newlead.txtprompt taking over part oftask.txt, and some more functional requirements.ralphex-mode-lead-requirements.md
lead.txt
Beta Was this translation helpful? Give feedback.
All reactions