Agent workflow orchestration
Designs a durable workflow substrate for visible agent sessions, gates, handoffs, verification, recovery, and operator intervention.
Research state: Incomplete
Verification cutoff: 2026-08-12. Candidate maturity, licenses, and public APIs require revalidation after this date.
Research question
How should jackin❯ coordinate a roadmap item through implementation, verification, independent review, fixes, and operator approval while keeping every agent session visible and interruptible?
Headline findings
- jackin❯ should own the execution substrate and durable run model because Capsule sessions, isolated workspaces, role environments, and host-mutation policy are core constraints rather than interchangeable runner details.
- External products converge on durable task state, provider mixing, visible execution, issue or PR integration, and human gates. None reviewed combines those properties with Capsule-owned PTYs and jackin❯ isolation closely enough to become the authoritative runtime dependency.
- The durable contract is a deterministic run ledger, not an LLM manager. Agent prose is evidence, never the transition authority; verification commands, runtime state, artifacts, GitHub state, and operator decisions advance the run.
- Operator intervention is normal workflow state. Attach, prompt, pause, manual Git changes, and cancellation must be recorded rather than treated as exceptional corruption.
- GitHub is the durable audit surface; Capsule remains the live execution surface. The reporter must stay compact and must never merge without explicit operator authority.
- A generic workflow language, background queue, dashboard, and autonomous review loops should not define the initial contract. Their delivery and sequencing belong to Roadmap.
Method and evidence
The research compared local orchestrators, coding-agent workbenches, workflow engines, terminal control systems, memory systems, and GitHub-native agent workflows. Prior art records the sources and reusable ideas. Design constraints defines the run model, evidence rules, control boundaries, GitHub behavior, and operator-intervention contract.
The comparison is architectural. Hands-on parity tests across the candidate workbenches remain incomplete, so dependency conclusions should be revisited if a candidate exposes a stable external session-provider API that preserves Capsule visibility and policy.
Limitations and open questions
- Should work begin from a tracking issue, a draft PR, or a branch with check-run visibility?
- Which evidence is required in addition to agent runtime
donebefore a phase becomes review-ready? - Should direct operator input always pause the run, or can policy permit verification-then-continue?
- How should workflow memory be selected, inspected, versioned, and proposed for promotion?
- Which agent-review adapters provide independent value without hiding sessions or duplicating branch ownership?
- Where should future declarative profiles live, and how should operator, workspace, and role precedence work?
How to read
| Page | Purpose |
|---|---|
| 01 — Prior art | External systems, reusable patterns, and dependency verdicts. |
| 02 — Design constraints | Durable objects, state transitions, evidence, Capsule APIs, GitHub reporting, intervention, memory, and adapters. |