Skip to content
Colony Docs

Sponsor

You charter and govern the colony. You don’t author issues, review PRs, or operate the pipeline day-to-day. You decide what work the colony is allowed to do, how much budget it can spend doing it, and when to expand or pull back.

If this is you: engineering managers, directors, IT leaders evaluating or funding a Colony rollout, anyone who owns the budget that pays for it.

What this role does

Section titled “What this role does”
  1. Charter — decide which repos, teams, and work types the colony is responsible for
  2. Set risk envelopes — define cost caps, automerge thresholds, escalation rules
  3. Track — read the rollups that tell you whether the colony is paying for itself
  4. Expand or pause — scale up successful patterns; pull back when something’s off

Charter

Section titled “Charter”

A Colony rollout is a chartered scope, not an unconstrained deployment. The questions to settle up front:

  • Which repos? Start with one. The “pilot” pattern is intentional — read Team Patterns → pilot patterns.
  • Which teams? The team whose work fits the colony best is rarely the one volunteering loudest. Look for teams with clear acceptance criteria and a high ratio of issues with file references.
  • Which work types? Bug fixes and well-scoped features land cleanly. Refactors and exploratory work need more human steering. Set scope deliberately.
  • What’s the success metric? Throughput, cycle time, cost-per-issue, escaped defects — pick the one that matters and commit to measuring it for at least 90 days before re-scoping.

Set risk envelopes

Section titled “Set risk envelopes”

Three levers control how much risk Colony takes on your behalf:

  • Per-issue cost cap. A budget ceiling per issue. Hits the cap → escalates to the Operator. Set conservatively at first; raise after a month of data.
  • Automerge threshold. What confidence level allows Colony to merge without human review. Default conservative; loosen per repo as confidence builds.
  • Human-review-required labels. Issues or PRs matching certain labels always go through human review. Use this for compliance-sensitive code, customer-data paths, or repos with high blast radius.

Track

Section titled “Track”

The rollups that matter:

  • Throughput — issues completed per week, by repo, by work type
  • Cost per issue — total spend ÷ issues completed; broken down by analyzer, developer, reviewer, merger
  • Cycle time — file → merged. Often the most credible metric for an enterprise audit.
  • Agent attribution — which work types Colony handled vs. which still needed human intervention. Trends matter more than weekly snapshots.
  • Escape rate — defects shipped that originated in Colony work. The best metric for whether the colony is actually paying for itself.

For audit conversations, all four metrics are exportable as a CSV with full attribution per issue: who authored, which agent worked, when each transition occurred, total cost.

Expand or pause

Section titled “Expand or pause”

The decisions that come back to you:

  • Expand to more repos. Wait until the pilot’s escape rate is at or below your existing baseline for human-only work. Two months of data is the minimum.
  • Expand to more work types. Refactors and exploratory work need more .colony/conventions.md investment than bug fixes. Plan the convention work before you expand the scope.
  • Pause an active rollout. Almost always the right call when an incident touches Colony’s surface area. Pausing is reversible; rushing through an incident isn’t.
  • Pull back permanently. Rare. If you find yourself considering it, the failure is usually upstream — .colony/conventions.md is wrong, or the work was outside Colony’s competent envelope, or the team isn’t using it the way you chartered. Diagnose before you cut.

Where you engage in the Workflow

Section titled “Where you engage in the Workflow”

The Sponsor role is mostly out-of-band — you read the dashboard, review reports, sign off on scope changes. The pipeline runs without you in the loop on most issues.

Your tools

Section titled “Your tools”
  • Dashboard rollups — throughput, cost-per-issue, agent attribution; the load-bearing surface for this role
  • Audit log export — for compliance, legal, security conversations
  • Per-tenant settings — risk envelopes, automerge thresholds, scope policies
  • The Sponsor page itself — yes, you. Pointing your engineering managers and directors at this page is part of the job.

Anti-patterns

Section titled “Anti-patterns”
  • Setting a per-issue cost cap tighter than the average epic. Silent throttling without escalation; see callout above.
  • Reading throughput without reading escape rate. A colony that ships a lot of broken code is worse than no colony at all. Always read both metrics together.
  • Expanding scope after a single good month. One month of clean throughput is luck or coincidence. Two months minimum before scaling.
  • Pausing the colony over the wrong incident. If the incident is in the colony’s surface, pause. If the incident is elsewhere and Colony just happens to be running, leave it alone — pausing creates additional disruption.
  • Treating Colony as a hiring substitute. Colony augments staff; it doesn’t replace judgment, taste, or domain knowledge. The Sponsor’s job is to keep that distinction visible to peers and execs.

Going deeper

Section titled “Going deeper”