Open source coding agent orchestrator

Your issue tracker is already the queue.

Sortie is the runner. It polls Jira, GitHub, GitLab, Linear or Gitea, gives every ticket an isolated workspace, launches the coding agent you already use, and follows the work through CI, review and merge. It installs as one file and runs on your laptop or on a server you already have. Nothing to install alongside it, and nothing phoning home.

$ curl -sSL https://get.sortie-ai.com/install.sh | sh

Also as a container image, and as release binaries for macOS, Linux and Windows on amd64 and arm64, each with a checksum and an SBOM.

Run your first ticket Read the source

Free and Apache-2.0. No account to create, no seat to buy, and no meter of ours between you and your agent.

What Sortie owns

Sortie does not make your agent smarter.

It assumes the agent already produces useful work when you run it by hand. Everything between that and a merged pull request is the part that does not exist yet, the part every team rebuilds ad hoc, and the part Sortie is.

The agent finishes and nobody moves the ticket.
The orchestrator writes the handoff transition, and can move the issue to a terminal state when the pull request it manages is merged. State machine
Two agents share one checkout and corrupt each other.
One isolated workspace per issue. Path containment and working-directory validation are enforced before launch, and retention is bounded by age. Workspace isolation
A run dies overnight and the state is gone.
State is written to disk as it happens. The retry queue, run history, session metadata and pending reactions are rebuilt on startup instead of lost. Resuming after a restart
CI turns red and the agent never learns about it.
CI status is read back through a provider interface, and the failure is injected into the retry prompt. CI feedback
A reviewer leaves six comments into the void.
Human review comments, bot reviews and merge conflicts are routed back to the session as reactions, deduplicated so the same comment is never answered twice. Review feedback
Nobody can say what last month cost.
Cumulative token counts per issue, a ceiling that stops the run before it overspends, and sortie stats over the recorded history. Controlling costs
The loop

Poll, dispatch, reconcile. Then do it again.

One process is the single authority for every scheduling decision. There is no external job queue and no distributed coordination to stand up first.

  1. 01 · POLL

    Read the tracker

    A query filter and a set of active states decide which tickets are in scope. Nothing else in your tracker is touched.

  2. 02 · DISPATCH

    Route the issue

    Dispatch rules pick an agent and a prompt template by label, issue type, priority, identifier or assignee. First match wins.

  3. 03 · ISOLATE

    Give it a workspace

    Every issue gets its own. Concurrency is capped globally and per state, effort is capped per issue by session count and token ceiling.

  4. 04 · REACT

    Follow the work

    CI failures, review comments, bot reviews, merge conflicts, the sortie:review and sortie:fix label commands, and auto-merge.

  5. 05 · HAND OFF

    Close the loop

    The issue is transitioned on completion, and can be moved to a terminal state when the managed pull request merges. Stalls, timeouts and retries are handled on the way.

Configuration

The whole configuration is one file, and the file is a prompt.

The block at the top says which tracker to read and which agent to run. Everything below it is the prompt, with each issue's own title, description and identifier filled in before the agent ever sees it. Sortie watches the file, so an edit applies without a restart.

WORKFLOW.md
---
tracker:
  kind: github
  api_key: $GITHUB_TOKEN
  project: acme/billing-api
  query_filter: "label:agent-ready"
  active_states: [todo, in-progress]
  handoff_state: review
  terminal_states: [done]

agent:
  kind: claude-code
  max_concurrent_agents: 4
---

You are a senior engineer.

Your task: {{ .issue.title }} ({{ .issue.identifier }})

## Context

{{ .issue.description }}

  • Two knobs, not a control plane

    Which tickets are in scope, and which agent runs them. Everything past that has a working default you can leave alone. Every field, explained

  • Switching agent is one line

    Change agent.kind and the next dispatch runs a different coding agent against the same tickets, with the same prompt. Adapter reference

  • The prompt is yours, in full

    Write it the way you already write prompts. Name a field that does not exist and the file refuses to load, instead of quietly handing the agent a blank space. Writing the prompt

  • Hot reload

    The file is watched. Edit the prompt, save, and the next session uses it. No restart, no redeploy, no in-flight work lost. Running several at once

  • Routing when one prompt is not enough

    Add a dispatch: block to send bugs to one agent and dependency bumps to another, matched on labels, type, priority, identifier or assignee. Dispatch rules

Integrations

Bring the tracker and the agent you already have.

Every integration sits behind an adapter interface. Nothing in the core is named after a vendor, and adding support for a new one is an additive change in a new package.

One caveat worth knowing before you pick: Kiro runs headless with no structured event stream, so token budgets and agent tools do not apply on that path. The other four agents carry the full feature set. Writing your own adapter

Agent tools over MCP

The agent can ask the orchestrator where it stands.

Sortie exposes an MCP server over stdio to the session it launched. No external connector to configure, no second set of credentials, and one result envelope across all five tools.

Day two

Built to be operated, not watched.

Parallel agents are only useful if you can leave them running. That means a metrics series you can alert on, a cost figure you can report, and a process that restarts cleanly.

Scope

Worth knowing before you install it.

The fastest way to be disappointed by an orchestrator is to expect it to be an agent. Here is the line, drawn on purpose.

Sortie is

  • An orchestrator for coding agents
  • A scheduler and runner
  • A tracker reader and handoff writer
  • One file to install, with nothing alongside it
  • Agent-agnostic
  • Tracker-agnostic

Sortie is not

  • A coding agent itself
  • A general-purpose workflow engine
  • A full tracker write layer
  • A hosted platform
  • Locked to one agent vendor
  • Locked to one tracker
Who runs it

Starts on one laptop. Survives a team.

Spec first

Every decision is written down, including the ones we reversed.

The architecture specification is the canonical description of the system, and drift from it counts as a bug in both directions. Twenty accepted decision records explain why one package per forge, why a workspace is kept by age and not by the state of its ticket, why the binary sends nothing home. Read them before you trust the code, or before you send a patch.

How it is built Full specification Decision records

Point it at a repository and a tracker.

Free, Apache-2.0, and the whole thing is one binary. The quick start takes a ticket to a pull request.

$ curl -sSL https://get.sortie-ai.com/install.sh | sh
Quick start GitHub Documentation