MVP to Production Series — m8tly.ai

Agency is Microsoft's internal platform for AI coding agents, built on top of GitHub Copilot CLI and Claude Code. This post walks through how to set it up from scratch — install, authentication, MCP tools, and custom agents — and explains why standardizing this setup across your team is worth the effort.

Introduction

The first thing most developers do when joining a new team is spend a day, even two - setting up their environment. Installing tools, hunting for the right credentials, figuring out which internal services they need access to, and reading through a setup doc that was last updated months ago.

Setting up AI coding agents properly from scratch has a learning curve of its own like which model, which tools, how to authenticate against internal systems, how to make the agent actually understand your codebase.

In this article I'd like to introduce you to a practice I have in my work setup at Microsoft. We call it Agency - a thin wrapper around GitHub Copilot CLI and Claude Code, pre-loaded with everything Microsoft engineers need to be productive from day one.

The idea is simple: extend the industry-standard tools. This post walks through exactly how to set it up, and how to push it further with tools, custom agents, and GitHub integration.

The Agency Model in Two Minutes

Before diving into commands, it helps to understand what Agency actually is. It sits between you and the underlying AI runtimes (GitHub Copilot CLI and Claude Code), adding four things that matter for engineering teams at scale.

The first is the engine. Agency lets you choose between GitHub Copilot CLI (agency copilot) and Claude Code (agency claude) depending on the task. Both are fully supported. You don't need to install or manage either runtime directly, Agency bundles and auto-updates them for you. You can think of an option to add any coding agent tool like OpenAI's Codex and more.

The second is tools. Rather than asking engineers to figure out MCP server configuration from scratch, Agency ships with a set of pre-built internal MCP servers: connections to Azure DevOps, GitHub, Kusto, Incident Manager, and more - that it wires up automatically based on context. In a GitHub repository, the right tools just show up.

The third is custom agents. These are Markdown files with YAML frontmatter that you drop into .github/agents/. Each one defines a specific persona, a set of tools, and a set of instructions. Think of them as reusable, shareable teammates: a code reviewer, a test specialist, a release manager. Once written, they work for your whole team.

The fourth is authentication. This is the part that usually causes the most friction on day one. Agency handles it through Entra ID, Microsoft's identity platform. You authenticate once with your corporate SSO and Agency takes care of the rest, no credential files to manage.

Together, these four layers mean that by the time you type your first prompt, the agent already knows your repo, has access to your internal tools, and is operating with the right permissions.

Why It Matters for Engineering Teams

At GTC 2026, NVIDIA CEO Jensen Huang made a pointed statement about what serious AI adoption actually looks like: "If that $500,000 engineer did not consume at least $250,000 worth of tokens, I am going to be deeply alarmed." [1] His argument is direct, give engineers AI tokens worth half their salary, and they become 10x more productive. Tokens, in Huang's framing, are the new compute budget for human output.

That's a compelling thesis. But token spend alone doesn't get you there. Those gains assume the tool is properly set up and integrated into the team's actual workflow. A developer with a half-configured agent, one that doesn't know the internal tools, can't access the right systems, and has no shared conventions captures a fraction of that upside regardless of how many tokens they burn.

Agency closes that gap by giving Microsoft engineers an opinionated, pre-configured starting point. It's the first layer of standardization: one install, one login, one shared set of tools and agents that every engineer on the team gets by default. GitHub integration is first-class since Agency is built on GitHub Copilot CLI, so it works natively in any GitHub repository with immediate access to your codebase, pull requests, and commit history.
Monorepo support is built in. And because agents and their configurations live in .github/agents/, they travel with the repo — every engineer who clones it starts from the same baseline.

For CTOs and tech leads, the practical implication is clear. There's no need for each engineer to independently set up their AI environment. You establish the configuration once, check it in, and it automatically extends to the entire team.

agency integrations

The Engineer's Guide: From Install to First Session

Getting Agency running takes about two minutes. Here's the full flow, step by step flow. Take this as an idea how to reuse it in your organzation.

Step 1 - Agency Installation

A one-liner for your operating system. This downloads the Agency CLI and adds it to your PATH automatically.

On Windows (PowerShell):

iex "& { (irm <internal-install-url>.ps1)} agency"

On macOS or Linux:

curl -sSfL <internal-install-url>.sh | sh -s agency && exec $SHELL -l

Step 2 — Log in

Launch an interactive session:

agency copilot
> /login

After typing login, users sign in with their corporate GitHub account. This is a one-time step Agency handles all authentication from here on, including access to the tools and services connected to his environment.

Step 3 — Run your first task

Describe what you want to do in plain language and the agent works through it, streaming its reasoning and code changes in real time. You can ask it to fix a bug, write a test, explain an unfamiliar module, or review a pull request. It has full access to your repository from the moment you start.

