Orchestrator.inc: From Agents to Reviewed PRs

Editorial note. Requested publication date: October 6, 2026. Technical claims and competitor comparison reviewed against documentation accessible on October 26, 2026. Some capabilities may have changed after the publication date, so this article does not claim every feature was already shipping on October 6. This is a documentation-based analysis, not a first-hand installation test or benchmark.

Related reading: Paseo and multi-provider agent orchestration and OpenChamber versus Paseo: comparing practical workflows. Those pieces explain the alternatives on their own terms. This article asks a slightly different question: who is responsible for a change after the agent has finished writing code?

The difficult part begins when you have several agents

Asking a coding agent to repair a function is no longer impressive by itself. The hard part emerges when three independent tasks start simultaneously. One agent changes a component, another repairs the test suite, a third edits a migration, and a review comment arrives on a pull request while you are away from the desk. Which branch belongs to which agent? Who should act on the comment? What happens when CI fails after the worker has declared victory?

That is the problem Orchestrator.inc is trying to address. Formerly known as Agent Orchestrator, or AO, it is not a replacement model for Claude Code, Codex or Cursor. It is the layer around those coding agents, connecting a task to an isolated working directory, a Git branch, a pull request and the subsequent verification process.

For an independent developer maintaining several repositories, the proposition is attractive: launch a few bounded jobs, let workers operate in parallel and return when judgment is required, instead of reconstructing a forest of terminal windows and browser tabs. Yet the distinction between the product and its best-case demo matters. A dashboard reporting that an agent finished is not evidence that the code works. A green card is not an independent test.

I want to examine the engineering behind this approach, not simply enumerate buttons. We will look at its Go daemon, session model, Git worktrees, review feedback loop, remote clients, security boundary and cost structure. At the end, I will compare it with Orca, OpenChamber and Paseo using practical selection criteria, rather than treating each project’s feature list as a measured benchmark.

What Orchestrator actually does

The official introduction describes a desktop application for supervising AI coding agents. Sessions can expose structured Chat or an agent’s native terminal interface. A project board collects worker activity, changed files, Git state, browser previews, pull requests, check results and review feedback. Installers are documented for macOS, Windows and Linux.

There are three responsibilities to keep separate. The coding agent decides how to inspect and modify the repository using its own runtime and permitted tools. The orchestration layer starts or attaches to sessions and records their relationship with tasks and branches. Git and the hosting platform remain the source of truth about commits, pull requests, review threads and CI results.

That separation is the entire argument for the tool. A terminal multiplexer can run six agents, but it does not necessarily understand which session created which pull request. A beautiful chat application can display plans and generated code, but it may not know whether the resulting branch is still compatible with the current base branch. Orchestrator aims to close that gap.

Installing it does not give you free access to premium models. External coding harnesses still need their own installation and authentication, and their usage limits or API costs still apply. The application can use the sign-ins already configured on your machine. In other words, there is no mysterious shared inference engine that removes the underlying providers’ billing policies.

Nor must it replace a familiar editor. It is perfectly sensible to examine a tricky implementation in your existing IDE while using the board to track its owning session. The useful abstraction is provenance: knowing what caused a change, which worker owns it, what evidence exists for completion and what still needs a human decision.

Anatomy of the system: Go, Electron and SQLite

According to the architecture reference, Orchestrator runs a long-lived Go daemon behind an Electron and React desktop client. An optional ao command-line client and an Expo mobile application communicate with the same local service over HTTP, server-sent events and terminal streams. The daemon manages session controllers, workspace adapters, persistent data and observations from supported source-control systems.

Electron desktop ──┐
ao command line ───┼──> Go daemon ──> agent/runtime controllers
Mobile client ─────┘       │                │
                           ├──> SQLite      ├──> sessions and worktrees
                           ├──> events      └──> GitHub/GitLab observation
                           └──> terminal / browser bridge

SQLite holds durable session facts; the desktop application starts and supervises the background service. This is a useful architectural compromise: a single-user local application does not require a database cluster or remote orchestration server just to begin. But the local machine remains the execution host. When it sleeps or shuts down, its local agents cannot continue merely because a phone displays the last cached status.

The architecture distinguishes stored facts from derived status. A worker might be active, idle, blocked, terminated or waiting for input. Separately, its pull request could have passing checks, unresolved review comments or merge conflicts. The interface derives the board’s current status from this evidence. That is more valuable than asking the developer to keep a Kanban card manually in sync.

Of course, the derived status can still become stale if an API call fails or credentials expire. The board should make remote failures visible, not pretend it outranks GitHub’s own records. The design goal is traceability and lower coordination overhead, not an infallible replacement for your source-control platform.

Structured Chat versus the agent’s native terminal

A session may use Chat, with messages, plans, approvals and activity details, or a Terminal UI that exposes the selected harness’s native interaction. On macOS and Linux, newer sessions can use a native pseudo-terminal host; on Windows the implementation uses ConPTY. Older or fallback sessions may use tmux.

The documentation also describes compatible Claude Code and Codex conversations moving between their native terminal and Chat interface while retaining the same session and worktree. The old controller is stopped or interrupted before the replacement starts. That detail is not merely a UI transition: two active controllers writing to the same conversation would create confusing and potentially unsafe behavior.

However, an impressive catalog of agent logos is not a list of identical capabilities. Some harnesses may work well as terminals without supporting structured chat or the reviewer role. Before committing to an integration, check the documented capability for the specific agent and version you intend to run. A launchable command is not equivalent to a fully observed, resumable session with first-class approvals.

Git worktrees: real isolation, with important limits

The fundamental parallel-work primitive is git worktree. Instead of pointing every agent at the same checkout, Orchestrator can create a distinct branch and working directory for a worker. It associates those with the task so the developer can inspect changes and decide what should be integrated.

Picture a small web application that needs search, accessibility copy improvements and a test repair. If those changes are largely independent, three workers can operate without constantly replacing one another’s local files. Each can be reviewed and tested independently. Pull requests can arrive in any order, and the developer need not remember which terminal owned which branch.

A simplified Git illustration looks like this:

git worktree add ../search -b feat/search
git worktree add ../a11y -b fix/a11y-copy
git worktree list

These commands explain the Git primitive; they are not instructions to run manually inside a worktree that Orchestrator has already provisioned. Its own lifecycle should manage the directory and associated branch.

Worktrees are not containers, however. They do not automatically isolate network services, filesystem locations outside the repository, environment variables, tokens or external databases. If two agents expect to listen on the same development port, one can still fail. If both apply migrations to a shared database, the conflict exists no matter how tidy their Git directories look.

They can also change overlapping source files. Git will eventually have to reconcile those edits. In fact, parallelizing dependent work too aggressively can make the total process slower: more rebases, conflict resolution, intermediate failures and reviewer effort. The best initial experiment is not to launch ten agents. It is to identify two genuinely independent deliverables and verify that the separation reduces overall human work.

The central idea: keep a PR attached to its worker

The quickstart guide begins with an uncomplicated path: add a repository, choose a worker, send a narrow instruction, inspect the session and review its result. The most distinctive part comes when code generation ends.

Orchestrator can associate the worker with its pull request, observe checks and reviews, and route relevant feedback back to that worker. The product overview illustrates a loop in which a failing test is sent to the session that produced the branch, the agent makes a correction, and the new CI outcome appears on the same card.

This could reduce a familiar type of wasted attention. When a test fails on one of five PRs, we do not want to search through five independent transcripts and explain the context from scratch. We want the worker that knows the branch to receive the precise failing check and associated logs. That is orchestration with a purpose.

But routing a failure is not fixing a failure. The agent might misunderstand the stack trace or decide to silence the test instead of addressing the defect. Some checks are flaky; some problems originate in infrastructure; some integration issues require modifying another branch. A reliable system needs limits on automated retries and a clear moment when the user takes over.

