Azure with AJ

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.

DevOps: Enhanced Release Automation with GitHub's AI-Powered Release Notes

Tue, 21 Oct 2025 19:00:00 +0000

In my previous article, “DevOps: Automating Release Tags”, I shared how we automated version tagging and release creation using GitHub Actions. While that solution worked well, the release notes generation was basic, essentially just copying the PR title and description. Today, I’ll show you how we evolved this approach by leveraging GitHub’s powerful automatic release notes generation API.

The Evolution: From Basic to Intelligent Release Notes

Our original workflow created releases with simple summaries, but we wanted something more comprehensive and professional. We envisioned release notes that would include:

Comprehensive Release Overview: A clear summary of what’s included in the release
Merged Pull Requests: A complete list of all PRs that contributed to the release
Contributor Recognition: Acknowledgement of all team members who contributed to this release
Complete Changelog: A full, detailed changelog showing every change with proper attribution and links

GitHub provides a powerful API that generates release notes automatically based on pull requests, labels, and commit history. This seemed like the perfect solution, but how do we integrate it effectively into our existing automation workflow?

Leveraging the GitHub API for Release Notes Generation

Understanding the GitHub Release Notes API

The GitHub API provides a dedicated endpoint for generating release notes: /repos/{owner}/{repo}/releases/generate-notes. This endpoint is intelligent. It analyses all changes between two tags, extracts contributors, and formats everything into a polished markdown changelog.

Key API Parameters:

tag_name: The tag for which you’re generating release notes (required)
previous_tag_name: The tag to compare against (optional, but essential for meaningful changelogs)
target_commitish: The target branch or commit (defaults to the repository’s default branch)

Integration Strategy

Rather than making shell calls with curl, I discovered that using GitHub’s JavaScript API client within actions/github-script@v7 provided a cleaner, more reliable approach. This eliminated the need for complex JSON manipulation with jq and provided better error handling.

Here’s how the integration works:

Step 1: Fetch Latest Tag

First, we need to identify the latest tag to compare against our new tagged release:

- name: Get latest tag
  id: get_tag
  run: |
    git fetch --tags
    latest_tag=$(git tag --sort=-v:refname | head -n 1)
    echo "latest_tag=$latest_tag" >> $GITHUB_OUTPUT

This step is crucial, it gives the API the context it needs to generate a meaningful changelog comparing the latest tagged version with our new tagged release.

Step 2: Tag our New Release

- name: Bump version and create tag
  id: bump_tag
  run: |
    latest_tag=${{ steps.get_tag.outputs.latest_tag }}
    is_major=${{ steps.major_trigger.outputs.major }}
    if [[ -z "$latest_tag" ]]; then
      new_tag="v1.0.0"
    else
      IFS='.' read -r major minor patch <<< "${latest_tag#v}"
      if [[ "$is_major" == "true" ]]; then
        new_tag="v$((major+1)).0.0"
      else
        new_tag="v$major.$minor.$((patch+1))"
      fi
    fi
    git config user.name "github-actions"
    git config user.email "github-actions@github.com"
    git tag "$new_tag"
    git push origin "$new_tag"
    echo "new_tag=$new_tag" >> $GITHUB_OUTPUT

This step creates the new tag for our release based on whether it’s a major or minor release.

Step 3: Call the GitHub API with JavaScript

- name: Generate release notes
  id: release_notes
  uses: actions/github-script@v7
  with:
    script: |
      const tag = '${{ steps.bump_tag.outputs.new_tag }}';
      const latestTag = '${{ steps.get_tag.outputs.latest_tag }}';

      // Use GitHub's automatic release notes generation API
      const response = await github.rest.repos.generateReleaseNotes({
        owner: context.repo.owner,
        repo: context.repo.repo,
        tag_name: tag,
        previous_tag_name: latestTag || undefined, // Use previous tag if available
        target_commitish: 'main'
      });

      // Determine release type based on version number analysis
      const major = tag.split('.')[0].replace('v', '');
      const minor = tag.split('.')[1];
      const patch = tag.split('.')[2];

      let releaseType;
      if (minor === '0' && patch === '0') {
        releaseType = "🚀 Major Release";
      } else if (patch === '0') {
        releaseType = "✨ Minor Release";
      } else {
        releaseType = "🐛 Patch Release";
      }

      // Combine release type with auto-generated notes
      const releaseNotes = `${releaseType} ${tag}\n\n${response.data.body}`;

      // Write to file for use in release creation
      const fs = require('fs');
      fs.writeFileSync('release-notes.txt', releaseNotes);

      // Also output for debugging
      core.setOutput('release_notes', releaseNotes);
      core.setOutput('release_name', response.data.name);

- name: Create GitHub Release
  if: steps.is_major.outputs.major == 'true'
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: |
    gh release create "${{ steps.bump_tag.outputs.new_tag }}" \
      --title "Release ${{ steps.bump_tag.outputs.new_tag }}" \
      --notes-file release-notes.txt

This step uses the GitHub API to generate the release notes and writes the final notes to a file for the release creation step.

Key Benefits of This Approach:

Automatic Context Awareness: GitHub’s API analyses commit history, PR titles, and labels to categorise changes intelligently
Built-in Contributor Detection: The API automatically identifies and credits all contributors
No Manual Parsing: Unlike shell-based approaches, we don’t need complex regex or JSON parsing

Handling Edge Cases

The implementation accounts for several edge cases:

1. First Release (No Previous Tag)

previous_tag_name: latestTag || undefined;

When latestTag is undefined (first release), the API generates notes for all commits in the repository, which is appropriate for initial releases.

2. No Changes Between Tags The API gracefully handles scenarios where tags are identical or when no PRs exist between versions.

3. Missing PR Metadata If PRs lack proper labels or descriptions, the API uses commit messages and titles as fallbacks.

The Complete Enhanced Workflow

Here’s the complete GitHub Actions workflow that combines automated tagging with intelligent release notes:

name: Enhanced Tag and Release with AI-Powered Notes

on:
  push:
    branches:
      - main

