Skip to content
← Back to Articles

The 3 Pillars of Agentic DevOps: From Zero to Hero

· 12 min read
AI GitHub Copilot DevOps Automation Developer Experience

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:

  1. 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.
  2. 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.
  3. /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:

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:

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:

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:

LevelPillarWhat ChangesKey Skill
BuilderContinuous Instruction ImprovementYou maintain your agent’s context on demandEvolving copilot-instructions.md with every session
ProContinuous Feedback IntegrationReal-world signals flow into context automaticallyBuilding hooks that consume CI, tests, and runtime feedback
HeroContinuous AI MaintenancePillars 1+2 run autonomously — the system maintains itselfScheduling 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.

← All Articles