Azure with AJ

Azure DevOps vs GitHub: Your 2026 Platform Decision

Mon, 08 Jun 2026 19:00:00 +0000

The question I get asked more than almost any other right now is deceptively simple. Azure DevOps vs GitHub, which one should we be standing on in 2026? It used to be a tooling preference. After Microsoft Build 2026, it is a strategy decision.

The short version is that both platforms are alive and supported, but only one of them is where the future is being built. If you read the Microsoft Build 2026 announcements closely, Microsoft drew a line as clean as a lightsaber cut. GitHub is the home of agentic development, and Azure DevOps is the stable, well supported workhorse that keeps doing its job without chasing the frontier.

This post unpacks what was actually announced, what it means for your teams, and how to plan a migration that does not blow up your delivery in the process. No hype, just the practical read.

TL;DR

GitHub is now the agent native control centre for planning, coding, review, security, and agents.
Azure DevOps continues with incremental improvements, with Microsoft committed to improving code quality in pull requests and helping developers remediate security issues faster. Boards, Pipelines, and Test Plans are not going anywhere.
Microsoft recommends a hybrid model, GitHub repositories with optional Azure DevOps orchestration.
Enterprise Live Migrations (ELM) now enable low downtime repository moves from Azure DevOps to GitHub.
Azure DevOps basic usage rights are included with GitHub Enterprise, so you are not paying twice to run both.
The industry is shifting from DevOps to Agentic DevOps, and your platform choice should reflect that.

The Real Difference in 2026

For years the comparison was feature for feature. Repos, pipelines, boards, artefacts. Both platforms covered the basics, so teams picked based on history, cost and habit. That framing is now out of date.

The real difference today is intent. GitHub is being built as an AI native platform where agents are first class participants in the software lifecycle. Azure DevOps is being maintained as a mature, predictable suite that prioritises stability over novelty. Neither position is wrong, but they pull in different directions.

If your strategy depends on AI agents doing meaningful work across planning, code, and review, the gap between the two platforms is now wide and growing.

What Microsoft Really Announced at Build 2026

Build 2026 was not subtle about direction. The headline was that GitHub is the home of agentic development, and the rest of the announcements reinforced it.

The GitHub Copilot App as the Control Centre

The standout was the GitHub Copilot app positioned as the agent native control centre. Instead of treating agents as a feature bolted onto an editor, the Copilot app becomes the place where you assign work, watch agents collaborate, review their output, and ship the result.

This builds directly on the Agent HQ vision I covered in Welcome Home, Agents. The difference in 2026 is maturity. What felt experimental last year now feels like the default way of working.

GitHub Gets the Newest Capabilities First

The pattern across the announcements was consistent. The newest capabilities across planning, coding, review, security, and agents land on GitHub first. Agentic planning, autonomous code review, security remediation by agents, and tighter agent collaboration are all GitHub stories.

This is the part engineering leaders need to sit with. It is not that Azure DevOps is being switched off. It is that the innovation budget is clearly pointed at GitHub.

Azure DevOps Keeps Calm and Carries On

Azure DevOps was not abandoned, and that matters. Microsoft confirmed continued investment, with a clear focus on improving code quality in pull requests and helping developers remediate security issues faster, rather than chasing new frontier features.

Critically, teams can keep using Azure Boards, Azure Pipelines, and Azure Test Plans. If those tools fit how your organisation runs, you are not being forced off them. They remain supported, hardened, and dependable.

graph TD
    A[Microsoft Build 2026] --> B[GitHub: Agentic Future]
    A --> C[Azure DevOps: Stable Workhorse]
    B --> D[Copilot App Control Centre]
    B --> E[Newest Capabilities First]
    C --> F[Security and Code Quality]
    C --> G[Boards, Pipelines, Test Plans]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style C fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style D fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style E fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style F fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style G fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a

When to Use Each Platform

So how do you choose? Rather than a religious war, think about where each platform earns its place.

Lean towards GitHub when you want to:

Put AI agents at the centre of planning, coding, and review
Adopt new capabilities as soon as they ship
Standardise on a single platform for code, security, and collaboration
Attract engineers who expect a modern, agent native experience

Stay comfortable with Azure DevOps when you:

Rely heavily on Azure Boards for established planning and reporting
Have mature, business critical Azure Pipelines you do not want to disturb
Depend on Azure Test Plans for structured, manual test management
Need a stable surface while you plan a measured transition

The honest summary is this. GitHub is where you invest for the future, and Azure DevOps is where you protect what already works. This is not about choosing a hero and a villain, both have a job to do.

The Industry Shift: DevOps to Agentic DevOps

None of this happens in a vacuum. The bigger story is the shift from DevOps to Agentic DevOps, a theme I have been tracking since DevOps: Dead or Evolved.

Traditional DevOps automated the pipeline. Agentic DevOps puts intelligent agents inside the workflow, taking on planning, code changes, reviews, and remediation as active collaborators.

When you frame Azure DevOps vs GitHub through that lens, the choice becomes clearer. You are not just picking a repository host. You are deciding how ready your platform is for agents to do real work.

A Pragmatic Hybrid Migration Path

Here is the reassuring part. You do not have to rip and replace. Microsoft is recommending a hybrid model, and it is genuinely sensible.

The pattern is GitHub repositories for code, security, and agents, with optional Azure DevOps orchestration where Pipelines or Boards still add value. Your source of truth moves to GitHub, while the orchestration you trust keeps running until you are ready to consolidate.

Two announcements make this practical. First, Azure DevOps basic usage rights are included with GitHub Enterprise, so running both during a transition does not double your bill. Second, Enterprise Live Migrations now enable low downtime repository migration from Azure DevOps to GitHub, which removes the classic fear of a big bang cutover.

graph LR
    A[Azure DevOps Today] --> B[Hybrid Phase]
    B --> C[GitHub Native]
    B --> D[GitHub Repos and Agents]
    B --> E[Optional ADO Pipelines and Boards]

    style A fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style B fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style C fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style D fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style E fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a

A migration that respects your delivery looks roughly like this.

Assess and prioritise. Map your repositories, pipelines, and boards, then rank them by risk and value.
Move code first. Use Enterprise Live Migrations to bring repositories across with low downtime, starting with lower risk projects.
Run hybrid deliberately. Keep Azure Pipelines or Boards orchestrating while the team settles into GitHub.
Introduce agents. Turn on agentic planning, coding, and review in the Copilot app on the migrated repositories.
Consolidate when ready. Retire the Azure DevOps surfaces you no longer need, on your timeline, not a forced one.

The goal is momentum without disruption. You gain the agentic capabilities of GitHub while protecting the orchestration your teams rely on.

Key Insights for Engineering Leaders

A few takeaways are worth holding onto.

This is a strategy call, not a tooling preference. The platforms now point in different directions.
Stability and innovation are both valid. Azure DevOps stability is a feature, not a consolation prize.
Hybrid is the responsible default. It lets you adopt the future without betting the quarter on a migration.
Agents change the value equation. The sooner your code lives where agents are first class, the sooner your teams feel the lift.

Conclusion and Next Steps

Azure DevOps vs GitHub in 2026 is not really a contest of features. It is a question of where you want your engineering organisation to be standing as agentic development becomes the norm.

Build 2026 made the answer plain. GitHub is the agent native future, Azure DevOps is the dependable present, and the hybrid path lets you honour both. Start by mapping your estate, pick a low risk repository, and try a live migration with agents switched on. Let the results make the case, because do or do not when it comes to agents, the teams that commit are the ones the Force favours.

For the wider context on this shift, the official Microsoft Build announcements and the Azure DevOps and GitHub AI Era article are the best places to go deeper.

Are you planning a move from Azure DevOps to GitHub, or running a hybrid setup already? Share your experiences and questions in the comments below, I would love to hear how your teams are approaching it.

How to Organise GitHub Copilot Customisations at Scale

Sun, 17 May 2026 19:00:00 +0000

If you’re trying to organise GitHub Copilot customisations across an enterprise, the hardest part usually is not creating the agent or the skill. It’s deciding where everything should live, how it should be shared, and which pieces should appear automatically versus stay self serve.

After untangling this for my own org, and losing a few hours to one buried prerequisite, I landed on a pattern that is simple enough to operate and structured enough to scale. One source of truth for every customisation, automatic distribution for agents, and marketplace with self serve for everything else.

This post focuses on that operating model. It is not a full catalogue of every Copilot customisation feature, but a practical pattern for organising them in a way platform teams can actually manage.

TL;DR

Use two repositories with automation connecting them. A central agent-platform repository holds every supported customisation, and acts as your Copilot plugin marketplace. A second repository named .github-private distributes a curated set of approved agents automatically to every user. A GitHub Actions workflow syncs and flattens those agents on merge, while plugins remain available through the marketplace for optional install.

I validated the behaviour described here against GitHub Copilot enterprise features available in May 2026, because this area is moving quickly and the finer points of distribution can change.

The Confusion Nobody Talks About

GitHub Copilot has quietly grown a sprawling customisation surface. In the last year alone we’ve gained:

Custom agents (.agent.md)
Instruction files (.instructions.md and copilot-instructions.md)
Skills (SKILL.md bundles)
Hooks
Plugins and plugin marketplaces
AGENTS.md for shared project context

Each one has its own discovery rules. Some are repo scoped, some are user scoped, some are org scoped, and some only appear if you enable a setting buried three menus deep. Teams end up with customisations scattered across personal directories, workspaces, teams channels, and probably some other hidden treasure trove nobody can find.

The question I kept asking myself is simple. Where should this stuff live, and how do I share it across the org without asking every developer to clone five repos?

The Pattern: One Source of Truth, Two Distribution Channels

The answer is to separate storage from distribution. Store everything in one place, then use the right GitHub mechanism to distribute each type.

graph TD
    A[agent-platform repo<br/>Source of Truth] --> B[Plugin Marketplace]
    A --> C[Instructions, Skills, Hooks]

    E[.github-private repo<br/>Org Distribution] --> F[Auto-discovered Agents]
    E --> G[settings.json points to plugin marketplace]

    A -.->|GitHub workflow syncs<br/>agents on merge| E

    F --> H[Developer IDE]
    B --> I[copilot cli or via IDE]
    C --> J[Self-serve via cli or manually]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style E fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style B fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style C fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style F fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style G fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style H fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style I fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style J fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff

Repo 1: `agent-platform` (Source of Truth)

This is where every customisation in your org actually lives. It’s a normal repository, structured however makes sense for your team, and it doubles as a Copilot plugin marketplace.

A workable layout:

agent-platform/
├── agents/                   # All custom agents (full versioned set)
│   ├── azure-architect/
│   │   ├── azure-architect.agent.md
│   │   └── README.md
│   └── engagement-builder/
├── instructions/             # .instructions.md files
├── skills/                   # Reusable SKILL.md bundles
│   ├── waf-review/
│   │   └── SKILL.md
│   └── bicep-refactor/
├── hooks/                    # Hook scripts
├── plugins/                  # Composable plugins published through the marketplace
└── .github
    ├── plugin
        ├── marketplace.json  # Plugin marketplace manifest

Everything is versioned, reviewed via pull requests, and owned by a CODEOWNERS rule. This is the repo your platform team curates. Everything else flows from here.

Repo 2: `.github-private` (Automatic Org Distribution)

GitHub treats a repository named .github-private in your organisation as a magic distribution channel for Copilot custom agents. Any .agent.md file in .github-private/agents/ automatically appears in every org member’s IDE agent picker. No cloning, no installing, no settings to flip on the user side.

This is brilliant, and it has one caveat that will absolutely bite you.

The flat structure rule: .github-private/agents/ only supports top level .agent.md files. Nested folders are ignored. If you put .github-private/agents/azure/architect.agent.md, it will silently fail to surface.

So .github-private looks like this:

.github-private/
├── agents/
│   ├── azure-architect.agent.md       # Surfaces automatically
│   ├── engagement-builder.agent.md    # Surfaces automatically
│   └── code-reviewer.agent.md         # Surfaces automatically
└── .github
    ├── copilot
        ├── settings.json              # Pointer to your plugin marketplace in the agent-platform repo

This repo mirrors a curated subset of what lives in agent-platform. We can also configure a GitHub workflow to automatically sync agents from agent-platform into .github-private when they’re merged and approved, eliminating manual copy-paste and ensuring .github-private always stays in sync with the source of truth.

Linking the Two Repos via the Plugin Marketplace

The settings.json in .github-private is what stitches it all together. It tells Copilot CLI in every org member’s environment where to find your plugin marketplace.

{
  "extraKnownMarketplaces": {
    "MARKETPLACE-NAME": {
      "source": {
        "source": "github",
        "repo": "OWNER/REPO"
      }
    }
  },
  "enabledPlugins": {
    "PLUGIN-NAME@MARKETPLACE-NAME": true
  }
}

Once enabled, developers using Copilot CLI can browse and install plugins directly from your marketplace:

# List available plugins from the org marketplace
copilot plugin marketplace browse MARKETPLACE-NAME

# Install a plugin
copilot plugin install azure-waf-reviewer@MARKETPLACE-NAME

For the full marketplace schema and enterprise governance options, see the GitHub docs on configuring enterprise plugin standards.

Referencing Skills and Templates from Agents

Because skills and supporting assets live in agent-platform rather than .github-private, your distributed agents need a way to pull them in. Two patterns work well.

Raw GitHub URL references in the agent definition:

---
name: azure-architect
description: Reviews Azure designs against the Well Architected Framework
---

When asked to review an architecture, fetch and apply the WAF review skill:
https://raw.githubusercontent.com/acme/agent-platform/main/skills/waf-review/SKILL.md

Use the bicep refactor skill for any IaC changes:
https://raw.githubusercontent.com/acme/agent-platform/main/skills/bicep-refactor/SKILL.md

This pattern is simple, but it depends on the consuming environment being able to read those raw URLs. If agent-platform is private, or your enterprise network controls block that access path, package the skill inside a plugin instead. In practice, raw URLs are best for lightweight and openly reachable assets, while plugins are the safer default for governed enterprise distribution.

Plugin bundles for anything more complex than a single skill. Bundle the agent, its instructions, skills, and hooks together as a plugin in your marketplace and let developers install the whole package with one command.

The Caveat That Cost Me Hours

Here’s the bit that cost me hours. You can set up .github-private, configure settings.json, push perfectly formed .agent.md files, and nothing will appear. No error, no warning, no clue.

The reason: custom agents in .github-private only surface if your enterprise has explicitly enabled the org for custom agents in AI controls. By default, no org is enabled.

To turn it on:

Navigate to your enterprise (from the Enterprises page on GitHub.com).
At the top of the page, click AI controls.
In the Custom agents section, select the Select organization dropdown.
Click the organisation that contains your .github-private repo.

That’s it. The moment you enable the org, agents start appearing in IDEs across your tenant. Full details are in the GitHub docs on preparing for custom agents.

If you remember nothing else from this post, remember this step. It’s the difference between a working rollout and a confusing afternoon staring at empty agent pickers.

Governance and Ownership

A pattern this powerful needs a few guardrails.

CODEOWNERS on agent-platform so every agent change is reviewed by the platform team
Branch protection on .github-private to prevent drift since it’s generated by workflow automation
GitHub workflow with automated sync that copies vetted agents from agent-platform to .github-private on merge, with optional filtering by agent tags or directories
Workflow approval gates so sync only happens after maintainer review (optional but recommended for production orgs)
Versioning on all supported copilot customisations so consumers can pin or upgrade deliberately

This mirrors how mature platform teams treat shared infrastructure modules. Agents are infrastructure for developer productivity. Treat them like it.

Wrapping Up

The reason teams struggle with Copilot customisations isn’t because the features are bad. It’s because there’s no opinionated guidance on where things should live and how they should reach developers. The pattern I’ve laid out, one agent-platform repo as source of truth, one .github-private repo for automatic distribution, and a plugin marketplace stitching them together, gives you the best of both worlds. Centralised governance and frictionless adoption.

If you want to go deeper, the official docs on preparing for custom agents and configuring enterprise plugin standards are essential reading. And if you haven’t yet, check out my earlier post on Agents as Code for the philosophy behind treating agents as first class engineering artifacts.

How is your org organising Copilot customisations today? Have you hit the flat structure rule or the AI controls gotcha? Share your war stories in the comments, I would love to hear them.

Agents as Code: Treating AI Agents as Versioned Artifacts

Sat, 11 Apr 2026 19:00:00 +0000

We version our infrastructure. We version our pipelines. We version our policies. So why are most teams still treating their AI agents like throwaway prompt snippets floating in someone’s clipboard?

If you’ve been following the Agentic DevOps journey on this blog, you’ll know I’ve been tracking how AI agents are reshaping development workflows. From the coding agent to agentic workflows, the trajectory has been clear: agents are becoming core development infrastructure, not just fancy autocomplete.

GitHub Copilot now supports custom agents defined directly in your repository, with full workspace awareness, tool access, and MCP connections. With over 60,000 open source projects already adopting AGENTS.md files and GitHub’s analysis of 2,500+ repositories revealing clear patterns of what works, agents as code is the next evolution of how engineering organisations standardise, govern, and scale AI-assisted workflows.

TL;DR

Custom agents defined in your repository (.agent.md files in .github/agents/) combined with AGENTS.md for shared project context are the new standard for embedding AI into development workflows. They’re versioned, reviewed, and shared like any other code artifact. This post covers how to structure them, what governance you gain, and practical patterns for adoption.

The Problem: Agents Without Anchors

Let’s be real for a second. Right now, most teams are using AI coding assistants in full Wild West mode, everyone has their own prompts, their own mental model, and their own bag of tricks. The result?

Inconsistent behaviour: Each developer’s AI writes code in a different style because they prompted it differently
Knowledge silos: That brilliant system prompt your senior engineer crafted lives in their personal settings and walks out the door when they do
No audit trail: When an AI agent breaks something, there’s no traceable instruction set to review
Zero governance: Security teams have no visibility into what instructions guide AI behaviour

Sound familiar? These are exactly the problems we solved with Infrastructure as Code. Before IaC languages like Terraform, Bicep, Pulumi, and CloudFormation became standard, infrastructure was undocumented folklore and snowflake configurations. We fixed it by codifying everything into versioned, reviewable artifacts. Agents deserve the same treatment.

AGENTS.md vs Custom Agents: Know the Difference

This is the distinction most teams get wrong. Two separate mechanisms exist and they serve fundamentally different purposes.

AGENTS.md: The Operating Manual

An AGENTS.md file at the root of your repository is a passive, always-on instruction set for any AI coding agent. Think of it as a README written for agents instead of humans: build commands, code style, testing instructions, and boundaries that every agent should respect.

# AGENTS.md

## Setup Commands

- Install deps: `pnpm install`
- Run tests: `pnpm test`

## Code Style

- TypeScript strict mode, single quotes, no semicolons

## Boundaries

- Never commit secrets or API keys
- Never edit `node_modules/` or `vendor/`
- Always run lint and test before committing

It’s cross-platform (works across GitHub Copilot, OpenAI Codex, Gemini CLI, Cursor, Windsurf, and more), nestable in monorepos, and stewarded by the Agentic AI Foundation under the Linux Foundation.

Custom Agents (.github/agents/): The Specialist Roles

Custom agents in .github/agents/ are active, switchable personas you invoke by name. Each .agent.md file creates a mentionable specialist (e.g., @test-agent) with its own tools, model preferences, and workflow handoffs.

---
name: test-agent
description: Writes and maintains unit tests for this project
tools: ["editFiles", "terminal", "search"]
model: Claude Sonnet 4.5 (copilot)
---

You are a quality software engineer specialising in test coverage.

## Boundaries

- **Always:** Write tests to `tests/`, run tests before committing
- **Ask first:** Before adding new test dependencies
- **Never:** Modify source code in `src/`, remove failing tests

These support tool restrictions per role, model selection per task, workflow handoffs between agents, and can be defined at the organisation level for consistency across repositories.

How They Work Together

The two approaches are complementary, not competing. AGENTS.md provides the foundational knowledge every agent inherits. Custom agents layer on specialised roles with specific tool access.

graph TD
    A["AGENTS.md<br/>(Always-On Knowledge)"] --> B["@test-agent"]
    A --> C["@docs-agent"]
    A --> D["@lint-agent"]
    A --> E["@security-agent"]

    B --> F["Writes Tests<br/>Tools: edit, terminal"]
    C --> G["Updates Docs<br/>Tools: edit, search"]
    D --> H["Fixes Style<br/>Tools: edit, terminal"]
    E --> I["Reviews Security<br/>Tools: search only"]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style C fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style D fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style E fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style F fill:#059669,stroke:#047857,stroke-width:2px,color:#fff
    style G fill:#059669,stroke:#047857,stroke-width:2px,color:#fff
    style H fill:#059669,stroke:#047857,stroke-width:2px,color:#fff
    style I fill:#059669,stroke:#047857,stroke-width:2px,color:#fff

The rule of thumb: if every agent should know it, put it in AGENTS.md. If only a specific role needs it, put it in a custom agent.

How This Changes Team Workflows

Once agents become versioned artifacts, the way teams work shifts fundamentally.

Shared capabilities replace personal prompts. A new developer clones the repo and immediately has access to the same @test-agent, @docs-agent, and @lint-agent that everyone else uses, configured precisely for this codebase. No more “ask Sarah how she prompts the AI for tests.” This is the same transformation we saw with CI/CD. Before pipelines as code, builds were manual, inconsistent, and locked in someone’s head. Once they lived in the repo, they became a shared, evolving team asset.

Onboarding becomes instant. The agents encode the team’s collective knowledge about how to write tests, structure docs, and review code in this specific codebase. No wiki hunting, no Slack archaeology.

Agents evolve through pull requests. Because definitions live in the repo, they follow the same lifecycle as any other code: feature branches for experimentation, PRs with review and discussion, git blame when something goes wrong. Governance you get for free just by putting agents where your code already lives.

Governance That Scales

For engineering organisations, this is where it gets really interesting.

Security review becomes standard practice. Every agent definition includes boundaries stating what it can and cannot do. Security teams review these in the normal PR process, just like IAM policies. The best agent files use a three-tier boundary model:

Always do: Safe actions (run tests, write to designated directories)
Ask first: Actions requiring judgment (schema changes, adding dependencies)
Never do: Hard boundaries (commit secrets, modify production configs, delete data)

Organisational standardisation becomes achievable. Platform teams maintain base agent templates that project teams inherit and customise. Distribute a @security-review-agent across 50 repositories and you’ve rolled out consistent AI-powered security review, versioned and auditable through Git.

Compliance gets a paper trail. Auditors can review what instructions guided AI behaviour at any point in time, who approved changes, and what boundaries were in place. That’s a significant improvement over the alternative: “some developer typed something into a chat box and the AI did a thing.”

Lessons from 2,500+ Repositories

GitHub’s analysis of over 2,500 agents.md files provides concrete, data-backed guidance on what actually makes agents effective:

Specificity wins. “You are a test engineer who writes Vitest tests for React 18 using Testing Library, following AAA pattern” beats “You are a helpful assistant” every time.
Commands come first. Front-load executable commands (pnpm test, npm run build). Agents reference these frequently.
Code examples trump explanations. One snippet showing preferred style beats three paragraphs describing it.
Cover six core areas. Commands, testing, project structure, code style, git workflow, and boundaries. Missing any degrades performance.
Boundaries prevent disasters. The always/ask first/never model is the most effective pattern. Without boundaries, agents will eventually surprise you.

What doesn’t work: vague personas, walls of prose with no examples, missing boundaries, and generic instructions that could apply to any project.

Practical Patterns to Adopt

Layer both for maximum effect. Start with an AGENTS.md covering build commands, code style, and universal boundaries. Then add focused custom agents for common tasks: @docs-agent (read-only source, writes to docs/), @test-agent (writes to tests/, runs tests), and @lint-agent (style changes only). These are safe, high-value, and easy to validate.

Iterate through feedback. Start minimal, use the agent on real tasks, and when it stumbles, add a specific instruction to prevent it. Commit the improvement through a PR with context. This mirrors how teams refine CI/CD pipelines: the configuration is a living document, not a set-and-forget template.

Standardise at the org and enterprise level. GitHub now supports managing custom agents and instructions centrally, not just per repository. Organisation and enterprise owners can define custom agents in a dedicated .github-private repository, making them available across all repositories within the organisation. Enterprise owners get additional controls, including rulesets that restrict who can edit agent profiles and the ability to delegate management to a team of AI managers.

On top of that, organisation owners can set organisation-level custom instructions that apply to every Copilot interaction across the organisation. Think of this as the org-wide equivalent of a .github/copilot-instructions.md file: coding standards, security requirements, and compliance constraints that every Copilot response respects, regardless of which repository or agent is in use.

The layering model becomes: org-level instructions (universal standards) → AGENTS.md (project-specific context) → custom agents (specialised roles). Teams can still fork and customise, but the baseline is consistent and governed.

The Bigger Picture: Everything as Code

Agents as code is the natural continuation of a decade-long trend:

graph TD
    A["Infrastructure as Code"] --> B["Pipelines as Code"]
    B --> C["Policy as Code"]
    C --> D["Agents as Code"]

    A1["Terraform, Bicep, Pulumi"] --> A
    B1["YAML Pipelines, GitHub Actions"] --> B
    C1["Azure Policy, OPA"] --> C
    D1["AGENTS.md, .github/agents/"] --> D

    style A fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style B fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style C fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style D fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style A1 fill:#059669,stroke:#047857,stroke-width:2px,color:#fff
    style B1 fill:#059669,stroke:#047857,stroke-width:2px,color:#fff
    style C1 fill:#059669,stroke:#047857,stroke-width:2px,color:#fff
    style D1 fill:#059669,stroke:#047857,stroke-width:2px,color:#fff

Each evolution followed the same pattern: take something manual and scattered across people’s heads, codify it into versioned artifacts, and gain consistency, auditability, and scalability as a result. Agents as code is the latest application of this principle.

Wrapping Up

Treating AI agents as versioned artifacts isn’t just a nice engineering practice. It’s the foundation for scaling AI-assisted development with the same rigour we apply to infrastructure, pipelines, and policies. The tools are here. GitHub Copilot’s custom agents, the open AGENTS.md standard, and the patterns emerging from thousands of real-world repositories all point in the same direction: agents belong in the repo.

Start small. Define three agents for your most common tasks. Review their boundaries. Iterate when they stumble. Commit improvements through pull requests. Before long, your team’s AI capabilities will be as well-governed and consistently applied as your CI/CD pipelines.

The era of ad-hoc prompting is ending. The era of agents as code has begun.

Have you started defining custom agents in your repositories? What patterns have worked for your team? Drop your experiences in the comments, I’d love to hear how others are approaching this.

References

How to Write a Great agents.md: Lessons from Over 2,500 Repositories — GitHub Blog
AGENTS.md: A Standard for Guiding Coding Agents — Agentic AI Foundation / Linux Foundation
Custom Agents in VS Code — VS Code Documentation
Creating Custom Agents for Copilot Cloud Agent — GitHub Documentation
Preparing to Use Custom Agents in Your Organisation — GitHub Documentation
Preparing to Use Custom Agents in Your Enterprise — GitHub Documentation
Adding Organisation Custom Instructions for GitHub Copilot — GitHub Documentation
Adding Repository Custom Instructions for GitHub Copilot — GitHub Documentation

Agentic Workflows: Reimagining Repository Automation with Natural Language

Sun, 15 Mar 2026 19:00:00 +0000

Repository automation works well for deterministic tasks, but struggles with work requiring context understanding and adaptive decision-making. When you need to keep documentation synchronised with code, triage issues intelligently, or verify pull requests comply with guidelines, traditional approaches force you to encode all logic upfront using conditionals, regex patterns, and scripts. But real development is messier than any ruleset can capture.

GitHub Agentic Workflows represent a different approach: describe what you want to happen in natural language, and an AI coding agent reads your instructions, understands your repository context, and takes intelligent actions. This is more than a convenience improvement. Agentic Workflows represent the bridge between “Continuous Integration” and “Continuous AI” - systematic, automated application of intelligence throughout your development lifecycle.

TL;DR

Agentic Workflows let you describe automation tasks in plain English instead of complex configuration. An AI coding agent reads your instructions, understands your repository context, and takes intelligent actions. Instead of encoding every path through conditional logic, you describe intent and the agent adapts. This enables powerful automation for nuanced tasks like intelligent issue triage, continuous documentation updates, compliance checking, and code quality improvements. Workflows remain fully auditable and safe with automatic permission scoping and sandboxed execution.

The Problem: Current Automation is Still Too Complex

Before we talk about solutions, let’s acknowledge why existing automation feels limiting.

Traditional GitHub Actions work well for deterministic tasks. When you know exactly what needs to happen (if file A changes, run test B), Actions excels. But real development workflows rarely work that way.

Consider these practical scenarios:

Scenario 1: Intelligent Issue Triage

You want to triage new issues automatically, adding appropriate labels, detecting spam, and asking clarifying questions for unclear reports. This requires:

Reading issue content and understanding context
Comparing to similar past issues to detect duplicates
Making judgment calls about relevance and priority
Phrasing helpful feedback that respects first-time contributors

Today, you’d either write complicated shell scripts with regex patterns or abandon automation entirely and do it manually.

Scenario 2: Keeping Documentation Current

Code evolves constantly. Documentation doesn’t. You want an agent that runs daily, identifies recent code changes, updates relevant documentation sections, and creates a pull request with those changes. This requires:

Parsing the git diff to understand what changed
Finding related documentation files
Rewriting sections to reflect new functionality
Creating coherent, well-written updates

Try doing this in traditional Actions: you’re either embedding massive Python scripts or chaining together countless workflow steps.

Scenario 3: Compliance Checking

When pull requests arrive, you want to verify they follow your contribution guidelines. Different PRs need different feedback. Some might be perfect but need a test plan. Others might be off-topic entirely. You need nuanced judgment, not just pattern matching.

These scenarios share something crucial: they require context understanding and adaptability. They’re not “if X then Y” - they’re “understand the situation, then do what makes sense.”

This is where agentic workflows shine.

What Are Agentic Workflows?

Agentic Workflows are GitHub Actions workflows written in natural language markdown instead of YAML. When triggered, they run an AI coding agent (like GitHub Copilot, Claude Code, or OpenAI Codex) with access to your repository context, allowing it to make intelligent decisions and take meaningful actions.

The key insight: Instead of programming every path, you describe the intention and let the agent navigate complexity.

graph LR
    A["Write Markdown<br/>with Instructions"] --> B["Compile to GitHub<br/>Actions YAML"]
    B --> C["GitHub Actions<br/>Runs Workflow"]
    C --> D["AI Coding Agent<br/>Executes Intelligently"]
    D --> E["Safe Outputs<br/>Create PRs, Comments, Issues"]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style C fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style D fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style E fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a