jobs:
  tag-and-release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Get latest PR merged
        id: pr
        uses: actions/github-script@v7
        with:
          script: |
            const prs = await github.rest.pulls.list({
              owner: context.repo.owner,
              repo: context.repo.repo,
              state: 'closed',
              sort: 'updated',
              direction: 'desc',
              per_page: 1
            });
            const pr = prs.data.find(pr => pr.merged_at && pr.merge_commit_sha === context.sha);
            if (!pr) throw new Error('No merged PR found for this commit.');
            core.setOutput('pr_number', pr.number);
            core.setOutput('pr_title', pr.title);
            core.setOutput('pr_body', pr.body);

      - name: Check for major release trigger
        id: major_trigger
        uses: actions/github-script@v7
        with:
          script: |
            const prNumber = Number(process.env.PR_NUMBER || '${{ steps.pr.outputs.pr_number }}');
            let isMajor = false;
            if (prNumber) {
              const pr = await github.rest.pulls.get({
                owner: context.repo.owner,
                repo: context.repo.repo,
                pull_number: prNumber
              });
              const labels = pr.data.labels.map(l => l.name.toLowerCase());
              if (labels.includes('major-release')) isMajor = true;
              if (pr.data.title.includes('[major]') || (pr.data.body && pr.data.body.includes('[major]'))) isMajor = true;
            } else {
              // Fallback: check commit message
              const commit = await github.rest.repos.getCommit({
                owner: context.repo.owner,
                repo: context.repo.repo,
                ref: context.sha
              });
              if (commit.data.commit.message.includes('[major]')) isMajor = true;
            }
            core.setOutput('major', isMajor ? 'true' : 'false');

      - name: Get latest tag
        id: get_tag
        run: |
          git fetch --tags
          latest_tag=$(git tag --sort=-v:refname | head -n 1)
          echo "latest_tag=$latest_tag" >> $GITHUB_OUTPUT

      - name: Bump version and create tag
        id: bump_tag
        run: |
          latest_tag=${{ steps.get_tag.outputs.latest_tag }}
          is_major=${{ steps.major_trigger.outputs.major }}
          if [[ -z "$latest_tag" ]]; then
            new_tag="v1.0.0"
          else
            IFS='.' read -r major minor patch <<< "${latest_tag#v}"
            if [[ "$is_major" == "true" ]]; then
              new_tag="v$((major+1)).0.0"
            else
              new_tag="v$major.$minor.$((patch+1))"
            fi
          fi
          git config user.name "github-actions"
          git config user.email "github-actions@github.com"
          git tag "$new_tag"
          git push origin "$new_tag"
          echo "new_tag=$new_tag" >> $GITHUB_OUTPUT

      - name: Check if major version
        id: is_major
        run: |
          tag=${{ steps.bump_tag.outputs.new_tag }}
          major=$(echo $tag | cut -d'.' -f1 | tr -d 'v')
          minor=$(echo $tag | cut -d'.' -f2)
          patch=$(echo $tag | cut -d'.' -f3)
          if [[ "$minor" == "0" && "$patch" == "0" ]]; then
            echo "major=true" >> $GITHUB_OUTPUT
          else
            echo "major=false" >> $GITHUB_OUTPUT
          fi

      - name: Generate release notes
        id: release_notes
        uses: actions/github-script@v7
        with:
          script: |
            const tag = '${{ steps.bump_tag.outputs.new_tag }}';
            const latestTag = '${{ steps.get_tag.outputs.latest_tag }}';

            // Use GitHub's automatic release notes generation API
            const response = await github.rest.repos.generateReleaseNotes({
              owner: context.repo.owner,
              repo: context.repo.repo,
              tag_name: tag,
              previous_tag_name: latestTag || undefined, // Use previous tag if available
              target_commitish: 'main'
            });

            // Determine release type based on version number analysis
            const major = tag.split('.')[0].replace('v', '');
            const minor = tag.split('.')[1];
            const patch = tag.split('.')[2];

            let releaseType;
            if (minor === '0' && patch === '0') {
              releaseType = "🚀 Major Release";
            } else if (patch === '0') {
              releaseType = "✨ Minor Release";
            } else {
              releaseType = "🐛 Patch Release";
            }

            // Combine release type with auto-generated notes
            const releaseNotes = `${releaseType} ${tag}\n\n${response.data.body}`;

            // Write to file for use in release creation
            const fs = require('fs');
            fs.writeFileSync('release-notes.txt', releaseNotes);

            // Also output for debugging
            core.setOutput('release_notes', releaseNotes);
            core.setOutput('release_name', response.data.name);

      - name: Create GitHub Release
        if: steps.is_major.outputs.major == 'true'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh release create "${{ steps.bump_tag.outputs.new_tag }}" \
            --title "Release ${{ steps.bump_tag.outputs.new_tag }}" \
            --notes-file release-notes.txt

Key Improvements Over the Original Workflow

1. Intelligent Release Notes

The GitHub API automatically:

Summarise changes since last release
Lists all contributors
Groups changes logically
Filters out noise (like dependency updates)

2. Better Historical Context

By comparing against the previous tag, the release notes include:

All changes since the last release
Complete PR history with links
Proper attribution for each contribution

3. Enhanced Major Releases

Major version releases get special treatment:

Prominent release highlights section
Assists with highlighting warnings about breaking changes
Enhanced formatting for visibility

4. Robust Error Handling

The workflow handles edge cases:

First release (no previous tag)
Missing PR metadata

Conclusion

By combining GitHub’s automatic release notes API with our existing automated tagging workflow, we’ve created a powerful, hands-off release management system.

The result is a system that:

Runs completely automatically
Generates comprehensive, well-formatted release notes
Recognises all contributors
Scales effortlessly as the team grows
Requires zero manual intervention

Click here to view a working example of the complete workflow on GitHub.

If you’re still manually creating release notes, I highly recommend implementing this approach.

Have you implemented automated release notes in your projects? What challenges did you face? Share your experiences in the comments below!

Building a Star Wars E-Commerce Empire with GitHub Spark: A Weekend DevOps Story

Mon, 13 Oct 2025 19:00:00 +0000

As a DevOps professional whose primary expertise lies in infrastructure, automation, and operational excellence rather than frontend development, I’ve always faced a persistent challenge: creating functional, presentable web applications for demos and presentations. This gap became particularly evident when conducting demonstrations and end-to-end workflows at community meetups and in my day-to-day job, where I needed to showcase the complete picture, not just the infrastructure layer.

Enter GitHub Spark, a tool that promises to transform ideas into full-stack intelligent applications through natural language. This is the story of how I built a fully functional Star Wars-themed e-commerce platform in a single weekend, juggling personal commitments while giving it only 50% of my attention, and the valuable lessons I learned about AI-powered development along the way.

The Challenge: Frontend Development for DevOps Professionals

My professional world revolves around CI/CD pipelines, infrastructure as code, container orchestration, and automated deployments. I excel at building the engines that power software delivery, but creating the user-facing interfaces that demonstrate these capabilities? That’s historically been my Achilles’ heel.

This skill gap created several challenges:

Demo Limitations: Showcasing infrastructure concepts without compelling frontends meant relying on PowerPoint slides and command-line demonstrations
Presentation Impact: Audience connecting more readily with visual, interactive demonstrations rather than terminal outputs
Time Investment: The learning curve for modern frontend frameworks (React, Vue, Angular) requiring significant time investment
Rapid Prototyping: Needing to quickly spin up functional demos for presentations and workshops

I needed a solution that would allow me to create production quality frontends without becoming a full-time frontend developer. GitHub Spark seemed to offer exactly that promise.

The Experiment: Building for the Galactic Empire

Why Star Wars E-Commerce?

I needed to build a fully functional e-commerce application for an upcoming demo. Being a lifelong Star Wars fan, there was never any question about the theme, of course it had to be Star Wars themed. Why build a generic shopping cart when you could be procuring Imperial starships for the Empire?

So I set out to create a Star Wars themed e-commerce platform where I could purchase Imperial starships on behalf of the Empire. The application needed to be more than just a pretty mock up with a Star Wars skin, it required genuine functionality:

Product Catalogue: Display various Imperial starships with descriptions and specifications
Shopping Cart: Add and remove items with persistent state
Credit System: Track available Imperial credits and deduct them after purchases
Transaction Management: Handle the complete purchase flow from selection to confirmation
Responsive Design: Work seamlessly across different devices

This project would serve multiple purposes:

Test GitHub Spark’s capabilities with a real-world application
Create a reusable demo platform for presentations
Explore the boundaries of AI-powered development
Fill the gap in my skillset without weeks or months of learning

The Weekend Build: From Concept to Functional Application

What impressed me most wasn’t just that GitHub Spark could build the application, it was the speed and quality of what it produced while I was multitasking with personal commitments throughout the weekend.

graph TD
    A[Saturday Morning: Initial Concept] --> B[Spark Session 1: Basic Structure]
    B --> C[Live Preview: Product Display]
    C --> D[Saturday Afternoon: Shopping Features]
    D --> E[Spark Session 2: Cart Functionality]
    E --> F[Live Preview: Working Cart]
    F --> G[Sunday Morning: Credit System]
    G --> H[Spark Session 3: Transaction Logic]
    H --> I[Live Preview: Complete Purchase Flow]
    I --> J[Sunday Afternoon: Polish & Testing]
    J --> K[Functional E-Commerce Platform]

    style A fill:#2188ff,stroke:#1b6cc7,stroke-width:3px,color:#ffffff
    style K fill:#28a745,stroke:#1e7e34,stroke-width:3px,color:#ffffff
    style C fill:#f9c513,stroke:#d4a00a,stroke-width:2px,color:#000000
    style F fill:#f9c513,stroke:#d4a00a,stroke-width:2px,color:#000000
    style I fill:#f9c513,stroke:#d4a00a,stroke-width:2px,color:#000000

What GitHub Spark Delivered

The platform Spark created included:

Core E-Commerce Functionality:

Product listing with detailed starship specifications
Functional shopping cart with add/remove capabilities
Imperial credit tracking system
Complete checkout and purchase flow
Order confirmation

Visual Design:

Star Wars themed interface with appropriate styling
Responsive layout that worked across devices
AI generated imagery fitting the Imperial aesthetic
Consistent design language throughout

Technical Implementation:

React-based frontend with proper component structure
State management for cart and user data
Local storage persistence
Clean, maintainable code structure

The most remarkable aspect? I achieved all this while simultaneously handling weekend family commitments, checking in periodically to review progress and provide the next set of instructions.

The Power of Natural Language Development

How GitHub Spark Actually Works

GitHub Spark operates on a fundamentally different paradigm from traditional development:

Traditional Development:

// You write: Component structure, state management, event handlers
import React, { useState } from "react";

function ShoppingCart() {
  const [items, setItems] = useState([]);
  const [credits, setCredits] = useState(10000);

  const addItem = (item) => {
    setItems([...items, item]);
  };

  // ... 50+ lines of implementation logic
}

GitHub Spark Development:

You write: "Add a shopping cart that tracks Imperial starships.
Users should be able to add ships, see the total cost, and have
their available credits updated after purchase."

Spark delivers: Fully functional component with all the logic implemented

This shift from implementation to specification represents a fundamental change in how we approach application development.

The Iteration Loop

What makes Spark particularly powerful is the rapid iteration cycle:

Describe: Use natural language to explain what you want
Preview: Instantly see the live implementation
Refine: Provide feedback and adjustments
Repeat: Continue until the feature matches your vision

sequenceDiagram
    participant You
    participant Spark
    participant Preview

    You->>Spark: "Add filter for starship class"
    Spark->>Preview: Generates filter component
    Preview->>You: Live visual feedback
    You->>Spark: "Make the filters more prominent"
    Spark->>Preview: Updates styling and layout
    Preview->>You: Refined implementation
    You->>Spark: "Perfect! Now add sorting options"
    Spark->>Preview: Adds sorting functionality

The preview updates in real-time, allowing you to see your ideas take shape immediately. This instant feedback loop accelerates development exponentially compared to traditional code-test-debug cycles.

Lessons Learned: The Hard-Earned Wisdom

Lesson 1: Prompt Engineering is Critical (Just Like Any AI Tool)

My biggest mistake early on was using basic, vague prompts:

Bad Prompt:

"Add credits"
"Make it work"
"Try again"

These generic instructions led to:

Spark making assumptions that didn’t align with my vision
Implementing features that conflicted with existing functionality
Getting stuck in loops trying to fix issues it created

Good Prompt:

"Implement an Imperial credit system with the following specifications:
- Starting balance: 10,000 credits
- Display current balance prominently in the header
- Deduct the exact cart total when purchase is confirmed
- Show transaction confirmation with remaining balance
- Persist balance in local storage
- Prevent purchases if insufficient credits"

The comprehensive prompt provided:

Clear Requirements: Specific functionality expected
Implementation Details: How the feature should behave
Edge Cases: What should happen when credits are insufficient
Persistence: How data should be stored

Key Insight: Treat GitHub Spark prompts with the same care and detail you would bring to writing technical specifications. The quality of your output directly correlates to the quality of your input.

Lesson 2: The Loop Trap is Real (And Expensive)

I hit my free plan limits alarmingly quickly when I got stuck in what I call the “Try Harder Loop”:

The Destructive Pattern:

Issue occurs → "Try again"
Still broken → "Try harder"
Different error → "Fix this"
New problem → "Still have the same issue"
Plan limits exhausted → Frustration

