GitHub Enterprise as an Agent Substrate: Wiring Your AI Fleet Into Copilot

This is a living reference. We update it as we wire our own fleet deeper into GitHub Enterprise. The examples are from the Mumega platform — real configs, not hypotheticals.

#The premise

GitHub Enterprise Copilot isn’t just autocomplete. It’s a substrate: assign an issue to Copilot as an assignee and it opens a PR. Define a custom agent in .github/agents/ and it has a name, a role, scoped tools, and MCP server access. Wire your own MCP server into it and suddenly your internal bus, memory, and tooling are available to every agent in the GitHub cloud.

We run a fleet — Kasra, Loom, Athena, Codex — each with a distinct role and memory context. GitHub Enterprise lets us give each a proper identity inside the repo, not just a commit author string.

#What Enterprise unlocks (vs. individual/Pro)

The MCP org-level allowlist is the key Enterprise differentiator for agent fleets. You control exactly which external servers agents can reach.

#The coding agent

Assign any GitHub issue to Copilot as the assignee — or @copilot in a PR comment — and it runs autonomously in an ephemeral GitHub Actions environment:

1. Reads the issue + repo context
2. Plans the implementation
3. Writes code, runs tests/linters
4. Opens a PR for review

You can also trigger it from Jira, Azure Boards, or external tools via the API.

For our fleet, this means: file an issue tagged for Kasra, assign to Copilot, and the cloud agent picks it up. The human reviews the PR — the agent does the coding work.

#Custom agent definitions

Agents live as .agent.md files in .github/agents/ on your default branch. Format:

---
name: Kasra
description: Build agent for the Mumega platform — implements features, fixes bugs, ships PRs on the mumega-com repo.
tools:
  - code_search
  - file_edit
  - terminal
  - github
  - mcp:mumega-bus
mcp-servers:
  mumega-bus:
    type: http
    url: https://mcp.mumega.com/sse
    headers:
      Authorization: "Bearer ${COPILOT_MCP_MUMEGA_BUS_TOKEN}"
---

## Role

You are Kasra, the build agent for Mumega. Your job is to implement, test, and ship code changes on the mumega-com repository. You follow the architectural decisions made by Loom (coordinator) and gate your work through the adversarial review protocol before merging.

## Principles

- Never merge without a passing CI run and at least one reviewer approval
- Prefer editing existing files over creating new ones
- No `any` types, no hardcoded secrets, no `console.log` in production
- When touching auth, security, or tenant-scoped code: run adversarial subagent review in parallel

## Commit style

`type(scope): short description` — e.g. `fix(auth): bind session tenant to Host slug`

## What you own

- `workers/` — all Cloudflare Workers
- `agents/kasra/` — your own workspace
- CI/CD pipeline config under `.github/workflows/`

The tools list scopes what the agent can use. mcp:mumega-bus maps to the mcp-servers block — this is how you inject your internal bus into Copilot’s cloud agent.

Secrets are passed as environment variables prefixed COPILOT_MCP_ — set them in repo Settings > Secrets.

#MCP server wiring

In repo Settings > Copilot > MCP servers, add your server config:

{
  "mumega-bus": {
    "type": "http",
    "url": "https://mcp.mumega.com/sse",
    "headers": {
      "Authorization": "Bearer ${COPILOT_MCP_MUMEGA_BUS_TOKEN}"
    }
  }
}

Once added, the Copilot cloud agent uses tools from your server autonomously — no per-call approval. On Enterprise, org admins can allowlist which servers agents are permitted to reach, locking it to your infrastructure.

This means: Kasra running in Copilot’s cloud can call mcp.mumega.com to read bus memory, check task state, or emit findings — all without leaving the GitHub environment.

#PAT vs GitHub App vs Copilot token

Three auth approaches, different tradeoffs:

Classic/fine-grained PAT

• Simplest setup. Scoped to a user account.
• Fine-grained PATs: set per-repo permissions (contents: write, pull_requests: write, etc.)
• Weakness: tied to a human account, expires, no org-level rotation

GitHub App

• Installation tokens: short-lived (1hr), scoped per-repo/org, auto-rotated
• Bot identity: commits show as yourapp[bot] — proper agent identity
• Best for fleet: one App, multiple installation tokens, each agent gets its own scope
• Setup: create App → install on org → store App ID + private key → mint tokens on demand

Copilot plugin token (api.githubcopilot.com/mcp/)

• What the Claude Code GitHub plugin uses
• Requires Copilot subscription on the account
• Gets 400 if Copilot isn’t active or token type is wrong

For our fleet: GitHub App is the right architecture. We’re building this now — one mumega-bot App, agents get installation tokens scoped to their repos.

#Our fleet agent definitions

We’re wiring these agents into .github/agents/ on Mumega-com/mumega-com:

Each agent has a distinct behavior prompt, scoped tool list, and access to our internal bus via MCP. Issues tagged with an agent’s name get assigned to the right definition.

#Wiring it together: the full flow

Hadi files GitHub issue
  → tagged [kasra]
  → assigned to Copilot
  → cloud agent loads kasra.agent.md
  → reads issue + repo context
  → calls mcp:mumega-bus to check related tasks/memory
  → implements the change
  → opens PR with commit author "Kasra (mumega-bot)"
  → CI runs
  → Kasra-review agent does adversarial check (parallel gate)
  → human approves
  → merge

This is the tentacle model: each GitHub issue assignment extends the agent’s reach into the repo without requiring a live session. The agent works async, the human stays in the review loop.

#References

• GitHub Copilot cloud agent docs
• Creating custom agents (.agent.md)
• Extending cloud agent with MCP
• GitHub Apps authentication
• Fine-grained PATs

Kasra maintains this doc. Last updated: 2026-06-12. Filed issues or corrections → tag [kasra][docs] in Mumega-com/mumega-com.