Orca CLI: an agent pipeline from tasks to workspaces

How a task becomes work for a dedicated agent

What interests me here is not Orca’s interface itself, but the combination of Orca CLI and automations: a card moved to Select for development can become the input for a dedicated agent run. Orca’s official overview and CLI reference describe operations with worktrees, terminals, files, diffs, an embedded browser, and progress reports. Separate documentation on scheduled automations confirms that tasks can be launched for a repository or an existing workspace.

I downloaded Orca and spent a couple of hours experimenting with it. I did not immediately want to move my entire workflow there, but the Markdown-kanban scenario clearly shows why a CLI layer on top of a development environment can matter. Orca becomes not another screen with an agent, but an execution layer between a task and a repository.

The proposed pipeline looks like this:

• a task appears on an Obsidian kanban board and changes status;
• an isolated workspace with its own branch is created for it;
• a small agent completes the work and prepares a changelog;
• the status and result are written back to the Markdown file;
• merging and deployment remain separate stages.

One important caveat: Orca’s official materials confirm support for isolated worktrees, automations, and Markdown artifacts, but not a ready-made Obsidian integration. As of August 24, 2026, the collected documentation does not describe such a connection. Monitoring kanban changes and updating the vault therefore need to be implemented as an external layer, rather than treated as a built-in feature.

Why a file-based kanban matters more than the interface

This approach can genuinely change how multiple projects are handled, but it does not make the process magically autonomous. A regular Markdown file becomes a task queue, while isolated workspaces reduce the risk of mixing contexts, branches, and unfinished changes between parallel agents.

The first thing I would test is idempotency: will a repeated event create a second workspace for the same card? Next come recovery after an agent failure, branch conflicts, status synchronization, and a clear definition of done. Otherwise, a polished pipeline quickly produces not code, but a collection of forgotten worktrees.

This is not a revolution in personal productivity. It is practical orchestration of familiar parts: Git, Markdown, schedules, and agents. The most interesting question remains open: how long can this file-based control plane stay simple once the number of tasks and repositories becomes genuinely large?

We previously examined how parallel Claude Code agents review PRs and uncover race conditions in workflows. This approach complements isolated workspaces, where every agent needs a separate environment for its task.