I distinguish four milestones that a superficial progress bar might collapse into one: the agent has finished editing, the branch has a PR, CI has passed, and the change is safe to publish. The first two are activity indicators. The third is automated evidence. The fourth may require UX checks, privacy review, deployment verification or other acceptance criteria.

Reviewer agents are assistants, not release authorities

Orchestrator documents agents that review pull requests and communicate findings to the implementing worker. That can help surface missing tests, unclear error handling, dependency changes or security risks before a human reads the diff. The benefit is especially noticeable if a codebase has a strong specification and reusable review criteria.

I would still treat automated review as an additional filter, not a substitute for critical inspection. Two agents using similar assumptions can agree on the same mistake. A reviewer can miss a design regression because tests are green. A generated explanation of a diff can sound convincing while omitting the most important changed line.

A safer feedback cycle is bounded: request one review, address actionable comments, rerun relevant checks and escalate unresolved decisions. Unlimited self-review loops risk burning model budgets or gradually expanding the scope. If a worker edits twenty unrelated files while supposedly fixing one failing assertion, the orchestration system should help reveal that, not congratulate its persistence.

A lightweight SDD workflow

The value becomes clearer with a practical example. Suppose we are adding a language selector to a portfolio. A weak instruction is “implement multilingual support, split the work between agents.” A better start is “inspect the existing routing, translation data, components and tests; report what can be reused and what must change.”

The resulting plan could be short: preserve URLs, use the existing component system, make keyboard navigation work, ensure language variants remain in parity and verify current automated checks. Only then would I consider splitting the implementation into independent tasks. For example, one worker could develop a narrowly scoped UI component while another prepares an isolated test fixture, assuming their files do not overlap.

This is a small version of inspect → define acceptance criteria → plan → implement → verify → close. Orchestrator makes sessions easier to supervise, but it cannot supply the product decisions the developer has not made. Parallel ambiguity is still ambiguity.

An initial task contract might read: “Do not add dependencies. Keep existing URLs stable. Reuse translation helpers. Explain any change outside these directories. Request approval before any destructive Git operation or deployment.” Such constraints reduce accidental breadth more effectively than merely increasing the reasoning effort of the model.

When the work is ready, review each diff and check the combined behavior after merging. Two PRs can independently pass CI and still conflict once integrated. A supervising board should help us see those dependencies, but the final validation must run on the final integrated state.

For projects with a private development repository and public publication mirror, there is an additional boundary: building successfully does not prove that no secret or internal working document will be published. The release script and the contents of the public artifact deserve separate scrutiny. No generic agent dashboard can infer the entire privacy policy of a particular repository.

Visibility, previews and the problem of evidence

A session inspector can show changed files, the live terminal and a browser preview. That is useful for frontend work: it is easier to see whether the UI actually renders than to interpret a worker’s statement that the page “looks good.” It also avoids guessing which terminal owns which development server.

I would use the preview to inspect mobile overflow, keyboard focus, translation wrapping, network errors and console messages. These are concrete questions. Opening a browser window, by itself, is not a test. Neither is a screenshot an accessibility audit. If an agent claims that a layout issue is fixed, I still want the viewport and interaction that demonstrated the problem.

The same applies to terminal history. Useful observability records what commands ran, where they ran, what files were changed, which tests were executed and what never ran. A clean-looking chat transcript cannot establish these facts if the agent had direct shell access outside the structured interface.

It also pays to name tasks carefully. A session called “do some fixes” will be impossible to interpret a month later. A task titled “prevent mobile navigation overflow at 360px” can be associated with an acceptance criterion and a recognizable branch. Good naming is a low-tech practice that improves every orchestration product.

Ideally, the human should spend less time understanding what an agent was doing and more time deciding whether the result is worth keeping. This distinction matters because dashboards can themselves become a productivity trap. Watching a fleet work is not the same as delivering maintained software.

Mobile access is a different security boundary

The mobile application is a control surface for agents running on another machine. It is not necessary to move your entire codebase onto a phone. The Connect Mobile guide documents a separate listener that can be enabled for pairing, with a QR code and rotating connection credentials.