This happened specifically with the credit system. Spark would add the total credits, but the deduction logic wouldn’t work correctly. I kept asking it to “try again” or “fix the credit deduction,” which led to:

Multiple failed attempts consuming premium requests
Spark making random changes hoping something would stick
Spark looping through the same flawed logic
The problem getting worse, not better

The Solution That Worked:

I completely removed the credit system:

"Remove the entire credit tracking system."

Then rebuilt with a detailed specification:

"Add a credit system with these exact requirements:
1. Initialise each user with Imperial credits aligned to ship costs
2. Store in React state
3. Display current balance in header component
4. On purchase confirmation:
   - Calculate total from cart items
   - Deduct total from balance and clear cart
   - If insufficient credits: show relevant error message
5. Update balance in local storage after each transaction"
6. Add a reset button to restore initial credits only visible for specific users

Key Insight: When stuck in a loop, reset and approach with better specifications rather than repeatedly asking the AI to “try harder.” Each iteration in a loop consumes your request quota without making meaningful progress.

Lesson 3: Plan Limits are Generous But Not Infinite

GitHub Spark operates on a premium request model:

Free Plan Reality:

50 premium requests per month
Each Spark message uses 4 premium requests
Getting stuck in loops exhausts quota rapidly
No ability to purchase additional requests

Copilot Pro+ Plan:

375 Spark messages included per month (1,500 premium requests)
Option to purchase additional messages
10 active app building sessions simultaneously
Unlimited app building overall

My recommendation? If you’re serious about using Spark for multiple projects or complex applications, review Copilot plans carefully from the start. The free tier is excellent for experimentation and small projects, but any substantial development work will quickly hit the limits, especially while you’re learning optimal prompting techniques.

Lesson 4: Let Spark Handle the Visuals (If You Want)

I intentionally chose not to provide custom images or assets for my Star Wars theme. I wanted to test whether Spark could handle the complete visual design independently.

The Result: Spark generated appropriate imagery, maintained consistent styling, and created a cohesive visual experience that genuinely felt like an Imperial procurement system.

When This Approach Works:

Prototyping and proof-of-concept development
Internal tools and demos
Quick mock ups for stakeholder feedback
Testing functionality before investing in design assets

When to Provide Your Own Assets:

Production applications requiring brand consistency
Client work with specific design requirements
Applications where visual design is a differentiator
When you have professional assets readily available

Key Insight: Spark’s AI generated visuals are remarkably good for functional applications and demos, but don’t expect them to replace professional design work for customer facing products.

Lesson 5: Incremental Development Still Wins

Even with AI powered development, building incrementally remains the most effective approach:

My Successful Pattern:

Core Framework First: Basic app structure and routing
Single Feature: Product display working perfectly
Next Feature: Shopping cart functionality
Integration: Cart and products working together
Transaction Logic: Purchase and credit system
Polish: Refinements and edge cases

Failed Approach:

"Build a complete e-commerce platform with products, cart,
checkout, user accounts, order history, and admin panel."

This “kitchen sink” approach led to:

Overwhelming Spark with too many simultaneous requirements
Features implemented half-way
Conflicting functionality between different components
Difficult to identify where things went wrong

Key Insight: Even with AI assistance, incremental development with clear milestones produces better results than trying to build everything at once.

The Practical Impact: Filling the Gap

This weekend experiment with GitHub Spark fundamentally changed my approach to demos and presentations. I now have:

A Reusable Demo Platform:

Functional transaction flows demonstrating end-to-end processes
Visual interface that resonates with technical and non-technical audiences
Platform I can adapt for various presentation needs

A New Development Capability:

Ability to prototype frontend ideas rapidly
Tool for creating functional mock ups without deep frontend expertise
Platform for testing UX concepts before formal development
Bridge between infrastructure expertise and user-facing applications

Confidence in AI Assisted Development:

Understanding of how to effectively collaborate with AI tools
Experience with prompt engineering for development tasks
Knowledge of when AI assistance is most valuable
Realistic expectations for AI powered development

The Bigger Picture: AI as a Force Multiplier

My weekend with GitHub Spark reinforced a fundamental truth about AI in development: it’s not about replacement, but amplification.

What AI Didn’t Replace:

My understanding of application architecture
My ability to break down complex requirements
My judgment about user experience and functionality
My testing and validation expertise
My domain knowledge

What AI Amplified:

My ability to implement ideas quickly
My capacity to create functional prototypes
My power to bridge skill gaps in frontend development
My efficiency in iterating on designs
My capability to deliver professional demos

This represents a shift from being limited by implementation skills to being limited only by ideas and specifications. As a DevOps professional, I’m no longer constrained by my frontend expertise when I need to create compelling demonstrations.

Conclusion: The Future of Specialised Development

GitHub Spark demonstrates that we’re entering an era where deep technical specialists can operate effectively across broader domains without sacrificing their core expertise. I didn’t become a frontend developer over a weekend, I became a DevOps professional who can effectively leverage AI to create functional frontends when needed.

Key Takeaways:

Prompt Quality Matters: Invest time in comprehensive, specific prompts
Avoid the Loop Trap: Reset and respecify rather than repeatedly asking AI to “try harder”
Understand Plan Limits: Choose the right tier for your usage pattern
Incremental Wins: Build features progressively, validating each step
AI Generated Visuals: Surprisingly effective for demos and prototypes
Specialisation + AI: Powerful combination that expands capabilities without diluting expertise

For fellow DevOps professionals, infrastructure engineers, and backend specialists who need to create compelling frontends for demos, presentations, or internal tools, GitHub Spark offers a genuine solution. It won’t replace dedicated frontend developers for production applications, but it absolutely fills the gap for creating functional, presentable interfaces without months of learning modern frontend frameworks.

The Empire’s procurement system is now operational, and I built it in a weekend while barely paying full attention. That’s the power of AI assisted development when approached with the right strategies and realistic expectations.

Here is a few screenshots of the final application in action:

Have you experimented with GitHub Spark or similar AI-powered development tools? What challenges or successes have you experienced? Share your experiences in the comments below

DevOps and Azure Policy Series: Remediation Tasks

Tue, 23 Sep 2025 19:00:00 +0000

Welcome to the fourth instalment of our DevOps and Azure Policy series! In our previous post, we explored how to manage policy exemptions using Infrastructure as Code (IaC) and CI/CD pipelines. Today, we’re diving into another critical aspect of Azure Policy governance: policy remediation tasks.

While exemptions help us handle exceptions to policies, remediation tasks take the opposite approach they actively fix non-compliant resources to bring them into alignment with our organisational standards. We’ll explore what remediation tasks are, when to use them, and how to implement them through automated PowerShell scripts and CI/CD pipelines.