How Agentic Workflows Work

Unlike traditional Actions that execute scripts you write, agentic workflows run AI coding agents that interpret your narrative instructions and decide what to do.

The Execution Model

When an agentic workflow is triggered, here’s what happens:

Frontmatter Configuration: The YAML frontmatter defines:
- When the workflow runs (schedule, triggers, permissions)
- What the agent can access (tools, GitHub permissions)
- What actions are allowed (safe outputs)
- Resource constraints (timeouts, network access)
Agent Execution: The AI agent reads:
- Your markdown instructions
- Repository context (files, issues, PRs, discussions)
- Current situation (what issue/PR triggered the workflow)
- Available tools and permissions
Tool Usage: The agent can use allowed tools like:
- GitHub (read pull requests, issues, discussions, code)
- File editing (modify code or documentation)
- Bash scripting (run tests, build, analyse code)
- Web fetching (research external resources)
- Model Context Protocol (MCP) servers (integrate external services)
Safe Outputs: The agent doesn’t have direct write access. Instead, it uses sanitised “safe outputs”:
- create-pull-request: Request a PR be created
- add-comment: Request a comment be added to an issue or PR
- add-labels: Request labels be applied
- create-issue: Request a new issue be created

This safety layer is critical. The agent is sandboxed; it can’t silently modify your code. All actions go through controlled paths that leave an audit trail.

A Concrete Example: Contribution Guidelines Checker

Let’s walk through a real example from GitHub’s agentics repository. The Contribution Guidelines Checker workflow automatically reviews incoming pull requests and verifies they comply with your CONTRIBUTING.md.

The YAML Front Matter:

---
description: |
  Reviews incoming pull requests to verify they comply with the repository's
  contribution guidelines. Checks CONTRIBUTING.md and similar docs, then either
  labels the PR as ready or provides constructive feedback.

on:
  pull_request:
    types: [opened, synchronize]
  reaction: eyes

permissions: read-all

safe-outputs:
  add-labels:
    allowed: [contribution-ready]
    max: 1
  add-comment:
    max: 1

tools:
  github:
    toolsets: [default]
    lockdown: false

timeout-minutes: 10
---

The Natural Language Instructions:

# Contribution Guidelines Checker

You are a contribution guidelines reviewer. Your task is to analyse PR #$ 
and verify it meets the repository's contribution guidelines.

## Step 1: Find Contribution Guidelines

Search for contribution guidelines in the repository. Check these locations:
1. `CONTRIBUTING.md` in root
2. `.github/CONTRIBUTING.md`
3. `docs/CONTRIBUTING.md`
4. Contribution sections in `README.md`

## Step 2: Retrieve PR Details

Fetch the full PR details including title, description, changed files, and commit messages.

## Step 3: Evaluate Compliance

Check the PR against the guidelines for:
- PR Title format and clarity
- PR Description completeness
- Commit message format
- Required sections (test plan, changelog)
- Documentation updates
- Other repo-specific requirements

## Step 4: Take Action

**If the PR meets all guidelines:**
- Add the `contribution-ready` label

**If the PR needs improvements:**
- Add a helpful comment that includes:
  - A friendly greeting
  - Specific guidelines not being met
  - Clear, actionable steps to bring it into compliance

When a PR is opened:

The agent reads your contribution guidelines from the repository
It fetches the PR content
It evaluates the PR against those guidelines with nuanced judgement
If compliant, it adds a label and moves on
If not, it writes constructive feedback specific to what’s missing

This is work that previously required either manual review or fragile regex-based heuristics. The agent brings genuine understanding to the task.

Why Agentic Workflows Exist: The Problem They Solve

Beyond Heuristics

Traditional automation relies on heuristics and pattern matching. These break down when reality is more nuanced than your rules anticipated.

Example: Issue triage with traditional Actions requires defining rules for labeling:

- if: contains(github.event.issue.title, 'bug')
  run: gh issue edit --add-label bug

But what if someone writes: “Something isn’t working”? Your heuristic misses it. What about the tenth variation? You’re constantly patching rules.

Agentic workflows understand intent. An agent reads “Something isn’t working as expected when I follow these steps in the docs” and can classify it appropriately, ask clarifying questions, and even suggest related issues.

The Continuous AI Vision

GitHub introduced the concept of “Continuous AI” - the systematic application of intelligence throughout development. It builds on years of Continuous Integration and Continuous Deployment.

Where CI/CD automates mechanical tasks (“run tests, deploy if tests pass”), Continuous AI automates decision-making and adaptation (“analyse this issue, understand what’s happening, suggest improvements”).

Agentic Workflows are GitHub’s primary vehicle for bringing Continuous AI to repositories today.

graph LR
    A["Traditional CI/CD"] --> B["Deterministic<br/>Automated Tasks"]
    C["Agentic Workflows"] --> D["Intelligent<br/>Automated Tasks"]
    B --> E["Continuous AI"]
    D --> E
    E --> F["Smarter Repository<br/>Ecosystem"]

    style A fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style B fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style C fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style D fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style E fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style F fill:#059669,stroke:#047857,stroke-width:3px,color:#fff

Practical Use Cases

To understand the value of agentic workflows, consider real scenarios from GitHub’s agentics repository:

Code Review and Quality

Daily Test Improver: Analyses coverage reports and creates PRs that add meaningful tests to under-tested areas.

Code Simplifier: Reviews recent code changes and creates PRs that simplify over-engineered or verbose implementations.

Duplicate Code Detector: Identifies repeated code patterns and suggests refactoring opportunities.

These aren’t running static analysis tools. A coding agent is reading your actual code, understanding what it does, and proposing targeted improvements with reasoning.

Documentation and Communication

Daily Documentation Updater: Watches for code commits, identifies what changed, and updates relevant documentation sections. Creates PRs with coherent, well-written updates.

Weekly Repository Map: Generates visualisations of your repository structure and file sizes, creating compelling updates about your codebase.

Daily Repository Chronicle: Transforms raw GitHub activity into an engaging narrative summary of what happened this week.

Issue Management

Issue Triage: When issues arrive, automatically add relevant labels, detect spam and duplicates, ask clarifying questions, and provide debugging suggestions.

Issue Arborist: Organises issues hierarchically by linking related issues as parent-child relationships, building a more discoverable issue taxonomy.

Contribution Check: Reviews open PRs in batches against contribution guidelines and creates summary reports with feedback grouped by readiness.

Continuous Improvement

Daily Accessibility Review: Runs your application automatically, checks WCAG 2.2 compliance, and creates issues with specific accessibility violations and fixes.

CI Optimiser: Analyses your GitHub Actions workflows for inefficiencies, identifies slow steps, and creates PRs with optimisations including time and cost reductions.

Performance Improver: Runs benchmarks, identifies bottlenecks, and implements targeted performance improvements with measured impact.

These workflows represent automation that genuinely understands your codebase and makes contextual decisions. A human would do many of these tasks manually today. Agentic workflows shift them to asynchronous, background execution.

Real Example: Diving into Contribution Guidelines Checker

Let’s examine how the Contribution Guidelines Checker actually works to illustrate the nuance agentic workflows enable.

The workflow accesses the agent instructions like this:

permissions: read-all

This permits reading your entire repository. Then the agent:

1. Locates Your CONTRIBUTING.md: Not all repos follow the same naming or directory structure. The agent searches multiple standard locations and adapts.

2. Interprets Guidelines Intelligently: It reads your guidelines and understands not just the literal rules, but the spirit of them. If your guidelines emphasise “respect for new contributors,” the agent considers whether feedback should be more encouraging.

3. Evaluates with Context: Rather than checking boxes against a fixed checklist, the agent understands the specific PR. A PR with 1,200 line changes might need different feedback than a 12-line typo fix.

4. Writes Helpful Feedback: Instead of generic comments like “PR title must follow format,” it writes something like:

Thanks for this contribution! I noticed the PR title could be more descriptive. Instead of “Update docs,” try “Add documentation for the new caching API.” This helps maintainers quickly understand what changed.

This is something a human PR reviewer would write. The agent learns to write similarly.

5. Decides Actions Based on Context: If contribution guidelines don’t exist, the agent assumes compliance rather than failing. It applies judgment about what matters.

The safety boundary is critical here:

safe-outputs:
  add-labels:
    allowed: [contribution-ready]  # Only this label can be added
    max: 1  # At most one label per run
  add-comment:
    max: 1  # At most one comment per run

The agent cannot directly push code or silently modify PRs. It can propose adding a label or commenting. A human would review the workflow logs and approve. This maintains trust.

Security and Safety: Building Trust in AI Automation

With AI systems taking actions in your repository, security is paramount. GitHub Agentic Workflows incorporate multiple safety layers:

1. Principle of Least Privilege

By default, workflows run with read-only permissions. Write operations must be explicitly enabled through safe-outputs:

permissions: read-all  # Read everything
safe-outputs:
  create-pull-request:  # Only PRs can be created, nothing else
    draft: true  # Draft PRs by default, require manual review

The agent literally cannot push to main branch, delete branches, or modify secrets. It can only use allowed outputs.

2. Sandboxed Execution

Agentic workflows run in GitHub-managed container environments with:

Network isolation (blocked by default)
Tool allowlisting (agent can only use explicitly allowed tools)
Bash command restrictions (even bash access is sanitised)
File system isolation (can’t access GitHub secrets or other workflows)

3. Safe Output Validation

Every action the agent takes goes through sanitised handlers:

safe-outputs:
  add-comment:
    max: 5  # Limit to 5 comments per run
    target: "*"  # Can comment on issues/PRs
    hide-older-comments: true  # Clean up previous agent comments

These validate the action, check permissions, and log the operation. There’s a full audit trail.

4. Compilation and Verification

Before an agentic workflow runs, it’s compiled from markdown to GitHub Actions YAML:

gh aw compile

This compilation process:

Validates YAML syntax and configuration
Applies security hardening (restricts context substitutions, validates tools)
Generates a lock file with all resolved references
Creates a reviewable YAML file you can inspect

You review the compiled YAML before committing. No hidden prompts or secret sauce.

5. Model-Agnostic Safety

Agentic Workflows support multiple AI coding agents (Copilot, Claude Code, OpenAI Codex). The safety boundaries apply regardless of which agent you’re using, ensuring consistent protection across different LLM providers.

Security Best Practices for Your Workflows

When implementing agentic workflows, follow these practices:

1. Start with Read-Only Operations

Begin with workflows that only comment on issues or create discussion posts. Gain confidence before enabling write operations.

permissions: read-all
safe-outputs:
  add-comment:  # Safe to experiment with
    max: 1

2. Use Draft PRs and Human Review Gates

If your workflow creates pull requests, make them drafts by default:

safe-outputs:
  create-pull-request:
    draft: true  # Requires explicit approval to mark ready

3. Limit Operations with max Settings

Always set reasonable limits on operations:

safe-outputs:
  create-issue:
    max: 1  # Only one issue per run
  add-comment:
    max: 5  # Limited commenting

4. Enable Rate Limiting

Protect against runaway agents with rate limiting:

rate-limit:
  max: 5
  window: 60  # Max 5 operations per 60 seconds

5. Use Protected Files for Critical Edits

If your workflow edits files, protect critical ones:

safe-outputs:
  create-pull-request:
    protected-files: fallback-to-issue  # If can't safely edit, create issue instead

This prevents accidental modifications to sensitive files like package.json or deployment configurations.

6. Audit Regularly

Review workflow logs periodically:

gh workflow view <workflow-name> --log

Check what tools the agent used, what decisions it made, and whether actions align with intent.

This is radically different from handing off automation to a third-party service where you can’t see how decisions are made.

Getting Started: Your First Agentic Workflow

Agentic Workflows require the GitHub Agentic Workflows CLI extension. Here’s how to get started:

Installation

gh extension install github/gh-aw
gh aw upgrade  # Get latest version

Quick Start: Try a Real Workflow

The easiest way to learn is by adding an existing workflow from the agentics repository:

cd your-repository
gh aw add-wizard githubnext/agentics/contribution-guidelines-checker

This interactive wizard:

Guides you through setup
Creates the workflow in .github/workflows/
Compiles it to a runnable YAML file
Explains what the workflow does

Creating Your Own Workflow

Create a new file in .github/agentic-workflows/my-workflow.md:

---
name: Daily Quality Scan
description: Scan for code quality issues
on:
  schedule: daily

permissions:
  contents: read
  issues: read

safe-outputs:
  create-issue:
    title-prefix: "[quality] "
    labels: [automation, quality]
    max: 1

tools:
  github:
    toolsets: [default]
  bash: true

timeout-minutes: 15
---

# Daily Quality Scan

You are a code quality reviewer. Scan the recent code changes and:

1. Identify code patterns that could be simplified
2. Find potential performance issues
3. Check for missing error handling
4. Suggest test coverage improvements

For each finding, create an issue with:
- Clear description of the issue
- Why it matters
- Suggested fix

Then compile and commit:

gh aw compile
git add .github/workflows/my-workflow.md.lock.yml
git commit -m "Add daily quality scan workflow"

The .lock.yml file is what GitHub Actions actually runs. It’s fully inspectable and version controlled.

Triggering Your Workflow

Once deployed:

# Trigger manually
gh aw run my-workflow

# View logs
gh run list
gh run view <run-id> --log

Limitations and Considerations

Agentic Workflows are powerful, but they’re not a silver bullet:

1. Tool Reliability: The agent can only use what’s available. If your workflow needs a specific analysis tool that doesn’t exist, you’ll need to build it or work around it.

2. Token and Cost Considerations: Every workflow run consumes LLM tokens. Running agents multiple times daily across teams adds up. Monitor costs and use rate limiting.

3. Hallucinations: AI models sometimes generate plausible-sounding but incorrect code or suggestions. This is why human review gates and draft PRs are important.

4. Context Limitations: Very large repositories might exceed context windows for some models. Agentic Workflows handle this, but it’s a practical constraint to be aware of.

5. Non-Determinism: Unlike traditional workflows that produce identical results on identical inputs, agentic workflows may vary slightly between runs because they involve LLM inference.

6. Learning Curve: Writing good agentic workflow instructions requires a different mindset than writing traditional automation. You’re giving intuitive suggestions, not algorithmic steps.

Conclusion: The Future is Conversational

Agentic Workflows represent a shift in how we think about repository automation. Instead of programming every detail, we describe intentions and let intelligent systems handle the complexity.

The future of development tooling is increasingly conversational. You don’t write long configuration files; you describe what you want. The tools understand context, ask clarifying questions, and adapt to your needs.

GitHub Agentic Workflows are how this future arrives in your repositories today. They’re safe, auditable, and in your control. They’re practical enough to use today, yet pioneering enough to shape how automation will work across the industry.

If you’re managing repositories where documentation drifts, issue triage becomes overwhelming, or contributor experience could be better, agentic workflows offer a path forward. Start small, build confidence, and expand from there.

The age of Continuous AI has arrived. What will you automate?

Have you experimented with agentic workflows yet? What repository problems would you want an AI agent to help solve? Share your thoughts and applications in the comments below.

MCP Apps: Interactive Dashboards Inside Your AI Conversations

Sat, 14 Feb 2026 19:00:00 +0000

If you’ve been working with AI agents lately, you’ve probably hit a limitation: the agent can describe what it found, but it can’t show you anything interactive. Your agent finishes scanning a dataset and presents a table in text format. You need to explore further, so you ask it to reorganise the results. Another round trip. Another text response.

