Feature deep dive
When one AI coding agent finishes a task, the next one needs to start automatically — without you in the loop. Jack handles handoffs through file-event triggers: a path pattern, an optional regex filter, and a prompt for the target agent. No DAG, no orchestrator, no manager agent — the "protocol" is your repo. Six handoff templates ship in the box, plus a custom rule editor. Cross-provider by design (Claude Code, OpenAI Codex, Google Gemini in any direction).
An agent handoff is the moment one AI coding agent finishes a piece of work and the next one picks it up. In a typical multi-agent flow, a backend-dev implements an endpoint and writes the contract to a spec file; a reviewer needs to read that spec, open the diff, and leave notes. The handoff is the bridge between those two steps.
Without a handoff mechanism, you become the bridge: copy the file path, switch agent, paste the prompt. With a handoff mechanism, the second agent gets pinged automatically when the first one is done.
A trigger in Jack is three things:
_shared/specs/*.md or apps/api/**/*.ts.When a file write matches the pattern (and passes the optional regex), the action fires. That's the entire mechanism. There is no scheduler, no graph runtime, no manager agent picking who runs next — the file system is the queue.
Jack ships six predefined templates that cover the workflow primitives a human team would already use. You enable them per workspace; you can also stack templates with your own rules.
.md file under _shared/specs/ is created or updated._shared/questions.md is modified._shared/decisions/ is created or updated._shared/tasks/ whose name starts with this agent's slug._shared/tasks/ flips to status: done. The notification is routed back to whoever opened the task, resolved at fire time. No agent A → agent B table to maintain.Multi-agent orchestration frameworks come and go. After watching three of them deprecate inside a year, we picked the primitive that doesn't break: files watching files. A trigger is a path pattern, an optional filter, an action — three things you could write in a shell script, surfaced in the workspace UI and auditable in the activity log.
The trade-off is real and intentional. We give up the rigour of a typed graph in exchange for handoffs that survive outside Jack: the same triggers, expressed as chokidar watches or git hooks, would still work without us. Your repo is the source of truth, not our runtime.
Yes — that is the point. The provider is a per-session choice, so a Claude Code session writing to _shared/specs/auth.md can fire a prompt on an OpenAI Codex session reviewing it. Or a Google Gemini agent posting a question can ping a Claude agent assigned as the topic owner. The trigger doesn't know which provider is on either side; it just matches a path and fires.
The same goes for the dynamic routing template — "whoever opened the task gets the ping when it's done" works the same whether the opener is a Claude session, a Codex session or a Gemini one.
Every file event, every fire, every skip and every error lands in the Activity panel with a timestamp. Filter by Fired, Observed, Skipped or Errors. When a handoff doesn't happen, you see why — not "task complete" on a task that silently failed.
A skip line tells you which file was observed and which filter rejected it. A fire line tells you which agent received which file. An error line tells you exactly what went wrong. Three categories, no guesswork.
A handoff in Jack is a single file-event trigger: when a path pattern matches, fire a prompt for the target agent. An orchestration step is a node in a DAG that a manager component schedules. Handoffs are decentralised — there is no scheduler, no manager, no graph runtime. Each rule is independently observable and independently disablable.
Triggers are off by default. Each rule is opt-in per pattern. The fired prompt still hits the same permission inbox before any tool call runs, so a runaway trigger cannot silently execute destructive actions on your machine.
Yes. Triggers are opt-in per workspace. If no rule is enabled, no handoff fires. You can also pause all triggers from a single toggle while keeping the rules configured.
Yes. The Custom template lets you define your own path pattern (glob) and an optional text-content regex. The action is the prompt sent to the target agent — you can include the matched file as context.
Yes. The fired prompt includes the file path and content (subject to size limits). For the dynamic routing template (task-completed), the prompt also routes back to whoever opened the task, resolved at fire time.
Yes. Handoffs are cross-provider by design. A Claude session writing to _shared/specs/auth.md can fire a prompt on a Codex session in any direction. Same trigger, different provider on either side.
_shared/, AGENTS.md) that handoffs sit on top of