Understanding Azure Policy Remediation

Policy remediation is the process of automatically correcting non-compliant resources to ensure they adhere to our defined policies. Think of it as the “auto-fix” capability for our governance rules. When Azure Policy identifies resources that don’t meet our standards, remediation tasks can automatically apply the necessary changes to bring them into compliance.

How Policy Remediation Works

The remediation process follows this workflow:

Policy Evaluation: Azure Policy continuously evaluates resources against assigned policies
Compliance Assessment: Resources are marked as compliant or non-compliant
Remediation Task Creation: You create a remediation task for a specific policy assignment
Resource Discovery: Azure identifies all non-compliant resources within the scope
Automatic Correction: The remediation task applies the necessary changes to fix non-compliant resources

Types of Remediation

Azure Policy supports two main types of remediation:

Remediation Type	Description	Use Case
Manual Remediation	Administrators manually review and fix non-compliant resources	Complex changes requiring human judgment
Automatic Remediation	Azure Policy automatically applies predefined configurations or deploy a specific resource	Standard compliance fixes that can be safely automated

When to Use Remediation Tasks

Remediation tasks are particularly valuable in these scenarios:

Tag Governance: Automatically applying missing mandatory tags to resources
Security Baseline: Enabling required security features like encryption or monitoring
Cost Optimisation: Implementing cost-saving configurations across resources
Compliance Enforcement: Ensuring resources meet regulatory requirements
Operational Standards: Applying consistent operational configurations

Limitations and Considerations

Before implementing remediation tasks, it’s important to understand their current limitations:

Bicep Support Limitation

At the time of writing, policy remediation tasks are not currently supported for deployment via Azure Bicep. This means that while you can define and assign policies using Bicep, the remediation tasks themselves must be managed through other means such as:

Azure Portal
Azure CLI
Azure PowerShell
REST API

Due to this limitation, we’ll focus on a PowerShell-based approach.

Remediation Scope

Remediation tasks can be created at different scopes:

Management Group Level: Remediate across multiple subscriptions
Subscription Level: Remediate within a specific subscription
Resource Group Level: Remediate within a specific resource group

Resource Discovery Modes

Azure Policy offers two resource discovery modes for remediation:

ExistingNonCompliant: Only remediate resources that are currently non-compliant
ReEvaluateCompliance: Re-evaluate all resources and remediate any that become non-compliant

Implementing Remediation with PowerShell

Let’s examine a PowerShell script that automates the creation and execution of policy remediation tasks. This script provides a standardised approach to managing remediation across your Azure environment.

The Core Remediation Script

[CmdletBinding()]
param (
  [Parameter(Mandatory)]
  [string] $remediationFile
)

begin {
  # Import policies to remediate from JSON file
  $remediations = Get-Content -Path $remediationFile | ConvertFrom-Json
}

process {
  # Policy Remediation
  foreach ($remediation in $remediations) {
    Write-Host "------------------------------------------"
    # Create arguments for Start-AzPolicyRemediation
    $arguments = @{
      Name                  = ($remediation.name + " - " + (Get-Date -Format "yyyyMMddHHmmss"))
      PolicyAssignment      = $remediation.policyAssignmentId
      ResourceDiscoveryMode = "ReEvaluateCompliance"
    }

    if ($remediation.managementGroup) {
      $arguments.managementGroup = $remediation.managementGroup
      $arguments.ResourceDiscoveryMode = "ExistingNonCompliant"
    }
    if ($remediation.subscriptionId) {
      Set-AzContext -Subscription $remediation.subscriptionId | Out-Null
    }
    if ($remediation.resourceGroup) {
      $arguments.ResourceGroupName = $remediation.resourceGroup
    }
    if ($remediation.policyDefinitionReferenceId) {
      $arguments.PolicyDefinitionReferenceId = $remediation.policyDefinitionReferenceId
    }

    # Start remediation task
    try {
      $pa = Get-AzPolicyAssignment -Id $arguments.PolicyAssignment -ErrorAction Stop
      if ($pa) {
        Write-Host "Starting remediation task for: $($arguments.Name)"
        Start-AzPolicyRemediation @arguments
      }
    }
    catch {
      Write-Host "Failed to create policy remediation task $($arguments.Name)"
      Write-Error $error[0].Exception.Message
    }
  }
  Write-Host "------------------------------------------"
}

Key Script Features

Dynamic Naming: Each remediation task gets a unique name with a timestamp to avoid conflicts:

Name = ($remediation.name + " - " + (Get-Date -Format "yyyyMMddHHmmss"))

Scope Flexibility: The script handles different remediation scopes:

Error Handling: Comprehensive error handling ensures failed remediation tasks don’t break the entire process.

Configuration Management

The script uses a JSON configuration file to define which policies to remediate. This approach provides several benefits:

Configuration Structure

[
  {
    "name": "Application Name Tag Remediation",
    "managementGroup": "production-mg",
    "policyAssignmentId": "/providers/microsoft.management/managementgroups/production-mg/providers/microsoft.authorization/policyassignments/tag-governance",
    "policyDefinitionReferenceId": "require-application-name-tag"
  },
  {
    "name": "Storage Encryption Remediation",
    "subscriptionId": "12345678-1234-1234-1234-123456789012",
    "policyAssignmentId": "/subscriptions/12345678-1234-1234-1234-123456789012/providers/microsoft.authorization/policyassignments/security-baseline",
    "policyDefinitionReferenceId": "storage-encryption-required"
  },
  {
    "name": "Resource Group Tag Remediation",
    "subscriptionId": "12345678-1234-1234-1234-123456789012",
    "resourceGroup": "production-rg",
    "policyAssignmentId": "/subscriptions/12345678-1234-1234-1234-123456789012/providers/microsoft.authorization/policyassignments/tag-governance",
    "policyDefinitionReferenceId": "require-environment-tag"
  }
]

Configuration Parameters

Parameter	Required	Description
`name`	Yes	Descriptive name for the remediation task
`managementGroup`	Optional	Management group ID (for MG-level remediation)
`subscriptionId`	Optional	Subscription ID (for subscription/RG-level remediation)
`resourceGroup`	Optional	Resource group name (for RG-level remediation)
`policyAssignmentId`	Yes	Full resource ID of the policy assignment
`policyDefinitionReferenceId`	Yes	Reference ID of the specific policy within an initiative

Finding Required IDs

Policy Assignment ID:

Navigate to the Azure Portal → Policy → Assignments
Select the policy assignment
Copy the Assignment ID from the overview blade

