Sortie
Turn issue-tracker tickets into parallel, recoverable coding-agent sessions.
Per-dimension scores and reasoning
The CI workflow uses read-only default permissions, disables persisted checkout credentials, and pins third-party Actions to commit hashes. The security policy also states path containment, workspace-name sanitization, execution-directory checks, environment-variable indirection for secrets, and non-logging of secret values. The README says Sortie sends no telemetry and clearly attributes architectural prior art to OpenAI Symphony; the license and repository origin are also explicit, justifying full source-attribution credit. Deductions apply because the supplied implementation cannot verify the stated security invariants; the orchestrator runs agents capable of code and network side effects without showing minimized agent privileges, per-action confirmation, or approval gates; tracker feedback can create external writes whose scope and confirmation controls are unclear; and retained run history is not evidence that commits, tracker writes, or other external effects can be rolled back. Dependencies and Actions are versioned, an automated update path and vulnerability-reporting policy exist, but no vulnerability scan, SBOM, or evidence that the listed versions are free of known vulnerabilities is supplied.
The README, SECURITY policy, go.mod, and CI are mutually consistent about a Go single-binary design, cross-platform scope, SQLite persistence, and the maintenance model, with no direct contradiction found; self-consistency is therefore strong. Static linking and a small direct dependency set reduce runtime requirements, although the installer endpoint, issue trackers, coding agents, and optional services remain external availability dependencies. The material states that failed runs are retried, history survives restarts, and security reports follow a defined response process. Deductions reflect the absence of concrete user-facing runtime error formats, retry limits, backoff rules, unrecoverable-error classification, and partial-failure examples.
The intended users, problem scenarios, five tracker families, and six coding-agent families are explicitly identified, with local or server operation, parallel sessions, and live WORKFLOW.md updates, so audience and scenario coverage is thorough. The security policy separates Sortie, third-party agent, and deployment-hardening responsibilities and names security boundaries, but actual restrictions on agent commands, network access, and capabilities depend on configuration and architecture material not supplied. Triggering is described as matching selected issues through WORKFLOW.md, but matching syntax, deduplication, race handling, and false-trigger safeguards are not shown. CI covers Linux, macOS, and Windows, while deployment prerequisites, containers, and detailed tracker-agent compatibility remain underdocumented in the provided files.
The README has a clear structure covering the problem, compatibility, installation, operation, documentation, prior art, and licensing; naming across WORKFLOW.md, the Go module, and security terminology is stable. The full Apache-2.0 text is present and agrees with the metadata, justifying full license credit. Installation includes a script, Homebrew, a service-free demo path, and a normal onboarding path, but the piped remote script lacks an accompanying checksum, pinned release, or manual-install alternative. Examples are largely external links plus one test script, with no substantive FAQ in the supplied material. The security policy documents support windows, scope, and reporting routes well, but general operational limitations are sparse. Semantic versioning and a CHANGELOG update path are stated, although the CHANGELOG itself is absent. Maintenance channels, timelines, and a security address are clear, but the publisher is not registry-verified and no named maintainers or governance structure are shown.
Outputs are made actionable through retained run history, progress and cost tracking, and optional CI or review feedback loops, which supports ordinary engineering use. The evidence does not show an actual session report, patch-delivery format, review interface, or completion-decision example, so output usability is not demonstrated comprehensively. Combining existing coding agents and trackers with isolated workspaces, retries, and persistence provides clear marginal value over manually launching each task. A single binary, SQLite, and parallel execution reduce deployment burden and cost tracking aids oversight; deductions apply because compute, token, storage, concurrency, and maintenance costs are not quantified and no benchmark or case study substantiates the benefit.
Most principal claims map to specific supplied artifacts, including dependency versions, cross-platform CI, workflow permissions, licensing, and the support policy. Deductions apply because important security and functionality claims are documentary assertions without the corresponding implementation, referenced architecture section, CHANGELOG, or full test suite in the evidence. The files provide some cross-corroboration around dependencies, platforms, credential handling, and testing strategy, but there is no independent source or complete source-level corroboration. Product claims, security policy, and CI configuration are generally separated clearly, yet efficiency claims and assertions such as never logging secrets or sending no telemetry are not explicitly distinguished as implementation-proven facts versus design requirements in the supplied source.
- The orchestrator launches third-party agents that may modify code, access networks, and write back to trackers; constrain filesystem, command, network, and token privileges separately for each agent before deployment.
- Do not treat the assertions in SECURITY.md as implementation verification of path isolation, secret redaction, or telemetry absence; the corresponding implementation was not included.
- The installation command pipes a remote script directly to a shell; controlled environments should download, inspect, and verify a pinned installer release first.
- Automatic retries and parallel runs can duplicate or amplify external side effects; avoid irreversible workloads until deduplication, retry limits, approval gates, and recovery procedures are confirmed.
- The publisher identity is unknown, not presumed suspicious; organizations should establish trust through their own supply-chain and maintainer due diligence.
What does this agent do, and when should you use it?
Sortie is a self-hosted coding-agent orchestrator written in Go that assigns issue-tracker work to multiple coding agents in parallel. A single WORKFLOW.md file defines which issues to select, which agent to run, and what instructions it receives. Each task runs in an isolated workspace, while execution history, progress, and cost information persist across restarts. Failed runs can be retried automatically, and CI failures or review comments can be sent back to an agent for further work. Sortie is delivered as a single binary, persists state in SQLite, requires no separate database or job queue, and states that it sends no telemetry itself.
Sortie selects matching tickets from GitHub Issues, GitLab Issues, Gitea Issues, Linear, or Jira according to a WORKFLOW.md file. That file also chooses a supported coding agent—Claude Code, Copilot, OpenCode, Codex, Kiro, or Gemini—and supplies its instructions. The orchestrator creates an isolated workspace for each issue, launches sessions in parallel, and records run history, progress, and costs. It retries failed runs automatically and can feed CI failures and review comments back to the agent when those feedback paths are enabled. Workflow configuration can be updated without restarting Sortie, and SQLite preserves orchestration state.
- An engineering team maintaining several repositories wants to dispatch selected GitHub, GitLab, or Gitea issues to trusted coding agents in parallel.
- A Jira- or Linear-based product team wants tracker tickets converted into isolated, retryable coding sessions.
- A DevOps team wants CI failures and code-review feedback returned to an agent so it can continue correcting a change.
- A team using Claude Code, Codex, Copilot, OpenCode, Kiro, or Gemini wants one self-hosted service to orchestrate those tools.
- A small team wants persistent run and cost tracking without operating a separate database server or job queue.
What are this agent's strengths and limitations?
- Directly supports five issue-tracker families and six coding-agent products, reducing dependence on a single provider.
- Runs tasks concurrently in separate workspaces and automatically retries failed sessions.
- Persists run history across restarts while tracking progress and costs.
- Can return CI failures and review comments to an agent for another correction cycle.
- Uses a single-binary and SQLite deployment model with no separate database or queue, and states that it emits no telemetry itself.
- Adoption still requires connection settings, credentials, and permissions for every selected tracker and coding agent, none of which are specified in the supplied material.
- End-to-end automation depends on external trackers, coding agents, and optionally CI and review systems; their outages or limits can interrupt runs.
- The supplied material does not show the WORKFLOW.md schema or an actual startup command, making initial configuration effort difficult to assess.
- Although the architecture is described as having pluggable adapters, no custom-adapter API or compatibility guarantees are provided here.
How do you install or deploy this agent?
On a machine or server with a shell and network access, run:
curl -sSL https://get.sortie-ai.com/install.sh | shOn macOS, Homebrew is also supported:
brew install --cask sortie-ai/tap/sortieThe supplied material does not state supported operating-system versions, the installation destination, minimum Go or system requirements, or a command for verifying the installation.
How do you use this agent?
Create a WORKFLOW.md that selects the issues to process, names the coding agent to run, and provides its instructions; Sortie then picks up matching issues and starts sessions. For an evaluation without external services, follow the documented local-demo path, which uses a simulated agent. A real deployment requires configuration for the chosen tracker and coding agent. The supplied material does not include the WORKFLOW.md schema, an exact command for starting Sortie, environment-variable names, or the credentials and permission scopes required by each integration, so a complete copyable first invocation cannot be derived from this source alone.
How does this agent compare with similar options?
Sortie explicitly credits OpenAI Symphony as architectural prior art. Compared with Symphony's Elixir reference implementation, Sortie uses Go for simpler deployment, SQLite instead of in-memory state, pluggable adapters rather than hardcoded Linear and Codex integrations, and orchestrator-managed handoff transitions instead of relying solely on agents to write completion state back to a tracker.