The Problem
Running multiple AI coding agents on one task means you become the message ferry: pasting one agent's output into another's chat, round after round. Context movement, triggering, and stopping conditions all live in your copy-paste buffer instead of the system.
What This Does
looperators is an Electron desktop app that puts agents on a graph canvas where the edges execute. When an upstream agent finishes, output travels down the edge and wakes the next agent; the downstream result flows back and triggers revision. Stopping conditions ("until review is clean, at most 6 laps") are defined on the edge, not in your head.
The graph is generated from conversation, not drag-and-drop. Chat normally, and when a loop pattern emerges, the matching graph appears automatically. It supports Claude Code, Codex, and Grok Build via adapters in electron/runtime/providers/.
How It Is Wired
Execution starts in electron/main.ts at broadcastRuntimeEvent and humanCommand, or in electron/runtime/externalSourceAdapters.ts at start. From start, the shortest path to an external effect is start -> connectAgents, which touches the filesystem via m.touch. The runtime makes 27 filesystem-touching functions, 15 database functions, and 3 outbound network calls.
The hub is electron/runtime/sessionManager.ts: 98 functions, called from 11 files, calling into 29, with filesystem writes. It owns getState and dispatchCommand, which appear 77 and 26 times in the call graph respectively. Changing it has the widest blast radius. The other hub, tests/runtime/support/deterministic-provider.mjs, has 27 dependents — a test fixture that grew into infrastructure.
Two import cycles exist: classicWorkflows.ts and goalTemplates.ts in electron/runtime/workflows/, plus src/shared/graph-state.ts and provider-runtime.ts. Breaking these requires extracting shared types or deferring imports.
The most-called internal functions carry the real risk: optionalTrimmedString (103 call sites), clone (102), now (101), isObject (81). A signature change ripples through nearly the entire codebase.
Database access is centralized in electron/runtime/kernelStore.ts (35 functions, schema initialization, corruption recovery). File I/O is spread across claudeRuntimeShared.ts, providerService.ts, and the workspace files under electron/runtime/workspace/.
How To Use It
git clone https://github.com/moses-y/looperators
cd looperators
npm install
npm run dev
Configuration is per-provider in the settings UI (src/components/provider-settings.tsx). The app targets macOS Apple Silicon. No environment variables are documented in the repo.
Real-World Use
A typical loop: wire Codex, Claude Code, and Grok Build to draft solutions to the same problem, with edges connecting them for cross-review. Set the stopping condition to "converge on consensus." Start the loop, open any agent as a normal chat mid-run, and adjust instructions — the graph keeps driving the rounds.
Code Health & Issues
Static analysis found 74 issues: 14 high, 60 medium. Key findings:
- High — Oversized files:
electron/runtime/workflows/classicWorkflows.tsat 1313 lines;src/shared/graph-state.tsandscripts/lib/orrery-client.mjssimilarly large. Split by responsibility. - High — Duplicated code: 611 repeated 6-line blocks across 120 files, including
electron/appUpdater.tsandelectron/runtime/claudeRuntimeShared.ts. Extract shared helpers. - High — Import cycles: 4 modules in circular dependencies (
classicWorkflows.ts,provider-runtime.ts,graph-state.ts). - High — Deep nesting: max indentation depth 10 in
scripts/orrery-cli.mjsandsrc/components/runtime-interaction-panel.tsx. - Medium — High branching density: 79 branch points over 212 lines in
shared/review-workflow.ts.
SDLC findings: GitHub Actions are pinned to tags, not commit SHAs (softprops/action-gh-release@v2) — a known supply-chain risk. No Dependabot, no dependency vulnerability scan in CI, and persist-credentials: false is missing from the macOS release workflow. Tests exist (102 files) and CI is configured.
The Bottom Line
The core idea is sound and the architecture is coherent: a graph-native runtime with provider adapters and a real session manager. The codebase is young and carries typical early-stage weight — oversized files and duplicated helpers will make changes slow. Worth evaluating if you run multi-agent workflows daily and want to stop being the middleware.