Source: https://internal-agents.com/agents/bitrise-kolega # Bitrise — 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](https://internal-agents.com/organizations/bitrise) - Collection: Agents - Approach type: Agent - Deployment stage: Deployed - Autonomy: Drafts reviewed - Evidence strength: Detailed primary - Status: Internal - First reported year: 2026 - Work: Coding, Code review, CI triage, Maintenance - Interfaces: Slack, Jira, Github, Ci - Invocation: Interactive, Event-driven - Entry reviewed: 2026-09-21 ## Purpose ### Summary 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. Fact · Reported · High confidence · `bitrise-kolega--summary` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 14, 16, 28, 44, 68 Representative workflow: Jira ticket assignment or Slack mention through delegated coding in a disposable dev environment to a human-instructed merge and ticket closure. ## How it works ### Pick up the work and post a plan 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-1` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 28, 32-33, 35 ### Delegate the coding to a disposable dev environment 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-2` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 77, 78 ### Write and test the code, push a branch, and open a pull request 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-3` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 14, 38-39, 79 ### React to anchored events without a human relay 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-4` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 44, 67 ### Merge on an explicit human instruction, then clean up 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-5` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 42, 44, 89 ## Where people stay involved - **Jira ticket assignment or Slack mention → merged pull request** — Work-product review · Level 3 **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 evidence #### Operating model assessment Level 3 for Jira ticket assignment or Slack mention → merged pull request; human attention boundary: work-product-review. Inference · Catalog judgment · High confidence · `bitrise-kolega--operating-models-0` Confidence reason: The post states that on a four-day migration the humans involved did exactly one thing, review, and that merging now happens only on an explicit human instruction after the agent once merged on seeing an approval. Review is of the pull request itself, which places the boundary at the work product rather than at the outcome. Qualifications: - Observation date: 2026-07 Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 48, 51, 89, 107 ## Implementation details ### 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 Fact · Reported · High confidence · `bitrise-kolega--architecture-sandbox` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 77, 79, 81 ### 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 Fact · Reported · High confidence · `bitrise-kolega--architecture-harness` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 59, 65, 82 ### 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 Fact · Reported · High confidence · `bitrise-kolega--architecture-model` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 65, 77, 105 ### Interfaces slack, jira, github, ci Fact · Reported · High confidence · `bitrise-kolega--architecture-interfaces` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 14, 28, 66, 67 ### 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 Fact · Reported · High confidence · `bitrise-kolega--architecture-tool-access` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 66, 68, 79 ### 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 Fact · Reported · High confidence · `bitrise-kolega--architecture-credentials` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 77, 79 ### 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 Fact · Reported · High confidence · `bitrise-kolega--architecture-context-mgmt` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 35, 65, 67 ### Ticket-to-merge loop in one Slack thread 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-0` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 14, 37-42 ### An orchestrator that cannot code 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-6` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 63, 68 ### Isolation as the security model 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-7` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, line 79 ### Never block on input 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-8` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, line 78 ### Implementation coverage - **Model:** reported - **Harness:** reported - **Sandbox:** reported - **Tool access:** reported - **Knowledge:** unreported — The 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:** reported - **Credentials:** reported - **Interfaces:** reported ## Validation and failure handling ### Test in an environment that matches CI 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-9` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, line 80 ### Gate public writes and fail closed 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 Fact · Reported · High confidence · `bitrise-kolega--primitives-10` Confidence reason: A linked first-party source states the claim. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 89, 92 ## Reported observations Observation: Implementation scale · Qualitative · One design-system migration Kolega handled, in usages, files, days, merge-conflict rounds, and review comments ### Key observation 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 Fact · Reported · Medium confidence · `bitrise-kolega--key-metrics-0` Confidence reason: Bitrise reports the file and usage counts for one migration in its own engineering blog without a measurement method; it describes the scale of one task, not a measured result. Qualifications: - Scope: One design-system migration Kolega handled during a recent week Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, line 48 Observation: Implementation scale · Qualitative · Size, authorship, and elapsed build time of the Kolega orchestrator service ### Key observation 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 Fact · Reported · Medium confidence · `bitrise-kolega--key-metrics-1` Confidence reason: Bitrise states the service size, its authorship, and an approximate build time in its own engineering blog; no line count, commit history, or dated milestone supports the few-weeks figure. Qualifications: - Scope: Building the Kolega orchestrator service Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, line 59 ## Lessons ### Lesson 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. Fact · Reported · High confidence · `bitrise-kolega--lessons-learned-0` Confidence reason: The post states the rule and names the enforced case: the orchestrator's shell, file, and GitHub source-read tools are denied in code rather than in the prompt. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 68, 88 ### Lesson 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. Fact · Reported · High confidence · `bitrise-kolega--lessons-learned-1` Confidence reason: The two retained decisions are stated explicitly, and the merge gate and the Approve / Reject button on public writes are described as the mechanisms that hold them. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, line 90 ### Lesson 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. Fact · Reported · High confidence · `bitrise-kolega--lessons-learned-2` Confidence reason: The post names the specific incident and the specific rule change it produced; it does not say how often the incident occurred or what other guardrails each incident produced. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, line 89 ### Lesson 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. Fact · Reported · Medium confidence · `bitrise-kolega--lessons-learned-3` Confidence reason: Both behaviors are described as implemented rules with their triggers named; the post gives no example of either firing, so the effect on real runs is not documented. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, lines 91, 92 ### Lesson 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. Opinion · Reported · Medium confidence · `bitrise-kolega--lessons-learned-4` Confidence reason: This is the team's stated design preference for its own orchestrator, supported by the reported fact that the orchestrator does not read source code; the post offers no comparison against an orchestrator that plans from source, so the preference is not shown to generalize. Evidence: - Supports · [1] [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) · [Preserved copy](https://github.com/steel-experiments/internal-agents-map/blob/main/archive/sources/bitrise-kolega-source-1/content.md) · Preserved content.md, line 93 ## Question coverage and scope - **purpose:** Reported - **workflow:** Reported - **human involvement:** 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. - **implementation:** Reported - **validation:** Reported - **observations:** Reported — Bitrise reports no performance metric for Kolega: no throughput, acceptance rate, cost, or time saved. Both recorded observations describe the scale of the work and of the build, not a measured result. - **lessons:** Reported ## Sources 1. [How we built a coding agent that lives in Slack, and the recipe to build your own](https://bitrise.io/blog/post/how-we-built-a-coding-agent-that-lives-in-slack-and-the-recipe-to-build-your-own) - Engineering blog · First party · Evidence - Original URL: - Publisher: Bitrise · Published: 2026-07-15 · Accessed: 2026-09-21 · Last verified: 2026-09-21 - Preserved copy in the repository: