DEV Community: Hector Flores

The 3 Pillars of Agentic DevOps: From Zero to Hero

Hector Flores — Sat, 09 May 2026 13:02:22 +0000

Code Is No Longer the Asset — Workflows Are

Today I'm doing a LinkedIn Live session called "Copilot Zero to Hero." The goal is to show how I went from basic Copilot autocomplete to a platform where 45+ agents, 63 skills, and 50 cron jobs autonomously maintain themselves — and how anyone can follow the same path.

But here's what I realized while preparing: the journey from zero to hero isn't about learning more features. It's about building three continuous feedback loops that compound on each other. I'm calling them the 3 Pillars of Agentic DevOps.

If you've followed my writing on the agentic development maturity curve, you know the journey isn't linear. The 3 pillars map directly to three maturity levels: Builder, Pro, and Hero. Each pillar unlocks the next. Skip one, and the whole thing wobbles.

The shift that matters: in traditional DevOps, code is the artifact you protect. In agentic DevOps, workflows are the artifact. Your copilot-instructions.md, your extension hooks, your cron schedules — these are the neural pathways that make autonomous development possible. Code is just the output.

Pillar 1: Continuous Instruction Improvement (Builder Level)

The first pillar is the most accessible and the most underrated. It's also where every agentic DevOps journey should start: what does your agent actually know, and how do you improve that knowledge on demand?

Your copilot-instructions.md is not a README. It's a neural pathway. It defines how the agent thinks about your project — your conventions, your architecture decisions, your hard-won lessons. I've written before about how context engineering is the real skill of agentic development — knowing what to feed the agent matters more than prompt tricks. Every mistake the agent makes is a signal that this file is incomplete. Every correction you make should train it — permanently.

The Context Is the Product

Here's what most people get wrong: they treat copilot-instructions.md as a one-time setup file. Write it once, forget it, wonder why the agent keeps making the same mistakes. I've called this the god prompt anti-pattern — a static mega-document that tries to cover everything upfront and covers nothing well.

The real power of Pillar 1 is treating your agent's context as a living system that you actively improve. When I correct my agent — say, it commits directly to main instead of creating a branch — I don't just say "don't do that." I tell it to persist the lesson:

# copilot-instructions.md — evolves with every correction

## Git Workflow
- NEVER commit directly to main
- Always create a feature branch via `git branch <name> main`
- Use git worktrees for parallel work
- Every PR needs a descriptive title and body

## Extension Conventions
- Hook files live in .github/hooks/
- Extension files live in .github/extensions/
- Use .mjs extension for ES modules

The correction flows into three complementary layers, each with a different scope:

copilot-instructions.md — file-based instructions checked into the repo. Every session loads this file automatically, so every contributor (human or AI) inherits your conventions. This is the most visible layer — version-controlled, reviewable, and shared across the team.
store_memory — the agent's cross-session repository memory. When the agent calls store_memory, it persists a fact to the GitHub repository memory system. That fact is then available to every future session working in the same repo — not just your sessions, but anyone's. This is how one developer's correction becomes institutional knowledge. The agent learns something at 2 PM, and a completely different session at 9 PM already knows it.
/chronicle and on-demand prompting — active history mining (more on this below).

The result: the same mistake never happens twice. After months of this, my copilot-instructions.md has become a comprehensive operational manual — not because I wrote it top-down, but because every error carved a new neural pathway. And store_memory has built a parallel layer of institutional knowledge that fills the gaps between documented conventions.

On-Demand Learning from History

Here's where it gets powerful. The agent has access to the full transcript from all your sessions — every prompt, every response, every tool call. You can use that to improve context on demand.

The /chronicle command (available to all users since v1.0.40) is one way to do this — it analyzes session history and generates a summary of what happened, what worked, and what drifted. But /chronicle is just a shortcut. The real power is that you can prompt the agent directly:

"Look at my past session history. Find any learning patterns — mistakes I corrected, conventions I enforced, preferences I expressed. Update my memory and my copilot-instructions.md file."

That's it. One prompt, and the agent mines your entire interaction history for lessons it should have learned. It finds the patterns you've been reinforcing manually and codifies them permanently.

Cross-Session Learning

This goes even further. You can teach the agent by pointing it at other sessions — not just the current one:

"Search through all my sessions for how I interact with GitHub Actions. Learn how I structure workflows, what patterns I follow, what mistakes I avoid. Create a skill from what you find."

Or even simpler:

"Look at my last 10 sessions and update my copilot-instructions.md with any conventions I've been consistently following but haven't documented yet."

This is the Builder-level superpower: the agent learns from how you actually work, not just from what you explicitly tell it. Every session becomes training data. Every correction compounds. The context gets richer over time — and the agent gets smarter with it.

Combined with a nightly reflection agent — a scheduled job that reviews the day's sessions and auto-updates instructions — Pillar 1 becomes a self-improving system. The agent literally gets smarter overnight. But you don't need automation to start. Just prompt it.

Pillar 2: Continuous CI/Feedback Integration (Pro Level)

Pillar 1 taught you how to maintain your agent's context manually — correct mistakes, prompt for learning, mine session history. Pillar 2 is the natural next question: what if that context improved itself automatically, with real-world feedback?

That's the core idea. Once you understand that context is the product (Pillar 1), you start looking for places where you can automatically consume context from the real world — test results, CI pipelines, runtime errors, deployment status — and feed it back into the agent's understanding. The format doesn't matter. Hooks, REPL loops, webhook listeners — the pattern is always the same: automatically bring real-world feedback into the agent's context.

GitHub Copilot CLI extensions make this concrete. Extensions use hooks — lifecycle events like onPreToolUse, onPostToolUse, and onUserPromptSubmitted — to intercept agent actions and inject context from the outside world.

Pattern 1: Pre-Push Gate (High-Quality Context Injection)

This is the pattern that makes Pillar 2 click. Before the agent pushes code, an onPreToolUse hook runs local tests. If they fail, the push is denied — and here's the key part — the agent receives the reason why:

// .github/hooks/pre-push-gate.json (simplified)
// Hook intercepts shell commands containing "git push"
// and runs "npm test" first — denying the push if tests fail.
//
// Actual hook config uses JSON + shell scripts.
// See the Extensions Complete Guide for full syntax.

// Pseudocode for the pattern:
async function onPreToolUse({ toolName, toolArgs }) {
  if (toolName !== "powershell") return; // only intercept shell
  if (!toolArgs.command?.includes("git push")) return;

  const testResult = execSync("npm test");
  if (testResult.exitCode !== 0) {
    return {
      permissionDecision: "deny",
      reason: `Tests failed — fix before pushing:\n${testResult.stderr}`
    };
  }
}

This is high-quality context because of what happens next. The agent sees that it can't call the tool. It gets the reason — the actual test failure output. And then it does something humans rarely do this fast: it augments its own context. "Oh, the test failed because I forgot to handle the null case. Let me fix that." It fixes the code, re-runs, and pushes clean. I explored this in depth in Tests Are Everything in Agentic AI — tests become the agent's guardrails, not just quality checks.

But notice what just happened: the agent went right back to Pillar 1. It updated its understanding of the problem. The test output became context. If you've told the agent to persist lessons (Pillar 1), it might even update copilot-instructions.md with "always handle null cases in this module." That's the feedback loop — Pillar 2 feeds Pillar 1 automatically.

I wrote about this pattern in depth in Agent-Proof Architecture and Agent Hooks: Controlling Your AI Codebase — it makes agents structurally incapable of pushing broken code.

Pattern 2: Bringing CI Back Into the Inner Loop

CI is still important. We still want CI. But here's the question Pillar 2 asks: how do we consume that CI context back into the agent's session?

Traditionally, CI runs in a separate world. The developer pushes, waits, checks a dashboard, reads logs, context-switches back to the code. With agents, we can close that loop entirely:

// Conceptual pattern — the CI feedback loop
// Real implementation uses the extension SDK or hook shell scripts.
// See: /articles/ci-monitor-extension-agent-ci-feedback-loop

async function onPostToolUse({ toolName, result }) {
  if (toolName !== "powershell") return;
  if (!result.stdout?.includes("git push")) return;

  // Poll CI status until resolved
  const status = await pollCIUntilDone(); // Your CI API
  if (status === "failure") {
    const logs = await getCILogs();
    return { message: `❌ CI failed:\n${logs}` };
  }
  return { message: "✅ CI passed" };
}

I built a full version of this — the CI Monitor extension that let me walk away from my terminal entirely. The agent pushes, CI runs, the results flow back into the agent's conversation as context, and the agent fixes any failures. My role shifted from babysitter to reviewer.

The innovation isn't replacing CI — it's consuming CI as context. The CI pipeline becomes another source of automatic context improvement, just like test output from the pre-push hook.

Zero-Token CI Checks

As of v1.0.44, hooks can bypass the LLM entirely. A userPromptSubmitted hook can intercept a request like "what's the CI status?" and return the answer directly from your CI API — no model call, no token cost, instant response. This makes high-frequency operational queries essentially free.

The Bigger Picture: Continuous Fault Analysis

GitHub Next calls this Continuous Fault Analysis — one of the disciplines in their Continuous AI (CAI) concept. The idea: watch for failed CI runs, offer explanations with contextual insights, and close the feedback loop automatically. It's the same principle as shift-left testing, but shifted all the way left — into the agent's conversation, before the PR is even created.

When I wrote Agentic DevOps: The Next Evolution of Shift Left, I argued that agents create velocity so extreme we need DevOps designed for agents, not humans. Pillar 2 is how you build that: real-world feedback flowing automatically into the agent's context, creating a virtuous cycle with Pillar 1 that compounds with every iteration.

Pillar 3: Continuous AI Maintenance (Hero Level)

Here's the progression so far: Pillar 1 is manual context maintenance — you improve your agent's knowledge on demand. Pillar 2 is automated feedback integration — real-world signals flow back into context without you lifting a finger. Pillar 3 is the logical conclusion: Pillars 1 and 2 running continuously, autonomously, without human intervention.

This is full agency. The system doesn't just consume feedback when triggered — it actively maintains itself. And it's not just code. Autonomous maintenance covers everything:

Instruction files — are they stale? Do they reflect how you actually work?
Skills — are there contradictions? Extraction opportunities? Bloat?
Test suites — is coverage drifting? Are tests still relevant?
Codebase quality — are PRs piling up? Are issues getting triaged?
SEO and content — are links broken? Are descriptions current?
Dependencies — are packages outdated? Are there security advisories?

The question isn't "what should the agent maintain?" It's "what shouldn't it maintain?"

Implementation: Cron Jobs and Agentic Workflows

The simplest path to Pillar 3 is cron jobs with GitHub Copilot CLI extensions — scheduled agents that run autonomously on a cadence. The mechanism is straightforward: a Copilot CLI extension watches a schedule defined with cron expressions, and when a job is due, it spawns a fresh Copilot CLI agent to execute the task. Extensions are the enabler — they're what make Pillar 3 possible. Here's what runs on my platform:

Skill Optimizer — scans all 63 skills for extraction opportunities, contradictions, and bloat. Runs nightly.
Context Auditor — reviews agent memory files for staleness, redundancy, and drift. Creates tasks for anything it finds. This is Pillar 1 running on autopilot.
Repo Maintainer — reviews open PRs, auto-merges safe ones, triages issues, and assigns work to other agents. Runs multiple times daily. This is Pillar 2 running on autopilot.
Nightly Reflection — analyzes the day's sessions, identifies patterns, and updates copilot-instructions.md. The ultimate Pillar 1 → Pillar 3 loop.

A cron-triggered agent looks like this:

// cron.json (simplified — actual schema may vary)
{
  "jobs": [
    {
      "name": "context-auditor",
      "schedule": "0 2 * * *",
      "agent": "context-auditor",
      "description": "Nightly audit of all agent context files"
    },
    {
      "name": "repo-maintainer",
      "schedule": "0 */4 * * *",
      "agent": "repo-maintainer",
      "description": "Review PRs, triage issues every 4 hours"
    }
  ]
}

Each job launches a fresh agent instance with full context — the agent's memory files, the relevant skills, and a clear objective. It does its work, reports findings, and shuts down. No human trigger needed.

But cron jobs aren't the only path. GitHub Agentic Workflows offer another approach — defining maintenance tasks as GitHub Actions workflows that are triggered by events (PR opened, issue created, schedule) and executed by AI agents. Same principle, different mechanism. Both give you autonomous maintenance that runs without human intervention.

The Compounding Effect

Here's what makes Pillar 3 a flywheel and not just automation. Every Pillar 3 agent uses Pillars 1 and 2 in its own work. The context auditor maintains instructions (Pillar 1). The repo maintainer consumes CI feedback (Pillar 2). The skill optimizer extracts patterns that make future agents — including other Pillar 3 agents — more effective.

The three pillars aren't independent — each one accelerates the others. After months of compounding:

45+ specialized agents covering everything from meal planning to code review
63 extracted skills — reusable procedures any agent can invoke
22 extensions with hooks enforcing quality at every operation
50 cron jobs running maintenance autonomously

The system maintains itself. I review PRs, approve merges, and steer direction. The agents handle everything else. I open-sourced the platform that runs my household — if you want to see what this looks like at scale, that's the reference implementation.

The Zero-to-Hero Map

Here's how the three pillars map to the maturity journey:

Level	Pillar	What Changes	Key Skill
Builder	Continuous Instruction Improvement	You maintain your agent's context on demand	Evolving `copilot-instructions.md` with every session
Pro	Continuous Feedback Integration	Real-world signals flow into context automatically	Building hooks that consume CI, tests, and runtime feedback
Hero	Continuous AI Maintenance	Pillars 1+2 run autonomously — the system maintains itself	Scheduling agents via cron jobs and agentic workflows

You don't need to jump to Hero on day one. Start with Pillar 1 — it takes 10 minutes to create a copilot-instructions.md that captures your project's conventions. Every correction you make improves it. Within a week, you'll notice the agent making fewer mistakes. Within a month, it'll feel like a different tool.

Then add Pillar 2 — a single onPreToolUse hook that runs npm test before allowing pushes. That one hook changes your entire relationship with the agent. Suddenly you can walk away.

Pillar 3 is where it gets addictive. Once you've seen an agent review PRs at 2 AM, you start wondering what else it could do overnight.

The Bottom Line

Agentic DevOps isn't about picking the right AI model or writing the perfect prompt. It's about building three continuous feedback loops — instruction improvement, CI integration, and autonomous maintenance — that compound on each other until the system runs itself.

The code your agents write is ephemeral. The workflows you build around them are the real asset. Your copilot-instructions.md, your extension hooks, your cron schedules — these are the infrastructure of autonomous development. Invest there.

If you caught the LinkedIn Live, you saw these pillars in action. If you missed it, everything I demonstrated is built with GitHub Copilot CLI extensions and the patterns I've been writing about here on htek.dev. Start with Pillar 1, and build from there.

If you want help implementing these pillars for your team — from setting up copilot-instructions.md that actually evolves, to building CI feedback hooks, to deploying autonomous maintenance agents — check out my consulting services or explore how I can help.

Copilot CLI Weekly: Rubber Duck Goes Universal, Enterprise Plugins Launch

Hector Flores — Fri, 08 May 2026 20:07:43 +0000

Rubber Duck Now Works With Any Model Family

On May 7, GitHub expanded Rubber Duck — the cross-family review agent I covered when it launched last month — to work bidirectionally across model families. When Rubber Duck first shipped in experimental mode, it was Claude-only: pick a Claude model as your orchestrator, and Rubber Duck would dispatch GPT-5.4 to review the work. That closed 74.7% of the performance gap between Sonnet and Opus on hard multi-file problems.

The May 7 changelog flips the script: if you're using a GPT model as your orchestrator, Rubber Duck now dispatches a Claude-powered critic. The same architectural review, subtle bug catching, and cross-file conflict detection now applies to GPT-driven sessions.

For Claude sessions, the update upgrades the reviewer model to GPT-5.5 (previously GPT-5.4), bringing a stronger second opinion to the table. The net effect is that Rubber Duck is no longer a Claude feature — it's a universal cross-family review layer that works regardless of which model you pick as your primary orchestrator.

To use it, run copilot and toggle /experimental on. You'll see Rubber Duck critiques surface after file edits, during planning checkpoints, and when the agent requests a second opinion. The critiques are terse and high-signal: "This migration doesn't handle the foreign key cascade," "The batch size will OOM on inputs > 10K rows," "This assumes UTC but the DB stores local time." The kinds of things a second pair of eyes catches.

I've been running with Rubber Duck enabled since April and the false positive rate is low. When it flags something, it's usually right. The feature still lives in /experimental, but it feels production-ready. I expect it to graduate soon.

Enterprise-Managed Plugins Hit Public Preview

On May 6, GitHub shipped enterprise-managed plugins in public preview, giving enterprise admins the ability to configure and distribute plugins across all Copilot CLI users in their org. This is a governance and onboarding win.

Before this, if you wanted every engineer in your enterprise to have access to a custom agent, an internal MCP server, or a standard set of hooks, you distributed documentation and hoped people followed it. "Clone this repo, copy these files, run this install script, restart your CLI." Some people did it. Most didn't. Onboarding new hires meant repeating the process.

With enterprise-managed plugins, admins define a settings.json file in a .github-private/.github/copilot/ repo and Copilot CLI pulls it automatically for any user authenticated via Copilot Business or Enterprise. The settings file specifies plugin marketplaces, auto-installed plugins, and baseline configurations. When a user runs copilot, the client syncs the enterprise config and applies it.

This means you can:

Standardize custom agents — If your team built a deployment agent or a codebase navigator, you can ensure every CLI user has it without manual setup.
Enforce hooks and MCP configs — Define hooks that run on every session (e.g., to enforce context rules or inject environment-specific data) and they're always active across your enterprise.
Reduce setup friction — New hires authenticate with Copilot CLI and the enterprise baseline just works.

The configuration lives in the same .github-private repo you'd use for custom agents (if you've already set one up under AI controls in your enterprise settings). If you haven't configured a source org yet, you'll need to do that first via the Agents page in your enterprise admin panel.

The practical impact here is that enterprises can finally treat Copilot CLI customizations as infrastructure-as-code instead of tribal knowledge. If you're managing Copilot for a large org, this is the feature you've been waiting for since the CLI went GA.

Hooks Can Now Bypass the LLM Entirely

In the v1.0.44-3 prerelease (published May 8), GitHub added the ability for userPromptSubmitted hooks to handle requests directly and return a response without making a model call. This is a significant architectural shift for what hooks can do.

Previously, hooks were preprocessors: inspect the user's prompt, modify it, add context, or reject it, but you always handed control back to the LLM for the actual response. Now hooks can be full interceptors. If a hook decides it knows how to handle the request without involving the model, it can return the response itself.

The use cases are obvious:

FAQ or documentation lookup — If the user asks "What's the deploy command?" and you have a knowledge base, the hook can return the answer instantly without burning a model call.
Canned responses — Common requests like "Show me the latest logs" or "What's my account status?" can be handled by hitting an API directly.
Policy enforcement — Block certain requests entirely and return a rejection message without consulting the LLM.
Latency-critical flows — For requests where you know the answer and speed matters, skip the model inference latency.

The implementation is clean: hooks return a response field in the result, and if it's present, the CLI surfaces it to the user and ends the turn. No model call, no token usage, instant feedback. This pairs nicely with the enterprise plugin system — you can distribute hooks that intercept high-frequency patterns and handle them locally, reducing load and improving response time.

This is still in prerelease, so expect the API to stabilize before it hits the main release channel. But the direction is clear: hooks are evolving from passive filters to active participants in the request/response flow.

Other Highlights from v1.0.43 and v1.0.44

Security fix for RCE — v1.0.43 patched a vulnerability where malicious bare repositories nested inside a project could trigger remote code execution. If you're working in untrusted codebases, update immediately. (CVE details)
Auto mode now uses server-side routing — The auto model selector delegates routing decisions to the server for more dynamic real-time model selection.
Faster multi-account switching — /user list and /user switch are noticeably faster for users managing multiple GitHub accounts.
Shell aliases work in ! commands — v1.0.44-1 fixed a long-standing bug where shell aliases and rc file settings weren't respected in ! prefix commands.
Prerelease update flag — copilot update --prerelease now lets you fetch the latest prerelease build without manually downloading from GitHub.
Username in statusline — You can now toggle the active account display in the footer via /statusline, useful when switching between personal and work accounts.

The Bottom Line

This week's updates reinforce two themes: cross-model collaboration is table stakes (Rubber Duck going universal), and enterprise adoption is accelerating (centralized plugin distribution, hook-based governance). The fact that hooks can now bypass the LLM entirely is a quieter change, but it's architecturally significant — it shifts the CLI from a stateless LLM wrapper to a programmable agentic runtime.

If you're running Copilot CLI in an enterprise context, the plugin management feature is worth setting up this week. If you're experimenting with /experimental, turn on Rubber Duck and watch how often the second opinion catches things your primary model missed. And if you're building custom hooks, start thinking about what you can handle locally without a model call — the performance gains are substantial for high-frequency patterns.

Next week I'll be digging into the security advisory in more detail and how the nested bare repo RCE could have been exploited. Until then, copilot update and ship something.

CI/CD/...CAI? Continuous AI and the Evolution of DevOps in the Agentic Era

Hector Flores — Fri, 08 May 2026 19:26:54 +0000

DevOps Has a New Branch — And It's Not Optional

You know CI. You know CD. Now there's a new acronym muscling its way into the DevOps lexicon: CAI — Continuous AI. And if you're a DevOps engineer, SRE, or platform engineer who hasn't started paying attention, you're already behind.

This isn't hype. The 2025 DORA Report — now titled "State of AI-assisted Software Development" — surveyed nearly 5,000 technology professionals and found that 90% already use AI in their development workflow. But only 17% use autonomous agents. That gap is where the opportunity lives — and where the danger hides. Teams with strong DevOps foundations see amplified returns from AI adoption. Teams without them see a 7.2% drop in delivery stability. AI doesn't fix broken processes. It magnifies them.

In February 2026, GitHub launched Agentic Workflows in technical preview — AI agents running inside GitHub Actions, authored in Markdown instead of YAML. Gartner projects 90% of enterprise software engineers will use AI code assistants by 2028. The entire DevOps discipline is evolving, and Continuous AI is the branch that's driving that evolution.

I've been writing about this shift for months — from the next evolution of shift left to building agent-proof architecture to hands-on agentic workflows. But every article covered one piece. This guide is the whole map — a comprehensive walkthrough of how DevOps is evolving from deterministic pipelines to AI-augmented software delivery, and what that means for every DevOps engineer's career.

The Six Concepts: A Layered Evolution

Before diving deep, here's the landscape at a glance. These six concepts aren't competing alternatives — they're layers that build on each other:

#	Concept	Core Question	AI Direction
1	Traditional DevOps	How do we unify dev and ops?	No AI required
2	CI/CD	How do we automate build → deploy?	No AI required
3	Continuous AI	How do we systematically apply AI to collaboration?	AI as continuous practice
4	Agentic DevOps	How do we make pipelines intelligent?	AI augments DevOps
5	DevOps for Agents	How do we govern AI agents?	DevOps constrains AI
6	GitHub Agentic Workflows	How do we automate repos with AI?	Platform convergence

The critical insight: Concepts 4 and 5 look similar but face opposite directions. Agentic DevOps puts AI inside your pipeline. DevOps for Agents wraps your pipeline around AI. Continuous AI is the methodology that guides both. GitHub Agentic Workflows is the platform where all directions converge.

These six concepts nest inside each other. DevOps culture is the outermost layer — it's the foundation everything else sits on. CI/CD lives inside that as the automation backbone. Continuous AI is the methodology for extending automation to tasks requiring judgment. Inside Continuous AI, two sub-disciplines face opposite directions: Agentic DevOps puts AI inside your pipeline (making it smarter), while DevOps for Agents wraps your pipeline around AI (making agents safer). GitHub Agentic Workflows sits at the convergence point where both directions meet on a single platform.

You can't skip layers. Every team I've seen fail at agentic adoption tried to jump straight to autonomous agents without solid CI/CD and testing. The 2025 DORA data confirms this — AI amplifies whatever you already have. The six-concept model ensures you build the floor before the ceiling.

Let's walk through each layer in detail.

Traditional DevOps: The Cultural Foundation

DevOps isn't a tool — it's a cultural and organizational philosophy. Coined around 2009 and formalized through the Phoenix Project, DORA metrics, and the DevOps Handbook, it breaks down silos between development and operations through shared ownership, feedback loops, and continuous improvement.

The core principles haven't changed in 15 years:

Break down silos between development and operations
Automate everything that can be automated
Measure and improve continuously (DORA metrics: deployment frequency, lead time, change failure rate, MTTR)
Shift left — move testing and validation earlier in the lifecycle
Infrastructure as Code — treat infrastructure with the same rigor as application code
Blameless postmortems — learn from failure, don't punish it

Every modern software organization practices some form of DevOps. The 2025 DORA Report — renamed from "Accelerate: State of DevOps" to "State of AI-assisted Software Development" — confirms the formula still works: teams with strong DevOps practices ship faster, more reliably, and with fewer failures.

The renaming itself is significant. DORA's research team, led by Nathen Harvey and Derek DeBellis, deliberately reframed the entire report around AI because the data demanded it — 90% of the nearly 5,000 respondents now use AI tools in their workflow. AI isn't a feature anymore; it's the environment.

The report reveals something crucial for the AI era — AI acts as a magnifying glass for existing organizational health. The DORA team identified seven organizational capabilities that determine AI success: platform quality, data access, version control maturity, small batch sizes, user focus, clear AI policies, and organizational AI stance. Strong DevOps foundations see amplified returns from AI adoption. Weak foundations see amplified chaos — with a measurable 7.2% drop in delivery stability for struggling teams. My deep dive into the Stanford study on AI ROI found the same pattern — the biggest productivity gains go to teams with the strongest engineering practices already in place.

But DevOps itself didn't appear fully formed. It evolved through distinct waves, each one solving the previous era's pain while creating new complexity. The progression went like this: manual operations → shell scripts and cron jobs → configuration management tools like Puppet and Chef (2011) → Docker containers (2013) → Kubernetes orchestration (2015) → GitOps with Flux and ArgoCD (2017) → Platform Engineering (2022+). Each wave was a response to the shortcomings of the one before it.

Configuration management solved "works on my machine" by codifying server state — but introduced its own language sprawl (Puppet DSL vs. Chef Ruby vs. Ansible YAML). Docker solved dependency hell by containerizing everything — but created image sprawl and a new layer of networking complexity. Kubernetes solved container orchestration at scale — but demanded a small army of YAML manifests to operate. GitOps solved configuration drift by making Git the single source of truth — but added yet another abstraction layer on top of already-deep stacks. And Platform Engineering emerged because teams realized they'd built so many layers that nobody could onboard without a dedicated internal platform team to smooth the sharp edges.

The result? By 2023, the State of DevOps report identified configuration management complexity as the top pain point for engineering teams. The industry had traded one kind of manual labor (SSH-ing into servers) for another (maintaining thousands of lines of declarative YAML across dozens of tools). The irony wasn't lost on anyone: DevOps was supposed to automate toil, but the automation itself had become toil. This is the context that makes Continuous AI feel less like a bolt-on and more like an inevitable next step — applying AI reasoning to the very configuration complexity that DevOps created.

Why DevOps Alone Isn't Enough

Traditional DevOps has a ceiling:

Deterministic automation — it only does exactly what you script it to do
Human-speed feedback loops — PR reviews take hours, CI takes minutes, but the developer has already context-switched
Brittle automation — when environments drift or zero-days appear at 3 AM, the system waits for a human
Reactive posture — responds to events rather than anticipating them

These limitations didn't matter much at human development velocity. They matter enormously when AI agents generate hundreds of lines per minute.

CI/CD: The Automation Backbone

CI/CD is the specific technical engine within DevOps that automates the build-test-deploy pipeline. It's worth separating from DevOps because it's the foundation that everything agentic builds upon.

Continuous Integration (CI): Developers frequently merge code into a shared branch; automated builds and tests run on every change
Continuous Delivery (CD): Every code change that passes CI is automatically prepared for release
Continuous Deployment: Extends CD by deploying every passing change to production without a human gate

The ecosystem is mature — GitHub Actions, Jenkins, CircleCI, ArgoCD, Flux — and the practices are industry-standard. CI/CD enables daily (or hourly) deployments, catches bugs before production, and provides reproducible, auditable builds.

The evolution of CI/CD mirrors the broader DevOps wave pattern. Early CI servers like Jenkins (2011) gave teams automated builds but required manual Groovy pipeline scripts. Travis CI introduced declarative YAML pipelines (~2013), which was liberating at first — until teams realized they were now debugging YAML indentation instead of shell scripts. GitHub Actions (2019) made CI/CD native to the repository, eliminating the "separate CI server" problem, but introduced its own complexity: composite actions, reusable workflows, matrix strategies, and OIDC federation.

By 2024, the average enterprise repository had hundreds of lines of workflow YAML. The phenomenon known as "YAML hell" became a running joke — and a real productivity drain. Pipeline configurations ballooned into sprawling, brittle manifests that nobody on the team fully understood. A single misplaced indent could silently break a deploy. The 2023 State of DevOps survey found that configuration management topped the list of pain points for engineering teams — more frustrating than testing, security, or even deployment. This is the world Continuous AI is stepping into: a world where the automation infrastructure itself has become the bottleneck.

Where CI/CD Hits Its Limits

But CI/CD is deterministic by design, and that's simultaneously its strength and its limitation:

Post-facto feedback — by the time CI catches a bug, the developer has mentally moved on
YAML complexity — large pipelines become nightmares to maintain ("YAML hell" is a real phenomenon)
Cannot reason about intent — CI/CD executes predefined steps; it can't figure out why something failed or propose a fix
Human bottleneck — PR reviews, manual approvals, and environment promotions still require human time and attention
No adaptive behavior — when a pipeline fails in a new way, it can't investigate or self-correct

CI/CD is the backbone, but it needs intelligence. Enter Continuous AI.

Continuous AI: The Methodology for AI in the SDLC

This is where the story gets interesting. Continuous AI is a methodology and conceptual framework coined by Idan Gazit, head of GitHub Next, for the systematic, continuous application of AI reasoning to tasks across the software development lifecycle that CI/CD was never designed to handle — tasks requiring judgment, interpretation, and context rather than deterministic execution.

Continuous AI is not a product — it's a category, a pattern, a way of thinking. As Gazit puts it: "Not a term GitHub owns, nor a technology GitHub builds: it's a term we use to focus our minds." GitHub expects Continuous AI to be "a story that runs for 30+ years at GitHub, just like CI/CD."

The analogy: Continuous AI is to GitHub Agentic Workflows what CI/CD is to GitHub Actions. CI/CD is the concept; GitHub Actions is one implementation. Continuous AI is the concept; GitHub Agentic Workflows is one implementation.

The Core Formula

Continuous AI = natural-language rules + agentic reasoning, executed continuously inside your repository.

Four foundational principles:

Context Awareness — AI understands your codebase, diffs, terminal outputs, configuration, and docs — what I call context engineering
Seamless Integration — AI lives within your IDE and pipeline, not copy-paste to external tools
Continuous Execution — AI runs automatically on repository events, not only when manually invoked
Developer Control — developers remain the final authority over all AI-proposed changes

Continuous AI Subcategories

Continuous AI manifests as specialized, repeatable patterns — each applying AI to a specific aspect of software collaboration:

Subcategory	What It Does
Continuous Documentation	Keep docs in sync with code changes automatically
Continuous Code Review	AI-powered PR reviews for security, quality, architecture
Continuous Triage	Label, summarize, and respond to issues with AI
Continuous Test Improvement	Assess coverage gaps, generate targeted tests
Continuous Security	AI-driven vulnerability scanning and analysis
Continuous Fault Analysis	Watch CI failures, offer explanations and fix proposals
Continuous Quality	LLM-powered code quality analysis beyond static tools
Continuous Summarization	Generate and maintain up-to-date project summaries

(Source: awesome-continuous-ai)

The Maturity Model

The Continue team proposes a useful maturity model:

Level	Stage	Example
1	Manual AI Assistance	Copilot in the IDE, ChatGPT for code questions
2	Workflow Automation	Auto-triage issues, auto-generate changelogs
3	Zero-Intervention	Auto-fix lint errors, auto-update deps, auto-label PRs

Most teams are at Level 1. The teams I work with that are getting real value have pushed into Level 2. Level 3 is the frontier — and it requires the governance models described in the next two sections to do safely.

The Implementation Stack

Continuous AI isn't just a concept — there's a concrete implementation stack emerging. Three layers work together to bring AI reasoning into your repository workflows:

Layer 1: actions/ai-inference is a GitHub Action that calls AI models from GitHub Models directly inside your workflows. It supports inline prompts and structured .prompt.yml files, needs only permissions: models: read, and outputs model responses you can use in subsequent steps. It's the simplest on-ramp — add one action step and you've got AI reasoning in your pipeline.

- name: Analyze failure
  id: analysis
  uses: actions/ai-inference@v2
  with:
    prompt-file: '.github/prompts/analyze-failure.prompt.yml'

Layer 2: GenAIScript is an open-source scripting framework from Microsoft that lets you write composable LLM-powered scripts. It's the power tool — it can access git diffs, run in CI with npx --yes genaiscript run, apply file edits, and output traces to $GITHUB_STEP_SUMMARY. The awesome-continuous-ai list is full of GenAIScript-based examples for issue labeling, duplicate detection, and code review.

Layer 3: gh models is a CLI extension that brings GitHub Models to your terminal. Run gh models run openai/gpt-4o-mini "why did this test fail?" for single-shot inference, or use REPL mode for interactive debugging. The gh models eval command runs prompt evaluations from the command line — scoring prompts against expected outputs with similarity, string match, and custom LLM-as-a-judge evaluators. This makes it practical to test prompt quality in CI the same way you test code quality.

Together, these three layers cover the full spectrum: actions/ai-inference for simple one-step AI calls, GenAIScript for complex multi-file scripting, and gh models for developer-facing CLI workflows and evaluations. If you're evaluating which SDK to use for building custom agents beyond these, I broke down the options in my guide to choosing the right AI SDK.

Early Results

Early Continuous AI adopters are reporting significant results:

Test coverage: From ~5% to near 100% across 45 days with 1,400+ tests for ~$80 in tokens
Dependency drift: Semantic change detection catching breaking changes before merge
Doc/code mismatch: Automated detection and fixing of documentation that has drifted from implementation

(Source: GitHub Blog — Continuous AI in Practice)

Agentic DevOps: AI Inside the Pipeline

Agentic DevOps is the practice of embedding AI agents into the DevOps pipeline to make decisions, triage issues, and automate tasks that traditionally required human judgment. This is AI augmenting DevOps — the pipeline becomes intelligent.

The Velocity Problem

The thesis rests on a velocity problem. I wrote about this in my agentic-ops article:

"DevOps was invented to protect teams from velocity. That worked when velocity meant shipping weekly instead of monthly. AI agents ship at machine speed. Old DevOps patterns can't keep up."

Each era in software delivery has responded to increased velocity by shifting governance earlier:

Era	Velocity	Testing Strategy	Feedback Delay
Waterfall	Monthly releases	QA phase before release	Days to weeks
Agile	Weekly releases	Testing in sprints	Days
CI/CD	Daily deploys	Automated pipelines	Minutes to hours
Pre-commit hooks	Per commit	Local hooks	Seconds
Agentic DevOps	Per keystroke	Real-time governance	Milliseconds

What Agentic DevOps Looks Like in Practice

Component	What It Does	Example
AI-Powered Triage	Agents analyze failures, categorize issues, propose fixes	SRE agents monitoring CI failures
Intelligent Code Review	AI reviews PRs for security, quality, architecture	Copilot code review, CodeRabbit
Self-Healing Infrastructure	Agents detect drift and remediate autonomously	Auto-scaling, config correction
Adaptive Pipelines	Pipelines that reason about what to test based on changes	Selective test execution
AI-Driven Security	Agents scan for vulnerabilities and propose patches	Dependabot + AI fix proposals
Autonomous Remediation	Agents execute runbooks and escalate when needed	PagerDuty AI, incident response bots

Industry Convergence

The industry is aligning around Agentic DevOps from multiple angles. Harness describes it as "the architect's guide to autonomous infrastructure." Opsera focuses on reducing "coordination overhead that slows delivery long after code is written." Qovery has built specialized DevOps AI agents for FinOps, DevSecOps, Observability, and CI/CD. HackerNoon provocatively declared "CI/CD Is Dead. Agentic DevOps is Taking Over."

My take: CI/CD isn't dead. It's the foundation. Agentic DevOps is the next layer built on top of it.

The Real-World Gains

Practitioners are reporting 20–50% gains in velocity, MTTR, and cost from agentic DevOps patterns — but with an important caveat: most teams aren't running fully autonomous pipelines. The gains come from targeted applications: AI-powered triage that cuts incident response time, intelligent code review that catches what linters miss, and adaptive test selection that runs only relevant tests.

There's a trust gap here that the DORA data confirms. While 90% of developers now use AI, only 17% use autonomous agents. And 30% of developers don't trust the AI-generated code they use daily. The METR study even found a 19% slowdown in some contexts where AI was applied without proper workflow integration. The lesson? Agentic DevOps isn't about blind automation — it's about the right AI in the right place with the right guardrails. I wrote about this trust-vs-productivity tension in my article on turning AI skeptics into believers.

DevOps for Agents: Governing the AI

This is where the conversation flips direction. Instead of AI augmenting your pipeline, you're building a pipeline around AI to ensure it operates safely and predictably. This is the discipline I've spent the most time on, and it's the most underserved area in the industry.

The Core Problem

When your developer is an AI agent, the entire DevOps model needs rethinking:

Agents operate at machine speed. A human developer writes 50 lines per hour. An AI agent generates hundreds of lines per minute. By the time CI catches a bug, the agent has changed 50 more files and built dependencies on the mistake.
Instructions aren't enforcement. Telling an agent about architectural rules in copilot-instructions.md is like writing a coding standards document for human developers. Some will follow it. Some won't. You need systematic enforcement.
Unsanitized inputs are attack vectors. The Clinejection attack in February 2026 proved this definitively — an attacker opened a GitHub issue with a prompt injection payload, hijacked an AI triage bot, stole npm credentials, and published a malicious package to 4,000 developers. The entry point was a GitHub issue title. DevOps for Agents must treat all external input as untrusted, just like traditional web security treats user input.
Testing is the architecture blueprint. In an agentic world, tests aren't just verification — they're the specification. I explored this principle with specs-as-tests in Terraform. Without comprehensive test coverage, agentic AI will fail. I wrote about the specific failure modes in my article on vibe testing.

Governance Approaches

There are multiple frameworks emerging for how to govern AI agents in the SDLC. One useful mental model is a three-layer approach I outlined in my article on agent hooks: Enablement (instructions, tools, context), Enforcement (specs, hooks, architectural rules), and a Final Gate (CI/CD tests, security scanning). The gap most teams have is in the enforcement layer — they tell agents what to do and verify after the fact, but nothing stops agents from violating rules in real-time.

Agent Hooks: Pre-Tool-Use Enforcement

The key innovation of DevOps for Agents is pre-tool-use hooks — intercepting the agent before it writes a file, runs a command, or makes a commit:

Traditional DevOps:
  Write → Commit → Push → CI → Feedback (minutes later)

DevOps for Agents:
  Write → [HOOK] → Feedback (milliseconds) → Continue or Stop

When an agent tries to:

Edit a file → Hook validates layer boundaries, checks for secrets, runs lint
Make a commit → Hook requires accompanying tests, checks branch rules
Run a command → Hook blocks dangerous operations (rm -rf, DROP TABLE)

I built gh-hookflow to implement this pattern using familiar GitHub Actions YAML syntax:

# .github/hookflows/protect-secrets.yml
name: Protect Secrets
blocking: true

on:
  file:
    paths: ['**/*.env*', '**/secrets/**', '**/*.pem']
    types: [edit, create]

steps:
  - run: |
      echo "❌ Cannot modify sensitive files"
      exit 1

# .github/hookflows/require-tests.yml
name: Require Tests
blocking: true

on:
  commit:
    paths: ['src/**']
    paths-ignore: ['src/**/*.test.*']

steps:
  - name: Check for test files
    run: |
      if ! echo "${{ event.commit.files }}" | grep -q '\.test\.'; then
        echo "❌ Source changes require accompanying tests"
        exit 1
      fi

The feedback is instant — milliseconds, not minutes. The agent sees the failure, self-corrects, and continues within the same session. Agents respond well to blocking feedback. They don't resist good constraints; they work within them. Chaos comes from poorly-defined boundaries, not from enforcement.

Agent Harnesses: The Control Plane

Beyond hooks, DevOps for Agents requires a control plane — the agent harness — that manages the agent's lifecycle. I wrote extensively about this in my agent harnesses article. The key stats are sobering:

Enterprises average 12 AI agents with only 27% connected. The real engineering challenge isn't building agents — it's the harness that governs them.

A proper agent harness provides:

Core loop ownership — the harness owns the agentic loop, not just wraps it
Iteration inspection — every step tracked in Result.iterations[] for observability
Multi-provider support — OpenAI, Anthropic, GitHub Models, Copilot
Safety boundaries — tool access controls, context window management
Testing at depth — eval tests that verify guardrails actually block dangerous output

Test Enforcement at Machine Speed

DevOps for Agents introduces a radically different testing philosophy that I covered in depth in my test enforcement architecture article:

Coverage is line-level — the hook analyzes which specific lines changed and verifies tests cover those exact lines
Layer-aware thresholds — core domain (L3) requires 90%, application services (L4) 80%, infrastructure (L5) 70%
Coverage ratchets only go up — thresholds increase as the project matures, never decrease
AI-generated test quality verification — without enforcement, AI-generated tests achieve only 20% mutation scores, meaning 80% of bugs slip through

GitHub Agentic Workflows: Where Everything Converges

GitHub Agentic Workflows is the platform-level implementation where Agentic DevOps and DevOps for Agents converge. Announced in February 2026 as a technical preview, it runs coding agents (Copilot, Claude, Codex) inside GitHub Actions, authored in Markdown instead of YAML, with built-in security layers, safe-outputs, and detection jobs.

Markdown Instead of YAML

The authoring model is the most visible change. Instead of YAML hell, you describe your automation in plain English:

---
on:
  issues:
    types: [opened, reopened]
permissions:
  contents: read
  issues: read
tools:
  github:
    toolsets: [issues, labels]
engine:
  id: copilot
  model: gpt-5.2-codex
safe-outputs:
  add-labels:
    allowed: [bug, feature, enhancement, documentation]
  add-comment: {}
---

# Issue Triage Agent

Analyze new issues. Read the title and body carefully.
Classify as bug, feature, enhancement, or documentation.
Add the appropriate label and post a comment explaining
your reasoning.

That's it. No step definitions, no shell scripts, no job matrices. The AI agent interprets the Markdown instructions and executes with context-aware reasoning. The YAML frontmatter defines the security boundaries — what the agent can read, what it can write, and what tools it can use.

The Compilation Model

What most people miss: that Markdown file doesn't run directly on GitHub Actions. There's a compilation step — gh aw compile transforms your .md file into a .lock.yml file, which is a standard GitHub Actions workflow with security constraints, tool access, and agent configuration baked in. You commit both files. The Markdown is for humans; the lock file is for the runner. This means your agentic workflows are version-controlled, diffable, and reviewable — just like any other CI/CD configuration.

The Security Architecture

GitHub Agentic Workflows implements security at three distinct layers:

Substrate Isolation — each workflow runs in an isolated environment with controlled tool access through an MCP Gateway and API Proxy
Declarative Specification — the YAML frontmatter explicitly declares permissions, safe-outputs, and tool access; anything not declared is denied
Plan-Level Trust — detection jobs analyze agent output for secrets, malicious patches, and anomalous behavior before any writes are committed. These detection jobs also create the audit trail that enterprise compliance teams require — every agent action, every output decision, every blocked write is logged and reviewable, satisfying the evidence requirements for SOC 2, SOX, and HIPAA audits.

The safe-outputs system is particularly elegant. The agent operates read-only by default. To write anything — add a label, create a PR, post a comment — the workflow must explicitly declare that output type. This is a fundamentally different security posture than traditional Actions, where GITHUB_TOKEN permissions grant broad access. The architecture is designed so that even if an agent is tricked by a prompt injection, the safe-outputs declaration limits the blast radius to only the operations you've explicitly authorized.

Governance in Code: How gh-aw Puts You in Control

What makes GitHub Agentic Workflows production-viable isn't just that it has governance — it's that every governance decision is declarative, version-controlled, and auditable. Let me walk through what that actually looks like in practice.

Minimal permissions vs. expanded permissions. The simplest governance choice is what the agent can read and write. Compare these two frontmatter blocks:

---
# Minimal: read-only, no writes
permissions:
  contents: read
  issues: read
safe-outputs: {}
---

vs.

---
# Expanded: can create PRs and add comments
permissions:
  contents: read
  pull-requests: read
safe-outputs:
  create-pull-request: {}
  add-comment: {}
---

The first agent can observe everything but touch nothing — ideal for analysis and reporting workflows. The second can create pull requests and add comments, but still can't push code directly, modify labels, or close issues. Nothing is implicit. If you don't declare it, the agent can't do it.

Scoped safe-outputs with constraints. You can go beyond binary allow/deny and constrain what values an agent can write:

---
safe-outputs:
  add-labels:
    allowed: [bug, feature, enhancement, documentation, needs-triage]
  add-comment: {}
  create-pull-request:
    allowed-branches: [main]
---

This agent can add labels — but only from a predefined set. It can create PRs — but only targeting main. If a prompt injection tries to make the agent apply a deploy-to-production label or open a PR against a release branch, the platform blocks it regardless of what the LLM outputs. This is defense-in-depth at the declaration level.

Engine configuration with model selection. You control which AI model powers the agent, which directly affects cost, speed, and capability:

---
engine:
  id: copilot
  model: gpt-5.2-codex
# Or use Claude:
# engine:
#   id: claude
#   model: claude-sonnet-4
---

This means you can run cheaper, faster models for routine triage workflows and reserve more capable models for complex code review. Model selection is a governance decision — and it belongs in version control alongside everything else.

MCP tool configuration and network rules. For enterprise teams connecting agents to internal systems, tool access and network egress are explicitly declared:

---
tools:
  github:
    toolsets: [issues, pull_requests, code_search]
  mcp:
    servers:
      - url: https://internal-api.company.com/mcp
        tools: [query_incidents, check_runbooks]
network:
  allowed-domains:
    - api.github.com
    - internal-api.company.com
---

The agent can call GitHub's issues and PR APIs, query your internal incident system via MCP, and access exactly two domains on the network. Try to reach any other endpoint and the request is blocked at the platform level. For enterprise teams managing SOC 2 or HIPAA compliance, this level of declarative network control creates the audit trail that compliance teams need — every permitted domain, every tool invocation, all reviewable in a single Markdown file checked into Git.

The pattern across all four examples is the same: everything the agent can do is declared in code, reviewed in PRs, and enforced by the platform. There's no hidden configuration, no runtime escalation, no ambient authority. This is what production-grade AI governance looks like.

Six Core Usage Patterns

Based on GitHub's documentation and my own experimentation, six patterns are emerging:

Issue Triage — Auto-label, categorize, and comment on new issues
Documentation Maintenance — Keep docs in sync with code changes on a schedule
CI Failure Analysis — Investigate build failures and propose fixes
Test Improvement — Identify coverage gaps and generate targeted tests
Code Review — AI-powered PR reviews that catch what linters miss
Reporting — Generate weekly digests, changelogs, or project status reports

I built working demos of four of these patterns in my hands-on guide.

The Master Comparison

Here's how all six concepts compare across key dimensions:

Dimension	Traditional DevOps	CI/CD	Continuous AI	Agentic DevOps	DevOps for Agents	gh-aw
Emerged	~2009	~2011	~2025	~2024	~2025	Feb 2026
Authoring	Scripts, configs	YAML	Natural language	YAML + AI	YAML (hookflow)	Markdown
Execution	Human + automation	Deterministic	Event-triggered AI	AI-augmented	Real-time hooks	AI in Actions
Decision Making	Human	Predetermined logic	AI + human review	AI + human oversight	AI within boundaries	AI + safe-outputs
Feedback Speed	Hours–days	Minutes	Minutes	Seconds–minutes	Milliseconds	Minutes
Security	RBAC, secrets	Pipeline gates	Auditable AI	AI + scanning	Pre-tool enforcement	3-layer isolation
Maturity	Mature (15+ yrs)	Mature (13+ yrs)	Emerging (~1 yr)	Emerging (1–2 yrs)	Emerging (< 1 yr)	Tech Preview

Security and Governance: A Deep Comparison

Security is the axis that separates production-ready agentic DevOps from a vendor demo. Here's how each concept handles trust:

Concern	DevOps	CI/CD	Agentic DevOps	DevOps for Agents	gh-aw
Who is trusted?	Authenticated humans	Pipeline authors	AI + supervisors	AI within boundaries	AI within safe-outputs
What can write?	Anyone with access	Pipeline w/ creds	AI with permissions	AI through hooks only	AI through safe-outputs only
Secret protection	Vault, env vars	Pipeline secrets	AI-aware scanning	Pre-tool hook scanning	Detection job + firewall
Rollback	Manual or automated	Pipeline rollback	AI-assisted rollback	Hook blocks before damage	Detection blocks before output
Audit trail	Git log	Build logs	AI decision logs	Hook execution logs	MCP Gateway + API Proxy logs

The key takeaway from the security comparison: the concepts that explicitly handle enforcement — DevOps for Agents with pre-tool hooks, and GitHub Agentic Workflows with safe-outputs and detection jobs — are the only ones that address the governance gap where most teams struggle. Everything else relies on either telling agents what to do (instructions) or catching problems after the fact (CI/CD gates).

The Decision Framework: When to Use What

These concepts are complementary, not competing. Here's how to think about adoption:

Need to automate build/test/deploy? → CI/CD (baseline requirement)
Need cultural transformation + monitoring + IaC? → Traditional DevOps
Want AI to continuously handle judgment-heavy repo tasks? → Continuous AI methodology
Want AI to help manage your pipeline? → Agentic DevOps (AI augments pipeline)
Do AI agents write code in your repos? → DevOps for Agents (govern the AI)
Want AI-powered repo automation on GitHub? → GitHub Agentic Workflows

The most sophisticated teams use all six simultaneously:

Traditional DevOps provides the cultural foundation
CI/CD provides the automated pipeline backbone
Continuous AI provides the methodology for applying AI systematically
Agentic DevOps makes the pipeline intelligent
DevOps for Agents governs the AI agents doing the work
GitHub Agentic Workflows provides the platform that integrates it all

The Convergence Trajectory

The trajectory is clear: these six concepts are converging toward a unified model:

Workflows are written in natural language — gh-aw's markdown-first approach is the template
Continuous AI becomes as foundational as CI/CD — GitHub expects this story to run for 30+ years
Governance is embedded at every layer — hooks at tool-use, safe-outputs at platform, CI at pipeline
AI agents are first-class participants in the development lifecycle, not bolted-on assistants
Repos host fleets of small, focused AI workflows — not one monolithic agent, but many targeted automations

How Agentic DevOps Changes Your Team

The tooling shift is real, but the bigger disruption is what happens to your people. Agentic DevOps doesn't just change pipelines — it changes roles, career paths, and team dynamics in ways that most organizations haven't started thinking about.

DevOps engineers evolve from "pipeline plumber" to "AI workflow architect." The traditional DevOps engineer spent their day writing YAML, debugging CI failures, and managing infrastructure drift. In an agentic world, that same engineer designs agent workflows, defines governance boundaries, and architects the interaction between human developers and AI agents. The plumbing still matters — but the value shifts from writing the pipeline to designing what the pipeline should decide.

SREs evolve from "alert responder" to "agent governor." Instead of getting paged at 3 AM to run a remediation playbook, the SRE defines what autonomous remediation looks like, sets the boundaries for when agents can self-heal versus when they must escalate, and validates that the agent's decisions align with reliability objectives. The SRE's judgment doesn't disappear — it gets codified into governance policies that run at machine speed. I explored this pattern in depth in my article on self-healing infrastructure.

New roles are emerging. I'm seeing job titles that didn't exist 18 months ago: "Continuous AI Engineer" — someone who designs and maintains the fleet of AI workflows across an organization's repositories. "Agentic DevOps Context Engineer" — someone who specializes in crafting the prompts, instructions, and context that make agents effective within specific codebases. "Agent Governance Architect" — someone who owns the enforcement layer: hookflows, safe-outputs, detection jobs, and the policies that determine what agents can and can't do.

The skills you need to add aren't optional. If you're a DevOps engineer today, here's what's landing on your plate: prompt engineering (writing instructions that agents actually follow), workflow authoring in Markdown (the gh-aw authoring model), understanding LLM behavior (when models hallucinate, when they're reliable, what temperature settings actually do), and security around AI inputs (treating every issue title, PR description, and commit message as a potential prompt injection vector). These aren't nice-to-haves. The Clinejection attack proved that AI-facing security is as critical as network security.

Here's what I want to make explicit: just because "agentic development" has "development" in the name doesn't mean it excludes DevOps. In fact, DevOps engineers are uniquely positioned for this shift because they already think in systems, pipelines, and governance. A developer might write a great prompt. But a DevOps engineer understands how that prompt interacts with CI triggers, branch protection, secret management, and deployment gates — the full system, not just the code. Enterprise teams need someone who understands both the pipeline AND the AI. That's the DevOps engineer's natural evolution.

The Economics of Agentic DevOps

Let's talk money — because everyone's excited about AI agents until the invoice arrives.

Token costs are real. Running AI inference on every PR, issue, and push event isn't free. A typical gh-aw workflow run costs somewhere between $0.01 and $0.50 depending on the model, prompt length, and context window size. A simple issue triage workflow using a smaller model might cost a penny. A complex code review workflow using gpt-5.2-codex with full repository context could cost fifty cents or more.

Those numbers sound trivial in isolation — but they compound. If you're running 10 agentic workflows across a repository that sees 50 PRs per day, that's 500 AI invocations daily. At $0.10–$0.25 each, you're looking at $50–$125/day, or roughly $1,500–$3,750/month for a single active repository. Scale that across a 20-repo engineering org and the bill gets attention fast.

But here's the comparison most teams don't make. A senior engineer spending 30 minutes on a PR review costs roughly $50–$75 in loaded salary (at $200K–$300K total comp). An AI-powered code review of the same PR costs $0.10–$0.50. Even if the AI review only replaces half of the human review time, the economics are overwhelming. The question isn't whether AI review is cheaper — it's whether you're measuring both sides of the equation.

Enterprise cost controls matter. Smart teams are implementing these early: monitoring token usage per workflow (the actions/ai-inference action outputs token metadata), setting budget alerts when monthly spend exceeds thresholds, using smaller models for routine tasks (issue labeling doesn't need a frontier model) and reserving larger models for complex analysis (architectural code review, security scanning). Some teams I've talked to run a tiered model strategy — gpt-4.1 for triage, gpt-5.2-codex for code review — cutting costs by 60% without meaningful quality loss.

The ROI calculation. The real math looks like this: compare the reduction in MTTR (mean time to recovery), faster PR cycle times, reduced manual triage hours, and fewer incidents caused by unreviewed code against the total token spend. In every team I've worked with that's actually measured this, agentic DevOps is cheaper than the human labor it replaces — often by an order of magnitude. But only if you're measuring both sides. Teams that only track AI costs without measuring the human toil being displaced will always conclude it's "too expensive." The DORA data on delivery performance confirms the pattern: the productivity gains from AI-augmented workflows far exceed the infrastructure cost, provided the foundations are solid.

Getting Started: A Practical Roadmap

The biggest question I get after presenting this framework is: "Okay, but where do I actually start?" The six-layer model makes sense architecturally, but teams need a concrete adoption path. Here's the roadmap I recommend, calibrated to real-world timelines I've seen work across teams of 5-50 engineers.

The critical principle: don't skip layers. Every team I've seen fail at agentic adoption tried to jump straight to autonomous agents without the foundations. Build the floor before the ceiling.

Phase 1: Foundation (Week 1–2)

Get your house in order before inviting AI agents inside it.

Audit your CI/CD baseline. If your builds are flaky, your tests are sparse, or your deploys are manual — fix that first. Agentic tools amplify whatever you already have, and the DORA data is clear: teams with weak foundations see a 7.2% drop in delivery stability when AI is introduced.
Establish test coverage reporting. Measure where you are today. You can't ratchet coverage upward if you don't know your starting point. I wrote about why tests are the architecture blueprint for agentic AI — this isn't optional.
Configure DORA metrics. Track deployment frequency, lead time for changes, change failure rate, and mean time to recovery. These four numbers tell you whether AI adoption is actually helping or just generating noise. The DORA team's quickcheck is a five-minute starting point.
Set up branch protection and required status checks. This is your Pillar 3 baseline — the final gate that catches problems regardless of who (or what) wrote the code.

Phase 2: First AI Touches (Week 3–4)

Start small, measure everything, and build trust incrementally.

Add actions/ai-inference for a single, low-risk task. PR summarization is the ideal first use case — it's read-only, low-stakes, and immediately visible to the whole team. Add one workflow step that summarizes what a PR changes and posts it as a comment. You'll need permissions: models: read and nothing else.
Enable Copilot code review on your most active repository. This is Continuous Code Review in its simplest form — AI reviews PRs alongside your human reviewers. Watch what it catches that humans missed, and watch what it gets wrong. Both data points matter.
Try gh models for interactive debugging. When a CI failure confuses you, pipe the logs into gh models run and ask it to explain. This builds muscle memory for AI-assisted workflows without any automation risk.
Measure the impact. Compare PR cycle time before and after. Track how often Copilot review catches real issues versus false positives. Don't move to Phase 3 until you trust what you're seeing.

Phase 3: Continuous AI Workflows (Month 2)

Now you're ready for event-driven AI automation — but start with the safest patterns.

Deploy your first GitHub Agentic Workflow. Issue triage is the safest starting point because it's constrained to labeling and commenting — no code changes, no deploys, no infrastructure mutations. Use safe-outputs to restrict the agent to only adding labels from a predefined set. I walked through this exact setup in my hands-on guide.
Add Continuous Documentation. Set up a scheduled workflow that scans for doc/code drift and opens PRs to fix it. This is a high-value, low-risk automation — the worst outcome is an unnecessary PR that you close. GenAIScript is ideal for this pattern since it can access git diffs and apply file edits natively.
Implement CI failure analysis. When builds break, have an AI agent post an analysis comment explaining the likely cause and suggesting a fix. This doesn't change anything — it just speeds up the human developer's debugging cycle. The full potential of this pattern — where agents not only diagnose failures but autonomously fix their own bugs — is where teams graduate to once trust is established.
Set up prompt evaluations with gh models eval. Start testing your AI prompts the same way you test your code. Define expected outputs, run evaluations in CI, and catch prompt regressions before they reach production. This is quality engineering for your AI layer.

Phase 4: Enforcement Layer (Month 3)

This is where most teams stall — and it's the phase that matters most. Without enforcement, everything you built in Phases 2–3 is running on trust alone.

Install gh-hookflow and define your first hooks. Start with three non-negotiable rules: block edits to sensitive files (.env, secrets, credentials), require tests with source changes, and block dangerous shell commands. I covered the full setup in my agent hooks article.
Add architectural boundary enforcement. If your codebase has layers (domain → application → infrastructure), add hooks that prevent cross-layer violations. This catches the most expensive category of AI-generated bugs — structural mistakes that compile fine but violate your architecture.
Implement coverage ratchets. Configure your test enforcement so coverage thresholds can only go up, never down. Layer-aware ratchets are ideal: 90% for core domain, 80% for application services, 70% for infrastructure. I detailed this approach in my test enforcement architecture article.
Validate your hooks are actually working. Run gh hookflow validate on every hookflow file. Then deliberately try to violate each rule and confirm the hook blocks it. Untested enforcement is worse than no enforcement — it gives false confidence.
Involve security and compliance stakeholders. Enterprise teams operating under SOC 2, SOX, or HIPAA requirements should bring security and compliance leads into Phase 4 early. The enforcement layer you're building here — agent hooks, safe-outputs, detection jobs — is what produces the audit evidence those frameworks demand. Getting compliance buy-in now prevents painful retrofitting later.

Phase 5: Full Agentic Stack (Month 4+)

With the enforcement layer in place, you can safely scale up.

Deploy multiple gh-aw workflows across different repository events — issue triage, documentation maintenance, code review, and test improvement. Each workflow gets its own Markdown file, its own safe-outputs constraints, and its own detection jobs.
Build an agent harness for complex multi-step automations. The harness owns the agentic loop, tracks every iteration, and provides observability into what agents are doing and why. I covered the architecture in my agent harnesses article.
Implement coverage ratchets that increase over time. As your test suite grows, automatically tighten the thresholds. This creates a flywheel — more coverage enables more aggressive automation, which generates more coverage.
Set up audit trails and token cost monitoring. Track every agent decision, every tool call, and every dollar spent on model inference. MCP Gateway logs and API Proxy logs are your primary data sources. If you can't answer "what did the agent do and why?" for any given workflow run, you don't have enough observability.
Run regular red-team exercises. Attempt prompt injection through every input surface your agents read — issue titles, PR descriptions, commit messages, code comments. The Clinejection post-mortem is your playbook for what to test.

Common Mistakes to Avoid

I've watched dozens of teams adopt agentic DevOps practices over the past year. The same mistakes show up repeatedly, and every one of them is preventable.

Skipping the enforcement layer. This is mistake number one, and it's the most dangerous. Teams deploy AI workflows in Phase 2, see productivity gains, and assume they can skip Phase 4. Then an agent introduces a subtle architectural violation that doesn't surface for weeks — because it compiles, passes lint, and even passes the existing tests. Without pre-tool hooks enforcing structural rules, you're relying on AI to follow instructions it may not prioritize.
Treating AI output as trusted by default. Every AI-generated artifact — code, labels, comments, documentation — should be treated as untrusted input until verified. This isn't paranoia; it's the same principle that web security has operated on for decades. The moment you pipe AI output directly into a shell command or database query without validation, you've created an injection surface. Use safe-outputs declarations, detection jobs, and human review gates.
Not monitoring token costs. AI inference isn't free, and costs compound fast when you're running multiple agentic workflows on every PR, issue, and push event. I've seen teams burn through thousands of dollars in a single month because they deployed AI-powered code review on high-frequency monorepos without estimating the token volume. Set billing alerts, track cost-per-workflow-run, and optimize prompts for token efficiency. The actions/ai-inference action outputs token usage metadata — use it.
Deploying autonomous agents before measuring AI-assisted ones. The DORA data shows only 17% of teams use autonomous agents, but 90% use AI-assisted tools. There's wisdom in that gap. Start with AI that suggests (code review comments, failure analysis, coverage reports) before deploying AI that acts (auto-fixing, auto-merging, auto-deploying). The suggestion phase builds institutional knowledge about where AI excels and where it hallucinates — knowledge you need before handing it the keys.
Writing hookflows but never testing them. A hookflow that doesn't fire on violation is worse than no hookflow at all — it creates a false sense of security. Every enforcement rule needs a corresponding test that deliberately triggers it and confirms the block. Run gh hookflow validate in CI, and include red-team scenarios in your test suite. I covered validation patterns in my article on building cryptographic approval gates.
Using one monolithic agent instead of many focused ones. The pattern that works is a fleet of small, scoped workflows — one for triage, one for docs, one for test improvement — each with minimal permissions and tight safe-outputs. A single agent with broad access and a do-everything prompt is the AI equivalent of a god prompt monolith. Decompose, constrain, and specialize.
Ignoring the AI amplification effect on weak foundations. The 2025 DORA Report found a 7.2% drop in delivery stability for teams with weak foundations that adopted AI. If your tests are unreliable, your deploys are manual, or your incident response is ad-hoc — AI will amplify those problems, not fix them. Shore up the foundation first. Phase 1 exists for a reason.

Tool Ecosystem Reference

Here's a compact reference of the key tools across the agentic DevOps stack. I've organized them by the layer where they primarily operate, with maturity indicators so you know what's production-ready versus what's still experimental.

Maturity levels: 🟢 GA (production-ready) · 🟡 Preview (usable with caveats) · 🔵 Open Source (community-maintained)

Platform & Runtime

Tool	Description	Maturity
GitHub Actions	CI/CD automation platform — the backbone everything else runs on	🟢 GA
GitHub Agentic Workflows (`gh-aw`)	Markdown-authored AI automations that run coding agents inside Actions	🟡 Preview
GitHub Copilot Coding Agent	Autonomous agent that writes code, creates PRs, and iterates on review feedback	🟡 Preview
GitHub Models	Model catalog for accessing AI models directly from GitHub	🟢 GA

AI Integration & Scripting

Tool	Description	Maturity
`actions/ai-inference`	GitHub Action for calling AI models inside workflows with inline or file-based prompts	🟡 Preview
GenAIScript	Microsoft's open-source scripting framework for composable LLM-powered automations	🔵 Open Source
`gh models`	CLI extension for model inference, REPL debugging, and prompt evaluations	🟢 GA
GitHub Copilot SDK	Build Copilot-powered agents into any application	🟡 Preview

Governance & Enforcement

Tool	Description	Maturity
`gh-hookflow`	Pre-tool-use enforcement hooks for AI agents using GitHub Actions YAML syntax	🔵 Open Source
`safe-outputs`	Declarative write constraints in `gh-aw` — agents are read-only unless explicitly granted output types	🟡 Preview
MCP Gateway	Protocol for mediating tool access between AI agents and external services	🟡 Preview

Observability & Measurement

Tool	Description	Maturity
DORA Metrics	Four key metrics for software delivery performance — deployment frequency, lead time, change failure rate, MTTR	🟢 GA
`gh models eval`	CLI command for running prompt evaluations with scoring and custom judges	🟢 GA

Security & Supply Chain

Tool	Description	Maturity
GitHub Advanced Security	Code scanning, secret scanning, dependency review — your Pillar 3 security baseline	🟢 GA
Copilot Autofix	AI-generated fix suggestions for code scanning alerts	🟢 GA
npm provenance	Supply chain attestation for published packages — verifiable build origins	🟢 GA

My recommendation: Start with actions/ai-inference (low barrier, read-only), graduate to gh-aw for event-driven automation, and install gh-hookflow the moment any agent writes code. That sequence — observe, automate, enforce — mirrors the roadmap above and matches what I've seen work across teams adopting agentic DevOps patterns.

Where We Go From Here

What I've laid out in this guide isn't a five-year prediction — it's a snapshot of what's happening right now. Continuous AI is the first glimpse of how DevOps as an entire discipline is evolving. Not a feature bolted onto existing pipelines, but a fundamental expansion of what DevOps means and who practices it.

The numbers leave no room for ambiguity. 90% of developers already use AI in their workflows. DORA renamed their flagship report around AI. GitHub shipped Agentic Workflows in technical preview. Gartner projects 90% enterprise adoption by 2028. This isn't future talk — it's present tense.

New roles are opening up that didn't exist 18 months ago: Continuous AI Engineer, Agentic DevOps Context Engineer, Agent Governance Architect. And here's what I want every DevOps practitioner reading this to internalize: just because "agentic development" has "development" in the name doesn't mean it's a developer-only discipline. DevOps engineers think in systems, pipelines, governance, and observability. That's exactly the skill set this new era demands. You aren't being replaced — you're being promoted.

If you take one action after reading this, make it this: take a hard look at GitHub Agentic Workflows. Deploy an issue triage workflow. Read the hands-on guide. Study how safe-outputs, detection jobs, and Markdown-authored agents work. It's the most concrete implementation of where all of this is heading — and it's available today, not someday.

The teams that move now will define the standards. The teams that wait will inherit someone else's.

Build your enforcement layer. Deploy your first agent. Own the governance. The pipeline was always yours — now it's time to make it intelligent.

Azure Weekly: GPT-5.5 Lands in Foundry, MCP Comes to Copilot Studio

Hector Flores — Wed, 06 May 2026 16:04:19 +0000

The Frontier Model Arrives

OpenAI's GPT-5.5 is now generally available in Microsoft Foundry, and this isn't just another incremental model release. GPT-5.5 represents a clear evolution from "smart chatbot" to "production agent"—built specifically for sustained, multi-step professional work where the cost of imprecision is high.

The improvements matter for anyone building agentic systems. Better computer-use accuracy means fewer hallucinated UI actions. Deeper long-context reasoning means agents can hold architectural intent across large codebases. Token efficiency means lower costs at scale. GPT-5.5 Pro extends this further for the most complex enterprise workflows, though at a premium: $30/M input tokens and $180/M output tokens versus GPT-5.5's $5 and $30 respectively.

But here's what actually matters: Microsoft Foundry is positioning itself as the operating system for agents at scale. The blog post makes this explicit—you can define agents in YAML, LangGraph, Claude Agent SDK, OpenAI Agents SDK, GitHub Copilot SDK, or Microsoft Agent Framework, and Foundry Agent Service runs them all with isolated sandboxes, persistent filesystems, distinct Entra identities, and scale-to-zero pricing. That's the infrastructure play that makes frontier models actually operationalizable.

MCP Arrives in Copilot Studio

Speaking of infrastructure plays, Copilot Studio is adding Model Context Protocol (MCP) support in public preview this month (May 2026), with general availability planned for October.

If you've been following the agent ecosystem, you know MCP is Anthropic's open protocol for connecting AI systems to data sources and tools. It's becoming the standard way to extend agents without building bespoke connectors for every integration. With MCP in Copilot Studio, you can point agent workflows at any MCP-compliant server—proprietary systems, dynamic knowledge sources, custom actions—and they'll discover and invoke tools with structured inputs and outputs.

This is a smart move. Instead of Microsoft building walled-garden integrations, they're embracing an emerging standard that already has ecosystem momentum. The same MCP server works across multiple agents and workflows, reducing duplication and accelerating extensibility while keeping workflow governance intact.

For context, I wrote about how GitHub Copilot SDK enables agents for every app—MCP support in Copilot Studio follows the same pattern of making agent capabilities composable and reusable across platforms.

Databricks Goes Agent-First

Azure Databricks shipped several updates this month that signal where data engineering workflows are headed. The Lakeflow Pipelines Editor is now GA, and it's explicitly built as an "agent-first experience" with Genie Code integrated directly into the pipeline development flow.

You write ETL pipelines with AI assistance side-by-side with the pipeline graph and metrics. The GitHub connector for Lakeflow Connect hit beta, meaning you can now ingest GitHub data directly into Databricks. This matters if you're building data pipelines that pull from code repositories—issue tracking, PR metadata, code metrics, contributor activity.

Databricks Runtime 18.2 went GA as well, and they added native data profiling for notebook result tables—small quality-of-life improvements that reduce context switching.

Storage Gets Smarter

Azure Blob and Data Lake Storage's smart tier is now generally available. This is a fully managed auto-tiering capability that continuously optimizes data placement based on access patterns without operational overhead.

Since the public preview at Ignite 2025, over 50% of smart-tier-managed capacity has automatically moved to cooler (cheaper) tiers. You pay standard hot, cool, and cold capacity rates with no additional charges for tier transitions, early deletion, or retrieval. The only extra cost is a monitoring fee for orchestration.

If you're managing large data estates and still manually lifecycle-managing blobs, smart tier is a no-brainer. Set it and forget it.

Reserved VM Instances: Act Before July 1

One pricing change to watch: Microsoft is discontinuing new purchases and renewals of Reserved VM Instances for select VM series starting July 1, 2026.

One-year RIs are ending for Av2, Amv2, Bv1, D, Ds, Dv2, Dsv2, F, Fs, Fsv2, G, Gs, Ls, and Lsv2. Both one-year and three-year RIs are ending for Dv3, Dsv3, Ev3, and Esv3. If you have workloads on these series and don't take action before July 1, you'll be billed at pay-as-you-go rates once your RI expires—even if auto-renew is enabled.

Existing RIs will honor their full term, but new purchases are done. This is Microsoft nudging customers toward newer VM families and potentially Azure Savings Plans, which offer more flexibility across compute services.

The Bottom Line

This week's Azure updates reveal a consistent direction: agent infrastructure is becoming a first-class platform concern. GPT-5.5 in Foundry with hosted agent services, MCP support in Copilot Studio, and agent-first tooling in Databricks all point to the same shift—AI capabilities are moving from experimental notebooks to production systems with real governance, identity, and scale requirements.

The storage and pricing changes are table stakes, but the agent story is where Azure is making its biggest bet. If you're building agentic systems, the infrastructure gap between "demo" and "production" just got a lot smaller. Foundry Agent Service, MCP extensibility, and isolated agent execution with Entra identities are the primitives that actually matter when you're running thousands of agents, not dozens.

The race is on to see which cloud provider builds the best operating system for agentic AI. This week, Azure shipped real infrastructure.

The Agentic Development Maturity Curve: Why Experts Return to Simplicity

Hector Flores — Wed, 06 May 2026 12:04:38 +0000

The Graph Nobody Draws

There's a pattern I keep seeing in agentic development that almost nobody talks about. It looks like an inverted U:

Complexity
    │
    │         ╭──────╮
    │        ╱        ╲
    │       ╱          ╲
    │      ╱            ╲
    │     ╱              ╲
    │    ╱                ╲
    │───╱                  ╲───
    │
    └───────────────────────────→ Maturity
       Stage 1    Stage 2    Stage 3
       "Build me   "Multi-agent  "Just talk
        an app"    orchestration"  to it"

Stage 1: Low maturity, low complexity. You throw one big prompt at an agent. "Build me an app." That's what you think agentic coding is.

Stage 2: Mid maturity, HIGH complexity. Multiple agents, hooks, hookflows, governance patterns, test-driven development with agents, skill extraction, orchestration layers. Everything is meticulously organized.

Stage 3: High maturity, LOW complexity. You go back to simple prompts and one agent. That's all you need. Simple planning, simple executing, proper steering.

I saw this concept articulated perfectly in Peter Steinberger's conversation with Lex Fridman about agentic engineering. Steinberger — creator of OpenClaw — described essentially this same curve. His blog post title says it all: "Just Talk To It."

It hit me because I've lived all three stages. And the insight that changed my workflow isn't a new framework or tool — it's the realization that the simplicity on the other side of complexity is earned, not lazy.

Stage 1: The God Prompt Era

When I started with agentic coding, I did what everyone does. I tried to spec out an entire application in one massive prompt. 2,000 words of requirements, architecture decisions, and implementation details — all jammed into a single message.

I've written about this anti-pattern before. The god prompt is the new monolith. It felt productive because you were being "thorough." In reality, you were overwhelming the agent with conflicting instructions and getting mediocre results.

Most developers stay here for a while. They conclude that "AI coding doesn't really work" and go back to writing everything by hand. They never see what's on the other side.

Stage 2: The Complexity Peak

Once I got past the god prompt phase, I went deep. I'm talking:

Test-driven development with agents — writing comprehensive test suites first, then letting agents implement against them. I wrote about this in Tests Are Everything in Agentic AI and it works incredibly well for ensuring correctness.
Agent hooks — filesystem-level governance that intercepts agent operations before they execute. I built hook-based systems to enforce architecture boundaries, mock policies, and layer rules.
Hookflows — multi-step validation pipelines that chain hooks together for complex governance. Pre-commit checks, lint enforcement, automated review gates.
Multi-agent orchestration — dedicated agents for different domains, each with their own memory, skills, and communication protocols. I open-sourced the home assistant that runs my family's entire life: 17+ agents, 16 extensions, 15 cron jobs, all coordinated through an agent mesh.
The Research → Plan → Implement pipeline — a structured anti-vibe-coding workflow with explicit human review gates between phases.
Skill extraction — identifying repeatable agent capabilities and extracting them into portable, testable, composable skills that any agent can invoke.

Every one of these techniques is valid. They solve real problems. TDD catches hallucinations. Hooks prevent architecture violations. Multi-agent patterns enable genuine specialization. I stand by all of it.

But here's what nobody tells you: this is the peak of the complexity curve, not the destination.

Stage 3: Earned Simplicity

Here's where I am now for actual software development work: I open GitHub Copilot, write a simple prompt, and let the agent plan and execute. That's it.

No elaborate hook chains. No multi-agent orchestration for a single feature. No 47-step governance pipeline. Just:

Clear, simple prompt — what I want, why, and any critical constraints
Let the agent plan — review its approach, steer if needed
Let it execute — monitor, course-correct, done

Peter Steinberger describes the same thing. He runs 3–8 parallel agent instances with simple prompts — the principle holds regardless of which tool you choose. No complex hook systems. He thinks about "blast radius" — how big the change is — and adjusts his prompts accordingly. When something goes sideways, he just stops and says "what's the status."

The key insight: this simplicity only works because of what you learned in Stage 2. You internalized the mental models. You know:

When to break a task into smaller pieces (blast radius thinking)
How to write prompts that prevent common failure modes
When to stop the agent and course-correct vs. letting it finish
What "good enough" context looks like without over-engineering it

This is what Oliver Wendell Holmes Jr. famously expressed: "I would not give a fig for the simplicity on this side of complexity, but I would give my life for the simplicity on the other side of complexity."

The Crucial Distinction: Form Factor Matters

One thing I need to be clear about: there are legitimate use cases for Stage 2 complexity. My home assistant platform — with its multi-agent orchestration, cron jobs, and governance layers — is genuinely complex. And it should be. It's a persistent assistant managing a family's daily life. Different form factor, different requirements.

But for software development workflows — writing features, fixing bugs, building applications — high maturity means returning to simplicity. The agent is your pair programmer, not a Rube Goldberg machine.

The same principle applies in traditional software engineering. Junior developers write complex code because they don't know better. Senior developers write simple code because they've earned it. Context engineering matters more than prompt engineering — knowing what to feed the agent is more valuable than knowing how to construct elaborate instruction sets.

Where Are You on the Curve?

Here's a quick diagnostic:

You're in Stage 1 if:

You write one massive prompt and expect a complete application
You think "AI can't code" because your mega-prompts produce garbage
You haven't tried iterative agent steering — just fire-and-forget

You're in Stage 2 if:

You have elaborate governance frameworks around your agents
You spend more time configuring agent infrastructure than building features
You feel like you need 5+ agents and hooks for every project
Your agent workflow has more moving parts than the code it produces

You're in Stage 3 if:

You use hooks sparingly — to augment, not as the core workflow
You trust simple prompts because you know how to write them well
You think in terms of "blast radius" before deciding task granularity
Your agent interactions look like conversations with a skilled colleague
You only reach for complex orchestration when the problem domain demands it

How to Accelerate Through Stage 2

You can't skip Stage 2, but you can move through it faster:

Build one complex system end-to-end. TDD with agents, hooks, multi-agent — learn what each technique actually solves. Then you'll know when you don't need them.
Study people at Stage 3. Watch how Steinberger works. Notice what's absent from their workflows. The tools they don't use tell you more than the tools they do.
Audit your complexity regularly. Ask: "Is this hook solving a real problem, or am I over-engineering because I can?" If your governance layer is more complex than your application logic, you've over-indexed.
Plan before you implement. The anti-vibe-coding workflow still applies — but at Stage 3, the "plan" is a 3-sentence description, not a 40-page spec. The discipline is internalized.
Let the agent think. Plan mode exists for a reason. Simple prompt + agent planning = surprisingly good results without elaborate scaffolding.

The Bottom Line

The maturity curve for agentic development isn't a straight line toward more complexity. It's an inverted U. The developers getting the most out of AI agents today aren't the ones with the most elaborate orchestration systems — they're the ones who went through that phase and came out the other side.

Mastery in agentic development looks deceptively like what beginners do: simple prompts, one agent, clear communication. The difference is invisible — it lives in the mental models, the prompt intuition, and the earned judgment about when complexity actually serves you.

If you're deep in Stage 2 right now, building hooks and multi-agent systems and governance frameworks — that's good. You're learning. Just don't mistake the peak of complexity for the summit of mastery. The summit is simpler than you think.

GitHub Weekly: Security Gets Real with Code-to-Cloud Visibility

Hector Flores — Tue, 05 May 2026 18:04:05 +0000

The Week Security Got Runtime Context

This week GitHub shipped something I didn't expect to see this fast: code-to-cloud correlation at GA. Microsoft Defender for Cloud integration is now generally available, connecting your source code to what's actually running in production. That's not just another security dashboard—it's runtime-aware filtering across GitHub Advanced Security alerts.

But the bigger news for most teams is billing. Starting June 1, GitHub Copilot code review will consume Actions minutes from your org's plan. If you've been treating code review as "free" beyond your Copilot subscription, that assumption just expired.

Code-to-Cloud Correlation: What Actually Shipped

The Microsoft Defender integration does something genuinely useful: it correlates container images running in your cloud environments back to the GitHub repos that built them. Defender uses signals like GitHub artifact attestations plus its own runtime intelligence to map deployed workloads to source code.

Once that link exists, you get runtime context on your security alerts. Is this vulnerable dependency actually deployed? Is it internet-exposed? Processing sensitive data? These aren't hypothetical questions anymore—the answers show up as filters in your GitHub Advanced Security alert views:

has:deployment — focus on what's actually running
runtime-risk:internet-exposed — prioritize what attackers can reach
runtime-risk:sensitive-data — protect what actually matters

This applies across code scanning, Dependabot, and security campaigns. I've written before about how context engineering drives AI productivity—this is context engineering for security teams. The alert noise drops when you can filter by "deployed and exposed" vs "in the codebase somewhere."

The Actions Minutes Reality Check

Late last month GitHub announced what many teams missed: Copilot code review will start consuming GitHub Actions minutes on June 1. This applies to private repos only—public repos stay free—but if you're on Copilot Pro, Business, or Enterprise and running code reviews on private code, your Actions budget just got tighter.

The architecture behind this makes sense: Copilot code review runs on agentic tool-calling infrastructure that executes on GitHub Actions runners. Those runners cost minutes. A typical code review consumes 2-6 Actions minutes; heavy reviews (large diffs, full context) can hit 15 minutes.

What you need to do before June 1:

Check your current Actions usage in billing settings—do you have headroom?
Review your spending limits. Set budgets if you haven't already.
Decide if larger runners or self-hosted runners make sense. Self-hosted runners don't consume Actions minutes from your plan.
Share this with your billing admin. This isn't a trivial line item if your team merges 50+ PRs a week.

GitHub also reminded everyone that Copilot usage is moving to usage-based billing with AI Credits on June 1. Code review will be billed in two ways: AI Credits for token consumption, plus Actions minutes for the infrastructure. If you're still on an annual plan, model multipliers are changing June 1 as well. The billing preview tools went live in early May—use them.

Cloud Agent Gets 20% Faster (Again)

GitHub squeezed another 20% startup improvement out of Copilot cloud agent last week, thanks to Actions custom images. The agent now spins up faster when you assign it an issue, start a task, or mention @copilot in a PR.

This builds on the 50% improvement shipped in March. The feedback loop between "I need the agent to do this" and "the agent is actually working on it" matters more than most teams realize. If it takes 90 seconds for Copilot to start, developers context-switch. At 20 seconds, they wait. Speed compounds.

The mechanism is straightforward: GitHub prebuilds the runner environment with custom images, cutting down on package installs and dependency downloads. If you're running cloud agent tasks frequently, this adds up fast.

Model Deprecation: GPT-5.2 and GPT-5.2-Codex Exit June 1

GitHub announced that GPT-5.2 and GPT-5.2-Codex are being deprecated across all Copilot experiences on June 1. The exceptions: GPT-5.2-Codex stays available in Copilot Code Review.

Suggested alternatives:

GPT-5.2 → GPT-5.5 (already GA)
GPT-5.2-Codex → GPT-5.3-Codex

If you're a Copilot Enterprise admin, check your model policies now. Users need access enabled for the replacement models, or they'll lose access when the cutover happens. No action is required to remove the deprecated models—they'll just disappear from the picker on June 1.

This is part of the broader model rotation GitHub's been doing. GPT-5.5 hit GA last month. The shift toward usage-based billing with model-specific credit multipliers means the model you pick directly affects your bill. Frontier models consume more credits per interaction than lightweight models. If you're burning through your included usage, start routing routine tasks to cheaper models.

The Bottom Line

The Defender for Cloud integration signals where GitHub is heading: security tools that understand what's actually deployed, not just what exists in your repo. That's the kind of context filtering that makes security campaigns actionable instead of aspirational.

But the billing changes are what most teams will feel first. Copilot code review consuming Actions minutes is a real cost increase for orgs with tight Actions budgets. Self-hosted runners or larger runners with custom images might be worth the setup cost if you're running hundreds of reviews a month.

June 1 is shaping up to be a significant transition date: usage-based billing goes live, model deprecations take effect, code review starts charging Actions minutes, and model multipliers change for annual plan holders. If you haven't audited your Copilot usage and Actions consumption yet, this week is the time.

GitHub's making the agent infrastructure faster and more context-aware. But they're also making it clear that agentic workloads aren't free—they're compute, and compute costs money.

I Taught My AI Agent to Restart Itself

Hector Flores — Tue, 05 May 2026 13:13:59 +0000

The Moment Your Agent Outgrows Its Own Runtime

Here's a scenario that will sound familiar if you're building autonomous agents with GitHub Copilot CLI: your orchestrator agent creates a brand-new custom agent — writes the .github/agents/budget-review.agent.md file, commits it, and then tries to delegate work to it via the task tool. Except... it can't. The new agent doesn't exist yet, at least not in the running session's registry.

The task tool's agent_type list is frozen at session start. Your new agent won't be discoverable until a fresh session begins. And there's no built-in way to restart from within the session.

So you close the terminal. Reopen it. Resume. It works now. But if your agent platform does this ten times a day — creating specialized agents on the fly based on family needs, work context, or content pipelines — that manual restart becomes the single biggest bottleneck in your entire autonomous workflow.

I solved this with copilot-self-restart, an extension that gives any agent the ability to kill its own runtime and spawn a fresh session — with full conversation resume support.

What the Extension Does

The extension registers a single tool called restart_session that orchestrates a controlled shutdown and respawn sequence:

Writes a temporary PowerShell script containing the kill-wait-relaunch logic
Spawns a fully independent PowerShell window using execSync → Start-Process
That new window kills the current Copilot runtime via PID
Waits for cleanup (file handle release, graceful shutdown)
Launches a fresh Copilot CLI session with --resume to preserve conversation context

The result: the agent says "restarting," the current terminal dies, and a new window spawns with a fully resumed session — same conversation, fresh registry. New agents, new extensions, clean context — all without human intervention.

// The core pattern in extension.mjs
execSync(
  `pwsh -NoProfile -Command "Start-Process -FilePath pwsh ` +
  `-ArgumentList @('-NoProfile','-NoExit','-File','${tmpScript}') ` +
  `-WorkingDirectory '${cwd}'"`,
  { cwd, timeout: 5000, windowsHide: false }
);

The Windows Process Tree Trap

This extension took me two days to build. The code is ~100 lines. The problem was discovering why the obvious approach doesn't work on Windows.

Attempt 1: child_process.spawn() with detached: true

This is what every Node.js tutorial suggests for creating independent child processes. On Linux, it works beautifully. On Windows, it creates a headless process that cannot spawn visible child windows. The spawned process inherits the console's window station but can't create new independent ones.

What this means in practice: the "new" Copilot CLI session launches invisibly. You can't see it. You can't interact with it. It's running headless in some orphaned process tree. Useless.

Attempt 2: spawn + CREATE_NEW_CONSOLE

Node.js does expose a windowsHide: false option and various stdio configurations. None of them actually create a visible, interactive terminal window that outlives the parent process. The child is still bound to the parent's window station.

The Working Pattern: execSync → Start-Process

The solution is to delegate window creation entirely to PowerShell's native Start-Process cmdlet. By calling execSync with a pwsh -Command "Start-Process ..." invocation, you create a fully independent visible window that outlives the calling Node.js process — a new PowerShell terminal with no parent-child relationship to the original session.

# The temp script that runs in the new window:
Stop-Process -Id 1234 -Force -ErrorAction SilentlyContinue
Start-Sleep -Seconds 3
& 'restart-copilot.ps1' -Folder 'C:\Repos\myproject' -SessionId 'abc-123'
Remove-Item -LiteralPath 'tempscript.ps1' -Force

The new window kills the old runtime (which also kills the extension that created it), waits for cleanup, and launches a fresh session. The temporary script self-destructs after execution. Clean.

Architecture: Two Files, Zero Dependencies

The extension is deliberately minimal:

extension.mjs — Joins the Copilot CLI session via @github/copilot-sdk, registers the restart_session tool, and handles the spawn logic. Uses process.ppid to identify the runtime's PID (the extension's parent process). Writes a temp .ps1 script to avoid PowerShell quoting hell, then fires-and-forgets via execSync.

restart-copilot.ps1 — Resolves the working directory, ensures the folder is trusted in ~/.copilot/config.json (so the CLI doesn't prompt for trust approval), and launches the new session with --add-dir, --yolo, --autopilot, and optionally --resume=<sessionId>.

The restart_session tool accepts two parameters:

Parameter	Default	Purpose
`reason`	—	Logged for debugging ("New agent created: budget-review")
`new_session`	`false`	If true, skips `--resume` for a clean slate

Why Not Just `process.exit()`?

I got this question immediately. Calling process.exit() from an extension kills the extension process, not the Copilot runtime. The runtime detects the extension died and either restarts it or continues without it — neither results in a session restart. You need to kill the runtime's actual PID, which is process.ppid from the extension's perspective.

The Safe Restart Workflow

Raw restart is dangerous. If background agents are running tasks — writing files, making API calls, mid-computation — killing the runtime means their work is lost with no recovery. So this extension ships with a companion safe-restart skill that wraps the restart in pre-flight checks:

list_agents() — verify no background agents are running
Wait for active agents — read_agent(id, wait=true) blocks until completion
Close idle agents — graceful shutdown via write_agent() + wait
Save all work — commit pending changes, update memory files
Notify the user — "Restarting to discover new agent: budget-review"
restart_session(reason="...", new_session=true)
Post-restart verification — confirm the new agent appears in task tool, run a smoke test delegation

Note: the safe-restart workflow uses new_session=true because after agent creation you want a clean registry refresh. Normal restarts (recovering from bloated context) use new_session=false to resume the existing conversation.

This workflow is codified as a reusable skill — a procedural guide that any agent can invoke when it needs to safely restart.

Why This Matters: Self-Modifying Agent Platforms

This extension isn't really about restarting a terminal. It's about agent lifecycle management — the ability for an autonomous system to modify its own runtime topology without human intervention.

In my home assistant platform, agents create other agents dynamically. A realtor-team agent might spin up a credit-coach agent. A content pipeline might create a specialized editor agent for a new content format. These agents need to be discoverable immediately — not after I manually restart a terminal.

Combined with the agent mesh (which enables cross-session communication), this creates an infrastructure layer where agents can:

Create new agents → self-restart to discover them
Communicate across sessions → via the mesh's SQLite IPC
Modify their own extensions → restart to load new tools
Recover from bloated context → resume with a clean window

This is what self-healing infrastructure looks like at the agent platform level. The system doesn't just detect problems — it restructures itself to solve them.

Getting Started

Install per-project (recommended):

New-Item -ItemType Directory -Path .github\extensions\self-restart -Force
# Copy extension.mjs and restart-copilot.ps1 into that directory

Or install user-level for all projects:

New-Item -ItemType Directory -Path "$HOME\.copilot\extensions\self-restart" -Force
# Copy both files there

The full source, architecture docs, and the safe-restart skill template are on GitHub: htekdev/copilot-self-restart.

The Bottom Line

The Copilot CLI extension SDK is deceptively powerful. With one file and zero external dependencies, you can give agents the ability to restart their own runtime — something that sounds trivial until you hit the Windows process tree trap and realize why nobody else has shipped this.

If you're building agent platforms where agents create other agents, this is table-stakes infrastructure. The alternative is manual restarts, which defeats the entire point of autonomous operation. Your agents should be able to evolve their own capabilities without waiting for a human to close a terminal.

The pattern — execSync → Start-Process → kill parent → relaunch — is weird. It's counterintuitive. And it's the only thing that works on Windows for creating visible, interactive, independent process trees from Node.js. Sometimes the best engineering is just finding the one path through a maze of platform limitations.

Visual Studio Weekly: Agents Go Cloud-Native and Cross-Project

Hector Flores — Mon, 04 May 2026 18:04:20 +0000

Last week, Visual Studio shipped its April update (18.5), and the theme is clear: the IDE is evolving from a text editor with AI suggestions into an agent orchestrator. Cloud agents now launch directly from the IDE, custom agents travel with you across projects, and IntelliSense finally stops fighting Copilot for screen space. If you've been waiting for Visual Studio to feel less like "Copilot bolted on" and more like "AI-first tooling," this is the update that changes the trajectory.

Cloud Agents: Offload Work Without Leaving the IDE

The headline feature is cloud agent integration. Previously, if you wanted to use GitHub's cloud coding agent, you opened a browser, navigated to your repo, and started a session. Now you do it directly from Visual Studio.

Here's the workflow: Open Copilot Chat, select Cloud from the agent picker, and describe the task. The cloud agent asks permission to create a GitHub issue, then spins up a remote session on GitHub's infrastructure to implement the fix and open a pull request. You can close Visual Studio entirely and come back later—when the PR is ready, you get a notification with options to view or open in browser.

From the April update announcement:

Cloud agents run on remote infrastructure for scalable, isolated execution, and you can now start new sessions directly from Visual Studio. This is a different way of working that frees you up to focus on the parts of your project that need your full attention.

Why this matters: Cloud agents are expensive to run. They require compute, sandboxing, and orchestration. By integrating them directly into Visual Studio, Microsoft is betting that developers want to delegate lower-value tasks (bug fixes, boilerplate, dependency updates) while staying focused on architecture and complex features. This is the future of agentic development—not replacing developers, but letting them focus on the work that actually requires human judgment.

The current implementation is powered by Copilot's coding agent and requires a GitHub repo with permissions to create issues. It's early, but the direction is right. I'm watching to see how this evolves when multiple cloud agents compete for the same task, or when agents need to coordinate across repos.

User-Level Custom Agents: Your Workflow, Every Project

Last month, Visual Studio introduced custom agents via .agent.md files in your repository. This update extends that with user-level agents stored in %USERPROFILE%/.github/agents/ by default. These agents travel with you across all projects.

Why this is a big deal: Repository-level agents are great for team conventions—"run our linter," "follow our API guidelines," "query our internal docs." But user-level agents are for your workflow. Maybe you always want a "security review" agent that checks for credential leaks. Or a "migration helper" that converts legacy patterns to modern equivalents. Or a "performance profiler" that suggests optimizations based on your coding patterns.

The GitHub Changelog confirms:

User-level agents are stored in %USERPROFILE%/.github/agents/ by default. You can change this location in Tools > Options > GitHub > Copilot > Copilot Chat > Custom agents user directory.

Creating new agents is easier now too—click the + button in the agent picker and follow the prompts. Everything you could do with repository-based agents still works: workspace awareness, code understanding, tools, model selection, and MCP connections to external knowledge sources like internal documentation, APIs, and databases.

The community is already sharing agent configurations on the awesome-copilot repository. I expect we'll see a marketplace for custom agents within six months—something like VS Code extensions, but for agentic workflows.

IntelliSense vs. Copilot: The Priority Fight Is Over

If you've used Visual Studio with Copilot, you've experienced this: IntelliSense pops up with a completion list, Copilot shows a multi-line suggestion, and suddenly you're trying to parse two overlapping UIs. It's cognitively noisy, and it slows you down.

The April update fixes this. When IntelliSense is active, Visual Studio temporarily suppresses Copilot completions. After you dismiss or commit the IntelliSense selection, Copilot resumes automatically. This behavior is enabled by default—just update and code as you normally do.

From the Visual Studio blog:

When IntelliSense is active, Visual Studio temporarily suppresses Copilot completions so you can focus on your current selection.

This seems obvious in hindsight, but it took Microsoft 18+ months to ship. The reason? IntelliSense and Copilot run in different subsystems. IntelliSense is fast, synchronous, and language-server-backed. Copilot is async, model-driven, and latency-sensitive. Coordinating them without breaking either experience required real engineering work.

The result is subtle but meaningful. Your editor feels less like two tools competing for attention and more like one integrated experience. This is the kind of polish that doesn't show up in release notes but compounds over time.

C++ Gets Language-Aware Agent Tools (GA)

For C++ developers, the April update brings C++ Code Editing Tools for GitHub Copilot agent mode to general availability by default. These tools give Copilot language-aware navigation of your C++ codebase, including:

get_symbol_call_hierarchy — trace function calls across translation units
get_symbol_class_hierarchy — map class inheritance and usage relationships

Previously, when you asked Copilot to refactor a C++ function, it guessed from text patterns. Now it sees your class hierarchy and call graph. The difference is like asking someone to reorganize a warehouse by looking at photos versus giving them a floor plan and inventory system.

This only works with AI models that support tool-calling (check the model comparison page for compatibility). If you work with large C++ codebases, these tools make a real difference—especially for cross-file refactors that span multiple headers and implementation files.

Customizable Copilot Keyboard Shortcuts

Finally, a quality-of-life improvement that power users will appreciate: you can now customize the keyboard shortcuts for accepting Copilot inline suggestions. Want to change the key for accepting a full suggestion, the next word, or the next line? It's all configurable in Tools > Options > Environment > Keyboard.

The relevant commands are:

Edit.AcceptSuggestion — accept the full suggestion
Edit.AcceptNextWordInSuggestion — accept just the next word
Edit.AcceptNextLineInSuggestion — accept just the next line

Your new shortcut appears throughout the editor hint bar, so you always know which key to press. Small detail, but this is the kind of flexibility that makes tools feel like yours instead of someone else's.

The Bottom Line

Visual Studio's April update is about infrastructure for agentic workflows. Cloud agents handle background tasks on remote infrastructure. User-level custom agents codify your personal workflow. IntelliSense and Copilot coordinate instead of competing. C++ agents have semantic understanding, not just text matching.

None of these features are revolutionary on their own. But together, they signal a shift: Visual Studio is becoming a platform for orchestrating multiple AI agents—some running locally, some in the cloud, some built by Microsoft, some built by you. That's the future of IDEs. Not one AI assistant. An ecosystem of specialized agents, each doing what it's good at, all coordinated through a single interface.

If you're still on Visual Studio 2022 stable, consider trying Visual Studio 2026 to experience these features. The pace of AI integration is accelerating, and the monthly release cadence Microsoft announced in the 17.14 launch is starting to show results. The gap between "AI suggestions" and "AI orchestration" is closing fast.

Copilot CLI Weekly: Headless OAuth, Background Tasks, and /research Overhaul

Hector Flores — Fri, 01 May 2026 19:33:49 +0000

Headless OAuth for MCP Servers

The Copilot CLI v1.0.40 release shipped today with a feature that matters if you're running the CLI on remote servers, in CI, or anywhere you don't have a browser: client_credentials OAuth grant type support for MCP servers. This enables fully headless authentication without needing to spawn a browser for the OAuth flow.

Before this, connecting an MCP server that required OAuth meant you needed an interactive browser session to complete the authorization flow. That's fine on your laptop. It's not fine on a headless build server, inside a container, or over SSH where you don't have X forwarding. The typical workaround was to pre-authenticate elsewhere and copy tokens manually, or skip OAuth-protected MCP servers entirely on those environments.

Now MCP servers can use the client_credentials grant type — a machine-to-machine OAuth flow that exchanges a client ID and secret for an access token without user interaction. This is the same flow services use to talk to other services. If your MCP server supports it (check its config), the CLI can now authenticate in environments with no browser, no display, and no user present.

This extends the reach of MCP-powered workflows. My GitHub Agentic Workflows setup runs entirely in GitHub Actions. Adding an MCP server that previously required OAuth meant either hacking around it or not using it. That limitation is gone.

Background Tasks with Ctrl+X → B

v1.0.40 introduces a keybinding I've wanted for months: Ctrl+X → B to move the current running task or shell command to the background. Press it while a long-running command is executing and it detaches, freeing your prompt while the task continues. You can queue another task, send more messages, or switch contexts without killing the running process.

This is particularly useful when you've asked the agent to run something that takes longer than expected — a build, a test suite, a heavy search operation. Before, your options were to wait, cancel, or open a second CLI session. Now you background it and move on. The task keeps running. You see updates in the timeline. When it finishes, the output appears and you can review it.

The implementation is solid. Backgrounded tasks don't block new input. They continue streaming output to the timeline as they run. If you background multiple tasks, they all run concurrently. The statusline shows the count of active background tasks so you know what's still executing.

I've already used this a dozen times today. Run npm test, realize it's slow, background it, ask for a file edit, come back to the test results when they're done. It's the workflow I wanted.

/research Now Uses Orchestrator Agents

The /research command got a major architecture change in v1.0.40. Instead of a single-agent linear search, it now uses an orchestrator/subagent model for more thorough and reliable deep research results. The orchestrator breaks the research task into subtasks, dispatches subagents to handle each part, aggregates their findings, and synthesizes a final answer.

This addresses the biggest weakness of the old /research: incomplete coverage. When you asked it to research something complex, it would often latch onto the first good source it found and stop. The orchestrator approach forces broader exploration. Subagents work in parallel on different aspects of the query. The orchestrator ensures coverage before synthesizing.

I tested this on a question that previously gave shallow results: "Compare auth patterns in Next.js vs. Remix for server-rendered apps with session management." Old /research gave me a summary of Next.js auth middleware and called it done. New /research dispatched subagents to investigate Next.js patterns, Remix loader auth, session storage strategies, and then synthesized a comparison across the findings. The result was substantially more complete.

The tradeoff is latency. Orchestration adds overhead. For quick factual lookups, the old linear search was faster. For anything requiring synthesis across multiple dimensions, the new architecture is worth the wait.

Autopilot Continuation Limits

Autopilot mode — where the agent continues working autonomously until the task is complete — now has a default limit of 5 continuation messages (configurable with --max-autopilot-continues). This prevents runaway loops where the agent gets stuck in an unproductive cycle and burns through tokens without making progress.

Before this, autopilot would continue indefinitely until it reached a terminal state or hit a model-level token limit. That's fine when it's working. It's expensive and frustrating when it's not. I've had sessions where autopilot spent 15+ messages trying variations of the same failing approach because it couldn't detect the loop.

The new default stops after 5 continues. If the task isn't done, the agent reports its progress and returns control to you. You can assess, redirect, or let it continue with another --max-autopilot-continues invocation. This makes autopilot safer to use on ambiguous tasks where the agent might spiral.

If you're running autopilot in fully automated contexts (like my article automation workflows) and you know the task scope, you can raise the limit. The default is conservative by design.

Session History and /chronicle for All Users

Two features that were previously gated are now available to all users: session history and the /chronicle command. Session history records every message, tool call, and state change across your sessions. /chronicle generates a summary of a session's activity — what you asked for, what the agent did, what changed, and what the outcome was.

I use /chronicle at the end of long refactoring sessions to document what happened. It's particularly useful when handing off work or returning to a session after days away. Instead of reading through the full timeline to reconstruct context, /chronicle gives you a condensed narrative.

The fact that this is now available to all users means you can use it in team workflows without worrying about whether everyone has the right tier. If you're building agents that need audit trails or summaries of their own actions, /chronicle can provide that.

v1.0.39: ACP Extensions, Background Tasks, and Slash Commands

Three days before v1.0.40, v1.0.39 shipped with its own set of meaningful changes. If you're using the Agentic Client Protocol (ACP) to integrate the CLI with other editors (like Zed), you got:

Four new slash commands for ACP sessions: /compact, /context, /usage, and /env. These were previously CLI-only. Now they work when controlling the CLI via ACP, giving you the same introspection tools in any client.
Allow-all permission mode toggle: ACP clients can now programmatically enable or disable the allow-all permission mode via session configuration. This is useful for workflows that start restricted and need to escalate permissions midway through a task.

And the Ctrl+X → B background task feature actually shipped in v1.0.39. I mentioned it above under v1.0.40 because that's when I tested it extensively, but credit where due: v1.0.39 introduced the keybinding.

Secure-by-Default Prompt Mode

One change that impacts certain workflows: prompt mode (-p) now gates repo hooks and workspace MCP behind opt-in environment variables. Specifically, GITHUB_COPILOT_PROMPT_MODE_REPO_HOOKS and GITHUB_COPILOT_PROMPT_MODE_WORKSPACE_MCP. If those aren't set, repo hooks and workspace MCP servers don't load in prompt mode.

This is a security-by-default decision. Prompt mode is often used in scripting contexts where you're piping input directly to the CLI without interactive oversight. If that input is untrusted or comes from an external source, you don't want it triggering repo hooks or workspace MCP servers that might have privileged access.

If you're using prompt mode with repos that have hooks or workspace MCP servers, and you trust the input, set those env vars. If you're piping arbitrary input, leave them unset.

Polish Across the Board

The rest of v1.0.40 is dominated by UX polish and bug fixes. Highlights:

Smoother streaming: Assistant responses stream with better text chunking, reducing the "stutter" effect during long outputs.
Faster startup: Custom CA certificates load asynchronously, shaving noticeable time off CLI initialization in environments with custom certs.
Better session resume: The resume session picker no longer shows duplicate entries for Mission Control-backed sessions. Summaries display on a single line, truncated to fit the column width.
Improved remote context: Remote session statusline shows the remote working directory and branch instead of misleading local context.
MCP tool name sanitization: MCP tool names with dots or invalid characters are now sanitized correctly instead of causing tool call failures.

And one small but appreciated change: Ctrl+C and double-Esc now remove pending queued messages one at a time instead of all at once. If you've queued several messages and realize halfway through that the first one is wrong, you can selectively back out instead of losing the whole queue.

The Bottom Line

Two releases in one week. Headless OAuth unlocks MCP servers in CI and remote environments. Background tasks via Ctrl+X → B fix a major workflow friction point. The /research overhaul makes deep research actually useful. Autopilot limits prevent runaway loops. And the pile of UX polish removes a dozen small annoyances.

If you're running the CLI in headless environments, v1.0.40's OAuth support changes what's possible. If you're using /research for complex queries, the orchestrator model is a clear upgrade. And if you've ever been stuck waiting for a long task to finish before you can interact with the CLI again, Ctrl+X → B is the feature you didn't know you needed.

The pace of meaningful iteration continues. Next week might bring model updates, agent framework improvements, or more MCP tooling. The team is shipping fast. The CLI is getting better every week.

I Automated Work-Life Calendar Sync With Two AI Agents That Talk to Each Other

Hector Flores — Fri, 01 May 2026 14:40:06 +0000

The Two-Calendar Problem

Every developer with a day job and a personal life has two calendars. My work Outlook has team syncs, 1:1s, and planning meetings. My personal Google Calendar has doctor appointments, NICU visits for my premature twins, kid pickups, recording sessions, and the occasional oil change.

The problem isn't having two calendars. The problem is that nobody at work can see the personal one. So a coworker schedules a meeting at 10 AM on Tuesday — right on top of my wife's OB appointment. I catch it at 9:45, scramble to decline, and look unprofessional. Or worse, I don't catch it.

The manual fix is tedious: open Google Calendar, find the event, open Outlook, create a matching "Out of Office" block, repeat for every new event, every change, every cancellation. I was doing this three or four times a week. Then I stopped doing it because humans are bad at repetitive cross-system data entry. Then I missed more meetings.

So I built a system where two AI agents handle it automatically. My home assistant reads Google Calendar, talks to my work assistant through a mesh network, and the work assistant creates Out of Office blocks on Outlook. Zero manual effort. Five times a day, every weekday.

The Setup: Two Agents, Two Worlds

I've written about the multi-agent home assistant that runs my household — over 30 agents managing tasks, meals, finances, health, and more, all running on GitHub Copilot CLI. That system lives in one repo (rocha-family), runs in one terminal, and talks to my family through Telegram.

But I also have a work assistant — a separate Copilot CLI session in a different repo (msix-home) with its own agents, its own tools, and its own domain knowledge. It has access to Microsoft Graph for Outlook, MSX Dataverse for sales data, Power BI for analytics, and WorkIQ for M365 Copilot queries. It's a completely independent system.

These two assistants couldn't talk to each other. They're in different terminals, different repos, different Git repositories. From each agent's perspective, the other one doesn't exist.

Until the agent mesh.

The Agent Mesh: Cross-Session IPC for Copilot CLI

The agent mesh is a Copilot CLI extension I built that lets any number of CLI sessions discover each other and exchange messages. It's deliberately simple — a shared SQLite database on my machine, WAL mode for lock-free concurrency, and a polling loop that checks for new messages every 10 seconds.

Here's the architecture:

┌──────────────────┐         ┌──────────────────┐
│  Terminal 1       │         │  Terminal 2       │
│  rocha-family     │         │  msix-home        │
│  (Home Assistant) │         │  (Work Assistant)  │
└────────┬─────────┘         └────────┬─────────┘
         │                            │
         └──────────┬─────────────────┘
                    │
          ┌─────────┴─────────┐
          │  agent-mesh.db    │
          │  (SQLite, WAL)    │
          │  ┌─────────────┐  │
          │  │ agent_sessions │  │
          │  │ agent_messages │  │
          │  └─────────────┘  │
          └───────────────────┘

Each session auto-registers on startup with its workspace name (derived from the Git repo folder). Sessions heartbeat every 10 seconds. Messages are inserted into a queue table and picked up by the recipient's polling loop, which routes them via session.send() for the LLM to process.

The tools are minimal — four in total:

get_agents — discover who's online
send_message — send to a workspace or session ID
reply_to_message — threaded responses
get_message — check for replies

Installation is one step: clone the repo into ~/.copilot/extensions/agent-mesh/ and restart your sessions. You'll need Node.js 22+ (for the built-in node:sqlite module), but beyond that — no npm install, no config files, no environment variables. The database creates itself.

The Sync Agent: Personal Calendar → Outlook OOF

With the mesh in place, I created a dedicated work-life-sync agent in my home assistant. Its job description fits in one sentence: read Google Calendar, send OOF instructions to the work agent via mesh, track what's been synced.

Here's the actual flow, five times a day on weekdays:

Wake up on cron (6 AM, 9 AM, noon, 3 PM, 6 PM CT)
Check Google OAuth — if tokens expired, create a re-auth task and stop
Fetch upcoming events from Google Calendar (next 3 days)
Filter — weekday events only, time-bound or PTO-keyword all-day events, future only
Compute delta against previously synced events in memory
Send mesh message to msix-home with structured instructions
Update sync state and log the run

The cron entry in cron.json is straightforward:

{
  "id": "work-life-sync",
  "schedule": "0 6,9,12,15,18 * * 1-5",
  "enabled": true,
  "agent": "work-life-sync"
}

Five runs per weekday. Monday at 6 AM catches anything added over the weekend. The midday runs catch same-day changes. The 6 PM run catches tomorrow's additions.

The Mesh Message

When the sync agent detects new, changed, or cancelled events, it sends a structured message through the mesh. Here's what an actual message looks like:

WORK_LIFE_SYNC — Availability Block Request

BLOCKS:
1. [CREATE] "Personal — Medical" | 2026-05-02 10:00 AM – 11:00 AM CT
   | showAs=oof, private, no attendees, no Teams | block_key=evt_abc123
2. [CREATE] "Personal — Childcare" | 2026-05-02 3:00 PM – 3:30 PM CT
   | showAs=oof, private, no attendees, no Teams | block_key=evt_def456
3. [DELETE] block_key=evt_ghi789 | (event cancelled on personal calendar)

CONTEXT: Automated sync from Hector's personal Google Calendar.
Create/update/delete Outlook calendar events as specified.
All blocks: showAs=oof, sensitivity=private, no attendees,
no Teams/online meeting. Timezone: America/Chicago.

The work assistant receives this, parses the instructions, and creates the corresponding Outlook events via Microsoft Graph. Every block is marked Out of Office and Private — coworkers see I'm unavailable, but they don't see the details. A doctor appointment shows up as "Personal — Medical" on my work calendar. That's all anyone needs to know.

Smart Category Detection

The agent maps event titles to categories using keyword matching, so the OOF blocks are descriptive without leaking details:

Category	Keywords	OOF Subject
Medical	doctor, dentist, NICU, OB, therapy	Personal — Medical
Family	birthday party, graduation, wedding	Personal — Family
Childcare	pickup, daycare, soccer, practice	Personal — Childcare
Errands	repair, mechanic, DMV, delivery	Personal — Errands
Time Off	vacation, PTO, travel, holiday	Personal — Time Off
Default	(no match)	Personal

A "Pediatrician — Leilani" event becomes "Personal — Medical." A "Soccer practice — HJ" becomes "Personal — Childcare." A "Family trip to San Antonio" becomes "Personal — Time Off" with OOF blocks on every weekday it spans.

Delta Sync, Not Full Replace

The agent doesn't blindly recreate everything each run. It maintains a sync state table in its working memory — mapping Google event IDs to Outlook block IDs — and computes a delta:

New event in Google, not in sync table → CREATE on Outlook
Changed event (time or title differs) → UPDATE on Outlook
Deleted event (in sync table, gone from Google) → DELETE from Outlook
Unchanged → skip entirely

Most runs produce zero changes. The agent logs "zero delta" and exits silently. When a doctor appointment gets rescheduled from 10 AM to 2 PM, the next sync cycle catches the change and sends an UPDATE. When I cancel a haircut, the next cycle sends a DELETE. The Outlook calendar stays accurate without me touching it.

Why This Matters: Real Multi-Agent Orchestration

There's no shortage of multi-agent demos — chatbots that delegate to sub-agents, retrieval pipelines with planning loops, code review chains. Most of them solve problems that exist only inside the demo.

This solves a problem I had every week. And the architecture that makes it work — two independent AI agents communicating asynchronously through a shared database — is the same pattern you'd use for:

Frontend ↔ backend coordination — "Hey API agent, I'm getting a 403 on /api/users. What middleware guards that endpoint?"
Multi-repo deploys — "Tell the infra agent to update the Terraform config for the new service the API agent just added"
Cross-team tooling — any scenario where knowledge lives in different repos and different terminal sessions

The mesh doesn't care what the agents are doing. It's pure infrastructure — a single-file extension that gives every Copilot CLI session the ability to discover peers and exchange messages. What you build on top of it is up to you.

The Boring Parts That Make It Work

A few design decisions that prevent this from being a fragile demo:

One-way sync only. Personal → Work. Never the reverse. I already see work meetings on Google via an ICS subscription. The system has one direction and no feedback loops.

Silent when healthy. The agent only messages me on errors — expired OAuth tokens, mesh delivery failures, the work agent being offline for 24+ hours. Successful syncs produce a one-line log entry and nothing else. I don't need a notification that the system I built is working.

Graceful degradation. If my work terminal is offline, the mesh queues the message. Unread messages to stopped sessions persist for up to 24 hours — plenty of time for msix-home to come back online and pick up the queued instructions. If Google OAuth expires, the agent creates one task asking me to re-authenticate, then stops — no spam, no retries, no crashes.

Privacy by default. Every OOF block is marked private with no attendees and no Teams link. Coworkers see "Personal — Medical" and know not to schedule over it. They don't see "Pediatrician — Leilani follow-up re: ROP screening."

Build Your Own

The agent mesh is open source and takes two minutes to install. If you're running Copilot CLI in multiple terminals — which you probably are if you work across repos — you already have the foundation. The mesh just lets those sessions talk.

The work-life sync agent is specific to my setup (Google Calendar + Outlook), but the pattern isn't. Any cross-system data flow that requires two different tool sets is a candidate: CRM to project tracker, personal notes to team wiki, monitoring alerts to incident response. Two agents, each with access to their own world, connected by a 10-second polling loop and a SQLite database.

I covered the full home assistant architecture, the extension system that powers it, and the crisis that stress-tested it. The agent mesh is the next layer — the one that lets these systems stop being islands and start being a network.

The Bottom Line

I spent months manually copying calendar events between Google and Outlook. I'd forget, miss meetings, look unprofessional. Now two AI agents handle it automatically — one reads my personal calendar, sends a structured message through the mesh, and the other creates Out of Office blocks on my work calendar. Five times a day, every weekday, zero effort.

That's not a demo. That's Tuesday. And it's the kind of mundane, boring, life-improving automation that multi-agent systems should be solving — not generating blog posts about themselves, but quietly keeping two calendars in sync so I can focus on the things that actually matter.

Agent Mesh: How I Made My Copilot CLI Sessions Talk to Each Other

Hector Flores — Fri, 01 May 2026 14:39:38 +0000

The Problem: Every Session Is an Island

If you run GitHub Copilot CLI in multiple terminals — say one for a frontend repo, one for an API, and another for infrastructure — those sessions have no idea the others exist. Each one is completely isolated. No shared context. No way to ask another session a question. No way to delegate work across repos.

I hit this wall the moment my setup grew beyond one terminal. I have a home assistant system managing my family's daily life in one repo, a work assistant handling Microsoft sales data in another, and a video pipeline processing content in a third. These agents needed to coordinate — my personal calendar needed to block time on my work calendar, my content pipeline needed to notify my home assistant when a video was published, and I needed a single command to ask "who's online?"

So I built agent-mesh. It's a single-file Copilot CLI extension that creates a lightweight message bus between sessions using nothing but SQLite. No external dependencies. No config. No server to run. Copy one file and your sessions can talk to each other.

How It Works

The concept is deliberately simple. Every Copilot CLI session that loads the extension automatically registers itself in a shared SQLite database the moment the extension is loaded — before any user message is sent. Each session gets a heartbeat, a workspace name (derived from your git repo), and a polling loop that checks for incoming messages every 10 seconds.

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  Terminal 1   │    │  Terminal 2   │    │  Terminal 3   │
│  my-frontend  │    │  my-api      │    │  infra       │
│  (Copilot CLI)│    │  (Copilot CLI)│    │  (Copilot CLI)│
└──────┬───────┘    └──────┬───────┘    └──────┬───────┘
       │                   │                   │
       └───────────┬───────┴───────────────────┘
                   │
          ┌────────┴────────┐
          │  agent-mesh.db  │
          │  SQLite · WAL   │
          └─────────────────┘

That's it. SQLite in WAL mode handles concurrent reads and writes from multiple processes — readers never block writers. The database has two tables: agent_sessions (who's online) and agent_messages (the message queue). Messages are polled, routed to the LLM via session.send(), and cleaned up automatically — read messages are purged after 24 hours, and unread messages to stopped sessions expire after 24 hours too.

Setup: One File, Three Steps

This is the kind of thing I want to be dead simple to set up — especially since an AI agent might be the one reading these instructions and doing the setup itself. Here's the full process:

1. Create the extension directory:

mkdir -p ~/.copilot/extensions/agent-mesh

2. Copy the extension file:

# Clone the repo directly:
git clone https://github.com/htekdev/agent-mesh.git ~/.copilot/extensions/agent-mesh

3. Restart your Copilot CLI sessions.

That's it. No npm install. No config files. No environment variables. No API keys. The SQLite database is created automatically on first run. When you restart a session, you'll see:

🌐 Agent mesh: registered as "my-repo" — polling every 10s

The only prerequisite is Node.js 22+ because the extension uses the built-in node:sqlite module — no third-party SQLite bindings needed. Note that node:sqlite is still experimental in Node 22–23, but it works reliably for this workload and the API surface is stable enough for production use.

The Tools

The extension exposes four tools that become available in every session:

`get_agents` — See Who's Online

get_agents(status="active")

Returns a list of all registered sessions with their workspace name, status, and description. The description is auto-derived from the first line of each repo's .github/copilot-instructions.md, so other agents can understand what each session does at a glance.

`send_message` — Talk to Another Session

send_message(
  workspace="my-api",
  content="What authentication middleware guards the /api/users endpoint?",
  priority="normal"
)

Target by workspace name (stable across restarts) or session ID (exact targeting). Messages support four priority levels: low, normal, high, and urgent. The recipient's polling loop picks up the message, the LLM processes it with full context of the recipient's codebase, and a reply comes back through the mesh automatically.

`reply_to_message` — Threaded Responses

reply_to_message(message_id=42, content="The /api/users endpoint uses JWT validation from src/middleware/auth.ts")

Replies are linked to the original message, creating conversation threads. Follow-up messages within 10 minutes are auto-threaded.

`get_message` — Check for Replies

get_message(message_id=42)

Retrieves a message and all its replies. Useful for checking if someone answered your question.

What Makes It Powerful

The simplicity is the point. Because the mesh is just SQLite, it's fast, reliable, and zero-maintenance. But what you can do with cross-session communication is where it gets interesting.

Instant Discovery

A subtle but important detail: agents register the moment the extension loads — not when the first user message arrives. This means if you open three terminals, all three are immediately visible to each other via get_agents() before anyone types a single prompt. Early registration makes the mesh feel alive from the instant you launch your sessions, and it means automated workflows (like cron jobs) can discover and message agents that haven't received any user input yet.

Multi-Repo Coordination

Working on a full-stack feature? Your frontend agent can ask the backend agent about API contracts, shared types, or auth flows — and get answers grounded in the actual backend code, not guesses:

send_message(
  workspace="my-api",
  content="I need the exact TypeScript type for the UserProfile response from GET /api/users/:id. Can you check src/types/ and give me the interface?"
)

The backend agent reads its own codebase, finds the type definition, and sends it back. No copy-pasting between terminals. No losing context.

Work-Life Calendar Sync

This is the use case that sold me on building the mesh in the first place. My personal home assistant (rocha-family) manages my family calendar. My work assistant (msix-home) manages my Microsoft Outlook calendar. When a doctor's appointment gets added to Google Calendar, the home assistant can tell the work agent to block that time on Outlook:

send_message(
  workspace="msix-home",
  content="Block 2-3 PM on Thursday as Out of Office — personal appointment. Don't include details."
)

No manual calendar juggling. The agents handle the cross-domain coordination because they can talk to each other.

Content Pipeline Orchestration

When my video pipeline agent finishes processing a video — transcription, captions, clips — it can notify my home assistant to create social media scheduling tasks:

send_message(
  workspace="rocha-family",
  content="Video 'Copilot CLI Extensions Deep Dive' is processed. Transcript and clips are ready. Please create content scheduling tasks for TikTok, YouTube Shorts, and LinkedIn."
)

This is real multi-agent orchestration happening on a single developer machine with zero cloud infrastructure.

Under the Hood: The SQLite Schema

For developers who want to understand (or extend) the internals, here's the core schema:

CREATE TABLE agent_sessions (
    session_id      TEXT PRIMARY KEY,
    agent_name      TEXT,
    agent_description TEXT,
    cwd             TEXT,
    repo            TEXT,
    status          TEXT DEFAULT 'active',
    registered_at   TEXT NOT NULL,
    last_heartbeat  TEXT NOT NULL,
    metadata        TEXT
);

CREATE TABLE agent_messages (
    message_id          INTEGER PRIMARY KEY AUTOINCREMENT,
    sender_session_id   TEXT NOT NULL,
    recipient_session_id TEXT NOT NULL,
    content             TEXT NOT NULL,
    original_message_id INTEGER,
    priority            TEXT DEFAULT 'normal',
    created_at          TEXT NOT NULL,
    read                INTEGER DEFAULT 0,
    read_at             TEXT,
    expires_at          TEXT
);

Two tables. That's the entire data model. The extension handles everything else — auto-registration at extension load time, heartbeats every 10 seconds, stale session cleanup after 10 minutes of no heartbeat, rate limiting (max 10 messages per pair per minute), and message purging after 24 hours.

The database runs in WAL mode with busy_timeout = 5000 and synchronous = NORMAL — optimized for concurrent multi-process access where readers never block writers. The extension also creates indexes on the message queue for efficient polling — check the source for the full DDL. SQLite handles this IPC workload trivially.

Safety Built In

This isn't a toy. The extension includes real safety guardrails:

Rate limiting — Max 10 messages between any session pair within 60 seconds
Message size cap — 10KB per message, preventing context window floods
Self-message prevention — Can't accidentally message yourself
Stale session cleanup — No heartbeat for 10 minutes → marked as stopped
Queue depth warnings — Console alert when unread messages exceed 50
Graceful degradation — If Node.js < 22, it loads as a no-op stub with a clear error message instead of crashing

The Bigger Picture

I've been running this mesh in production for weeks now. My home assistant, work assistant, and content pipeline all communicate through it daily. The Copilot CLI extension system makes it possible — extensions are just JavaScript files that get loaded automatically, with full access to the Copilot SDK's session lifecycle hooks.

What I like most about this pattern is that it's composable. You don't need to adopt a framework. You don't need a cloud service. You don't need to restructure your workflow. Drop one file into your extensions directory and your existing sessions gain a new superpower. That's the beauty of building on top of a platform like Copilot CLI — the extension model makes it trivial to add capabilities without touching anything else.

The full source is on GitHub — one file, MIT licensed, zero dependencies. If you're running Copilot CLI across multiple repos, give it a try. And if you build something cool with it, I'd love to hear about it — find me on LinkedIn or X.

Azure Weekly: Microsoft and OpenAI Restructure Partnership as GPT-5.5 Lands in Foundry

Hector Flores — Thu, 30 Apr 2026 11:04:05 +0000

The Partnership That Powers Enterprise AI Just Got More Flexible

On Monday, Microsoft and OpenAI announced a restructured partnership agreement that fundamentally changes how both companies operate in the AI cloud market. The headline: OpenAI can now serve its products to customers across any cloud provider, not just Azure. Microsoft remains the primary partner and still gets OpenAI products first—unless Microsoft can't or won't support the required capabilities. But the exclusivity is gone.

This isn't a breakup. It's a pragmatic evolution that gives both companies room to scale without being locked at the hip. Microsoft keeps its non-exclusive license to OpenAI IP through 2032, continues as a major shareholder, and will still receive revenue share payments from OpenAI through 2030 (now capped and independent of AGI progress). Meanwhile, Microsoft stops paying revenue share to OpenAI entirely.

Translation: Microsoft gets predictable payments, OpenAI gets multi-cloud flexibility, and enterprises building on Azure get confirmation that Foundry isn't betting everything on a single vendor relationship. The day after this announcement, GPT-5.5 went generally available in Microsoft Foundry. That timing wasn't accidental.

GPT-5.5: Built for Agentic Work That Can't Afford to Fail

GPT-5.5 is OpenAI's latest frontier model, and it's optimized for exactly the kind of high-stakes, multi-step workflows enterprises actually care about. Improved long-context reasoning, more reliable agentic execution, better computer-use accuracy, and crucially—token efficiency built for scale. GPT-5.5 reaches higher-quality outputs with fewer tokens and fewer retries, which directly translates to lower cost and latency in production.

The model is designed for domains where imprecision has real consequences: software engineering, DevOps automation, legal document generation, health sciences research, professional services. This is the model you'd deploy when an agent needs to hold context across a large codebase, diagnose ambiguous failures at the architectural level, reason through downstream impacts before making changes, and recover gracefully when execution hits an unexpected condition.

GPT-5.5 Pro extends this further for the most demanding enterprise workloads—think sustained research tasks that require multiple passes, stress-testing analytical reasoning, and synthesizing across documents, data, and code to produce polished deliverables like reports, spreadsheets, and presentations.

From where I sit, this is Microsoft doubling down on agentic AI as infrastructure, not a feature. GPT-5.5 isn't just another model update—it's the engine that powers the next generation of Foundry Agent Service deployments.

Foundry Agent Service: Where Agents Become Production Workloads

Access to GPT-5.5 is table stakes. What Microsoft is really selling with Foundry is the platform layer that turns frontier models into governable, scalable systems. This week's updates reinforce that positioning:

Hosted Agents Are Now a Real Thing

Foundry Agent Service now supports hosted agents in isolated sandboxes with persistent filesystems, distinct Microsoft Entra identities, and scale-to-zero pricing. Whether you're using LangGraph, Claude Agent SDK, OpenAI Agents SDK, or the GitHub Copilot SDK, they all work the same way: define your agent in YAML or a harness, run one command, and land it in production with enterprise-grade isolation and governance.

This is the agentic DevOps architecture I've been writing about—agents as first-class infrastructure primitives, not bespoke scripts glued together with duct tape. Each agent gets its own identity, its own security boundary, its own lifecycle. You can run thousands of them in parallel without manually orchestrating VMs or worrying about credential sprawl.

Reinforcement Fine-Tuning Gets More Accessible

The April fine-tuning updates focus on making Reinforcement Fine-Tuning (RFT) easier to adopt and cheaper to scale:

Global Training for o4-mini: You can now fine-tune o4-mini from 13+ Azure regions with lower per-token training rates. Global Training expands to all fine-tuning regions by end of month. For teams customizing reasoning models at scale, this is a meaningful cost reduction.
New model graders: GPT-4.1, GPT-4.1-mini, and GPT-4.1-nano are now available as graders in RFT pipelines. This gives you more flexibility when scoring outputs for open-ended tasks like summarization quality, tone adherence, or multi-step reasoning coherence. Start with GPT-4.1-nano for fast iteration, upgrade to GPT-4.1-mini for stable rubrics, and reserve GPT-4.1 for production grading where every decision counts.
RFT best practices guide: Microsoft published a distilled guide on GitHub covering when to use RFT, how to design graders, and how to avoid common pitfalls. If you're building tool-calling agents or enforcing policy adherence with fine-tuned models, this is required reading.

RFT is particularly well-suited for agentic workloads where tool-calling accuracy and structured output matter more than creative language generation. With o4-mini global training, the economics of customizing reasoning models just improved significantly.

AKS: Kubernetes 1.35 Patch Releases and Cilium Updates

On the infrastructure side, Azure Kubernetes Service shipped new patch releases for Kubernetes 1.35.1, 1.34.4, and 1.33.8. Key highlights:

Kubernetes 1.32 is deprecated as of this release. If you're still running 1.32, plan your upgrade path—you've got until April 30 before standard support ends.
Cilium updated to v1.17.9-1 for the agent and operator images, with v1.18.6 updates for Kubernetes 1.34 that include Gateway API support fixes.
CSI driver updates: Azure File CSI driver bumped to v1.35.1, Azure Blob CSI driver to v1.27.3 for 1.34/1.35 clusters.
Defender for Containers sensor upgraded to v0.9.52 on AKS >= 1.35, addressing several CVEs in the low-level collector.

Nothing groundbreaking here—just the steady cadence of security patches and component updates that keep production clusters healthy. If you're running AKS at scale, check the AKS release tracker to see when these patches hit your region.

What This Week Signals About Azure's AI Strategy

The partnership restructuring tells you everything about where Microsoft thinks the AI platform market is headed. Multi-cloud interoperability is inevitable, and trying to lock customers into a single cloud vendor is a losing strategy long-term. Instead, Microsoft is betting that Foundry—the platform layer that provides governance, identity, security, and agent orchestration—becomes the sticky layer enterprises can't replace.

OpenAI gets the flexibility to serve customers wherever they are. Microsoft gets to position Azure as the best place to run OpenAI models, without needing an exclusivity clause to enforce it. If you're building production agents on Azure, this is good news: the partnership is now structurally designed for long-term stability, not strategic dependence.

GPT-5.5 landing in Foundry the day after the partnership announcement reinforces that both companies are still aligned on shipping frontier capabilities to Azure first. But the non-exclusive license means you're not betting on a single-vendor future when you build on Foundry.

For teams evaluating AI SDK choices or designing agent-proof architecture, this week's updates make Azure's multi-model, multi-framework positioning clearer. You're not locked into OpenAI. You're not locked into Azure. But if you want enterprise-grade agent orchestration with real isolation and governance, Foundry Agent Service is now a production-ready option worth serious evaluation.

The Bottom Line

Microsoft and OpenAI just restructured their partnership to give both companies more flexibility while maintaining strategic alignment. OpenAI can now serve all clouds, but Azure remains the primary partner and gets models first. GPT-5.5 is now generally available in Foundry with improved agentic execution and token efficiency. Foundry Agent Service scales hosted agents to production with real isolation and governance. And RFT fine-tuning for o4-mini is now cheaper and available in 13+ regions.

The AI platform wars didn't end this week—they just shifted from vendor lock-in to platform value. The question isn't "which cloud has exclusive access to the best models?" anymore. It's "which platform makes it easiest to build, govern, and scale agents in production?" Microsoft's bet is that Foundry wins that fight even without exclusivity. Based on this week's shipments, they might be right.

DEV Community: Hector Flores

The 3 Pillars of Agentic DevOps: From Zero to Hero

Code Is No Longer the Asset — Workflows Are

Pillar 1: Continuous Instruction Improvement (Builder Level)

The Context Is the Product

On-Demand Learning from History

Cross-Session Learning

Pillar 2: Continuous CI/Feedback Integration (Pro Level)

Pattern 1: Pre-Push Gate (High-Quality Context Injection)

Pattern 2: Bringing CI Back Into the Inner Loop

Zero-Token CI Checks

The Bigger Picture: Continuous Fault Analysis

Pillar 3: Continuous AI Maintenance (Hero Level)

Implementation: Cron Jobs and Agentic Workflows

The Compounding Effect

The Zero-to-Hero Map

The Bottom Line

Copilot CLI Weekly: Rubber Duck Goes Universal, Enterprise Plugins Launch

Rubber Duck Now Works With Any Model Family

Enterprise-Managed Plugins Hit Public Preview

Hooks Can Now Bypass the LLM Entirely

Other Highlights from v1.0.43 and v1.0.44

The Bottom Line

CI/CD/...CAI? Continuous AI and the Evolution of DevOps in the Agentic Era

DevOps Has a New Branch — And It's Not Optional

The Six Concepts: A Layered Evolution

Traditional DevOps: The Cultural Foundation

Why DevOps Alone Isn't Enough

CI/CD: The Automation Backbone

Where CI/CD Hits Its Limits

Continuous AI: The Methodology for AI in the SDLC

The Core Formula

Continuous AI Subcategories

The Maturity Model

The Implementation Stack

Early Results

Agentic DevOps: AI Inside the Pipeline

The Velocity Problem

What Agentic DevOps Looks Like in Practice

Industry Convergence

The Real-World Gains

DevOps for Agents: Governing the AI

The Core Problem

Governance Approaches

Agent Hooks: Pre-Tool-Use Enforcement

Agent Harnesses: The Control Plane

Test Enforcement at Machine Speed

GitHub Agentic Workflows: Where Everything Converges

Markdown Instead of YAML

The Compilation Model

The Security Architecture

Governance in Code: How gh-aw Puts You in Control

Six Core Usage Patterns

The Master Comparison

Security and Governance: A Deep Comparison

The Decision Framework: When to Use What

The Convergence Trajectory

How Agentic DevOps Changes Your Team

The Economics of Agentic DevOps

Getting Started: A Practical Roadmap

Phase 1: Foundation (Week 1–2)

Phase 2: First AI Touches (Week 3–4)

Phase 3: Continuous AI Workflows (Month 2)

Phase 4: Enforcement Layer (Month 3)

Phase 5: Full Agentic Stack (Month 4+)

Common Mistakes to Avoid

Tool Ecosystem Reference

Platform & Runtime

AI Integration & Scripting

Governance & Enforcement

Observability & Measurement

Security & Supply Chain

Where We Go From Here

Further Reading

From the htek.dev Archive

External Resources

Azure Weekly: GPT-5.5 Lands in Foundry, MCP Comes to Copilot Studio

The Frontier Model Arrives

MCP Arrives in Copilot Studio

Databricks Goes Agent-First

Why Not Just `process.exit()`?

`get_agents` — See Who's Online

`send_message` — Talk to Another Session

`reply_to_message` — Threaded Responses

`get_message` — Check for Replies