One security warning stands out: the daemon’s primary local API listens on 127.0.0.1 and is not designed for public exposure. The documentation explicitly warns against forwarding that unauthenticated interface through a public reverse proxy or Tailscale Serve. Mobile access has its own authenticated endpoint; this is not an invitation to expose the internal daemon port.

On a trusted home LAN, direct pairing may be sufficient. For access from outside the network, Orchestrator documents managed HTTPS tunnel mechanisms and platform-specific restrictions. In particular, it does not claim universally verified raw Tailscale pairing on every iPhone and Android configuration. I would test the actual device and network path before relying on it.

The QR is effectively a credential. Sharing a screenshot of it, putting it in a public issue or logging it in the wrong place is a security incident waiting to happen. The safe approach is to pair on a trusted network, keep remote listeners disabled when unused and rotate the connection password if exposed.

We also need to distinguish closing the UI, terminating the background service and suspending the physical machine. A daemon may outlive a window; a local agent cannot work through a fully suspended host. Cloud-based sessions have different operational assumptions and should not be described as merely another way to view a local process.

Running on a home Linux server: what to ask first

For a developer with a small Linux server, a laptop and an Android phone, a tool with remote control looks ideal. Before choosing one, though, I would ask a technical question: is the intended primary host an interactive desktop, or a headless server?

Orchestrator’s primary workflow is centered on a desktop application that starts its daemon. It offers desktop packages for Linux, but that does not automatically make it the cleanest choice for an unattended, headless service managed by systemd. Its remote connections require using documented authenticated paths. There is a difference between a supported desktop that stays running and a general-purpose server API intended for the public Internet.

That is where the comparison with Paseo becomes interesting. Paseo explicitly documents a CLI/server installation, a Docker image and a self-hosted web UI. Orca, meanwhile, documents SSH-connected worktrees as a development feature. OpenChamber has its own deployment and tunnel options. These are not cosmetic differences: the preferred process model affects reboot recovery, permissions, updates and how safely a phone reconnects after the network changes.

For any option, I would record where the agent CLI runs, who owns its process, where authentication tokens live, what survives a reboot and what remains reachable from an untrusted network. I would test those facts rather than inferring them from the availability of a mobile app badge.

Privacy: local code can still generate outbound data

A local process does not imply that every byte remains local. Agent harnesses may call hosted models, GitHub integrations use remote APIs, and optional relay or cloud features introduce their own endpoints. The Orchestrator FAQ additionally discloses production telemetry sent to PostHog.

The documented analytics can include an installation identifier, product usage and reliability data, repository-owner names and a GitHub username. Signing into Orchestrator Cloud introduces additional identity fields. According to the maintainers, the product telemetry does not include source files or conversation content, and session recording is disabled. There is an opt-out in the application’s privacy settings.

That is a substantially more precise description than either “the app sends all your code” or “open source means no tracking.” The former would be unsupported; the latter would be false. Repository owners and user identifiers can still be personal data, even if code contents are excluded.

My starting configuration for an important project would use least-privilege credentials, a clean working tree, narrowly defined writable directories and explicit review before publishing. I would keep unnecessary agent extensions disabled and examine what happens to logs and cached session data. Security is layered: Git permissions, host filesystem permissions, agent tool rules, tunnel authentication and the release pipeline all matter.

Git worktrees improve collaboration safety but do not constrain network egress. An agent that can read secrets in the user’s home directory may still access them despite having an isolated checkout. Where possible, test agents in dedicated operating-system accounts, restricted containers or temporary environments. Do not confuse organizational convenience with a security sandbox.

Pricing: zero application cost is not zero operating cost

The local product is described as free and open source under Apache 2.0. External agent providers retain their own pricing and usage limits. Running five expensive agents in parallel can improve throughput, but it can also burn through five budgets while creating five diffs that a human must inspect.

Cloud sessions are a separate offering. The pricing page lists free and paid tiers including Starter and Pro. The site’s landing page and dedicated pricing page currently show not entirely consistent numbers or limits for some cloud and device features. Rather than freeze disputed quotas in an article, I would verify the offered terms in the active account and release before making a purchase.

