AgentsAgent orchestrationAgent orchestration program

Agent orchestration decision and benefit matrices

Compares orchestrator ideas by operator benefit, jackin❯ values, and the risks of copying adjacent tools directly.

Summary

The strongest external ideas improve boundary visibility, fleet legibility, terminal automation, recovery, and operator control without weakening jackin isolation or runtime neutrality.

Question and scope

Which adjacent-tool ideas deserve adoption, adaptation, rejection, or postponement when evaluated against the dossier's values?

Method

This comparison applies the jackin evaluation values to public product capabilities at the dossier cutoff.

Findings

ToolStrongest idea to borrowMain reason not to copy it directly
graemerocher/multicodeParallel workspace table, GitHub status links, multicode-remote, skill-driven tags, Codex provider support, editor launcher, autonomous queue config, Apple-container experimentsLinux-first bwrap/systemd-run core; isolation is convenience, not a strong boundary; some Apple-container workflows still mount the host Docker socket
dredozubov/hazmatSession contract, tier decision flow, native macOS containment, strict integration rules, rollback/proof disciplinemacOS-only; one hardcoded agent user; no smooth multi-agent fleet surface
Docker SandboxesMicroVM plus private Docker daemon, host-side network proxy, credential injection outside the VM, branch worktrees under .sbx/Product is tied to Docker Desktop; not an extensible jackin role ecosystem; credentials/network proxy are not available primitives in plain Docker
ogulcancelik/herdrTwo-stage done state (Done vs Idle), foreground-process ownership, semantic integration reports, visible-screen arbitration, workspace-level status roll-up, notification suppression when tab is focused, sound-escalation opt-in, and blocking wait semantics on the socket APIAGPL-3.0 (embedding conflicts with jackin Apache 2.0 license); heuristics degrade when the observed terminal is docker attach rather than the agent process; no container isolation, mount model, or auth forwarding
kitlangton/cellshot, asciinema, Charmbracelet VHS, and terminal test/record toolsTreat terminal sessions as observable, scriptable, replayable objects: structured cells, visible-text waits, input injection, .cast/JSONL traces, and text/JSON/SVG/PNG artifact bundlesMost tools own their own PTY daemon, browser terminal, or host process; jackin should expose the existing Capsule PTY/session state instead of nesting another runtime. See Terminal observation and automation
stablyai/orcaWorktree-per-task visual orchestration, diff-annotation-to-agent feedback loop, embedded Chromium per worktree (Design Mode), 30+ zero-config runtimes, WebGL multi-pane terminals, mobile companionHost-native agents run as host user; no container boundary; isolated UX ideas are the borrow target, not the isolation model. See Orca ADE research
Claude/devcontainer patternsDefault-deny firewall and reproducible container setupDevcontainers are workspace setup, not a multi-agent orchestrator or full operator platform
Conductor-style native worktreesLow-friction host-native worktreesNo meaningful sandbox boundary; useful only as a UX comparison

User-facing benefit matrix

This table is the "why would an operator care?" pass. A feature only belongs in the design when it improves an engineer's day-to-day control loop, not just because another tool has it.

User-visible benefitSeen injackin direction
Know the exact boundary before launchHazmat session contract; Docker Sandboxes security modelSession contract and explain mode becomes the common preflight for mounts, auth, Docker, network, ports, persistence, and recovery
Pick the right containment tier for the jobHazmat tier decision flow; Docker Sandboxes private-daemon pathAdd a tier recommendation to jackin explain rather than forcing users to infer whether dind, rootless DinD, microVM, SSH remote, or Kubernetes is appropriate
Run Docker/Compose without trusting the host daemonDocker Sandboxes private Docker Engine; Hazmat Tier 3Keep host socket mounting out of scope; make private-daemon backends the Docker-capable path under selectable sandbox backends
See and govern outbound network behaviorDocker Sandboxes dashboard network panel; Hazmat deny-mode routingNetwork egress policy should include connection logs and rule-editing UX, not only static allowlist config
Open services started by the agentDocker Sandboxes sbx ports; multicode host-localhost notesTrack service exposure as a first-class session-contract section with explicit host-side effects and non-persistent port mappings
Work in parallel without clobbering the main checkoutDocker Sandboxes --branch; multicode short-lived workspacesjackin already has per-mount worktree/clone isolation; improve the operator surface around branch naming, preserved worktrees, and post-session review
Resume a configured environment without rebuilding everythingDocker Sandboxes named/persistent VMs; multicode workspacesPreserve jackin explicit state model, but add disk/resource visibility and cleanup policy so persistence does not become invisible bloat
See which agents are idle, busy, waiting, done, stuck, or expensiveHerdr state roll-ups; CCManager and ccmux live status; Docker Sandboxes dashboard cardsAgent runtime status authority, console resource panel, and token telemetry should converge into one operator overview
Script, test, and replay a visible agent terminalcellshot wait/send/snapshot; VHS .tape; asciinema recordings; tui-test getByText and tracesTerminal observation and automation should turn Capsule sessions into typed read/wait/send/snapshot/record targets for CLIs, tests, future workflow runners, and external adapters
Jump from agent output to issue/PR/repo statemulticode <multicode:*> tagsKeep the tag protocol vendor-neutral and optional, then use it to drive GitHub link tracking and custom operator actions
Reuse stack setup safelyHazmat integrations; Docker Sandboxes kits/templatesKeep roles as the environment unit, but allow non-executable stack hints and future reviewed setup kits where they cannot widen trust
Roll back after a bad unattended runHazmat snapshots/restore; Docker Sandboxes disposable VM cleanupSession snapshot and rollback should separate metadata recovery, project snapshots, and sandbox-state deletion
Run the same operator model over SSH/server/Kubernetesmulticode-remote; jackin roadmap visionjackin-remote and Kubernetes support should reuse the same contract/status/policy vocabulary instead of becoming separate products

Ideas to decline or postpone

Some adjacent-tool features are attractive but would cut against jackin values if copied directly.

IdeaWhy not copy directlySafer jackin alternative
Host Docker socket passthroughAny agent with daemon access can create privileged containers or host bind mounts; this collapses the sandbox boundaryPrivate daemon only: DinD, rootless DinD, microVM-owned Docker, or Kubernetes-controlled pods
Same-absolute-path workspace passthrough everywhereElegant in microVMs, but it would break jackin explicit dst mount model in Docker/container backendsKeep dst explicit; only use same-path passthrough inside a backend that natively needs and explains it
TUI-only orchestrationFast for one product, but jackin core users automate from terminals, SSH, and scriptsCLI-first contracts and commands, with jackin console as the common day-to-day overview
Repo-controlled integration manifests with arbitrary paths/hooksTurns untrusted project files into policy authorityRepo may recommend known integration names; operator approval and jackin-owned manifests decide what activates
Broad environment inheritance for convenienceSecret-shaped env vars and auth sockets are easy to leak into agentsNamed credential sources, safe env selectors, and bridge/proxy-mediated capabilities
"Sandbox equals safe" messagingDocker Sandboxes and Hazmat both document residual workspace, hooks, network, and persistence riskPrint backend-specific risk posture and recovery limits in the session contract

Implications for jackin

Borrow operator outcomes and protocol shapes, not host-trust assumptions, product-specific runtime architecture, or hidden convenience paths.

Limitations and unknowns

Feature availability and product behavior are volatile. Revalidate the cited projects before converting a matrix direction into an implementation commitment.

Sources

On this page