MCP Apps change that equation entirely. They let your MCP servers return interactive HTML interfaces such as dashboards, forms, visualisations and configuration panels that render directly inside your AI conversation. No tab switching. No context loss. Just rich, interactive interfaces right where you’re having the conversation.

In this post, I’ll explain what MCP Apps are, how they work, why they matter, and how you can leverage them in real scenarios like browsing Azure resources with an interactive dashboard.

What Are MCP Apps?

MCP Apps are an extension to the Model Context Protocol that lets MCP tools declare and serve interactive user interfaces. Rather than returning only text, images, or structured data, a tool can now say “render this HTML interface alongside your response.”

The key insight is simple: sometimes showing is better than telling. An agent can describe “your database has performance bottlenecks in query processing,” but an interactive graph lets you drill into the call stacks, hover for timing details, and validate the analysis yourself.

MCP Apps bridge the gap between pure text-based AI interactions and rich desktop applications. They give agents a visual voice.

The Problem MCP Apps Solve

Traditional agent workflows suffer from a classic problem: agents work in text space, but developers think in visual and interactive space. When an agent presents findings, you often want to explore further, but the agent can only respond with more text.

MCP Apps flip this around. Agents can now display:

Interactive dashboards: Visualise metrics, logs, or resource states
Forms with validation: Configure systems with confidence
Data tables with sorting and filtering: Explore large datasets without truncation
Visualisations: Flame graphs, heatmaps, network diagrams, 3D models
Terminal-like interfaces: Real-time monitoring and status updates
File pickers and selectors: Choose resources from rich interfaces

The agent doesn’t lose context, and it works alongside the interactive UI. When you interact with the app, it can call MCP tools to fetch fresh data, validate your choices, or execute actions.

How MCP Apps Work

Understanding the architecture helps explain why MCP Apps are secure and efficient.

graph LR
    A["MCP Server<br/>Registers Tool"] --> B["Tool Description<br/>Includes UI Resource URI"]
    B --> C["Host/Agent<br/>LLM Decides to Call Tool"]
    C --> D["Host Fetches<br/>UI Resource<br/>from Server"]
    D --> E["Sandboxed iframe<br/>Renders HTML/JS"]
    E --> F["Bidirectional<br/>Communication<br/>via postMessage"]
    F --> G["App Calls Tools<br/>Host Updates Display"]
    
    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style C fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style D fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style E fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style F fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style G fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff

The flow works in four key steps:

1. Tool Registration with UI Metadata

An MCP server registers a tool with a special _meta.ui.resourceUri field that points to an HTML interface:

registerAppTool(
  server,
  "list-azure-storage",
  {
    title: "List Azure Storage Accounts",
    description: "Browse storage accounts with filtering and drill-down",
    inputSchema: {},
    _meta: { 
      ui: { 
        resourceUri: "ui://storage-dashboard/mcp-app.html" 
      } 
    },
  },
  async () => {
    // Fetch storage account data
    const accounts = await listStorageAccounts();
    return {
      content: [{ type: "text", text: JSON.stringify(accounts) }],
    };
  },
);

2. UI Preloading and Resource Fetching

When an agent calls the tool, the host can preload the UI resource before the tool even executes. The host fetches the bundled HTML from the server, which is typically a single file containing HTML, CSS, and JavaScript bundled together.

3. Sandboxed Rendering

The host renders the HTML in a sandboxed iframe. This is crucial for security, as the app can’t access the parent window’s DOM, steal cookies, or execute scripts in the parent context. All communication happens through the postMessage API, which is controlled by the host.

4. Bidirectional Communication

The app and host communicate via JSON-RPC over postMessage. The app can:

Receive the initial tool result when rendered
Call tools on the server (e.g., “fetch more data with these filters”)
Send log messages back to the host
Update the model’s context with structured data
Request actions like opening URLs

This bidirectional flow means your UI stays dynamic without page reloads.

Practical Uses: Building an Azure Storage Dashboard

Let me walk through a concrete example: building an interactive dashboard to browse Azure storage accounts.

Instead of asking your agent “list all storage accounts and filter by location,” you could have an interactive dashboard where you:

See all storage accounts in a table
Filter by resource group, region, or storage type
Click to view details (access keys, endpoints, configuration)
Perform actions (create a new account, update settings, delete a container)
Copy information without manual re-typing

Here’s an example of how the server implements this:

// Server side: register the tool with UI metadata
registerAppTool(
  server,
  "storage-dashboard",
  {
    title: "Azure Storage Dashboard",
    description: "Interactive dashboard for browsing and managing storage accounts",
    inputSchema: {
      type: "object",
      properties: {
        subscriptionId: { type: "string" },
        resourceGroup: { type: "string" },
      },
    },
    _meta: { 
      ui: { 
        resourceUri: "ui://storage-dashboard/app.html" 
      } 
    },
  },
  async (params) => {
    // Fetch storage accounts from Azure
    const accounts = await getStorageAccounts(
      params.subscriptionId,
      params.resourceGroup
    );
    
    return {
      content: [{ 
        type: "text", 
        text: JSON.stringify(accounts)
      }],
    };
  },
);

// Register the UI resource
registerAppResource(
  server,
  "ui://storage-dashboard/app.html",
  { mimeType: RESOURCE_MIME_TYPE },
  async () => {
    const html = await fs.readFile("dist/app.html", "utf-8");
    return {
      contents: [
        { 
          uri: "ui://storage-dashboard/app.html",
          mimeType: RESOURCE_MIME_TYPE,
          text: html 
        },
      ],
    };
  },
);

On the UI side, the dashboard receives the storage account data and renders it interactively:

// Client side: UI implementation
import { App } from "@modelcontextprotocol/ext-apps";

const app = new App({ 
  name: "Storage Dashboard", 
  version: "1.0.0" 
});

app.connect();

// Receive initial data from the tool
app.ontoolresult = (result) => {
  const accounts = JSON.parse(
    result.content?.find((c) => c.type === "text")?.text || "[]"
  );
  renderStorageTable(accounts);
};

// When user filters, call a tool to fetch filtered data
async function applyFilters(filters) {
  const result = await app.callServerTool({
    name: "storage-dashboard",
    arguments: { 
      subscriptionId: filters.subscription,
      resourceGroup: filters.group 
    },
  });
  
  const accounts = JSON.parse(result.content?.[0]?.text || "[]");
  renderStorageTable(accounts);
}

function renderStorageTable(accounts) {
  // Render interactive table with filtering, sorting, drill-down
  // Users can see all accounts at once, explore details,
  // and perform actions without leaving the UI
}

This approach gives you:

Instant visual feedback: Tables, icons, colours communicate status at a glance
Exploration without friction: Filter, sort, drill down without conversation turns
Context preservation: Everything stays in one place—the agent’s workspace
Reduced latency: UI interactions feel responsive

Rather than asking your agent “show me storage accounts in the Australia regions” five times with slightly different filters, you see all options at once and click to explore.

Security Considerations for MCP Apps

MCP Apps run in a sandboxed iframe, which provides strong security isolation, but “sandboxed” does not mean “bulletproof.” Here are security practices you should follow:

Sandboxing Fundamentals

MCP Apps run inside a sandboxed iframe with these restrictions:

No DOM access: The app can’t access the parent window’s document or modify the main page
No cookie theft: localStorage and sessionStorage are isolated
No page navigation: The app can’t redirect the parent window
Restricted script execution: Scripts in the app run only within the sandbox

All communication between the app and host happens through postMessage, which is an explicit, controlled channel.

Content Security Policy (CSP)

When serving your UI, specify which external origins can load resources. This prevents your app from accidentally (or maliciously) loading scripts from untrusted domains:

registerAppResource(
  server,
  "ui://storage-dashboard/app.html",
  { 
    mimeType: RESOURCE_MIME_TYPE,
    _meta: {
      ui: {
        csp: ["https://cdn.jsdelivr.net", "https://cdn.example.com"]
      }
    }
  },
  async () => {
    // Serve HTML
  },
);

Permission Requests

Your app can request permissions (microphone, camera, geolocation), but these go through the host. The user is always in control of what the app can access. If your app doesn’t need a permission, don’t request it.

Input Validation and Sanitisation

Since your app receives data from the server and may send data back to the server, validate everything:

// On the client: validate server responses
app.ontoolresult = (result) => {
  try {
    const accounts = JSON.parse(result.content?.[0]?.text || "[]");
    
    // Validate the data structure
    if (!Array.isArray(accounts)) {
      throw new Error("Expected array of accounts");
    }
    
    // Sanitise rendered content if it comes from user input
    accounts.forEach(account => {
      account.name = sanitiseHTML(account.name);
    });
    
    renderStorageTable(accounts);
  } catch (e) {
    console.error("Invalid tool result:", e);
  }
};

Tool Call Authorisation

The host controls which tools your app can call. When you call app.callServerTool(), the host validates that:

The tool exists on the server
The host has access to that tool
The user has authorised the interaction

You don’t need to implement authorisation on the client, as the host enforces it.

Secure Default Data Handling

MCP Apps can request “rich context” updates to the model. Be careful what data you send:

// Good: send only necessary data
app.updateContext({
  type: "resource",
  resource: {
    uri: "azure://storage/account/myaccount",
    name: "myaccount",
    mimeType: "application/json"
  }
});

// Bad: don't send secrets or sensitive tokens
app.updateContext({
  type: "resource",
  resource: {
    data: { accessKey: "very-secret-key" }  // Never do this
  }
});

Server-Side Security

Your MCP server also has security responsibilities:

Validate inputs: Check tool arguments before executing
Authenticate requests: Ensure the user has Azure/cloud access
Limit data exposure: Don’t return secrets, access keys, or connection strings to the UI
Rate limiting: Protect against abuse
Audit logging: Track who accessed what dashboards and resources

registerAppTool(
  server,
  "storage-dashboard",
  { /* ... */ },
  async (params, context) => {
    // Validate inputs
    if (!params.subscriptionId?.match(/^[a-f0-9-]{36}$/)) {
      throw new Error("Invalid subscription ID format");
    }
    
    // Check authentication
    const user = await getCurrentUser(context);
    if (!user) {
      throw new Error("Authentication required");
    }
    
    // Verify user has access to this subscription
    const hasAccess = await verifySubscriptionAccess(
      user, 
      params.subscriptionId
    );
    if (!hasAccess) {
      throw new Error("Access denied");
    }
    
    // Fetch data and return (without secrets)
    const accounts = await getStorageAccounts(params.subscriptionId);
    
    // Remove sensitive data before returning
    const safeAccounts = accounts.map(acc => ({
      id: acc.id,
      name: acc.name,
      location: acc.location,
      type: acc.kind,
      // Never include:
      // primaryEndpoints, accessKey, connectionString, etc.
    }));
    
    return {
      content: [{ type: "text", text: JSON.stringify(safeAccounts) }],
    };
  },
);

Getting Started with MCP Apps

Building an MCP App is straightforward. The MCP team provides several ways to get started:

Using an AI Coding Agent (Fastest)

NOTE: At the time of writing, MCP Apps are only supported in VS Code Insiders, so you will need the Insiders build to render apps inside the editor.

If you have access to Claude Code, VS Code with GitHub Copilot, or another agent that supports skills, you can leverage the create-mcp-app skill:

# Install the skill (Claude Code example)
/plugin marketplace add modelcontextprotocol/ext-apps
/plugin install mcp-apps@modelcontextprotocol-ext-apps

Then ask your agent: “Create an MCP App that displays a live Azure storage account dashboard.”

The agent will scaffold a complete project with server, UI, and configuration files ready to run.

Manual Setup

If you prefer hands-on control, clone the examples repository and modify a starter template:

git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps/examples/basic-server-react
npm install && npm run build && npm run serve

The ext-apps repository includes starter templates for React, Vue, Svelte, Preact, Solid, and vanilla JavaScript. Choose the framework that matches your preferences.

Testing Your App

For development, use the basic-host test interface to debug your app locally:

cd ext-apps/examples/basic-host
SERVERS='["http://localhost:3001/mcp"]' npm start

Navigate to http://localhost:8080 to see your app render in an MCP-compatible host.

What’s Next?

MCP Apps are still early, but adoption is growing rapidly. VS Code, Claude Desktop, Postman, and other AI environments already support them. As more tools and agents integrate MCP, you’ll see dashboards and interactive workflows become standard.

The implications for DevOps and cloud engineering are particularly interesting. Instead of describing infrastructure or asking an agent to list resources in text, you could have interactive dashboards for:

Resource discovery and filtering: Browse Azure resources visually
Configuration wizards: Step through deployment decisions with validation
Monitoring and alerting: Real-time dashboards alongside AI analysis
Approval workflows: Review changes and approve with confidence
Cost analysis: Interactive charts and drill-down into spending patterns

The combination of AI agents and interactive dashboards creates a powerful new class of tools.

Demo: MCP Storage Account App

I built a small demo MCP App that surfaces Azure storage accounts in a simple dashboard so you can explore the list, inspect details, and validate the flow end to end. If you want a practical reference implementation, you can find it here:

https://github.com/tw3lveparsecs/mcp-apps-demo

Key Takeaways

MCP Apps solve a real problem: Text-based agent responses don’t scale for exploration, configuration, or monitoring
Security is built-in: Sandboxed iframes isolate apps from the host, but you still need to validate inputs and protect secrets
The architecture is elegant: Simple tool registration with UI metadata, bidirectional postMessage communication, and no reinventing the wheel for authentication
Azure integration is practical: You can build dashboards that replace manual CLI queries and portal browsing
The ecosystem is growing: With VS Code support and multiple framework options, building MCP Apps is accessible to most developers

Have you started building MCP Apps? What problems are you trying to solve with interactive dashboards? Share your experiences in the comments. I’d love to hear how the community is pushing this technology forward.

References

GitHub Copilot's Agentic Memory: Teaching AI to Remember and Learn Your Codebase

Wed, 21 Jan 2026 19:00:00 +0000

One of the biggest challenges with AI coding assistants has been their stateless nature with every interaction starting from scratch, requiring developers to repeatedly explain coding conventions, architectural patterns, and repository-specific knowledge. GitHub has just changed the game with the public preview of agentic memory for GitHub Copilot, a revolutionary capability that allows AI agents to remember and learn from your codebase over time.

This isn’t just another incremental improvement, it’s a fundamental shift toward truly intelligent AI assistants that grow smarter with every interaction. Let’s dive into how this groundbreaking feature works and why it’s set to transform how we collaborate with AI in our development workflows.

The Problem: Context Lost in Translation

Picture this scenario: You’re working on a complex enterprise application with specific coding conventions, database connection patterns, and synchronised configuration files. Every time you interact with GitHub Copilot, you find yourself explaining the same architectural decisions and coding standards. The AI produces decent code, but it lacks the deep understanding of your repository’s unique patterns and requirements.

Traditional AI assistants suffer from “contextual amnesia” - they can’t retain knowledge between sessions. This means:

Repetitive explanations: Constantly re-explaining coding conventions and patterns
Inconsistent suggestions: AI recommendations that don’t align with established codebase patterns
Missed relationships: Failing to understand dependencies between files that must stay synchronised
Generic responses: One-size-fits-all solutions that don’t respect repository-specific best practices

While we can leverage GitHub Copilot’s instructions to provide context, this approach is limited. Instructions can become lengthy, hard to maintain, and still don’t solve the problem of retaining knowledge across sessions.

Introducing Agentic Memory: AI That Learns and Remembers

Agentic memory represents a paradigm shift in how AI assistants work with code. Instead of starting fresh with each interaction, Copilot now builds and maintains a persistent understanding of your repository through “memories”. Tightly scoped pieces of knowledge that it discovers and validates over time.

How Memories Are Created

The memory system works through what GitHub calls “just-in-time verification”. Here’s the elegant process:

graph TD
    A[Copilot Agent Working] --> B{Discovers Actionable Pattern}
    B -->|Yes| C[Create Memory with Citations]
    B -->|No| D[Continue Work]
    C --> E[Store Memory in Repository]
    E --> F[Available for Future Sessions]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style C fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style E fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style F fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a

When Copilot discovers something worth remembering, it creates a structured memory entry:

{
  "subject": "API version synchronisation",
  "fact": "API version must match between client SDK, server routes, and documentation.",
  "citations": [
    "src/client/sdk/constants.ts:12",
    "server/routes/api.go:8",
    "docs/api-reference.md:37"
  ],
  "reason": "If the API version is not kept properly synchronised, the integration can fail or exhibit subtle bugs. Remembering these locations will help ensure they are kept synchronised in future updates."
}

Memory Validation and Self-Healing

The brilliant aspect of this system is its self-healing nature. Before applying any stored memory, Copilot validates it against the current codebase:

graph TD
    A[Agent Starts New Session] --> B[Retrieve Repository Memories]
    B --> C[Check Citations Against Current Code]
    C --> D{Citations Valid?}
    D -->|Yes| E[Apply Memory Knowledge]
    D -->|No| F[Store Corrected Memory or Discard]
    E --> G[Continue with Enhanced Context]
    F --> G

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style C fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style E fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style F fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style G fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a

This real-time verification ensures that memories remain accurate even as code evolves, branches change, and files are refactored.

Privacy and Security: Is it safe to use?

One of the first questions that comes to mind with any AI memory system is privacy and security. Is it safe to let an AI remember details about my codebase?

What I had to understand is that Copilot Memory stores repository-scoped memories only. This means memories are tied to a specific repository and can only be used by Copilot operations on that same repository.

Key points:

Repository Isolation: Memories are strictly scoped to individual repositories (not shared across repositories or orgs)
Permission-Based Creation: Only contributors with write permissions can create memories
Access Control: Memories can be used by other users with appropriate repository access, but not outside that repository
Management Tools: Repository owners can view and delete stored memories via repository settings
Automatic Expiry: Memories automatically delete after 28 days unless refreshed through validation

This ensures that sensitive repository knowledge stays within the appropriate boundaries while enabling powerful AI assistance.

Current Availability and Getting Started

Agentic memory is currently available in public preview for:

Copilot Coding Agent: Enhanced task completion with repository-specific knowledge
Copilot Code Review: Smarter pull request reviews based on learned patterns
Copilot CLI: Context-aware command-line assistance

Enabling Memory for Your Team

The feature is opt-in and available for all paid Copilot plans:

For Individual Users (Copilot Pro/Pro+):

Navigate to Personal Copilot Settings
Under “Features”, find “Copilot Memory”
Select “Enabled” from the dropdown

For Organisations and Enterprises:

Go to Organisation/Enterprise Settings
Navigate to Copilot policies
Enable Copilot Memory for your team

Repository Management: Repository owners can review and manage stored memories via: Repository Settings > Copilot > Memory

Implementation Best Practices

To maximise the value of agentic memory in your development workflows:

1. Start with High-Impact Repositories

Enable memory on repositories with:

Complex coding conventions
Synchronised configuration files
Specific architectural patterns
Multiple team contributors

2. Monitor Memory Quality

Regularly review stored memories to:

Remove outdated or incorrect memories
Validate that learned patterns align with current practices
Ensure memories reflect your team’s coding standards

3. Leverage Cross-Agent Benefits

Use multiple Copilot features together:

Let Code Review agents learn from expert developer patterns
Allow Coding Agent to benefit from review insights
Use CLI with enhanced repository context

4. Educate Your Team

Ensure team members understand:

How memories are created and validated
The privacy and security model
How to review and manage repository memories

Conclusion: A New Era of Intelligent Development

GitHub Copilot’s agentic memory represents a fundamental evolution in AI-assisted development. By solving the “contextual amnesia” problem, it enables AI agents to become true collaboration partners that grow more valuable over time.

The beauty lies not just in the technical implementation, but in how it transforms the developer experience. No more explaining the same patterns repeatedly. No more generic suggestions that miss repository-specific context. Instead, you get AI assistance that truly understands your codebase and respects your team’s established practices.

As we embrace this new era of agentic AI, the question isn’t whether to adopt these capabilities, but how quickly we can integrate them into our development workflows to unlock their full potential.

Have you enabled agentic memory in your repositories yet? What patterns do you hope Copilot will learn from your codebase? Share your experiences and thoughts in the comments below.

References

Beyond Planning: How GitHub Spec Kit Transforms Ideas into Implementation

Mon, 15 Dec 2025 19:00:00 +0000

In my journey exploring agentic DevOps tools, I’ve previously written about delivering major enhancements using Awesome Copilot and GitHub’s built-in Plan Agent. Each tool has pushed the boundaries of what’s possible when AI assists with development workflows. Today, I’m diving into my experience with GitHub Spec Kit, a developer-centric toolkit that takes planning and implementation to an entirely new level of detail and sophistication.

This post explores how Spec Kit compares to the other tools I’ve evaluated, the unique advantages it brings to the developer experience, and why it might be the most comprehensive approach to AI-assisted development I’ve encountered yet.

What is GitHub Spec Kit?

GitHub Spec Kit is an open-source toolkit designed to help developers create detailed specifications and implementation plans directly within their development environment. Unlike the more accessible Plan Agent or the prompt-based Awesome Copilot approach, Spec Kit is purpose-built for developers who want to stay in their IDE while creating incredibly detailed project specifications.

The toolkit provides structured templates, workflows, and methodologies for:

Requirements gathering: Systematic approach to capturing functional and non-functional requirements
Technical specification: Detailed architecture and implementation planning
Task breakdown: Granular work item creation with dependencies and acceptance criteria
Implementation tracking: Progress monitoring and milestone management

My Demo Project: Visualising Spec Kit in Action

To truly understand how Spec Kit works, I’ve been building a demo web application that demonstrates the toolkit’s capabilities and workflow using GitHub Spec Kit. The project showcases how Spec Kit transforms high-level ideas into detailed, implementable specifications.

Demo repository available here (Note: This project is still in active development as I continue exploring Spec Kit’s capabilities)

The demo includes:

Interactive visualisation of the Spec Kit workflow
Sample scenarios showcasing various inputs and their resulting outputs
Custom scenario builder using your own specifications
Exploration of tokens and constitution principles

My demo application showcasing GitHub Spec Kit’s workflow and capabilities

The Evolution: From Simple Planning to Comprehensive Specification

Let me position Spec Kit within my broader experience with agentic development tools:

graph TD
    A[Awesome Copilot] --> B[Proven Prompts<br/>& Agents]
    B --> C[Manual Integration<br/>Required]

    D[Plan Agent] --> E[Built-in VS Code<br/>Integration]
    E --> F[Zero Configuration<br/>Planning]

    G[GitHub Spec Kit] --> H[Developer-Centric<br/>Toolkit]
    H --> I[Comprehensive<br/>Specification Framework]

    C --> J[Good for: Accessing<br/>Library of Customisations]
    F --> K[Good for: Natural<br/>Language Planning]
    I --> L[Good for: Staying<br/>in the IDE]

    style A fill:#6366f1,stroke:#4f46e5,stroke-width:2px,color:#fff
    style B fill:#818cf8,stroke:#6366f1,stroke-width:2px,color:#fff
    style C fill:#a5b4fc,stroke:#818cf8,stroke-width:2px,color:#1e1b4b
    style D fill:#f97316,stroke:#ea580c,stroke-width:2px,color:#fff
    style E fill:#fb923c,stroke:#f97316,stroke-width:2px,color:#fff
    style F fill:#fdba74,stroke:#fb923c,stroke-width:2px,color:#431407
    style G fill:#10b981,stroke:#059669,stroke-width:2px,color:#fff
    style H fill:#34d399,stroke:#10b981,stroke-width:2px,color:#fff
    style I fill:#6ee7b7,stroke:#34d399,stroke-width:2px,color:#022c22
    style J fill:#a5b4fc,stroke:#818cf8,stroke-width:2px,color:#1e1b4b
    style K fill:#fdba74,stroke:#fb923c,stroke-width:2px,color:#431407
    style L fill:#6ee7b7,stroke:#34d399,stroke-width:2px,color:#022c22

Each tool serves different needs:

Awesome Copilot: Flexible, customisable, requires configuration knowledge
Plan Agent: Accessible, integrated, easy to get started
Spec Kit: Requires setup knowledge, developer-focused, keeps you in the IDE

My Experience: Four Key Observations

1. Developer-Centric and IDE-Native

One of Spec Kit’s greatest strengths is how it keeps you firmly planted in your development environment. Unlike web-based planning tools or even the Chat view in VS Code, Spec Kit integrates directly into your project structure.

What I observed:

Specifications become part of your repository, versioned alongside your code
Templates and workflows integrate with your existing development tools
No context switching between planning and implementation environments
Natural integration with Git workflows for specification evolution

This approach feels natural for developers who prefer staying in their IDE rather than switching to separate planning tools.

2. Barrier to Entry vs Accessibility

While Spec Kit’s developer-centric approach is a strength, it also creates a higher barrier to entry compared to something like Plan Agent.

Plan Agent advantages:

Works immediately in VS Code with zero setup
Natural language interface - just describe what you want
No need to understand templates or workflow structures
Easy to get started

Spec Kit considerations:

Requires understanding of the toolkit’s structure and methodology
Initial setup and configuration needed
Need familiarity with templates and specification formats
Best suited for developers comfortable with structured approaches

For teams new to AI-assisted development, Plan Agent provides a gentler introduction. Spec Kit is better suited for teams ready to invest in a more comprehensive planning methodology.

3. Incredibly Detailed Planning and Implementation

Where Spec Kit truly shines is in the depth and detail of the plans it helps you create.

Level of detail I experienced:

Requirements: Not just functional requirements, but detailed acceptance criteria, edge cases, and non-functional requirements
Implementation phases: Granular task breakdown with dependencies, and success criteria
Test plans: Detailed test plans specific to each user story
Documentation: Built-in templates for technical documentation, API specs, and user guides

4. Understanding Each Phase and Input Requirements

To get the most out of Spec Kit, I found you need to understand its methodology and provide specific inputs at each phase. This isn’t necessarily a limitation, but it does require investment in learning the system.

Key phases I learned:

Discovery Phase: Gathering requirements, stakeholder input, and constraints
Specification Phase: Creating detailed technical and functional specifications
Planning Phase: Breaking down work into implementable tasks
Implementation Phase: Executing against the detailed specifications
Validation Phase: Testing and verification against original requirements

Critical inputs for success:

Context: Detailed background about the system, users, and constraints
Requirements: Clear functional and non-functional requirements
Constraints: Technical, business, and resource limitations
Dependencies: External systems, APIs, and integration requirements
Success criteria: Measurable outcomes and acceptance criteria

When to Use Each Tool: My Current Thinking

Based on my experience across all three tools, here’s my current framework for tool selection:

Use Plan Agent When:

Natural language: Prefer a natural language centric approach
Proof of concepts: Exploring feasibility of ideas
Team onboarding: Introducing AI-assisted planning
Accessibility priority: Need zero-configuration solutions

Use Awesome Copilot When:

Custom workflows: Need specific prompt structures or agents
Team standards: Require consistent planning templates
Iterative refinement: Building on proven prompt libraries
Flexibility priority: Need to customise approaches

Use Spec Kit When:

Developer centric Prefer a developer centric approach
Developer teams: Working with teams comfortable with structured approaches
Investment in planning: Invested in gathering and providing inputs for each phase of the workflow

The Future of Specification-Driven Development

Spec Kit represents a fascinating evolution in how we think about AI-assisted development. Rather than replacing human planning, it provides structure and methodology to make our planning more comprehensive and actionable.

Conclusion

The investment in learning Spec Kit’s methodology pays dividends in the quality and detail of the resulting specifications. For development teams ready to embrace structured, specification-driven development, Spec Kit provides a powerful framework for transforming ideas into thoroughly planned implementations.

The key insight from my experience across all three tools is that different projects require different levels of planning sophistication. Having access to this spectrum of tools, from the quick accessibility of Plan Agent to the developer centric approach of Spec Kit. It enables us to match our planning approach to our project needs.

Have you experimented with GitHub Spec Kit or similar specification frameworks? I’d love to hear about your experiences and how you’re integrating structured planning into your development workflows.

From Awesome Copilot to Plan Agent: GitHub's Built-in Planning Revolution

Tue, 09 Dec 2025 19:00:00 +0000

In my previous post about delivering major enhancements using agentic DevOps, I shared how I leveraged GitHub’s Awesome Copilot repository to access proven prompts and agents for creating implementation plans. That approach served me well, but GitHub has now introduced something that changes the game entirely: the built-in Plan agent.

This post explores how the new Plan agent compares to my previous Awesome Copilot workflow, what’s changed in my approach, and whether this native integration delivers on its promise of streamlining complex coding tasks.

The Evolution: From External Resources to Native Integration

My Previous Approach with Awesome Copilot

When I wrote about my agentic DevOps journey, my planning workflow relied on external resources:

Accessing the Awesome Copilot repository for proven prompts and methodologies
Using the Create Implementation Plan prompt to generate comprehensive technical plans
Applying the Implementation Plan agent (formerly chat mode) to iteratively refine and expand the plan
Optionally using the MCP server to integrate these resources into my workflow

This approach worked exceptionally well, but it required:

Knowledge of where to find these resources
Manual integration of prompts and agents
Context switching between resources and VS Code
Configuration of MCP servers for seamless integration

The New Built-in Plan Agent

With VS Code 1.105, GitHub introduced the Plan agent as a native feature. Instead of hunting for external prompts or configuring MCP servers, you can now access planning capabilities directly from the Chat view.

graph LR
    subgraph Previous["Previous Approach"]
        A[Awesome Copilot Repo] --> B[Find Prompts]
        B --> C[Configure Agents]
        C --> D[Create Plan]
    end

    subgraph Current["Current Approach"]
        E[Open Chat View] --> F[Select Plan Agent]
        F --> G[Describe Task]
        G --> H[Receive Plan]
    end

    style A fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style B fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style C fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style D fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style E fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style F fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style G fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style H fill:#059669,stroke:#047857,stroke-width:3px,color:#fff

How the Plan Agent Works

The Plan agent is designed to help you analyse tasks, break them down into steps, and generate implementation plans before you start development. This approach helps avoid missing important requirements, something I emphasised heavily in my previous workflow.

Getting Started with Plan Agent

To use the Plan agent:

Open the Chat view (Ctrl+Alt+I)
Select Plan from the agents dropdown
Describe your task in detail
Review and refine the generated plan

The Handoff Feature

One of the most powerful features of the Plan agent is the handoff capability. After finalising your plan, you can:

Start implementation immediately: Transition directly to coding with context preserved
Save the plan for later: Store the plan for future reference or team collaboration

This handoff feature uses VS Code’s new custom chat modes system, creating guided workflows that transition between planning and implementation phases with suggested next steps.

Comparing the Two Approaches

What Awesome Copilot Offered

The Awesome Copilot resources provided:

Curated prompts: Community-tested and refined over time
Structured templates: Consistent format for implementation plans
Agents: Persona-driven interactions for specific tasks
Flexibility: Ability to customise and extend prompts
MCP integration: Programmatic access to resources

What Plan Agent Brings

The built-in Plan agent offers:

Zero configuration: Works out of the box in VS Code
Native integration: Seamless experience within the editor
Handoff workflow: Direct transition from planning to implementation
Context preservation: Plan context carries through to development
Subagent support: Works alongside VS Code’s new isolated subagents feature

My Experience: Plan Agent vs Awesome Copilot

The Good: Accessibility and Workflow

The Plan agent’s greatest strength is its accessibility. It’s incredibly intuitive and requires virtually no learning curve. Within minutes of opening the Chat view, I was generating comprehensive plans without needing to reference external documentation or configure anything.

The iterative refinement process feels natural. Unlike my previous workflow where I’d copy prompts from Awesome Copilot and paste them into chat, the Plan agent maintains conversation context seamlessly. I can ask for more detail on specific steps, request alternative approaches, or drill down into technical considerations without losing the thread of the discussion.

Perhaps most impressive is the handoff mechanism. The ability to transition directly from planning to implementation or save the plan to a file while preserving all context eliminates friction.

The Trade-offs: Structure and Depth

The Plan agent’s output differs from what I was accustomed to with Awesome Copilot’s structured templates:

Plan Structure: The Awesome Copilot “Create Implementation Plan” prompt produced well-structured output with clearly articulated goals and tasks broken down hierarchically, making it suitable for backlog items, stakeholder communication, or sprint ceremonies. In contrast, the Plan agent breaks plans down into detailed bulleted steps focused on technical implementation. While this works well for development, it’s less structured for project management purposes.

Risk and Dependency Analysis: I’ve noticed that dependencies and risks aren’t explicitly called out in the plans. The Awesome Copilot templates had dedicated sections for:

Technical dependencies and integration points
Potential risks and mitigation strategies
Security and compliance considerations
Performance implications

Integration with the Broader Agentic Workflow

The Plan agent doesn’t exist in isolation. It’s part of a broader ecosystem that GitHub introduced at Universe 2025:

graph TD
    A[Plan Agent] --> B[Create Implementation Plan]
    B --> C{Handoff Decision}
    C -->|Immediate| D[Start Implementation]
    C -->|Delegate| E[Coding Agent]
    C -->|Save| F[Plan for Later]

    D --> G[Local Development]
    E --> H[Autonomous Development]
    F --> I[Team Collaboration]

    G --> J[Pull Request]
    H --> J
    I --> K[Future Session]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style C fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style D fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style E fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style F fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style G fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style H fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style I fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style J fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style K fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a

Subagents for Research

The new isolated subagents feature complements the Plan agent perfectly. You can use subagents for:

Context gathering: Research authentication mechanisms, API patterns, or existing implementations
Analysis: Investigate codebase structure or dependency relationships
Parallel research: Delegate research tasks while you focus on planning

Delegation to Coding Agent

If your repository has the Copilot coding agent enabled, you can delegate directly from your planning session. This mirrors my previous workflow but with better context preservation:

Plan with the Plan agent
Refine and finalise the plan
Delegate to the coding agent
Review and merge the PR

Conclusion

The introduction of the Plan agent signals GitHub’s commitment to making agentic workflows more accessible. Rather than requiring developers to discover and configure external resources, core capabilities are being baked into the tools we use daily. The journey from Awesome Copilot prompts to the built-in Plan agent represents a significant step forward in making agentic DevOps accessible to all developers. While Awesome Copilot remains a valuable resource for customised workflows and team-specific templates, the Plan agent provides an excellent starting point that requires zero configuration.

For my workflow, the Plan agent has become my default starting point for new features and enhancements. The seamless integration, handoff capabilities, and context preservation make it a natural fit for the agentic DevOps approach I outlined in my previous post.

Have you tried the Plan agent in VS Code? I’d love to hear how it compares to your existing planning workflows. Share your experiences in the comments below.

Azure Copilot Agents: Transforming Cloud Operations

Sun, 23 Nov 2025 19:00:00 +0000

Microsoft Ignite 2025 has delivered what might be the most transformative announcement for cloud operations teams: Azure Copilot Agents. This isn’t just another AI assistant, it’s a fundamental reimagining of how we deploy, monitor, optimise, and troubleshoot cloud infrastructure.

The announcement centres around five specialised agents that work together as an orchestrated team, each bringing deep expertise in their domain while maintaining the context and governance that enterprise cloud operations demand. This is the natural evolution of what we’ve been building toward in the DevOps space: AI that doesn’t just complete our commands, but actively participates in the operational lifecycle.

The Problem: Cloud Operations Complexity at Scale

Before we dive into the solution, let’s acknowledge the reality of modern cloud operations. Today’s cloud teams are drowning in complexity:

Deployment sprawl: Managing infrastructure across multiple regions, subscriptions, and resource types
Reactive troubleshooting: Constant fire-fighting instead of proactive optimisation
Knowledge silos: Deep expertise trapped in individual team members
Context switching: Bouncing between Azure Portal, CLI tools, monitoring dashboards, and documentation
Compliance burden: Ensuring security and governance across growing environments

The traditional approach requires teams to master dozens of services, maintain mental models of complex interdependencies, and execute repetitive operational tasks that could be automated if only we had the orchestration capabilities to make it happen safely and reliably.

graph TD
    A[Cloud Operations Team] --> B[Azure Portal]
    A --> C[Azure CLI]
    A --> D[PowerShell Scripts]
    A --> E[Monitoring Dashboards]
    A --> F[Documentation Sites]

    B -.->|No shared context| C
    C -.->|Manual coordination| D
    D -.->|Reactive responses| E
    E -.->|Knowledge gaps| F
    F -.->|Context switching| B

    G[Complex Cloud Environment] --> H[Deployment Issues]
    G --> I[Performance Problems]
    G --> J[Security Concerns]
    G --> K[Cost Overruns]

    style A fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style B fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style C fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style D fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style E fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style F fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style G fill:#dc2626,stroke:#991b1b,stroke-width:3px,color:#fff
    style H fill:#ef4444,stroke:#dc2626,stroke-width:2px,color:#fff
    style I fill:#ef4444,stroke:#dc2626,stroke-width:2px,color:#fff
    style J fill:#ef4444,stroke:#dc2626,stroke-width:2px,color:#fff
    style K fill:#ef4444,stroke:#dc2626,stroke-width:2px,color:#fff

The Transformation: Azure Copilot as Your Cloud Operations Command Centre

Azure Copilot Agents transforms this fragmented experience into a unified, intelligent operations platform. Instead of managing tools, you’re orchestrating specialised agents that bring deep expertise to every aspect of cloud operations.

The core insight is elegant: Azure Copilot becomes your cloud operations command centre, intelligently surfacing the right agent at the right time based on your needs. Whether you’re deploying new infrastructure, investigating performance issues, or optimising costs, the appropriate specialist agent appears with full context and actionable recommendations.

graph TD
    A[Azure Copilot Command Centre] --> B[Deployment Agent]
    A --> C[Observability Agent]
    A --> D[Optimisation Agent]
    A --> E[Resiliency Agent]
    A --> F[Troubleshooting Agent]

    B <--> C
    C <--> D
    D <--> E
    E <--> F
    F <--> B

    G[Cloud Operations Team] --> A

    H[Unified Context & Governance] --> A
    I[Azure Well-Architected Framework] --> A
    J[Enterprise Controls] --> A

    style A fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style B fill:#3b82f6,stroke:#2563eb,stroke-width:2px,color:#fff
    style C fill:#8b5cf6,stroke:#7c3aed,stroke-width:2px,color:#fff
    style D fill:#f59e0b,stroke:#d97706,stroke-width:2px,color:#fff
    style E fill:#10b981,stroke:#059669,stroke-width:2px,color:#fff
    style F fill:#06b6d4,stroke:#0891b2,stroke-width:2px,color:#fff
    style G fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style H fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style I fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style J fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff

The Five Specialised Agents: Your Cloud Operations Dream Team

Let’s explore each agent and understand how they transform specific operational workflows.

1. Deployment Agent: Your Virtual Cloud Architect

The Deployment Agent serves as a virtual cloud solution architect, guiding you through infrastructure planning and deployment with precision and best practices built-in.

What Makes It Game-Changing

Intelligent planning: Translates high-level goals into detailed infrastructure blueprints
Azure Well-Architected compliance: All recommendations follow Microsoft’s framework
Multi-turn conversations: Clarifies requirements through iterative discussion
Complete automation: Generates ready-to-deploy code configurations
Integrated workflows: Direct integration with GitHub and VS Code for the Web

Example Workflow

Here’s how the Deployment Agent transforms a typical infrastructure request:

sequenceDiagram
    participant O as Operations Team
    participant AC as Azure Copilot
    participant DA as Deployment Agent
    participant GH as GitHub
    participant VS as VS Code Web

    O->>AC: "I need a scalable web app with SQL database"
    AC->>DA: Routes to Deployment Agent
    DA->>DA: Analyzes requirements
    DA->>AC: Asks clarifying questions about scale, regions, security
    O->>AC: Provides additional context
    DA->>DA: Generates comprehensive plan
    DA->>AC: Returns detailed infrastructure blueprint
    O->>AC: Approves plan
    DA->>DA: Generates code configurations
    DA->>AC: Presents configurations in artifact pane
    O->>VS: Opens in VS Code for the Web
    O->>GH: Creates pull request
    GH->>GH: CI/CD pipeline deploys infrastructure

    Note over O: Primary User
    Note over AC: Central Orchestrator
    Note over DA: Specialist Agent
    Note over GH: Version Control
    Note over VS: Development Environment

2. Observability Agent: Your Investigation Specialist

The Observability Agent transforms how you handle Azure Monitor alerts and incident investigation by providing deep, automated analysis and clear remediation paths.

Key Capabilities

Automated investigations: Creates Azure Monitor issues and runs root cause analysis
Contextual insights: Leverages your specific environment data
Multi-alert correlation: Identifies patterns across related alerts
Actionable remediation: Provides specific steps to resolve issues
Support escalation: Automatically creates support requests when needed

Practical Usage Patterns

Direct Alert Investigation:

# When viewing an alert in Azure Portal
"Can you help investigate this alert?"

# For specific alerts
"Start an investigation for my alert: /subscriptions/[...]/alerts/ALERT_ID"

Proactive Monitoring:

"What are the key alerts raised in the last 24 hours?"
"Show me any patterns in Application Insights failures"

3. Optimisation Agent: Your Cost and Performance Expert

The Optimisation Agent focuses on reducing costs and carbon emissions while maintaining performance, a critical capability for sustainable cloud operations.

Current Focus Areas

Resource Types:

Virtual Machines (VMs)
Virtual Machine Scale Sets (VMSS)

Optimisation Capabilities:

Detailed recommendations: Specific actions with cost impact analysis
Alternative options: Multiple approaches for comparison
Script generation: Ready-to-execute PowerShell and Azure CLI commands
Visual insights: Charts showing expected results
Carbon footprint: Environmental impact analysis

Example Optimisation Workflow

graph TD
    A[Request Optimisation] --> B[Agent Analyses Usage Patterns]
    B --> C[Identifies Opportunities]
    C --> D[Calculates Impact]
    D --> E[Generates Recommendations]
    E --> F[Creates Visual Charts]
    F --> G[Provides Scripts]
    G --> H{Approve Changes?}
    H -->|Yes| I[Execute Optimisations]
    H -->|No| J[Explore Alternatives]
    J --> E
    I --> K[Monitor Results]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style C fill:#8b5cf6,stroke:#7c3aed,stroke-width:2px,color:#fff
    style D fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style E fill:#3b82f6,stroke:#2563eb,stroke-width:2px,color:#fff
    style F fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style G fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style H fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style I fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style J fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style K fill:#10b981,stroke:#059669,stroke-width:2px,color:#fff

Sample Optimisation Requests

Subscription-wide Analysis:

"Show me the top five cost-saving opportunities for subscription [GUID]"
"Summarise total potential cost and carbon reduction from all active recommendations"

Resource-specific Optimisation:

"Show me cost saving recommendations for [Resource URI]"
"Is there an alternate recommendation for ContosoVM1?"
"Generate a PowerShell script to apply the recommended optimisations"

4. Resiliency Agent: Your Business Continuity Guardian

The Resiliency Agent helps ensure your Azure resources can recover from failures, cyber attacks, data corruption, and datacentre outages.

Core Responsibilities

Zonal resiliency configuration: Multi-zone deployment strategies
Backup management: Azure Backup policy implementation
Disaster recovery: Azure Site Recovery setup and management
Security posture: Recovery services security improvements
Compliance monitoring: Backup and recovery compliance checking

Zonal Resiliency Automation

The agent provides ready-to-deploy scripts for configuring zonal resiliency across supported services:

Supported Services:

Virtual Machines
App Services
Azure Database for PostgreSQL
Azure Database for MySQL
SQL Managed Instance
Azure Cache for Redis
Azure Firewall

Sample Resiliency Tasks

Infrastructure Hardening:

"Configure zonal resiliency for this resource"
"Which service groups are currently not zonally resilient?"
"Increase the security level of this vault"

Backup and Recovery:

"How many backup jobs failed in the last 24 hours?"
"Which data sources don't have a recovery point within the last 7 days?"
"Help me create vault ABC"

5. Troubleshooting Agent: Your Technical Support Specialist

The Troubleshooting Agent accelerates issue resolution by running diagnostics, providing solutions, and creating support requests when needed.

Advanced Capabilities

Root cause analysis: Deep diagnostic investigation
One-click fixes: Automated resolution for common issues
Support request generation: Automated ticket creation with full context
Resource-specific expertise: Specialised knowledge for different Azure services

Specialised Service Support

Azure Cosmos DB:

"Help me troubleshoot why my Cosmos DB Cassandra API is failing"
"I'm trying to connect to Azure Cosmos DB from my local machine, but I keep getting a timeout"

Virtual Machines:

"Help me investigate why my VM is unhealthy"
"I can't connect to my VM, can you help me troubleshoot?"

Azure Kubernetes Service:

"Investigate the health of my pods"
"Identify reasons for high CPU or memory usage in my AKS cluster"

Agent Orchestration: The Magic of Intelligent Routing

What makes Azure Copilot Agents truly powerful is the intelligent orchestration. You don’t need to manually select which agent to use, the system automatically surfaces the right agent based on your request.

How Orchestration Works

graph TD
    A[User Request] --> B[Azure Copilot Orchestration]
    B --> C{Request Analysis}

    C -->|"Deploy infrastructure"| D[Deployment Agent]
    C -->|"Investigate alert"| E[Observability Agent]
    C -->|"Reduce costs"| F[Optimisation Agent]
    C -->|"Configure backups"| G[Resiliency Agent]
    C -->|"Fix connection issue"| H[Troubleshooting Agent]

    D --> I[Specialised Response]
    E --> I
    F --> I
    G --> I
    H --> I

    I --> J[Cross-Agent Collaboration]
    J --> K[Unified Result]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style C fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style D fill:#3b82f6,stroke:#2563eb,stroke-width:2px,color:#fff
    style E fill:#8b5cf6,stroke:#7c3aed,stroke-width:2px,color:#fff
    style F fill:#f59e0b,stroke:#d97706,stroke-width:2px,color:#fff
    style G fill:#10b981,stroke:#059669,stroke-width:2px,color:#fff
    style H fill:#06b6d4,stroke:#0891b2,stroke-width:2px,color:#fff
    style I fill:#64748b,stroke:#475569,stroke-width:2px,color:#fff
    style J fill:#8b5cf6,stroke:#7c3aed,stroke-width:2px,color:#fff
    style K fill:#059669,stroke:#047857,stroke-width:3px,color:#fff

Cross-Agent Collaboration

The real magic happens when agents work together. For example:

Troubleshooting Agent identifies a performance issue
Optimisation Agent provides cost-effective solutions
Deployment Agent generates infrastructure changes
Resiliency Agent ensures the solution includes backup strategies
Observability Agent sets up monitoring for the new configuration

Getting Started: Enabling Agent Mode

Using Azure Copilot Agents is straightforward once your tenant has access:

NOTE: Azure Copilot Agents is currently in preview and access will be rolled out gradually over time.

Step 1: Enable Agent Mode

In Azure Copilot, start a conversation as you normally would, then select the agent mode icon.

Step 2: Natural Language Requests

Simply describe what you need in natural language:

"I need to set up a resilient web application with global load balancing"
"Why is my Application Insights showing high response times?"
"What are the biggest cost optimisation opportunities in my environment?"

Step 3: Review and Approve

Agents provide detailed plans and recommendations before taking any action. You maintain full control over what gets implemented.

Step 4: Monitor and Iterate

Use the unified interface to track agent progress, review results, and provide feedback for continuous improvement.

Enterprise Considerations: Security and Governance

Microsoft has built enterprise-grade controls into the agent experience, addressing critical concerns for production use.

Tenant-Level Access Control

Gradual rollout: Access is managed at the tenant level with gradual expansion
Administrator control: IT admins can enable/disable access and manage user groups
Audit trail: Complete logging of all agent activities
Compliance integration: Works within existing Azure governance frameworks

Security Best Practices

Built-in Protections:

Integration with Azure RBAC
Compliance with organisational policies

Privacy and Data Handling

Microsoft has implemented strict data handling practices:

Conversations are encrypted and secured
No training data extraction from your environment
Compliance with enterprise privacy requirements
Integration with existing Azure security controls

Current Limitations and Future Roadmap

Current Preview Limitations

Deployment Agent:

Terraform configurations only (ARM and Bicep coming)
Greenfield deployments only (existing infrastructure import coming)
Manual CI/CD integration (automated pipelines coming)

Optimisation Agent:

VMs and VMSS only (more resource types coming)
No automatic execution (approval workflows coming)
Limited budget integration (full cost management coming)

Observability Agent:

Application Insights alerts only (broader alert types coming)
Investigation only (automatic remediation coming)

Language Support:

Full support in English only
Limited support for other languages

Expected Enhancements

Microsoft has outlined several areas of active development:

Expanded Resource Support:

More resource types for optimisation
Broader troubleshooting capabilities
Enhanced resiliency configurations

Deeper Integration:

Native CI/CD pipeline creation
Advanced governance controls
Multi-cloud scenarios

Advanced Capabilities:

Predictive optimisation recommendations
Automated remediation with approval workflows
Cross-tenant collaboration for managed service providers

Strategic Implications: The Future of Cloud Operations

Azure Copilot Agents represents more than just new tooling, it’s a fundamental shift toward agentic cloud operations. This transformation has several strategic implications:

1. Role Evolution

Cloud Architects become orchestrators, focusing on:

Strategic planning and governance
Agent delegation and oversight
Cross-platform integration

Operations Engineers shift from reactive to proactive:

Defining automation policies
Monitoring agent effectiveness
Continuous improvement processes

2. Skill Development

New competencies become critical:

Agent prompt engineering: Crafting effective requests
Agentic workflow design: Orchestrating multi-agent processes
AI-human collaboration: Working effectively with AI partners

3. Organisational Changes

Faster Innovation Cycles:

Rapid infrastructure experimentation
Automated compliance and security
Continuous optimisation

Improved Reliability:

Proactive issue detection
Consistent best practices application
Reduced human error

Cost Efficiency:

Automated optimisation recommendations
Resource right-sizing
Predictive capacity planning

Conclusion: Embracing the Agentic Future

Microsoft Ignite 2025’s Azure Copilot Agents announcement signals the beginning of truly agentic cloud operations. This isn’t just an incremental improvement, it’s a fundamental reimagining of how we interact with cloud infrastructure.

The five specialised agents (Deployment, Observability, Optimisation, Resiliency, and Troubleshooting) work together as an expert team that never sleeps, never forgets best practices, and continuously learns from your environment. The intelligent orchestration means you focus on strategic decisions while agents handle operational execution.

Key Takeaways

Start experimenting now: Request preview access and begin familiarising your team
Plan for workflow changes: Consider how agentic operations will transform your processes
Invest in agent skills: Begin developing prompt engineering and AI collaboration competencies
Prepare governance frameworks: Establish controls and approval processes for agent activities
Measure and iterate: Track efficiency gains and optimise agent utilisation

The transformation is already underway. Organisations that embrace agentic cloud operations now will have a significant advantage in speed, reliability, and cost efficiency. The question isn’t whether this future will arrive, it’s whether you’ll be ready to lead in it.

Ready to start your agentic cloud operations journey? Begin by exploring the Azure Copilot Agents documentation and requesting access for your organisation.

Have you started experimenting with Azure Copilot Agents? I’d love to hear about your experiences and what use cases you’re exploring. Share your thoughts and questions in the comments below.

Welcome Home, Agents: How GitHub Copilot Agent HQ is Transforming Development Workflows

Sun, 16 Nov 2025 19:00:00 +0000

The development landscape has fundamentally shifted. We’re no longer working with simple AI assistants that complete our code,we’re orchestrating fleets of specialised agents that can take on entire features, collaborate across tools, and work asynchronously while we sleep. GitHub’s announcement of Agent HQ at Universe 2025 marks a pivotal moment in how we think about development workflows, and the accompanying VS Code updates make this vision tangible today.

After spending the last few months working deeply with GitHub Copilot’s coding agent and now experimenting with the latest VS Code agent integrations, I’ve witnessed firsthand how this transformation changes everything from how we plan work to how we manage our development sessions. This isn’t hype,it’s a fundamental shift in how development teams operate.

The Problem: Fragmented Agent Experiences

Before Agent HQ, working with AI agents felt like managing multiple contractors who all used different communication channels, had no visibility into each other’s work, and required constant context switching. You might have:

GitHub Copilot coding agent running on GitHub.com
VS Code local chat sessions for immediate help
GitHub Copilot CLI for terminal commands
Third-party agents like OpenAI Codex or Anthropic Claude in their native interfaces

Each operated in its own silo. You’d assign work to a coding agent on GitHub, switch to VS Code to write some code with chat assistance, jump to the terminal for CLI help, and then try to mentally piece together what was happening across all these sessions. The cognitive overhead was immense, and the lack of unified visibility meant agents couldn’t benefit from each other’s context.

graph TD
    A[Developer] --> B[GitHub Copilot on GitHub.com]
    A --> C[VS Code Chat Sessions]
    A --> D[GitHub Copilot CLI]
    A --> E[Third-Party Agents]

    B -.->|No visibility| C
    C -.->|No visibility| D
    D -.->|No visibility| E
    E -.->|No visibility| B

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style C fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style D fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style E fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a

The Vision: Agent HQ as Your Development Command Centre

GitHub’s Agent HQ fundamentally reimagines this experience. Instead of disconnected tools, you get mission control,a unified command centre that follows you wherever you work. Whether you’re in VS Code, on GitHub.com, using the CLI, or even on mobile, you have consistent visibility and control over all your agents.

The core principle is elegant: GitHub is your Agent HQ. It’s where agents live, work, and collaborate, just like human developers do through pull requests and issues.

graph TD
    A[Agent HQ: Mission Control] --> B[VS Code Sessions]
    A --> C[GitHub Copilot Coding Agent]
    A --> D[GitHub Copilot CLI]
    A --> E[Third-Party Agents]
    A --> F[Mobile/Web Access]

    B <--> C
    C <--> D
    D <--> E
    E <--> B

    G[Developer] --> A

    style A fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style G fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style C fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style D fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style E fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style F fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a

The Game Changer: Agent Sessions View in VS Code

The October 2025 VS Code release (v1.106) brings Agent HQ directly into your editor with the Agent Sessions view. This is now enabled by default and provides centralised management of all your active agent sessions, both local and remote.

What the Agent Sessions View Gives You

The Agent Sessions view is organised by source, making it easy to see exactly what’s happening across your development environment:

Local Chat Sessions: Your VS Code chat conversations
Copilot Coding Agent: Background agent sessions running on GitHub
GitHub Copilot CLI: Terminal-based agent sessions
Third-Party Agents: Sessions from OpenAI Codex, Anthropic Claude, and others

