Kolega
Bitrise runs Kolega, an internal coding agent that lives in Slack. A Jira ticket assigned to its Jira user or an @mention in a thread starts a session; the agent reads the requirements, posts a plan, and delegates the coding to a disposable Remote Dev Environment. It opens a pull request, watches CI, and reacts to review comments, CI results, and Jira events as they arrive, then cleans up the machine and closes the ticket after the merge. The orchestrator itself cannot run or read code. Bitrise published bitclaw, an MIT-licensed reference implementation of the same architecture.
- Company
- Bitrise
- Approach type
- Agent
- Work
- Coding, Code review, CI triage, Maintenance
- Human involvement
- Drafts reviewed
- Invocation
- Interactive, Event-driven
- Interfaces
- Slack, Jira, Github, Ci
- Deployment stage
- Deployed
- Evidence strength
- Detailed primary
- Entry reviewed
How it works
Jira ticket assignment or Slack mention through delegated coding in a disposable dev environment to a human-instructed merge and ticket closure.
Assigning a Jira ticket to Kolega's Jira user, or an @mention in a thread, starts a session; the agent posts a card within a second, reads the requirements, posts a plan, and then reports milestones only[Source 1]
The orchestrator creates a Remote Dev Environment from a pinned template with a self-contained task brief naming the repository, the ticket, the acceptance criteria, and the branch rules[Source 1]
The coding agent in the dev environment makes the change, runs the tests locally, pushes the branch over git, and the pull request is opened and reported back to the thread[Source 1]
Review comments, CI results, Jira comments, and the merge itself arrive in the owning thread as they happen; the agent fixes what a reviewer asked for, answers questions on the ticket, and reacts to events rather than polling[Source 1]
Merging happens only on an explicit human instruction; after the merge the agent tears down the dev machine, transitions the ticket, and signs off in the thread[Source 1]
Where people stay involved
People review, approve, or guide the agent’s work here.
Reported: Humans review the pull request and then give an explicit merge instruction; the agent may not merge on an approval alone, and every write the outside world can see waits behind an Approve / Reject button.
Supervision level
Work-product review
A person reviews the draft or implementation.
Level 3 of 5
- Jira ticket assignment or Slack mention → merged pull request[Source 1]
Implementation details
- Model
- Claude. The orchestrator holds one persistent Claude conversation per Slack thread, and the dev-environment template installs Claude Code for the coding agent; no model version is named[Source 1]
- Harness
- A single small Python service orchestrating from Slack. One Slack thread is one session; the orchestrator creates and drives Remote Dev Environment sessions through the RDE MCP server, typing instructions into the coding agent's tmux pane and reading the pane back[Source 1]
- Sandbox
- A disposable Remote Dev Environment per task, created from a single pinned template whose warmup script installs Claude Code, sets up a git-only SSH identity, and starts the agent in a tmux session; every task gets its own machine, and the machine is deleted when the work is done[Source 1]
- Tool access
- Narrowly scoped orchestrator tools: post to Slack, read and manage pull requests, read Jira, query Datadog for logs, metrics, and error tracking, and create and drive Remote Dev Environments. The orchestrator has no shell and no file access and cannot read source code through the GitHub API; those tools are denied in code rather than in the prompt. The coding agent inside the dev environment holds a push-scoped SSH key and no GitHub API access, so git is its only interface to the outside world[Source 1]
- Knowledge
- Not reportedThe agent pulls what it needs at run time through scoped tools and the working tree in the dev environment; no retrieval corpus, index, or company knowledge store is described.
- Context management
- One Slack thread is one session backed by one persistent Claude conversation, so context survives messages, webhooks, and days-later follow-ups. Pull requests and tickets are anchored to the thread that owns them, so review comments, CI results, and Jira transitions arrive in the right conversation. The thread receives milestones only, not the agent's running commentary[Source 1]
- Credentials
- Credentials reach the coding machine through encrypted saved inputs and session inputs and are never baked into an image. The coding agent receives a push-scoped SSH key and no GitHub API access, and the orchestrator's own credentials never touch the machine[Source 1]
- Interfaces
- slack
- jira
- github
- ci
Mechanisms
Jira assignment or Slack mention → plan → delegated coding in a disposable dev environment → pull request → reactions to review and CI events → human-instructed merge, cleanup, and ticket closure[Source 1]
The orchestrator has no shell and no file access and cannot even read source code through the GitHub API; the tools are denied in code, not in the prompt, so it plans, relays, narrates, and asks[Source 1]
The coding agent's push-scoped SSH key and lack of GitHub API access mean that a prompt injection hidden in a codebase reaches no further than a pushed branch that still has to survive human review[Source 1]
The task brief instructs the coding agent to pick the most defensible default, document the assumption in the commit message and pull request description, and continue, because the pull request review is where wrong assumptions get corrected[Source 1]
Validation and failure handling
Dev-environment sessions run on the same infrastructure and stacks as Bitrise CI, so passing tests in the session and in CI stop being different claims; when CI fails the orchestrator relays the failing check into the session and the coding agent reproduces it[Source 1]
Untrusted authors' text is redacted before the model sees it, every public write waits behind an Approve / Reject button in Slack, and the agent holds when it cannot confirm that an author is trusted, a repository is private, or a check succeeded[Source 1]
Reported observations
These results come from the sources. Notes below each result explain what it covers and any reported limits.
Bitrise describes a design-system migration touching around 200 usages across 167 files that Kolega planned, delegated, and then shepherded for four days through three rounds of merge conflicts and nine automated review comments, with the humans involved only reviewing[Source 1]
One design-system migration Kolega handled during a recent week
About this result
- Category
- Implementation scale
- Evidence type
- Qualitative
- What it covers
- One design-system migration Kolega handled, in usages, files, days, merge-conflict rounds, and review comments
Bitrise describes the orchestrator as a single small Python service that was mostly written by a coding agent and went from first commit to handling real tickets in a few weeks[Source 1]
Building the Kolega orchestrator service
About this result
- Category
- Implementation scale
- Evidence type
- Qualitative
- What it covers
- Size, authorship, and elapsed build time of the Kolega orchestrator service
Lessons
Bitrise puts its guardrails in code rather than in the system prompt: which tools exist, whose text the agent may read, and what needs approval are hard checks rather than prompt instructions.[Source 1]
Bitrise keeps humans on two decisions, merging and anything the outside world can see, and lets planning, coding, testing, and replying to reviewers run without a human in the middle.[Source 1]
Each Bitrise guardrail followed an incident: the agent once merged its own pull request the moment it saw an approval, so merging now happens only on an explicit human instruction.[Source 1]
Bitrise handles a stop command outside the normal message queue so that it interrupts a running turn, and holds when the agent cannot confirm that an author is trusted, a repository is private, or a check succeeded.[Source 1]
Reported opinion: The Bitrise team prefers to delegate the thinking rather than only the typing: its orchestrator does not read source code even to plan, on the view that the coding agent in front of the full working tree should plan its own work.[Source 1]