AI engineering control plane for GitHub

Manage the work. Orchestrator manages the agents.

Shape features, architecture, and priorities in GitHub. Orchestrator coordinates specialized agents to plan, implement, audit, and review the work, then surfaces only the decisions that need you.

See the workflow

Agents run locally Provider keys stay local GitHub remains the work ledger

acme/platform

GitHub Project · Delivery

Feature parent · #172

Govern production deployments

Architecture decision attached · 3 child issues

parent item pinned

One level above the sessions

Stay at the level of the work.

GitHub holds the plan. You steer scope, architecture, priority, and approval. Orchestrator handles the agent sessions beneath that work and keeps project state synchronized.

You manage

The outcome and the decisions.

Feature scope

Architecture

Priority

Approval

Orchestrator manages

The execution loop and its evidence.

Plan

Inspect the repository and turn intent into finishable work.

Claim

Promote eligible work and move a Ready item into progress.

Execute

Run the selected specialist inside an isolated local workload.

Return evidence

Attach branches, PRs, reviews, events, or a precise blocker.

Issue Planner

Turn the rough idea into work agents can finish.

The planner reads the repository before asking questions, checks for duplicate work, and proposes either one standalone issue or one parent with focused child issues and real blocker relationships.

Rough briefread-only

Add a workspace audit trail for organization administrators.

Repository inspected

Existing issues compared

One decision needed

How long should audit events be retained?

Proposed GitHub work

One parent. Three finishable changes.

Review before creation

Tracking parent

Add the workspace audit trail

Persist structured audit events

Database migration · unit tests · CLI evidence

Build the administrator audit view

Accessible UI · filtering · visual evidence

Blocked by 01

Document retention controls

Operator docs · validation steps · PR evidence

The planning model sees a read-only checkout. It receives no GitHub credential and no GitHub mutation tool during the interview.

Specialized roles

Specialists share one work ledger.

Planning, implementation, pull-request review, and repository auditing stay separate so each role has a clear trigger, runtime, and verifiable outcome.

Issue Planner

Inspects the repository, asks only for missing decisions, and drafts work you can approve before GitHub changes.

Runs when: A rough feature or architecture brief
Leaves behind: One issue or a parent with focused child issues

Provider · model · thinkingTrusted planner image

Code Agent

Claims eligible project work and carries the implementation through branch, commit, validation, and pull request.

Runs when: A GitHub Project issue becomes Ready
Leaves behind: Branch, PR, issue comment, and validation trail

Provider · model · concurrencyDefault, local, or registry image

PR Review

Reads the diff and nearby code, leaves concrete findings, and records a separate merge-readiness summary.

Runs when: An eligible open pull request
Leaves behind: Inline findings and a verified review marker

Provider · model · instructionsDefault, local, or registry image

Repository Review

Runs scheduled, read-only audits and turns evidence-backed maintenance findings into deduplicated work.

Runs when: The repository audit becomes due
Leaves behind: Parked Backlog issues, ready for prioritization

Provider · model · scheduleDefault, local, or registry image

Privacy by architecture

The SaaS coordinates. Your machine does the work.

The hosted app never asks you to paste or store OpenAI, Anthropic, or OpenRouter credentials. Configure Codex OAuth, a Claude setup token, or provider API keys in the local runner environment instead.

GitHub OAuth remains a hosted integration; AI provider credentials do not.

Hosted SaaS

Control plane

Job contract and repository configuration
GitHub Project coordination
Events, health, usage, and outcome evidence

Not sent here

Provider API keys, provider OAuth roots, and a hosted copy of your source checkout.

Outbound WebSocket from your runner

Your computer or infrastructure

Local Orchestrator runner

outbound only

kind / Kubernetes job pod

per job

Repository agent

Docker-based tool image, local checkout, and scoped GitHub access.

Trusted inference sidecar

Receives only the selected provider credential and exposes inference on localhost.

persistent workspace where neededshort-lived pod and secrets

Returns sanitized provider availability, job events, token telemetry, status, and verified outcome evidence.

No provider keys stored in the hosted app

Source checkouts stay in your environment

Outbound-only runner connection

Isolated workload per job

Short-lived credential boundary

Per-agent controls

Choose the brain and tools for each job.

Compatible models come from authenticated OpenAI, Anthropic, and OpenRouter catalogs. The exact provider, model, and supported thinking level are pinned for each job with no silent substitution. The Docker image comes from the agent configuration at dispatch; a running workload keeps the image it started with.

Docker-based repository tools run inside the local kind/Kubernetes cluster. Use the Orchestrator defaults or a trusted local or registry image; provider root credentials remain isolated from ordinary agent containers.

Provider, model, thinking level, and Docker image configuration by agent
Agent	Provider	Model	Thinking	Docker image
Code	Provider: OpenAI	Model: Live catalog choice	Thinking: Supported level	Docker image: Orchestrator default / custom
Issue Planner	Provider: Anthropic	Model: Live catalog choice	Thinking: Pinned per plan	Docker image: Trusted default
PR Review	Provider: OpenRouter	Model: Live catalog choice	Thinking: Supported level	Docker image: Orchestrator default / custom
Repository Review	Provider: Per-agent choice	Model: Live catalog choice	Thinking: Supported level	Docker image: Orchestrator default / custom

Reliability and attention

Healthy work stays quiet. Exceptions rise.

The runner reconnects automatically, active jobs survive socket reconnects, stale leases return to the queue, and planning interviews resume from saved state.

Connection recovery

Capped backoff reconnects the outbound runner without duplicating active work.

Saved evidence

Events, token use, branches, pull requests, reviews, and failures stay attached to the run.

Honest blocked states

Usage limits and missing decisions become explicit blockers with a reason instead of silent churn.

thanusiv/bayshore

runner online

Healthy work

The loop keeps moving.

03 / 04

Code#184 Deployment approvals12m

PR review#48 Header navigation cleanup4m

Repository reviewScheduled auditnext

Needs judgment

One run is blocked

Issue #42 needs a retention-policy decision before work can continue.

View evidence

Last heartbeat: 8s ago
Saved events: 27

One runner, then the loop runs

From sign-in to managed work.

Connect GitHub

Choose a repository and the GitHub Project that should remain the shared work ledger.

Install the local runner

The CLI verifies Docker, kind, and kubectl, pulls the website-specified trusted images when missing, and prepares the local kind/Kubernetes cluster.

Enable the work loop

Move work to Ready. Orchestrator claims it, runs the right specialist, and returns evidence to GitHub.

Official CLI

Install once. Run it from anywhere.

Install the official Homebrew release on macOS or Linux, then connect it to the workspace with a one-time runner token.

Before you run the CLI: install Docker, kind, and kubectl, then make sure Docker is running.

macOS + Linux

Homebrew

Install: brew install interesta-ai/tap/orchestrator
Upgrade: brew upgrade interesta-ai/tap/orchestrator
Uninstall: brew uninstall orchestrator

Verify the installed command with orchestrator --version.

Start the work loop

Run agents at the level of the work.

Connect one repository and let Orchestrator coordinate the planning, implementation, review, runtime, and evidence behind it.