Azure Boards in.Azure Repos out.
Agent Smith picks up a work item from Azure Boards, clones your Azure Repos into a sandbox, writes the change, runs your tests, and opens the pull request in Azure Repos. Then it moves the work item to the state you called done.
No GitHub mirror in between. It runs in your own estate and calls the model you already pay for.
Why this page exists
If your tickets live in Azure Boards and your code lives in Azure Repos, you have probably asked whether Copilot can take a work item and hand back a pull request. It can, as long as the code sits on GitHub. Microsoft says so on its own page: the integration "requires GitHub repositories and GitHub App authentication. Azure Repos (Azure DevOps Git repositories) aren't supported" (Use GitHub Copilot with Azure Boards, as of its update on 2026-07-23).
Copilot's code review did make it to Azure Repos (public preview since August 2026). Reviewing a pull request somebody already wrote is a different job, though. Writing it from the ticket is the part that is missing, and that is the part Agent Smith does.
If Microsoft ships Azure Repos support tomorrow, this page gets a new date. We'd still run Agent Smith there, for the reasons further down.
What happens to a work item
It routes by tag, area path or repository
A project in Agent Smith says which work items belong to it: tag them TodoList, put them under an area path, or name the repository. A service hook posts to Agent Smith when a work item changes, or it polls with WIQL if you can't open a port to it. Comments and image attachments on the work item go to the model along with the description.
Every repository gets its own sandbox
A product spread over four Azure Repos gets four sandboxes, each on the toolchain image that repository builds with. The agent works in all of them at once and opens one pull request per repository, and each pull request links to the others.
Green means your tests passed
Each repository declares how it is verified, and the run is only called done when those commands pass on the change it actually committed. A red verification still opens the pull request, as a draft, so the work is there to look at and nothing unverified looks mergeable. Afterwards every acceptance criterion gets its own verdict, with the evidence it rests on. You can overrule a verdict you disagree with, and the reason you give is kept.
The work item hears back
The work item moves to your done state and gets a comment with every pull request link and the run id. If the ticket is too thin to act on, it goes to your needs-clarification state with the questions, and your answer in the comments resumes the run.
Before there is a work item
A ticket is often one line long, and the thinking it needs hasn't happened yet. So the dashboard has a page called Work it out, where you talk the change through with an agent that reads your actual repositories while it answers. When you both agree, it proposes a specification: one work item, or a list of them in the order they can merge, each naming the ones it requires. You approve that, and Agent Smith files them in Azure Boards, with the work item type you mapped (User Story, Bug, whatever your process uses).
Each work item's run works exactly its approved specification, spec by spec, and a spec only starts once the one before it has verified. Microsoft's page lists as a limitation that Copilot "doesn't handle dependencies between work items". Agent Smith does: every work item it files gets a Dependency link to the ones it requires, and it starts only when those have merged.
It stays in your estate
Agent Smith runs on your Kubernetes cluster or on a single Docker host. It needs a Personal Access Token with Code and Work Items read and write, and nothing on GitHub. For the model, point it at your Azure OpenAI deployment and the code never leaves your tenant. Anthropic, OpenAI, Gemini or a local Ollama work too, and you can pick a different model for each role.
Sign-in to the dashboard goes through your own OpenID Connect authority, Entra ID included, and roles map from your groups. Every run keeps its full trail of tool calls, and what it cost.
And if half your teams are on Jira
It's the same product. Jira, GitHub Issues and GitLab work as trackers, and GitHub and GitLab as code hosts, so one installation can serve an Azure DevOps team and a Jira team side by side. The main page tells that story.
Have a look.
The Azure DevOps guide wires a tracker, four repositories and a project in the configuration studio.