The more meaningful cost measure is accepted work per unit of attention. I would track how many tasks pass their acceptance tests without substantial rework, how often the developer must intervene and how long final review takes. A free orchestrator that sends workers into unbounded loops can cost more than a simpler workflow. Conversely, reliable feedback routing that prevents repeated manual triage can pay for itself in reduced cognitive overhead.

There are hidden maintenance costs too: updating CLIs, debugging auth failures, recovering disconnected terminals, adapting to model API changes and learning the interface. The orchestration layer is software, not magic. Its added complexity needs to earn its place.

A reproducible evaluation protocol

I would choose a small test repository and prepare five bounded scenarios: a reproducible bug, an accessibility improvement, a failing test, a feature touching a handful of files and a refactor that must preserve existing behavior. Each task starts from a known Git commit and has clear acceptance tests and forbidden out-of-scope changes.

Then I would run the same scenarios with the same model or equivalent provider settings wherever possible. I would record runtime versions, costs, permissions, retries and any manual actions. If one product is using a better model and another is constrained to a weaker one, the outcome cannot fairly be attributed to the orchestrator.

Useful measures include accepted tasks, minutes of human supervision, minutes of final code review, unexpected file changes, recovery time after a failing CI job and failures caused by worktree or terminal management. Keep the PR links and final diffs. A completed conversation does not count as success unless the code meets its tests and scope.

Two adversarial exercises are especially revealing. First, launch two genuinely independent jobs and see whether concurrency reduces total time. Second, deliberately create conflicting changes and observe how clearly the interface explains the problem. A dashboard that surfaces inconvenient truths may be more useful than one that hides them.

I would also test reconnection from Android, switching networks mid-session and safely losing access when the host sleeps. In a home-hosted setup, the secure remote experience can decide the entire choice. I cannot report comparative scores for these experiments here because I have not executed them. The protocol is a proposal that readers can replicate.

Limits and open questions

The first unresolved issue is adapter maintenance. Every external agent can change its flags, authentication method, event stream and session format. A large compatibility list is only meaningful when the specific operation you depend on actually works with your installed version.

Next is state recovery. What happens if the daemon restarts while the agent waits for approval? Does the application reattach to a durable session, detect an exited process or leave an ambiguous stale card? How are interrupted pull-request review loops resumed without repeating a destructive command? A reassuring interface is no substitute for explicit failure semantics.

Another concern is merge ordering. Two individually successful PRs can become incompatible when integrated. An orchestrator can route feedback and help display merge conflicts, but it does not repeal the need for updated tests on the final branch. Worktree isolation is the beginning of the integration problem, not its end.

Finally, the product can encourage more simultaneous work than a solo developer can reasonably review. Launching eight agents does not grant eight times as much judgment. Sometimes the optimal configuration is one focused worker, one reviewer and a clean backlog. A tool that makes delegation effortless should also make stopping unnecessary work effortless.

Sources and further reading

• Orchestrator.inc product site and product documentation.
• Go daemon, SQLite and controller architecture, quickstart and platform support.
• Authenticated mobile access, privacy and telemetry FAQ and pricing.
• Orchestrator open-source repository.
• Orca repository, features and license.
• OpenChamber docs and source repository.
• Paseo orchestration, server/CLI setup and relay security.

Final comparison: Orchestrator.inc vs Orca, OpenChamber and Paseo

These four products occupy an overlapping space: a development cockpit connecting a human to coding agents. But they optimize different moments of the workflow. This comparison reflects documented capabilities on October 26, 2026, not performance results, controlled reliability testing or a certified matrix of every operating-system version.