Policy Definition Reference ID:

Open the policy assignment in the Azure Portal
Click “View Definition”
Locate the Policy Definition Reference IDs (usually match the display names)

DevOps Integration and Best Practices

CI/CD Pipeline Integration

While we can’t use Bicep for remediation tasks, we can still integrate them into our DevOps workflows using PowerShell and CI/CD pipelines.

# Example GitHub Actions workflow for policy remediation
name: Policy Remediation

on:
  workflow_dispatch:
    inputs:
      remediation_scope:
        description: "Remediation scope (management-group, subscription, resource-group)"
        required: true
        default: "subscription"
        type: choice
        options:
          - management-group
          - subscription
          - resource-group

jobs:
  remediate_policies:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Azure Login
        uses: azure/login@v1
        with:
          client-id: $
          tenant-id: $
          subscription-id: $

      - name: Run Policy Remediation
        shell: pwsh
        run: |
          ./policy-remediation/policy-remediations.ps1 -remediationFile ./policy-remediation/policy-remediations.json

Best Practices for Remediation

1. Test Before Production

Always test remediation tasks in non-production environments first
Use resource group level testing to validate behaviour
Monitor remediation results closely during initial deployments

2. Scope Appropriately

Start with narrow scopes (resource groups) before expanding to subscriptions or management groups
Use management group level remediation only for well-tested, low-risk policies

3. Configuration Management

Keep remediation configurations in source control
Use descriptive names that clearly indicate the purpose
Document the business justification for each remediation task

4. Timing Considerations

Run remediation tasks during maintenance windows when possible
Consider the impact on running workloads
Stagger large-scale remediation across multiple time periods

Governance Workflow for Remediation

Implementing a structured workflow ensures remediation tasks are executed safely and effectively:

graph TD
    A[Policy Non-Compliance Detected] --> B{Risk Assessment}
    B -->|Low Risk| C[Automated Remediation]
    B -->|Medium Risk| D[Staged Remediation]
    B -->|High Risk| E[Manual Review Required]

    C --> F[Execute Remediation Task]
    D --> G[Test in Non-Production]
    E --> H[Platform Team Review]

    G --> I{Test Results OK?}
    H --> J{Approved for Remediation?}

    I -->|Yes| F
    I -->|No| K[Investigate Issues]
    J -->|Yes| D
    J -->|No| L[Alternative Solution Required]

    F --> M[Monitor Results]
    M --> N[Document Outcomes]

Workflow Stages

1. Risk Assessment

Evaluate the potential impact of automated remediation
Consider the criticality of affected resources
Assess the complexity of the required changes

2. Approval Process

Low-risk changes: Automated approval
Medium-risk changes: Platform team review
High-risk changes: Security and business stakeholder approval

3. Execution Strategy

Phased rollout for large-scale remediation
Monitoring and rollback capabilities
Communication to affected teams

4. Post-Execution Review

Verify compliance improvement
Document any issues encountered
Update procedures based on lessons learned

Complete Example

The PowerShell script, JSON configuration, and CI/CD pipeline integration we’ve explored provide a comprehensive solution for automated policy remediation. To help you implement this approach in your own environment, I’ve created a complete working example:

Click here to view the policy remediation example

Conclusion

Policy remediation tasks provide automated compliance enforcement for Azure environments, ensuring non-compliant resources are automatically corrected rather than simply identified. While Bicep support isn’t available yet, PowerShell-based remediation workflows integrated with CI/CD pipelines offer a robust governance solution.

This approach offers several advantages:

Automated Compliance: Non-compliant resources are fixed automatically without manual intervention
Scalable Governance: Apply consistent standards across large Azure environments through configuration-driven remediation
Risk Management: Structured workflows ensure appropriate oversight while enabling automation for low-risk changes
DevOps Integration: JSON configuration and PowerShell scripts integrate seamlessly with modern CI/CD practices

The combination of automated remediation with policy exemptions creates a comprehensive governance framework that balances compliance requirements with operational flexibility.

In our next article, we’ll continue exploring advanced Azure Policy scenarios. Stay tuned!

Delivering Major Enhancements Without Writing Code: My Agentic DevOps Journey

Tue, 16 Sep 2025 19:00:00 +0000

As a busy professional, I found myself in a familiar situation, needing to deliver a major enhancement to an internal solution while managing my regular day-to-day responsibilities. The challenge wasn’t a lack of capability or resources, but rather finding the sustained focus time that complex development work typically demands.

This is the story of how I successfully delivered that enhancement without writing a single line of code myself, using agentic DevOps principles and GitHub Copilot’s coding agent capabilities to transform my development approach.

The Challenge: Maximising Development Impact Alongside Daily Operations

The enhancement I needed to deliver was substantial, the kind that typically requires sustained focus and deep technical thinking. However, my reality involved managing a full schedule of meetings, stakeholder communications, and immediate delivery needs. My challenge wasn’t just finding time to work on the enhancement, but optimising how I could make meaningful progress within the time constraints I had.

Every traditional development session resulted in:

Context rebuilding: Spending significant time re-establishing where I left off
Fragmented thinking: Difficulty maintaining the full architectural vision across interrupted sessions
Inefficient progress: Short development windows that weren’t sufficient for complex problem-solving
Cognitive overhead: Mental energy divided between the enhancement and immediate responsibilities

I needed a development approach that could work with my schedule, not against it, one that would allow me to make consistent progress while fulfilling my daily operational responsibilities.

The Solution: Agentic DevOps as a Personal Force Multiplier

This is where I utilised agentic DevOps, a methodology where AI agents become integral partners in your development workflow. Rather than replacing my technical expertise, these agents would amplify it, handling the implementation heavy lifting while I focused on strategic decisions and quality oversight.

My key realisation? Success with agentic DevOps isn’t about having AI write perfect code immediately. It’s about creating the right structures, processes, and feedback loops that enable AI agents to deliver value consistently while working around my existing responsibilities.

graph TD
    A[Problem: Limited Development Time] --> B[Agentic DevOps Approach]
    B --> C[Strategic Planning]
    B --> D[Structured Backlog Creation]
    B --> E[AI-Powered Development]
    B --> F[Human-Led Validation]

    C --> G[GitHub Copilot Prompts & Chat Modes]
    D --> H[Automated Issue Generation]
    E --> I[Coding Agent Implementation]
    F --> J[Quality Assurance & Testing]

    G --> K[Comprehensive Implementation Plan]
    H --> L[Manageable Work Items]
    I --> M[Production-Ready Code]
    J --> N[Delivered Enhancement]