Agency detects the current repository automatically based on where you run it. If you're inside a GitHub repository, it reads the remote and loads the relevant MCP servers for that context - no extra configuration needed. Just cd into your repo before starting a session and Agency knows where it is.

agency copilot --prompt "Summarize what changed in the last three commits and why"

Extending Agency: MCP Tools, Skills, and Custom Agents

The extended experience is where Agency becomes a real force multiplier.

MCP tools are the connectors that give the agent access to external systems. Agency ships with several built-in ones out of the box. ado connects to Azure DevOps for work items, pull requests, and build status. kusto lets the agent run queries against your data clusters. Beyond those, Agency includes connectors for internal code search, incident management, and team messaging - each pre-authenticated, so the agent can interact with these systems without any additional setup on your end.

You can also add tools manually to a session with the --mcp flag. Example:

agency copilot --mcp kusto --mcp icm

For a more permanent setup, we add them to .vscode/mcp.json in the repository. This makes the configuration part of the codebase and available to every engineer on the team:

{
  "servers": {
    "ado": { "command": "agency", "args": ["mcp", "ado"] },
    "kusto": { "command": "agency", "args": ["mcp", "kusto", "--service-uri", "https://mycluster.kusto.windows.net"] }
  }
}

Authentication for all of these is handled automatically via Entra ID. No additional login steps.

One thing I'd like to highlight is Microsoft's WorkIQ tool. WorkIQ is actually Microsoft's intelligence personalization layer for Microsoft 365 built on three integrated layers: data (secure access to M365 tenant data, Dynamics 365, external sources via Copilot Connectors), context (explicit and implicit memory, semantic index, business understanding), and skills & tools (agentic instructions and custom toolsets). It's what makes Copilot CLI context-aware for each user and organization.

Skills sit between MCP tools and custom agents in terms of scope. A skill is a SKILL.md file - a Markdown file with a short YAML frontmatter block that has a name and description.

A skill might encode how your team writes tests, how to run the deployment pipeline, or how to triage a specific type of bug. The agent picks it up automatically when the situation calls for it, without you having to invoke it by name.

When you start an agency copilot session, the agent scans all SKILL.md files in .github/skills/ (and ~/.copilot/skills/ for personal ones) and reads only their YAML frontmatterת specifically the name and description fields.

The simplest skill looks like this:

---
name: test-conventions
description: How we write and structure tests in this repository
---

Always use the arrange-act-assert pattern. Test files live alongside source
files with a `.test.ts` suffix. Use `describe` blocks to group related cases
and keep each test focused on a single behavior.

Custom agents are where you encode your team's specific workflows. An agent is a Markdown file with a YAML header and a body that works as the agent's instructions. Here's a minimal example:

---
name: code-reviewer
description: Reviews code for quality, best practices, and potential issues
---

You are a code review specialist. Analyze code for quality, maintainability,
best practices, potential bugs, security issues, and performance. Provide
specific, constructive suggestions for improvement.

Create it with:

agency create code-reviewer --type repo

This creates the file in .github/agents/code-reviewer.md. Run it with:

agency copilot --agent code-reviewer

You can go further: add specific MCP servers to the agent's frontmatter, bundle NuGet or Universal packages as artifacts, or define input variables to parameterize behavior. A test specialist agent will look quite different from a release manager agent, even though both use the same underlying runtime.

Going Further: Sharing Agents Across Teams

Once you've built agents that work well, you don't have to keep them to yourself. Agency has two marketplaces for sharing.

The Playground is an open contribution space for experimental agents. It's the right place to put work-in-progress agents or domain-specific tools you want feedback on. Browse what others have built with agency list --source playground and run any of them with agency copilot --agent <name> --source playground.

The company-wide catalog is a vetted collection of agents available across Microsoft engineering. These have gone through a review process and represent patterns that have worked at scale. If an agent you've built in the Playground proves useful beyond your team, the promotion process moves it into the broader catalog.

Both marketplaces mean that onboarding a new team member stops being an individual configuration exercise. They install Agency, log in, and immediately have access to the same agents and tools as everyone else on the team.

Conclusion

Setting up an AI coding environment used to mean making a lot of small decisions: which tools, which models, how to authenticate, which conventions to encode. Agency collapses most of those decisions into one install command and a login.

For individual engineers, the payoff is immediate - less friction, more focus. For teams, a shared setup that lives in the repository means everyone starts from the same place without any coordination overhead. And for engineering leaders, it moves AI adoption from something people do inconsistently on their own to something the team actually builds on together.

The AI teammate is already configured. You just need to invite it.

References

[1] NVIDIA CEO Jensen Huang at GTC 2026, via The Decoder. "Nvidia CEO Jensen Huang says he'd be deeply alarmed if a $500K developer spent less than $250K on AI tokens." https://www.aol.com/articles/jensen-huang-says-deeply-alarmed-040314321.html