graph LR
    A[Agent Sessions View] --> B[Local Sessions]
    A --> C[Coding Agents]
    A --> D[CLI Sessions]
    A --> E[Third-Party Agents]

    B --> B1[Chat Session 1]
    B --> B2[Chat Session 2]

    C --> C1[Issue #123: Add DNS Fallback]
    C --> C2[Issue #456: Fix Bug]

    D --> D1[Terminal Session 1]

    E --> E1[OpenAI Codex Session]
    E --> E2[Anthropic Claude Session]

    style A fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style B fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style C fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style D fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a
    style E fill:#94a3b8,stroke:#64748b,stroke-width:2px,color:#0f172a

Practical Workflow with Agent Sessions

Here’s how this changes your daily workflow:

Morning Stand-up Scenario:

Open VS Code
Check Agent Sessions view
See that the coding agent completed 3 PRs overnight
Review the CLI agent's deployment preparation
Resume your local chat session from yesterday
All without leaving your editor

You can search sessions (Ctrl+Alt+F), quickly jump between them, and see the status of background work at a glance. The view also supports a consolidated single-view mode if you prefer everything in one place.

Plan Agent: The Strategic Thinking Partner

One of the most impactful additions is the Plan Agent, available via the agents dropdown in the Chat view. This fundamentally changes how I approach complex features.

Why Planning Matters More Than Ever

I’ve learned from my agentic DevOps journey that the quality of AI output directly correlates with the quality of planning input. The Plan Agent addresses this by helping you:

Break down complex tasks into step-by-step implementation plans
Ask clarifying questions to ensure all requirements are captured
Identify dependencies and potential issues before code is written
Create a detailed blueprint that you approve before implementation begins

How We Can Use the Plan Agent

Here’s an example workflow:

graph TD
    A[Start with Feature Idea] --> B[Select Plan Agent]
    B --> C[Describe Feature Requirements]
    C --> D[Agent Asks Clarifying Questions]
    D --> E[Iterate on Requirements]
    E --> F[Review Generated Plan]
    F --> G{Plan Acceptable?}
    G -->|No| E
    G -->|Yes| H[Approve Plan]
    H --> I[Choose Implementation Method]
    I --> J[Local Implementation in VS Code]
    I --> K[Cloud Agent Implementation]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style H fill:#059669,stroke:#047857,stroke-width:3px,color:#fff
    style G fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff

The beauty is that you invest time upfront in the plan, catching gaps and missing decisions early, before any code is written. This dramatically reduces rework and improves the final implementation quality.

Custom Plan Agents for Your Team

VS Code also lets you create custom plan agents tailored to your organization’s workflows. Using the “Configure Custom Agent” menu, you can:

Copy the built-in plan agent as a starting point
Customise planning style to match your methodology (Agile, Waterfall, etc.)
Define specific tools and prompts for your domain
Set organization-specific guidelines and constraints

This means your team can have consistent planning approaches while maintaining flexibility for different project types.

Cloud Agents: Seamless Background Execution

The October VS Code release migrated the Copilot coding agent integration from the GitHub Pull Request extension directly into the Copilot Chat extension. This might seem like a small technical change, but it’s actually huge for the user experience.

What Changed and Why It Matters

Before: Coding agent functionality felt bolted on, living in a separate extension with different behaviours and limited integration.

Now: Cloud agents are first-class citizens in VS Code, providing:

Native experience: Same interface patterns as local chat
Bidirectional transitions: Smoothly move between VS Code and GitHub Mission Control
Unified context: Cloud agents benefit from your local workspace context
Consistent delegation: Delegate work to cloud agents using familiar patterns

Example Cloud Agent Workflow

Here’s how cloud agents fit into a typical development day:

**Morning:** Assign 3 issues to Copilot coding agent on GitHub.com

**During the Day:** Work on other tasks, occasionally checking Agent Sessions view

**Afternoon:** Coding agent creates PRs for 2 completed issues

**Evening:** Review PRs in VS Code, provide feedback as PR comments

**Overnight:** Coding agent iterates on feedback

**Next Morning:** PRs ready to merge

The key insight: You’re not blocked waiting for implementations. You maintain momentum on strategic work while agents handle the execution heavy lifting.

sequenceDiagram
    participant D as Developer
    participant GH as GitHub.com
    participant CA as Coding Agent
    participant VS as VS Code

    D->>GH: Assign issues to @copilot
    activate CA
    CA->>CA: Analyses requirements
    CA->>CA: Implements features
    CA->>GH: Creates PRs
    deactivate CA

    D->>VS: Opens Agent Sessions view
    VS->>GH: Fetches agent status
    GH->>VS: Shows completed PRs

    D->>VS: Reviews PR in editor
    D->>GH: Adds review comments

    activate CA
    CA->>GH: Reads feedback
    CA->>CA: Implements changes
    CA->>GH: Updates PR
    deactivate CA

    D->>VS: Final review & merge

CLI Agents: Terminal Intelligence

The GitHub Copilot CLI integration brings agents directly into your terminal workflow. This is particularly powerful for complex command sequences and system administration tasks.

How CLI Agents Work in VS Code

VS Code now provides two ways to work with CLI agents:

Chat Editor Mode: Create CLI agent sessions in a dedicated editor
Integrated Terminal Mode: Run CLI agents directly in your terminal

Chat Editor Benefits:

Full chat interface with message history
Model switching capabilities
Context attachment from workspace files
Persistent sessions across VS Code restarts

Terminal Mode Benefits:

Natural command-line feel
Immediate execution in your shell environment
Integration with existing shell history
Quick access via terminal dropdown

Practical CLI Agent Use Cases

Infrastructure Deployment:

# In CLI agent terminal
@copilot How do I deploy this Bicep template to multiple regions with different parameters?

# Agent provides step-by-step commands
# You can execute them directly or ask for clarifications

Troubleshooting:

# Attach error logs
@copilot /attach error.log
@copilot Why is this Azure Function failing to start?

# Agent analyses logs and suggests fixes

CLI Edit Tracking

A particularly useful feature: chat edit sessions now track edits made by CLI agents. When you create sessions from the Agent Sessions view, you can see edits through:

Inline edit pills: Visual indicators in your code
Working set view: Comprehensive list of all changed files

This means you maintain full visibility into what CLI agents modify, just like you would with local chat sessions or coding agents.

Agent Delegation: Orchestrating Specialised Work

The delegation model is where Agent HQ truly shines. Instead of doing everything yourself, you can delegate specific tasks to the most appropriate agent for the job.

How Delegation Works

From any chat session, you can:

Identify specialised work: “This needs deployment expertise”
Use the cloud button: Delegates to available agents
Choose the agent: Select from Copilot coding agent or third-party agents
Monitor progress: Track in Agent Sessions view

From CLI to Coding Agent:

The /delegate command in CLI editors or terminal instances allows you to hand off work directly to the Copilot coding agent. This is incredibly useful when you realise a terminal task requires broader codebase changes.

# In CLI agent session
@copilot Create a deployment script for multi-region failover

# Agent realises this needs code changes
# You delegate to coding agent
/delegate Create the deployment script and integrate with CI/CD pipeline

# Coding agent picks up work, creates branch, implements changes

Delegation Strategy

A strategic mental model for choosing the right agent for each task:

Local Chat (VS Code): Quick questions, code explanations, immediate assistance
Plan Agent: Strategic planning, requirement refinement, architectural decisions
Coding Agent: Feature implementation, bug fixes, pattern replication
CLI Agent: Deployment commands, system configuration, troubleshooting
Third-Party Agents: Specialised tasks (e.g., OpenAI Codex for Python, Claude for documentation)

graph TD
    A[Development Task] --> B{Task Type?}

    B -->|Quick Question| C[Local VS Code Chat]
    B -->|Complex Feature| D[Plan Agent]
    B -->|Implementation| E[Coding Agent]
    B -->|Terminal/Deploy| F[CLI Agent]
    B -->|Specialised| G[Third-Party Agent]

    D --> H[Create Plan]
    H --> E

    C --> I{Needs More?}
    I -->|Yes| E
    I -->|No| J[Done]

    E --> K[Creates PR]
    K --> L[Review in VS Code]

    F --> M{Complex Changes?}
    M -->|Yes| E
    M -->|No| N[Execute Commands]

    style A fill:#2563eb,stroke:#1e40af,stroke-width:3px,color:#fff
    style B fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style I fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style M fill:#f59e0b,stroke:#d97706,stroke-width:3px,color:#fff
    style J fill:#059669,stroke:#047857,stroke-width:3px,color:#fff

Custom Agents: Tailoring AI to Your Workflow

One of the most powerful features is the ability to create custom agents with .agent.md files. These replace the previous “chat modes” and are now compatible across VS Code, GitHub Copilot Cloud Agents, and GitHub CLI.

Why Custom Agents Matter

Custom agents let you:

Encode team knowledge: Specific patterns, conventions, and best practices
Create specialists: Security-focused agents, testing agents, documentation agents
Define workflows: Multi-step processes unique to your organization
Control behaviours: Precise guardrails and guidelines for AI behaviour

Creating a Custom Agent

Custom agent files live in .github/agents/ and use the .agent.md suffix:

---
description: Generate an implementation plan for new features or refactoring existing code.
name: Planner
target: vscode
tools: ["fetch", "githubRepo", "search", "usages"]
model: Claude Sonnet 4
handoffs:
  - label: Implement Plan
    agent: agent
    prompt: Implement the plan outlined above.
    send: false
---

# Planning instructions

You are in planning mode. Your task is to generate an implementation plan for a new feature or for refactoring existing code.
Don't make any code edits, just generate a plan.

The plan consists of a Markdown document that describes the implementation plan, including the following sections:

- Overview: A brief description of the feature or refactoring task.
- Requirements: A list of requirements for the feature or refactoring task.
- Implementation Steps: A detailed list of steps to implement the feature or refactoring task.
- Testing: A list of tests that need to be implemented to verify the feature or refactoring task.

Custom Agent Metadata

The target property is particularly important as it determines how the agent runs:

target: vscode: Optimised for local VS Code chat with access to:

name: Custom display name
description: Agent purpose
argument-hint: Guidance on prompting
model: Preferred AI model
tools: Available VS Code tools
handoffs: Links to other agents

target: github-copilot: Prepared for cloud agents and CLI with:

name: Display name
description: Purpose
tools: Limited to edit, search, shell, custom-agent, and MCP tools
mcp-servers: Model Context Protocol server access
target: Deployment environment

Agent Handoffs: Workflow Orchestration

The handoffs property enables guided transitions between agents, letting you chain multi-step workflows:

---
name: Feature Development Agent
handoffs: [plan-agent, testing-agent, security-agent, documentation-agent]
---

## Workflow

1. Start with plan-agent for requirements
2. Implement features
3. Hand off to testing-agent for test coverage
4. Hand off to security-agent for security review
5. Hand off to documentation-agent for docs

This creates a pipeline where each agent specialises in its domain, but they work together seamlessly.

VS Code Agent File Editing

The VS Code editor now provides rich support for .agent.md files:

Validation: Real-time errors for invalid configurations
Code completions: IntelliSense for properties and values
Hovers: Documentation for each property
Code actions: Quick fixes and migrations

There’s even an auto-migration feature for older .chatmode.md files with a quick fix to convert them to the new format.

Enterprise Considerations: Control and Governance

With great power comes great responsibility. Agent HQ includes enterprise-grade controls that I consider essential for production use.

The Agent Control Plane

GitHub’s control plane provides centralised governance for AI agents across your organization:

Agent Access Control: Define which agents are allowed in your org
Model Access Management: Control access to specific AI models
Security Policies: Set organization-wide security rules
Audit Logging: Complete audit trails of agent activities
Usage Metrics: Understand Copilot usage across teams

Branch Controls for Agent-Created Code

Utilise branch controls provide granular oversight:

## Branch Protection for Agent PRs

- CI required before allowing any modifications to agent PRs
- Status checks must pass before human review
- Draft PRs block GitHub Actions workflows by default
- Require approval from someone other than the task requester

This ensures agent-created code goes through the same rigour as human-written code.

Identity and Attribution

All agent work is properly attributed:

Co-authored commits: Shows both agent and human collaborator
Session logs: Complete transparency into agent decision-making
Review requirements: Enforces separation of duties
Audit trails: Full compliance documentation

Security Best Practices with Agent HQ

Working with AI agents introduces new security considerations. Here’s how to maintain security hygiene while leveraging Agent HQ’s capabilities:

1. Start with Recommended Defaults

The built-in security protections are solid:

Sandboxed execution environments
Read-only repository access
Branch naming restrictions (copilot/* only)
Branch protection compliance

2. Add Custom Instructions for Security

In your .github/copilot-instructions.md:

## Security Requirements

- Never commit secrets, API keys, or passwords
- Use Azure Key Vault references for sensitive data
- Implement least privilege access patterns
- All security-sensitive changes require security-agent review

3. Configure Firewall Settings

For enterprise environments, customise agent internet access:

# Recommended: Allow specific internal resources
firewall:
  enabled: true
  recommended_allowlist: true
  custom_allowlist:
    domains:
      - "artifacts.company.internal"
      - "packages.company.internal"

4. Review Session Logs

Make it a practice to review agent session logs at github.com/copilot/agents:

Internal reasoning: Understand the agent’s decision-making
Tool usage: What commands were executed
Code changes: Complete diffs
Test results: Validation outputs

The GitHub MCP Registry: Extending Agent Capabilities

VS Code is the only editor that supports the full Model Context Protocol (MCP) specification, and the October release makes it even better with the GitHub MCP Registry integration.

What is MCP?

Model Context Protocol allows agents to interact with external services and data sources. Think of it as APIs for AI agents.

One-Click MCP Server Installation

The GitHub MCP Registry in VS Code lets you:

Discover: Browse available MCP servers (Stripe, Figma, Sentry, etc.)
Install: One-click installation directly from VS Code
Enable: Instant availability for all agents
Configure: Workspace or user-level installation

This means your agents can interact with your tools and services without custom integration work.

Creating Custom Agents with MCP Tools

Combine custom agents with MCP servers for powerful workflows:

---
name: Deployment Agent
target: github-copilot
tools: [shell, custom-agent]
mcp-servers: [azure-mcp, datadog-mcp]
---

# Deployment Specialist

You handle Azure deployments and monitoring.

When deploying:

1. Use azure-mcp to validate resource configurations
2. Execute deployments via shell tool
3. Use datadog-mcp to set up monitoring
4. Create deployment documentation

Example Workflow: Putting It All Together

Let us walk through how we can use all these features together in a typical development scenario.

Scenario: Adding a Complex Feature to an Infrastructure Project

Step 1: Planning with Plan Agent (10 minutes)

Me: I need to add geo-redundant disaster recovery to our Azure landing zone pattern

Plan Agent: [Asks clarifying questions about RPO/RTO requirements, budget constraints, region preferences]

[After discussion...]

Plan Agent: Here's your comprehensive plan with 4 phases, 15 tasks, dependencies mapped...

Step 2: Create Backlog Items

Using the awesome-copilot prompts (via MCP server):

@copilot Use the create-github-issues-from-plan prompt to generate issues from this plan

[Generates 15 detailed GitHub issues with descriptions, acceptance criteria, dependencies]

Step 3: Delegate to Coding Agent

Assign issues to @copilot on GitHub.com. Monitor progress via Agent Sessions view in VS Code.

Step 4: Parallel Development

While coding agent works on infrastructure, we use:

Local Chat: Quick questions about Azure services
CLI Agent: Test deployment commands
Custom Security Agent: Review security implications

Step 5: PR Reviews

As PRs arrive:

Review in VS Code
Use custom testing agent to validate
Provide feedback as PR comments
Coding agent iterates automatically

Step 6: Integration

Use CLI agent to:

Deploy to test environment
Run integration tests
Monitor with MCP-connected tools

The Result: Feature delivered in days instead of weeks, with consistent quality and complete documentation.

gantt
    title Agent HQ Workflow Timeline
    dateFormat YYYY-MM-DD

    section Planning
    Plan Agent Discussion       :2025-11-20, 1d

    section Backlog
    Generate Issues             :2025-11-20, 1d

    section Development
    Coding Agent Work           :2025-11-21, 3d
    Parallel Local Development  :2025-11-21, 3d
    CLI Testing                 :2025-11-22, 2d

    section Review
    PR Reviews                  :2025-11-24, 2d
    Agent Iterations            :2025-11-24, 2d

    section Integration
    Deployment & Testing        :2025-11-26, 1d

What’s Next: The Future of Agent HQ

GitHub’s roadmap for Agent HQ is ambitious and exciting:

Upcoming Third-Party Agents

Over the coming months, agents from these providers will be available:

Anthropic Claude: Deep reasoning and code analysis
OpenAI Codex: Advanced code generation (already available in Insiders)
Google Jules: Google’s coding agent capabilities
Cognition: Specialised development workflows
xAI: Elon Musk’s AI coding assistant

All accessible through your existing GitHub Copilot subscription, no additional accounts needed.

Enhanced Mission Control

Upcoming improvements to mission control:

Mobile app access: Monitor agents from anywhere
Slack/Linear/Teams integrations: Agent notifications in your workflow tools
Advanced delegation: More sophisticated task routing
Multi-agent collaboration: Agents working together on complex tasks

Code Quality Integration

GitHub Code Quality (in public preview) will integrate with Agent HQ to:

Pre-review agent code: Automated quality checks before human review
Maintainability scoring: Org-wide code health visibility
Automatic remediation: Agents fix quality issues proactively

Conclusion: A New Era of Development

Agent HQ represents a fundamental shift in how we think about development teams. We’re moving from a world where developers write all code to one where developers orchestrate specialised agents that handle implementation while humans focus on strategy, architecture, and quality.

The VS Code October 2025 release makes this vision tangible. With the Agent Sessions view, Plan Agent, cloud agents, CLI integration, custom agents, and MCP support, we now have a cohesive environment for agentic development.

What strikes me most is how natural it feels. Yes, there’s a learning curve and some rough edges to smooth out, but the core experience of working with agents through Agent HQ feels intuitive. It’s not bolted-on AI,it’s AI integrated into the development workflow we already know.

The key insight: This isn’t about AI replacing developers. It’s about transforming development from a primarily solitary activity to an orchestrated collaboration between humans and specialised agents. The developer’s role evolves from writing every line of code to designing systems, defining requirements, reviewing implementations, and making strategic decisions.

For those of us who have spent years in DevOps, this is the natural evolution we’ve been working toward: automation that doesn’t just handle repetitive tasks but actively participates in the creative process of building software.

Ready to embrace Agent HQ? Start small:

Enable the Agent Sessions view in VS Code
Try the Plan Agent for your next feature
Create one custom agent for your team’s domain
Delegate a well-defined task to the coding agent
Reflect on what worked and iterate

The future of development is here. Welcome home, agents.

Have you started working with Agent HQ and the new VS Code agent features? I’d love to hear about your experiences and what patterns you’ve discovered. Share your thoughts in the comments below.

Azure with AJ

Azure DevOps vs GitHub: Your 2026 Platform Decision

TL;DR

The Real Difference in 2026

What Microsoft Really Announced at Build 2026

The GitHub Copilot App as the Control Centre

GitHub Gets the Newest Capabilities First

Azure DevOps Keeps Calm and Carries On

When to Use Each Platform

The Industry Shift: DevOps to Agentic DevOps

A Pragmatic Hybrid Migration Path

Key Insights for Engineering Leaders

Conclusion and Next Steps

How to Organise GitHub Copilot Customisations at Scale

TL;DR

The Confusion Nobody Talks About

The Pattern: One Source of Truth, Two Distribution Channels

Repo 1: agent-platform (Source of Truth)

Repo 2: .github-private (Automatic Org Distribution)

Linking the Two Repos via the Plugin Marketplace

Referencing Skills and Templates from Agents

The Caveat That Cost Me Hours

Governance and Ownership

Wrapping Up

Agents as Code: Treating AI Agents as Versioned Artifacts

TL;DR

The Problem: Agents Without Anchors

AGENTS.md vs Custom Agents: Know the Difference

AGENTS.md: The Operating Manual

Custom Agents (.github/agents/): The Specialist Roles

How They Work Together

How This Changes Team Workflows

Governance That Scales

Lessons from 2,500+ Repositories

Practical Patterns to Adopt

The Bigger Picture: Everything as Code

Wrapping Up

References

Agentic Workflows: Reimagining Repository Automation with Natural Language

TL;DR

The Problem: Current Automation is Still Too Complex

What Are Agentic Workflows?

How Agentic Workflows Work

The Execution Model

A Concrete Example: Contribution Guidelines Checker

Why Agentic Workflows Exist: The Problem They Solve

Beyond Heuristics

The Continuous AI Vision

Practical Use Cases

Code Review and Quality

Documentation and Communication

Issue Management

Continuous Improvement

Real Example: Diving into Contribution Guidelines Checker

Security and Safety: Building Trust in AI Automation

1. Principle of Least Privilege

2. Sandboxed Execution

3. Safe Output Validation

4. Compilation and Verification

5. Model-Agnostic Safety

Security Best Practices for Your Workflows

Getting Started: Your First Agentic Workflow

Installation

Quick Start: Try a Real Workflow

Creating Your Own Workflow

Triggering Your Workflow

Limitations and Considerations

Conclusion: The Future is Conversational

Further Reading

MCP Apps: Interactive Dashboards Inside Your AI Conversations

What Are MCP Apps?

The Problem MCP Apps Solve

How MCP Apps Work

1. Tool Registration with UI Metadata

2. UI Preloading and Resource Fetching

3. Sandboxed Rendering

4. Bidirectional Communication

Practical Uses: Building an Azure Storage Dashboard

Security Considerations for MCP Apps

Sandboxing Fundamentals

Repo 1: `agent-platform` (Source of Truth)

Repo 2: `.github-private` (Automatic Org Distribution)