The Foundation: Strategic Planning with AI

How I Leveraged GitHub’s Awesome Copilot Resources

My first step was pretty straightforward but made all the difference: I needed a solid plan that would set up the coding agent for success. Without getting this foundation right first, even the smartest AI would have a tough time delivering the complex enhancement I was after.

This is where I accessed the wealth of proven prompts and methodologies from GitHub’s Awesome Copilot repository (There is also a MCP server that can be used to interact with GitHub’s Awesome Copilot repository to integrate prompts, instructions and chat modes into your workflow). Among the many resources available, two stood out as particularly relevant to my needs.

I specifically chose to use:

Create Implementation Plan prompt: A well-structured prompt to generate a comprehensive technical plan for the enhancement
Implementation Plan chat mode: A persona designed to iteratively refine and expand on the initial plan, ensuring it was detailed and actionable

How I Created a Meaningful Plan

I learned that the key to success with coding agents is providing them with rich, contextual information. I used GitHub Copilot’s prompts and chat modes to develop a plan that included:

Functional Requirements: Detailed feature list and user stories
Dependencies: External services and internal components affected
Testing & Validation Criteria: Clear, measurable outcomes for validation
Risks & Assumptions: Identification of potential challenges and underlying assumptions

<!-- Example implementation plan (shortened for brevity) -->

# Create Enhancement Implementation Plan

## Introduction

This implementation plan outlines the creation of a enhancement that follows the same structure and conventions as the existing example pattern. The new pattern will provide X enhancement to the solution, while maintaining consistency with the established pattern architecture.

## 1. Requirements & Constraints

### Functional Requirements

- **REQ-001**: Create enhancement X that mirrors the structure of the existing example pattern
- **REQ-002**: Support the same subscription model
- **REQ-003**: Include all the same core components as example pattern but adapted for X enhancement architecture
  ... (Additional functional requirements as needed)

### Security Requirements

- **SEC-001**: Implement secure connectivity patterns following Azure Well-Architected Framework
- **SEC-002**: Support for network security and traffic inspection
- **SEC-003**: Ensure proper network segmentation and traffic flow control
  ... (Additional security requirements as needed)

### Technical Constraints

- **CON-001**: Must use the same folder structure as example pattern
- **CON-002**: Must integrate with existing Bicep module registry
- **CON-003**: Must support the same diagnostic and monitoring capabilities
  ... (Additional constraints as needed)

### Guidelines

- **GUD-001**: Follow established naming conventions for resources and parameters
- **GUD-002**: Maintain consistency with existing pattern documentation structure
- **GUD-003**: Use modular approach for different components
  ... (Additional guidelines as needed)

### Patterns to Follow

- **PAT-001**: Mirror the folder structure of example pattern
- **PAT-002**: Use the same subscription-scoped deployment approach
- **PAT-003**: Implement similar parameter validation and metadata
  ... (Additional patterns as needed)

## 2. Implementation Steps

### Implementation Phase 1: Core Structure Setup

- GOAL-001: Establish the foundational structure and main pattern files

| Task     | Description                                                                          | Completed | Date |
| -------- | ------------------------------------------------------------------------------------ | --------- | ---- |
| TASK-001 | Create new folder structure at `bicep/patterns/<enhancement>/`                       |           |      |
| TASK-002 | Copy and adapt the main.bicep from example pattern as the orchestrator               |           |      |
| TASK-003 | Create `<enhancement>.bicepparam` template file for parameter configuration          |           |      |
| TASK-004 | Create comprehensive README.md for the pattern with architecture overview            |           |      |
| TASK-005 | Set up examples folder with three example configurations (basic, standard, advanced) |           |      |

### Implementation Phase 2: Enhancement Component

- GOAL-002: Implement the enhancement component identical to example pattern

| Task     | Description                                                         | Completed | Date |
| -------- | ------------------------------------------------------------------- | --------- | ---- |
| TASK-006 | Copy management module from example pattern (example/example.bicep) |           |      |
| TASK-007 | Verify module compatibility with architecture                       |           |      |
| TASK-008 | Update any specific documentation and README                        |           |      |
| TASK-009 | Test module deployment independently                                |           |      |

... (Additional phases would follow similarly)

## 3. Alternatives

- **ALT-001**: Modify existing example pattern to support both topologies - Rejected due to complexity and potential breaking changes
- **ALT-002**: Create a unified pattern with topology selection parameter - Rejected due to maintenance complexity and different architectural requirements
- **ALT-003**: Use existing archived example pattern as-is - Rejected due to structural inconsistencies with current standards
  ... (Additional alternatives as needed)

## 4. Dependencies

- **DEP-001**: Access to Bicep registry for network modules
- **DEP-002**: Existing shared-modules for common functionality
- **DEP-003**: Access to test Azure subscriptions for validation
  ... (Additional dependencies as needed)

## 5. Files

### New Files to Create

- **FILE-001**: `bicep/patterns/enhancement/main.bicep` - Main orchestrator template
- **FILE-002**: `bicep/patterns/enhancement/enhancement.bicepparam` - Parameter template
- **FILE-003**: `bicep/patterns/enhancement/README.md` - Pattern documentation
  ... (Additional files as needed)

### Files to Reference/Adapt

- **FILE-013**: Source example pattern files for structure and parameter reference
- **FILE-014**: Archived example pattern files for specific configuration
- **FILE-015**: Existing shared modules for common functionality

## 6. Testing

- **TEST-001**: Bicep template compilation and linting validation
- **TEST-002**: Parameter validation and type checking
- **TEST-003**: Deployment testing in development environment with basic example
  ... (Additional tests for standard and advanced examples, component-specific tests)

## 7. Risks & Assumptions

### Risks

- **RISK-001**: pricing model may be significantly different from example solution, affecting cost comparisons
- **RISK-002**: Some features available in example solution may not have direct enhancement equivalents
- **RISK-003**: enhancement may require different configuration approaches than traditional example solution
  ... (Additional risks as needed)

### Assumptions

- **ASSUMPTION-001**: The same subscription model applies to enhancement pattern
- **ASSUMPTION-002**: Enhancement service is available in target regions
- **ASSUMPTION-003**: Current Bicep registry contains necessary modules
  ... (Additional assumptions as needed)

## 8. Related Specifications / Further Reading

- Links to Microsoft articles relating enhancement

How I Transformed My Plan into Action: Creating an Actionable Backlog

With my solid implementation plan in hand, I faced the next challenge of breaking it down into manageable work items that I could effectively delegate to the coding agent. Here’s where the create-github-issues-feature-from-implementation-plan prompt became invaluable to my workflow.