Criterion	Orchestrator.inc	Orca	OpenChamber	Paseo
Primary focus	Task → worktree → PR → checks → review	Parallel-agent development environment	Visual OpenCode control room	Multi-provider, multi-device daemon
Agent support	Many harnesses, varying capabilities	Numerous terminal-based agents	OpenCode ecosystem and models	Claude Code, Codex, OpenCode and others
Parallelism	Session-linked Git worktrees	Worktrees and side-by-side comparisons	Worktrees, Multi-run and Fusion	Worktrees and inter-agent delegation
Source control	Strong PR, CI and review-feedback loop	PRs, diff comments and task integrations	Git, PRs and guided change review	Diffs, PRs and terminal in one environment
Mobile experience	Paired companion to desktop daemon	Mobile companion app	Web/mobile/PWA depending on setup	Full native mobile app, web and CLI
Remote execution	Local desktop host, authenticated remote endpoint, optional Cloud	Documented SSH worktrees	Remote OpenCode and tunnels	Headless daemon, Docker, optional E2E relay
Natural fit	Managing several PRs through verification	Editor/terminal-heavy development	OpenCode-focused workflows	Self-hosting and device independence

Orchestrator.inc versus Orca: shipping workflow or development cockpit?

Orca describes itself as an agentic development environment. Its published capabilities emphasize rich split terminals, file editing, inline diff annotations, visual Chromium-based design context, SSH worktrees and running the same task across several isolated agents to compare results. Its mobile companion allows monitoring and follow-up instructions.

If your daily bottleneck is handling windows, changing working directories, editing alongside agents and giving visual UI feedback, Orca deserves close attention. It attempts to make the entire working surface comfortable.

Orchestrator’s strongest editorial proposition is different: keep the worker attached to the pull request, track its checks and direct review feedback back to the responsible session. Someone juggling several active PRs may value that traceability more than another editor. This is a distinction of emphasis, not an absolute claim that Orca cannot review PRs or Orchestrator cannot expose a terminal. I would start with Orca for intensive interactive editing and with Orchestrator for end-to-end PR supervision.

Orchestrator.inc versus OpenChamber: breadth of harnesses or OpenCode depth?

OpenChamber is principally a visual workspace for OpenCode. Its documentation covers session goals, worktree sessions, Multi-run across models, Fusion to combine approaches, guided change walkthroughs, Git and PR workflows, previews and secure remote access.

That specialization is not a weakness by definition. If you primarily use OpenCode, close integration with its capabilities may deliver a more coherent experience than a generic interface spanning many agents. Multi-run is especially appealing when you want to compare alternative solutions to a difficult task instead of merely dividing separate tasks among workers.

Orchestrator brings a broader set of coding harnesses into one delivery-oriented board, though different integrations support different interface and reviewer modes. A developer frequently switching between Claude Code, Codex and other tools may find that valuable. A developer deeply committed to OpenCode should try OpenChamber first. Breadth is not the same as capability parity.

Orchestrator.inc versus Paseo: pull-request supervision or device independence?

Paseo supports parallel agents, delegation between providers, worktrees and control from different machines. Its server documentation explicitly describes running a daemon from the CLI on a headless machine, using Docker and serving a web UI. Its optional relay design provides end-to-end encryption between client and daemon.

For someone running a small Linux computer continuously while interacting from a laptop, browser and Android device, that explicit self-hosting story is compelling. Paseo treats cross-device operation as a central architectural concern.

Orchestrator also has a daemon, mobile access and optional remote/cloud capabilities. But its distinctive workflow is following a worker all the way through PR review and CI correction. If your main worry is losing track of code-review feedback, try Orchestrator. If your main worry is keeping agents running on your own remote host with interchangeable clients, try Paseo. In either case, inspect the actual authenticated listener and recovery behavior before exposing anything outside your trusted network.

What I would choose as an indie developer

My provisional decision would be Orchestrator.inc for several simultaneous PRs tied to CI, Orca for everyday editing with multiple agents and terminals, OpenChamber for a deeply OpenCode-centered setup, and Paseo for a persistent Linux host controlled from multiple devices.

I would not award a definitive numeric winner without running equivalent tasks under controlled conditions. The interesting question is not which product can keep the largest number of agents busy. It is which one minimizes the time between a clear requirement and a reviewed, tested, safely published change.

The best orchestration tool is the one that lets you stop watching the agents without surrendering control of the software they ship.