Two loops can read the same repository and still work from incompatible assumptions. One sees a module before a refactor, another records a test mapping from a different branch, and both treat the finding as current. Parallelism then converts context drift into merge conflict or, worse, a clean merge with inconsistent behavior.
Multiple Ralph loops need shared repository knowledge only where it is safe to reuse. Branch state, task progress, scratch work, and write authority should remain isolated. The design goal is a read-only common orientation layer with explicit provenance, not a shared agent mind.
Why Multiple Loops Need Shared Context
Multiple Ralph loops often repeat the same orientation work. Each loop locates module owners, reads repository rules, identifies public entry points, and finds relevant tests. A reviewed, current index can prevent every worker from rebuilding that map independently.
Parallel Ralph agents need the same source-backed orientation without sharing mutable task state. That distinction keeps reuse separate from coordination authority.
This concurrency is not a universal property of Ralph. Geoffrey Huntley’s original description presents a simple outer loop operating on a plan and repository with executable backpressure. The snarktank implementation similarly runs one task-oriented process per iteration. Concurrent workers are an implementation choice layered on top.
Ralph Orchestrator is one such variant. Its parallel-loop guide describes worktree-isolated loops and optional integration of successful branches. That makes coordination explicit, but it does not make every state surface safe to share.
The useful common ground is knowledge that many tasks need and no implementation loop should mutate casually: repository rules, module boundaries, ownership, definitions, dependencies, and verified test relationships. Everything shared should still identify the commit and source from which it was derived.
What Should Be Shared Read-Only
Parallel Ralph agents should share approved repository instructions and architectural constraints as read-only context. The AGENTS.md specification allows instructions to be scoped by directory, with more deeply nested files applying within their subtree. A loop should receive only the rules relevant to the paths it reads or edits, not an undifferentiated global prompt.
Share derived structural indexes as read-only data. A code graph can provide modules, symbols, imports, calls, implementations, ownership, and test mappings with file and commit provenance. Graphify is one possible codebase graph layer for this purpose. Each loop can query a task-sized subgraph and verify the cited source in its own checkout.
Share immutable task specifications when several loops contribute to the same program, but assign each task a distinct owner and write scope. Shared acceptance criteria establish a common contract; they should not become a collaborative scratchpad that any worker can rewrite.
Searches for “Multiple Ralph loops Reddit” may surface useful coordination anecdotes, but they are not evidence that one shared memory model is safe. Classify each item by authority, provenance, scope, and expiry before sharing it.
Community discussions often collapse all memory into one category. The safer distinction is authority. Source-derived context and approved rules can be shared because workers consume them. Hypotheses, interim decisions, and branch-local results should remain with the loop that produced them until reviewed and promoted.
What Must Stay Isolated
Searches for “Multiple Ralph loops Reddit” may surface coordination anecdotes, but they do not change the isolation requirement. Branch and worktree state must remain isolated. Two loops editing the same checkout can overwrite uncommitted work, run checks against mixed changes, and produce ambiguous Git history. A dedicated branch and worktree give each task a stable filesystem and commit identity.
Task progress should also be isolated. A loop’s failed attempts, pending checks, and next action belong to its task. Merging progress logs creates an ordering problem and can cause one worker to adopt another worker’s unresolved hypothesis. Share a verified finding through a promotion workflow instead.
Scratchpads, tool output, temporary credentials, and environment values should never become general shared context. Their sensitivity and lifetime differ from repository knowledge. Store secrets in approved systems and pass only the minimum reference needed for the task.
Write authority must stay isolated even when read context is shared. A graph result may show that a dependency crosses into another team’s module. That evidence can trigger coordination, but it does not grant the loop permission to edit the dependency. Read scope, write scope, and merge authority are separate controls.
Branch, Task State, and Write-Scope Boundaries
Assign each loop a task ID, base commit, branch, worktree, allowed write paths, validation commands, and completion condition. Record these values in machine-readable task state. At iteration start, the loop should reject shared context whose commit or scope is incompatible with its checkout.
When a worker discovers a cross-task fact, it should publish a proposed finding containing the claim, source paths and symbols, commit, evidence type, and expiration condition. Another owner or automated check can validate it before the fact enters the read-only shared layer. This prevents a confident summary from bypassing review.
Merge in a controlled order. A successful branch can still conflict semantically with a branch that passed tests against an earlier base. Rebase or merge the current integration state, rerun affected checks, and invalidate structural context that no longer matches. The merge owner should resolve overlap; individual loops should not silently coordinate by editing a common file.
Ralph Orchestrator documents a shared memory file with locking in its codebase, alongside loop-specific events, task state, and scratchpads. A lock prevents simultaneous file corruption; it does not establish that the stored claim is correct or safe for every loop. Content still needs scope, provenance, ownership, and expiry.
Conflict and Security Risks
The most common conflict is stale shared context. A module map indexed at the base commit may become wrong after the first branch merges. Attach commit and index version to every result, then invalidate or rebuild after structural changes. Do not let “latest” remain an unverified label.
Semantic conflicts are harder than textual conflicts. Two branches may modify different files while making incompatible assumptions about an interface or data model. Shared dependency and ownership information can flag the overlap early, but affected tests and human review remain necessary.
Security risks include cross-repository disclosure, secret leakage through logs, prompt injection stored as “memory,” and excessive permissions on the shared service. Apply repository access controls to indexing and queries, sanitize untrusted content, and keep implementation loops unable to rewrite the evidence they consume.
Ralph Orchestrator’s MCP surface should not be mistaken for a native code-graph bridge. Its documented role is an inbound, workspace-scoped control plane for orchestrator state. Connecting a graph through MCP or another transport would be a separate integration with separate credentials, audit logs, and lifecycle rules.
Finally, define a safe stop condition. Pause a loop when its base commit is obsolete, its write scope overlaps a merged task, required shared context is stale, or validation reveals a cross-task contract change. Parallel throughput is not useful when coordination evidence is uncertain.
FAQ
Who merges shared findings?
A designated integration owner or reviewed automation should promote findings into the shared read-only layer. The producer supplies source paths, symbols, commit, and limitations. For architecture, security, or cross-team claims, the relevant code owner should approve the promotion.
What should never be shared between loops?
Do not broadly share secrets, temporary credentials, raw private prompts, unreviewed hypotheses, mutable scratchpads, or branch-local task state. Avoid sharing derived relationships without provenance. A loop can report a finding, but another loop should not receive it as authoritative until it is validated.
How should stale shared memory expire?
Tie structural facts to a commit and index version, task findings to a task or branch, and reviewed rules to an owner and review trigger. Invalidate on relevant merges, refactors, generation changes, or contradiction from current source. Archive history for audit rather than feeding it into active context.
What is the Ralph Wiggum coding technique?
It is an iterative agent workflow that repeatedly works from a task or plan, modifies a repository, and uses tests, builds, or other checks as feedback. Parallel workers, worktrees, shared memory, and code graphs are implementation options, not requirements of the base pattern.
Conclusion
Multiple Ralph loops work best when they share evidence, not mutable thought. Keep reviewed rules and source-derived repository structure read-only and provenance-rich. Isolate branches, task progress, scratch state, write permissions, and merge authority.
The hard boundary is promotion: a loop can discover a useful fact, but that fact becomes common context only after its scope and source are checked. For repository orientation in a single loop, see Ralph Loop large codebase context. For the shared structural layer, see knowledge graphs for AI coding assistants.
Leave a Reply