How I Generated My Automated Backlog

This prompt transformed my comprehensive plan into exactly what I needed:

Discrete GitHub issues: Each representing a focused development task that could be completed independently

Each issue included:
- Description: A detailed overview of the task
- Tasks to complete: Specific steps required to complete the issue
- Requirements: Any specific conditions or prerequisites for the issue
- Definition of Done: Clear criteria for when the issue can be considered complete
- Dependencies: Any related issues or tasks that must be completed first
- Related Files: Links to any relevant documentation or code
- Implementation Plan Reference: Links back to the original implementation plan for context
- Next Phase: Reference to the subsequent phase in the implementation plan

The result? I had a backlog of 10 well-defined issues, each scoped perfectly for completion within a focused development session, exactly what I needed for my agentic DevOps approach.

The Game Changer: The Coding Agent as My Development Partner

Here’s where this approach truly transformed my productivity. Instead of trying to carve out large blocks of focused development time from my busy schedule, I assigned each backlog item to GitHub Copilot’s coding agent. The agent essentially became my dedicated developer, working through issues while I continued with my regular responsibilities.

How The Coding Agent Workflow Functioned

The process became simple:

Issue Assignment: I would assign a backlog item to the coding agent
Autonomous Development: The agent implemented features based on my detailed requirements while I focused on other tasks
Pull Request Creation: Completed work was submitted for my review, ready when I had time to evaluate it
Iterative Improvement: I provided feedback through the standard PR review process during natural breaks in my day

How I Maintained Quality: The Human Touch in the Workflow

While the coding agent handled implementation, my role evolved to quality oversight, which I found to be more valuable and engaging than writing code myself. This shift allowed me to focus on the strategic aspects of development that truly required my expertise.

The Review Process

I treated each pull request with the same rigour I would apply to work from any team member:

Code quality assessment: Evaluating architecture, readability, and maintainability
Functional testing: Verifying implementation against my acceptance criteria
Integration validation: Ensuring compatibility with our existing systems
Security review: Following our established security guidelines

What I Learned About Effective Feedback

Through this process, I discovered that providing specific, actionable feedback yielded the best results:

What worked for me: “Resolve Bicep warning errors related to value could be null”
What was less effective: “Resolve all warning errors in Bicep file” (too vague, led to generic solutions that required iteration)

What I Learned: The Reality of Human-AI Partnership

What Worked Exceptionally Well for Me

A Structured Approach: The combination of detailed planning and incremental delivery proved highly effective. I found the coding agent performed best when I provided clear, specific requirements upfront.

Context Preservation: Unlike my previous fragmented development attempts, the agent maintained full context across all work items, ensuring consistency and coherence throughout the enhancement.

Quality Consistency: Code quality remained high throughout my project, as each PR received focused review attention during convenient moments in my schedule.

My Challenges and Key Learnings

Communication Precision Matters: I learned that vague feedback led to suboptimal solutions that required additional iterations. Specific, actionable guidance consistently yielded better results faster.

Tool Integration Quirks I Encountered:

VS Code’s GitHub PR extension currently doesn’t recognise @mentions, this occasionally caused issues when trying to assign the coding agent where I had typos and caused delays
The GitHub.com interface refreshed faster than the VS Code extension, so I often switched to the web interface
I sometimes needed to force refresh to see updates in VS Code
When Copilot created pull requests it defaulted to the base branch rather than my feature branch, so I had to manually change it each time

These are minor inconveniences that I expect will improve as the tools evolve.

Why Human Oversight Remained Critical: I discovered that while the coding agent is incredibly capable, it still required my guidance for:

Strategic architectural decisions that impacted other systems
Complex business logic interpretation specific to our domain
Edge case handling based on operational experience
Integration complexity management with our existing infrastructure
Security considerations that required nuanced understanding
Testing and validation to ensure functionality met real-world needs

The Results: Successfully Delivering the Major Enhancement

After two weeks of applying this agentic DevOps approach, I successfully delivered the complete enhancement without writing a single line of code myself. The final solution I delivered included:

Full feature implementation: All planned functionality working exactly as I specified
Comprehensive testing: Both automated and manual test coverage that I validated
Complete documentation: Technical documentation and user guides ready for the team
Production readiness: Code that met all our organisational standards and passed our quality gates

The Future of Development: Agentic DevOps Adoption

Immediate Benefits

This experience demonstrated several immediate advantages of agentic DevOps:

Parallel processing: Development continues while handling other responsibilities
Consistent quality: Dedicated focus on each work item
Reduced cognitive load: Less context switching and mental overhead
Scalable approach: Methodology applicable to projects of various sizes

Strategic Implications

For development teams and organisations, this approach suggests:

Resource multiplication: Senior developers can guide multiple parallel work streams
Knowledge transfer: AI agents can implement patterns and practices consistently
Risk reduction: Incremental delivery with continuous validation
Innovation enablement: More time for strategic thinking and architectural decisions

Getting Started: Your Agentic DevOps Implementation

Essential Prerequisites

Access to GitHub Copilot: Particularly the coding agent functionality
Structured project management: Clear issue tracking and PR workflows
Quality gates: Established code review and testing processes
Planning discipline: Investment in upfront requirement definition

Recommended First Steps

Start small: Choose a well-defined enhancement or feature
Leverage proven prompts: Use resources from the Awesome Copilot repository
Establish feedback patterns: Develop clear communication styles with AI agents
Measure and iterate: Track time savings and quality metrics

Conclusion: Redefining What’s Possible in Development

This experience fundamentally changed my perspective on software development productivity. I realised that my constraint wasn’t my coding ability or technical knowledge, it was optimising how I used my available time and focus. Agentic DevOps allowed me to solve both challenges simultaneously.

By shifting my role from code writer to architect and reviewer, I was able to deliver more value in less time while maintaining the high quality standards I demand. The coding agent became my ideal development partner: tireless, consistent, and focused, requiring only strategic guidance and quality oversight from me.

I’ve learned that the future of software development isn’t about replacing developers with AI, it’s about augmenting our capabilities to achieve outcomes that were previously difficult given our time and context constraints. Agentic DevOps provided me with the framework for that augmentation.

Ready to transform your own development approach? I recommend starting with your next enhancement or feature. Create a detailed plan, break it into manageable issues, and let a coding agent handle the implementation while you focus on strategy and quality. You might be surprised by what becomes possible when you shift from writing code to orchestrating development.

Have you experimented with agentic DevOps approaches in your own projects? I’d love to hear about your experiences and lessons learned in the comments below.