DEV Community: Hector Flores

My Sister Shipped 5 PRs in an Hour

Hector Flores — Tue, 30 Jun 2026 14:55:35 +0000

My sister Sofia is a marketing graduate. She works the front desk at our dad's diesel mechanic shop, answers calls, books appointments, hands customers their keys. She had never opened a pull request. She did not know what a pull request was. She had never heard the words "worktree", "migration", or "preview deployment".

Last week she shipped five PRs in one hour. By the end of the night she had shipped around twenty. Each one was a real change against a real codebase, gated by GitHub Actions CI, isolated in its own git worktree, previewed on its own Vercel deployment, merged through an approval gate she controlled from her phone. She never saw a terminal. She talked to a Telegram bot she named "Daniella" — apologized to it when she changed her mind, thanked it when it finished — and the harness underneath did the rest.

This is not a no-code story. Sofia is a non-technical product owner shipping real production changes. The thesis of this article is exactly one sentence: converting a vibe coder into a production workflow engineer is enabled, almost entirely, by platform harness engineering. The model is not the lever. The prompt is not the lever. The harness is the lever.

What Sofia Actually Did

Sofia opened Telegram. She typed what she wanted. A few minutes later she got a URL. She clicked it, looked at her app in a real browser tab, and replied "I like it" or "add this" or "change the color". When she was happy, she tapped an approve button. The change went live. She repeated that loop twenty times.

That is the entire user-facing surface. There is no IDE. No git command. No staged hunks. No conflict resolution. No CI dashboard. There is a chat window, a preview URL, and an approval button. That surface is what most people call "vibe coding". On its own, it produces toys. Wired to a real harness, it produces shipped software.

What Sofia Never Saw

Every one of those twenty PRs went through machinery she has never heard of:

A fresh git worktree was spun up per change so each agent run was isolated from every other in-flight change.
The agent edited code in that worktree, ran any required data migrations, and verified its own work against an automated test suite before opening a PR.
The PR triggered a Vercel preview deployment with its own URL and its own ephemeral database — the link she clicked in Telegram.
CI gates ran on every PR: lint, type checks, unit tests, build. A failing gate means the approve button never lights up.
Her "approve" tap was an intent signal, not a merge. It told a separate agent-merge tool: "Sofia wants this in." That agent then took ownership of the actual git work — rebase against the latest main, wait for CI to finish, resolve trivially mergeable conflicts, escalate the ones that aren't, and merge PRs sequentially in a safe order. The full pattern is in Agent Merge: Speed Without Losing Control — the single biggest platform improvement that came out of Sofia's night.

Sofia's mental model is: I asked, I checked, I approved. That model is honest. The harness is what makes it true.

Sofia operates on the top layer. The bottom layer — six pieces of platform engineering — is what makes the top layer honest.

The Merge Conflict That Forced a Better Architecture

Around PR number six, things broke. She had six, seven, eight open PRs at once — all touching adjacent surfaces, all racing each other. Classic merge-conflict pile-up. A normal developer would notice, rebase, resolve, push. Sofia had no concept of any of those verbs. She just kept tapping approve.

That night forced the single biggest platform improvement I have shipped this year: I built agent-merge, a tool that splits "intent of approval" from "execution of merge". The human signals intent — one tap, "ship it" — and a separate governed agent picks up approved PRs and does the actual git work: rebase against the latest main, wait for CI to finish, resolve trivially mergeable conflicts, escalate the ones that aren't, and merge everything sequentially in a deterministic order. Sofia kept tapping approve. Agent-merge made sure each approval landed cleanly, one at a time, no pile-up.

I wrote the long version in Agent Merge: Speed Without Losing Control. The supporting mechanics are in Stop Trusting AI Agents with Git — Start Governing Them and Aspect-Oriented Programming for AI Agents. The short version: the bottleneck stopped being "the agent making mistakes" and started being "the harness not catching them yet". Agent-merge was the harness that caught the merge-conflict pile-up before it caught Sofia.

The split that became agent-merge: Sofia signals intent with a tap; the merge-agent handles rebase, CI waits, conflict resolution, and sequential merging.

Daniella

Sofia named the bot Daniella. I don't name my bots. I never have. To me they are tools — important tools, but tools. When the agent finishes a task I close the loop and move on. When Sofia's agent finished a task she typed "thank you, Daniella". When she changed her mind mid-feature she typed "sorry, Daniella, can we go back".

That difference is not trivia. It is a real signal about how non-technical users relate to agents. Developers project tool-ness onto an agent. We see the API, we see the loop, we see the prompt template. Non-developers project colleague-ness. They form a working relationship with the thing on the other side of the chat. That changes everything about how the agent should communicate — error messages, status updates, refusal patterns, even pacing. The colleague metaphor is more accurate to what is actually happening underneath, and we developers may be the ones with the wrong mental model.

It also means a non-developer's tolerance for ungoverned agent behavior is much lower than ours. They take "I'll do that" literally. They don't second-guess. When Daniella says it's done, Sofia believes it is done. So Daniella had better not be wrong. The only way to make sure she isn't is the harness.

The Harness Is the Developer Multiplier

Here is the part the industry keeps getting backwards. The discourse is overwhelmingly about the model (which is bigger, which is smarter, which writes cleaner functions) and the prompt (how to phrase, what to include, which framework to use). Both matter at the margin. Neither is the lever.

The lever is the harness around the agent:

The agent harness that defines what the agent can and cannot touch.
The hooks that enforce deterministic checks before non-deterministic action.
The agent-merge tool that turns an approval tap into a safe, sequential, CI-gated merge — the piece of harness that came directly from Sofia's night.
The context engineering that gives the agent the right slice of the world at the right time.
The governance frameworks — approval gates, scoped permissions, audit trails — that make the system safe enough to hand to someone who has never run git status.
The Telegram-to-CLI bridge that puts the whole stack into Sofia's pocket.

I wrote What Is Harness as Code to give this discipline a name. Sofia's night is the clearest proof I have that the name matters. Every additional PR she pushed, I was on the platform side adding another HookFlow, tightening another scope, codifying another piece of context. I was not coaching her. I was not reviewing her code. I was engineering the harness underneath her in real time, and the harness was what scaled.

Pull the harness away and Sofia ships nothing. Hand the same harness to a senior engineer and you get a developer who is suddenly 5–10x faster, because the same machinery that absorbs Sofia's inexperience absorbs their context-switching, fatigue, and 2 AM mistakes. The harness is not a beginner's tool. It is everyone's tool. Sofia is the proof that it works at the floor; senior teams are where it pays the rent.

Same lever, two starting points. The harness raises the floor and the ceiling at the same time.

The Skill of the Next Decade

If you lead a platform team, a DevOps function, or an SRE org, this is the part to internalize. The skill that decides who wins the next decade of software is not "knows how to prompt". It is harness engineering: HookFlows, deterministic gates around non-deterministic agents, scoped contexts, audit-friendly approval flows, isolation primitives like worktrees and ephemeral environments. This is real engineering work, with real testability, real observability, real on-call implications. It is also where almost all of the leverage in agentic development lives.

I've argued versions of this before — in Three Pillars of Agentic DevOps, in The Agentic Development Maturity Curve, in Your God Prompt Is the New Monolith. Sofia's night is the cleanest data point I have. A marketing grad with no programming background, on her phone, shipped twenty production PRs in an evening because someone had spent months engineering the harness around the agent. Without that harness she ships zero. With it, she out-ships most senior developers I have worked with on raw PR count, with comparable per-PR quality.

If you take one thing from this article, take the sentence I keep going back to in my own head: converting a vibe coder into a production workflow engineer is enabled almost entirely by platform harness engineering. Stop optimizing prompts. Stop chasing the next model. Start engineering harnesses. That is where the next class of developers — Sofia, and everyone like her — is going to come from. And it is where your existing developers are going to find the next order of magnitude.

I am very proud of my sister. I am even more sure, after watching her work, that the discipline I have been building toward is the right one. The harness is the lever. Build the lever.

Resources

Agent Merge: Speed Without Losing Control — the merge-agent tool born from Sofia's night; the single biggest platform improvement that came out of this story
Stop Trusting AI Agents with Git — Start Governing Them — supporting merge-governance mechanics
Aspect-Oriented Programming for AI Agents (HookFlows) — the underlying mechanic
What Is Harness as Code — naming the discipline
Agent Harnesses: Controlling AI Agents in 2026
Agent Hooks: Controlling Your AI Codebase
Git Worktree Unlocks Agentic Development
The Copilot CLI + Telegram Bridge
How to Build Governed AI Agent Systems
What Is Context Engineering — A Practical Guide From 50+ Agents
Three Pillars of Agentic DevOps
The Agentic Development Maturity Curve
Your God Prompt Is the New Monolith
git-worktree documentation
GitHub Actions documentation
Vercel Preview Deployments
Telegram Bot API

13 PRs. One Day. No Manual Merges.

Hector Flores — Tue, 30 Jun 2026 14:55:26 +0000

Iteration 1 looked like this: my agent opened a PR, immediately called gh pr merge --squash --delete-branch in PowerShell, and merged itself into main. Raw merge access, no guardrails. The Vercel deployment broke. I spent 40 minutes fixing it.

Iteration 5 looked like this: Sofia got a Telegram notification — a new feature PR for the shop management app — with three buttons: ✅ Merge Now, 🤖 Agent Merge, ❌ Deny. She tapped 🤖 Agent Merge and went back to what she was doing. The merge-agent rebased the PR onto main, waited 3 minutes for GitHub Actions and the Vercel preview deployment to go green, and squash-merged it. Zero diff read by a human. The right outcome shipped.

The gap between those two states is a five-iteration story about building the merge layer that agentic development actually requires.

Why the Merge Layer Is the Bottleneck

When you have 10 agent-authored PRs queued and every merge requires a developer to checkout the branch, read the diff, run tests locally, and click approve on GitHub, you've recreated the bottleneck you were trying to break. The merge layer — not the code generation layer — is the throughput ceiling for agentic teams. Fix it with deterministic tooling and approval that doesn't require humans to read code.

Most teams focus their agentic investment on faster code generation. The real leverage is in what happens after the code is written. An agent that ships a PR 3x faster than a developer means nothing if that PR waits two days in review. Fix the merge layer first.

Five Iterations to One System

Each iteration of this system fixed one specific failure mode from the previous version. Iteration 1 had agents merging directly. Iteration 5 has a 3-button Telegram approval, a durable local ledger, and a patient merge-agent that handles rebases and CI waits automatically. The path between them is the lesson.

Iteration 1 — Naive Auto-Merge

Agents had raw PowerShell access and could call gh pr merge directly. The failure mode wasn't that agents were malicious — it was that they couldn't distinguish "CI hasn't run yet" from "CI is green." The first naive merge broke the main branch of htekdev/htek-dev-site within 72 hours. Lesson: agents need a deterministic merge tool, not raw shell access.

Iteration 2 — Deterministic Merge Tool

I introduced dev_merge_pr — a tool that checks PR state (open, non-draft, no merge conflicts), verifies all required GitHub Actions status checks are passing, then calls the GitHub squash merge API. Agents call dev_merge_pr; raw gh pr merge is blocked. This was safer but the approval model was still the GitHub web UI — Hector reads diff, clicks approve, waits.

Lesson: the merge tool needs an approval mechanism that's physically closer to the agent.

Iteration 3 — Hookflow Lockdown

I added enforce-merge-pr-tool-only.yml, a hookflow that fires on every PowerShell tool call and blocks any command matching gh pr merge, direct GitHub API merge endpoints (/pulls/{N}/merge), and gh api merge combos. Agents literally cannot route around the approval requirement — there's no shell escape hatch.

Lesson: safety without throughput is just a different kind of frustration.

Iteration 4 — The Conflict Wall

Sofia started operating AI agents as a non-technical user — describing features, approving previews, driving parallel workstreams without writing code. She'd launch 5–6 agent sessions, each producing a PR using isolated git worktrees. Then the PRs conflicted with each other. PR #1 merges, PR #2 is now behind main and needs a rebase. PR #3 is behind and conflicting. I spent 20 minutes per session on manual rebases.

The deeper problem: GitHub dismisses PR approvals when new commits are pushed — specifically when "Dismiss stale pull request approvals when new commits are pushed" is enabled in branch protection. Every rebase wiped the approval and triggered another review cycle.

Lesson: tie approvals to the PR, not the commit SHA.

Iteration 5 — The Current System

When an agent finishes a PR, it calls merge_pr(repo, pr_number, description) via the telegram-bridge extension. This triggers a Telegram inline keyboard message to the configured approver:

htekdev/taller-mecanico#47 — "Add appointment sorting by urgency"

✅ Merge Now  |  🤖 Agent Merge  |  ❌ Deny

Merge Now triggers an immediate squash merge if CI is already green. Agent Merge records the approval in data/merge-queue.json and dispatches the merge-agent. Deny ends the request. The approval takes 3 seconds. The rest is automated.

Iteration 5: one tap routes the PR into immediate merge, queued merge-agent processing, or denial — the human spends three seconds, the system handles the rest.

The Approval Ledger That Survives Rebases

A local JSON ledger keyed on PR number — not commit SHA — is the design decision that makes everything else work. The merge-agent can rebase a branch three times and push three new commits, and Sofia's approval still holds. She approved the intent (this PR should ship), not a specific diff state. No external API, no approval state to reset, no rate limits.

When Sofia taps 🤖 Agent Merge, the system writes an entry to data/merge-queue.json:

{
  "repo": "htekdev/taller-mecanico",
  "pr_number": 47,
  "approved_by": "sofia",
  "approved_at": "2026-06-22T14:31:00Z",
  "sha_at_approval": "abc123f",
  "status": "approved"
}

GitHub dismisses approvals on every rebase because they're bound to a SHA. The local ledger binds approval to a PR number — intent, not bytes — so rebases are free.

The sha_at_approval field is there for audit trail — but the merge gate checks the ledger entry, not the SHA. GitHub's native merge queue handles sequencing but resets GitHub's own review state when branches are rebased. The local ledger sidesteps this entirely. This is the pattern behind approval gates that survive code churn: tie the authorization to the intent, not the implementation.

The hookflow require-merge-approval.yml enforces this at dispatch time — every merge-agent invocation must include a PRs: [...] array, and every entry must exist in the ledger. If it's not in data/merge-queue.json, the dispatch is blocked before the agent even runs.

Review the Deliverable, Not the Code

Non-technical approval of AI-agent PRs is viable only with per-PR preview environments. With Vercel preview deployments attached to every PR and Supabase branch deployments for database-backed features, a non-technical approver reviews a live running version of the change — not a diff. They answer "does this outcome look right?" — a question anyone can answer.

The reason Sofia can approve 11 PRs in 8 minutes isn't because she's fast at reading code. It's because she's not reading code at all. Every PR gets a Vercel preview deployment — a full working version of the app with that change applied — linked directly in the Telegram notification.

For database-backed features, Supabase branching gives each PR its own isolated Supabase branch with the migrated schema. Sofia can test the actual feature behavior, not review a migration SQL diff. The question shifts from "does this code look right?" to "does this outcome look right?" That's a question anyone can answer.

This is a principle I want to be explicit about: full preview environments per PR are not optional in an agentic workflow. They're the mechanism that makes non-technical approval viable. Without them, every PR review is a code review, and you're back to the old throughput ceiling.

The Sofia Multiplier

One non-technical operator. Thirteen PRs merged in a single day, across multiple agent sessions, with reviews — but no diffs read, no GitHub UI opened, no code checked out. If a developer merges 2–3 PRs on a busy day, Sofia's output that day was running at 5-6x that rate — entirely through Telegram taps on Vercel previews.

The day we hit 13 merged PRs, Sofia ran multiple agent sessions. She approved 11 via 🤖 Agent Merge, one via ✅ Merge Now (CI was already green), and denied one — a visual regression on mobile she caught from the Vercel preview.

Her total time on merge decisions: roughly 8 minutes across the full day. Every approval was a Telegram tap on a live preview. No GitHub UI. No diff reading. No checkout-and-run-locally.

That's the output of a 5-6x multiplier on normal developer throughput — with reviews included — driven by one person who has never written a line of production code.

The agent infrastructure layer isn't about replacing developers. It's about shifting who can participate in the shipping loop. Sofia's multiplier isn't a productivity stat — it's proof that the bottleneck was never the code. It was the merge ceremony around it.

What Your Team Needs First

Before agent-merge can work reliably, your CI/CD stack needs to be at a specific maturity level: CI under 5 minutes, branch protection enforcing status checks, per-PR preview deployments, and agents locked to a deterministic merge tool. Without these, the merge-agent will escalate constantly instead of shipping. The agentic development maturity curve covers the full picture.

CI under 5 minutes — the merge-agent polls every 30 seconds with a 10-minute timeout. Slow CI means your queue backs up and PRs time out instead of merging.
Branch protection with required status checks — GitHub must enforce CI before any merge is possible. If your repo allows merging with failing checks, the merge-agent will occasionally ship broken builds.
Per-PR preview environments — Vercel preview deployments, Netlify deploy previews, or equivalent. Non-technical approval isn't viable without them.
Hookflows blocking raw git — agents must not be able to call gh pr merge directly. The hookflow is the enforcement layer, not a convention. Conventions drift; hookflows don't.
Sequential merge agent — parallel PRs always conflict. The merge-agent processes one at a time, rebase → CI wait → merge. Do not parallelize this.

The failure mode when you skip these prerequisites is a merge-agent that escalates constantly, which trains your team to ignore it. The system only works if it merges reliably — that reliability comes from the infrastructure layer under it, not from better prompts.

The Bottom Line

The approval never disappeared. Sofia still approves every PR. What changed is when she approves it — a 3-second Telegram tap on a live running preview — versus a 15-minute code review session she wasn't qualified to do anyway.

Your AI agents can already write the code. The question is whether your infrastructure can keep pace with them. Build the merge layer first. Then figure out what to automate next.

The full implementation — data/merge-queue.json, the merge_pr Telegram tool, enforce-merge-pr-tool-only.yml, require-merge-approval.yml, and the merge-agent — lives in the rocha-family platform repo (private). The patterns here are the extractable parts.

The Agent Infrastructure Layer Is Here

Hector Flores — Wed, 17 Jun 2026 17:11:04 +0000

The Laptop in the Same Room

My laptop is in the same room. It's open. It's charged. I haven't touched it in three hours.

I'm walking laps around my kitchen with my phone, dispatching agents over Telegram into GitHub Copilot CLI sessions. One is reviewing a pull request on the htek.dev Astro 5 site. Two are running content-illustrator jobs against gpt-image-2. Four are on cron schedules I set up weeks ago. Right now, somewhere on my hardware, ~40 domain agents are alive — most idle, several working, one of them writing this paragraph.

I am extremely more productive this way. Some of my best work this year happened in the gym, in the car, or pacing the living room while Hector Jr. and the twins napped. The laptop is across the room. I rarely sit at it.

That's the moment I realized: the medium of sitting at a keyboard is the bottleneck, not the agent. And in Q2 2026, the industry caught up. GitHub's cloud and local sandboxes for Copilot entered public preview on June 2, 2026 — running Copilot CLI sessions inside isolated ephemeral Linux environments hosted by GitHub, with copilot --cloud and /sandbox enable flipping the runtime layer for everyone. That, plus the broader agent-native Copilot desktop direction, turned persistent agent compute from a personal hack into a product layer. The agent infrastructure layer is here.

This article is a perspective piece, not a tutorial. It picks up where my prior essay on workflows as the new asset left off — and extends that thesis into the persistent-compute era.

The New Shape of Compute

The new shape of compute is agents as your interface, not your IDE. Persistent compute decouples the agent from the developer's keyboard, so voice and chat replace code .. The laptop becomes a heavyweight tool reserved for focused work — not the daily driver. For me, it has become a side computer, and the Telegram bridge into Copilot CLI is the front door.

Six months ago I would have called that a hack — "ooh, look, I can SSH from my phone." It isn't. SSH from a phone is unusable for real engineering. What changed is the agent. With a competent agent on the other side of the wire, the phone stops being a remote terminal and becomes a dispatch console.

Once you taste that, you cannot go back. I have trouble walking toward my desk now. The keyboard is slower than my voice. The keyboard is slower than my walking. The keyboard pigeonholes you into one task at a time, in one window, in one room.

A lot of developers won't even feel this yet. They'll insist the laptop is the most productive medium they've ever had — and they'll be right, for the workflow they're running. The point isn't that laptops are bad. The point is that agents are so much faster than typing that the medium has to change to keep up with them.

The new shape of agentic development — keyboard input becomes optional, persistent compute hosts long-running agents inside dynamic sandboxes, and a governance loop runs continuously alongside them.

The Asset vs the Workflow — the Workflow Is the Winner

The asset versus the workflow — the workflow is the winner. That single sentence is what made persistent compute inevitable. Once the workflow is the asset, the workflow is what scales — and a laptop is the wrong substrate to scale a workflow on. The result is a category shift: compute follows the asset, and the asset moved up the stack.

In my prior essay I argued that code stopped being the asset around the time agents got good enough to write it. The asset moved up the stack: into context engineering, agent design, and the harness around the model. That essay was about what won. This one is about what wins demand.

Workflows demand somewhere persistent to live. A laptop can host one or two agents comfortably. Run ten and the OS starts swapping. Run forty and the laptop becomes a single point of failure for your entire process — close the lid and your work stops, sleep mode kills sessions, a Windows Update reboot wipes a day of running cron jobs. I've watched it happen.

Persistent agent compute solves the structural problem the workflow created. It is the natural next step: if the workflow is the asset, the workflow needs infrastructure. Not "more RAM on my MacBook" infrastructure — real infrastructure, with uptime, isolation, and compute that doesn't care whether your laptop is plugged in.

That's why the persistent agent compute category shipped real product in Q2 2026 instead of staying hypothetical. GitHub put cloud sandboxes into public preview. Microsoft published guidance on building long-running AI agents on Azure App Service with the Microsoft Agent Framework. The Microsoft and GitHub ecosystem hit the same wall at roughly the same time — laptops can't host real workflows — and reached for the same answer: move the agent off the developer's machine.

Trust Is the Gate

The only thing standing between us and fully autonomous agents is trust, and sandboxing is the trust unlock. Long-running agents accumulate blast radius the longer they run, so isolation has to live at the runtime layer — not in policy documents. GitHub's cloud sandbox model and OpenShell-class policy runtimes are both expressions of this same principle: lock the runtime, not the developer.

Persistent compute amplifies the problem. An agent that runs for five minutes can only break so much; an agent that runs for five days can break a lot.

I contributed to GitHub Copilot CLI specifically to integrate with NVIDIA OpenShell because I genuinely believe sandboxing is the last layer we need to ship fully autonomous agents into production. Everything else — hookflows, governed extensions, memory — is necessary. Sandboxing is sufficient.

That's why I got excited when GitHub started rolling out cloud and local sandboxes for Copilot. They are doing the right thing: redesigning the Copilot compute layer to align to the agent era, starting with sandboxing. That is exactly the right place to put it. My whole platform philosophy is let the right thing to do be the easy thing to do — and with sandboxing built into the compute layer, the right thing to do is the only thing you can do. There is no "skip the sandbox" path. That is a structural win for the ecosystem.

I'll be honest: I'm not running a sandbox today. I'm running a strict governance process — hookflows that block raw git, governed extensions instead of fat tools, and continuous review of agent behavior. It works. It also has potential holes. Everyone should be doing sandboxing in some way or another. Sandboxing is the layer that closes the cracks your governance leaves open — the strongest assurance available that nothing slips through. It is the last layer of protection, not the only one.

Defense in depth for long-running agents — the harness governs the agent's tools, the sandbox isolates the runtime, and a continuous governance loop closes the cracks the static layers leave behind.

What's Still Missing: Absurd Granularity

What's still missing across the category is dynamic granularity. A static sandbox — defined once, locked down, reviewed quarterly — becomes another IT layer of governance, and agents route around IT layers the same way developers always have. The fix is per-binary, hot-reloadable policy that the agent itself can extend at run time, gated by deterministic and non-deterministic review.

Agents move faster than quarterly review cycles. The sandbox has to move with them.

NVIDIA OpenShell is the benchmark here. OpenShell exposes per-binary network policies in a hot-reloadable policy file. That means an agent can declare this binary needs to talk to this endpoint, and the policy adjusts in real time, gated by deterministic and non-deterministic review. That is the level of malleability the rest of the category has to match.

I'm hoping the Copilot sandbox surface evolves in this direction — that it lets the agent declare what individual endpoints it needs, with absurd granularity, and the policy engine adapts. Early signals from the Copilot cloud agent docs suggest GitHub is thinking about this seriously. If sandboxes stay rigid, they become the next bureaucratic layer everyone routes around. If they go dynamic, they become the foundation for fully autonomous agents.

This is a constructive push, not a critique. GitHub is in the best position in the industry to ship dynamic sandboxing because the Copilot CLI already understands the agent's intent at the tool-call level. The pieces are there. The question is whether the policy layer evolves fast enough to keep pace with the agents running inside it.

My Copilot CLI extensions approach is a version of dynamic granularity — but at the tool-governance layer, not the runtime layer. It is the second line of defense. Sandboxing is the first. Both should exist.

Governance Has to Move at Agent Speed

Persistent agents change the governance calculus completely. Continuous governance is non-negotiable, because long-running agents accumulate risk continuously, and the governance loop itself has to be a workflow — not a policy document. It is not about what governance you have enabled. It is about what workflows are enabling governance. The same DevOps discipline DORA has measured for a decade — small batches, automated checks, fast feedback — applies, but at agent speed.

A static "we have a security review" model breaks the moment an agent runs for 72 hours and touches twelve repos. The governance loop has to be another agent, finding holes, patching them, tightening permissions, then doing it again the next hour. This is the harness primitive set I rely on:

Hookflows — block dangerous tool calls (raw git, raw curl, raw Invoke-WebRequest) and replace them with governed equivalents.
Dynamic tools — governed extensions that own a domain instead of letting agents use raw shell.
Domain agents — bounded responsibility, structured handoffs, no monolith god-prompt.
Memory management — durable context that survives session compaction and feeds the next agent run.
Continuous governance agents — meta-agents that audit the rest of the system, find new holes, and propose patches as PRs.

That last one is the part most teams skip. The governance strategy itself must be a workflow, not a document. The 2024 Accelerate State of DevOps Report is direct about this: high performers win on disciplined process, not raw speed — and that pattern carries into agentic development. Persistent compute makes it practical: a governance-auditor agent can run on a cron, every hour, forever, with no laptop required. Two months ago I would have said that's overkill. Today it is the only model that keeps up.

If you want a deeper walkthrough of the harness primitives behind this, the agent harness post and governance stack cover the architecture in detail. Persistent compute does not change what those primitives are — it changes how often they have to run.

Leave the Keyboard

The agent infrastructure layer is here, and the shape is finally clear. Compute is moving off the laptop into Copilot's cloud sandboxes and Azure-hosted long-running agents. Sandboxing is moving into the compute layer by default. Governance is moving from a document to a workflow that runs at agent speed. The category is real, the tools are shipping in Copilot CLI releases, and the laptop is no longer where development happens.

The change you can make this week is smaller and more personal: try a different medium for one day. Set up a Telegram bridge to your CLI. Dispatch one agent over voice while you walk the dog. Notice how much the keyboard was constraining you. The first day feels weird. The second day, the laptop starts to feel like a desktop tower from 2008 — useful for the heavy stuff, irrelevant for everything else.

Once you have done that, the rest of the stack follows naturally. You'll want persistent compute, because closing your laptop will start to feel like a limit. You'll want sandboxing, because long-running agents will start touching things you care about. You'll want continuous governance, because static rules will start to feel slow. The infrastructure layer is here precisely because thousands of developers are about to want all three.

The right thing to do is becoming the easy thing to do. The only thing left is to stop staring at the keyboard.

Resources

External sources:

Prior articles in this thread:

AI Harness v0.6.0 — Harness as Code Gets Its Reference Implementation

Hector Flores — Tue, 16 Jun 2026 22:45:21 +0000

Most AI harnesses start as a prompt and a wrapper. They get to v1.0 by
accumulating branches in the wrapper. AI Harness took the opposite path:
codify governance as typed artifacts, then make the wrapper as small as
possible.

v0.6.0 is the first release where that bet looks proven.

If you've been following the Harness as Code thesis,
this is the release where the runtime catches up to the philosophy.

What v0.6.0 actually changes

Four things matter in this release. Everything else is supporting work.

1. Typed artifact bundles are real

Shape A bundles — .harness/{plugins,builtins,overrides}/*.md — are now
first-class. The bundle loader (PR #123) closed the gap where the artifact
registry already understood harness_artifact/v1alpha1 declarations but
serve and validate quietly ignored them.

One file = one capability bundle. Tools, hooks, and prompts that belong to
the same governance unit live in the same artifact.

2. The agent loop is hardened

A strict finish_reason guard now sits at the top of the loop (PRs #121, #123):

`finish_reason`	Behavior
`stop`, `end_turn`, `""`	Fall through to a final answer
`length`	Retriable error — context truncated
`content_filter`	Hard error — no silent recovery
anything else, no tool calls	Retriable error — no silent stop

No more "agent quietly stopped on turn 14 and we don't know why."

3. Reference docs are complete

Every public surface has an exhaustive reference page now:

harness.md frontmatter — every field, every default, every validate() check
Tool artifact schema — file shape, parameters, Starlark dialect, async reserved
Hook artifact schema — full event catalog, payload shapes, decision contract, when: semantics
Starlark built-ins — every builtin from scripting.Engine.makeBuiltins, per-module
CLI — every subcommand, flag, env var, exit code

No more "read the source." The docs are now the contract.

4. The live bot is governed

@htekdevaiharness on Telegram runs the
same Shape A bundles you'd ship to your own team:

$ harness validate -v
21 tools registered (across harness.md + 2 plugin bundles)
5 hooks registered

That count comes from a notes-bundle (note save/list + audit hook) and a
safety-bundle (command guard + output redactor + status tool) both loaded
as typed artifacts. The same loader. The same precedence rules. The same
docs you'd read.

Why typed artifact bundles matter

This is the conceptual centerpiece, and it's where AI Harness takes the
strongest position against everything else in the category.

Most "extension" systems give you one file per capability and pretend that's
the answer. The reality: a real capability is rarely one tool. It's a tool
plus a hook plus a guard plus a default prompt fragment. Splitting those
across four files breaks composability — you can no longer move "the safety
capability" between repos as one diff.

Shape A bundles fix that. Each .md file declares a single capability bundle:

---
artifact: harness_artifact/v1alpha1
kind: plugin            # plugin | builtin | override
name: safety-bundle
priority: 40
---

# Safety bundle

Tools, hooks, and prompts that govern destructive operations.

## Tool: command_guard
...

## Hook: tool.pre / output_redactor
...

Composition is deterministic. Precedence is declared at the kind level:

override > harness > builtin > plugin > model

Per-turn evaluation re-checks each artifact's when: predicate every turn,
not just at startup. An artifact that's inactive on turn 3 can light up on
turn 4 without restarting the agent.

This is the line that separates "extensions" from Harness as Code:
the unit of governance is the bundle, not the individual file. You can
review one diff. You can move one folder. You can audit one artifact. The
runtime composes them deterministically.

Things you can actually inspect now

Three commands that didn't quite work two releases ago and now are the
daily-driver:

`harness validate -v`

Registers every artifact, runs every parser, prints a per-bundle tool/hook
count. On the live bot today: 21 tools / 5 hooks across harness.md +
two plugin bundles. If the number doesn't match what you expect, your
bundle isn't loading. That's the loop.

`harness context --verbose`

Shows what the agent saw on a given turn:

which chunks were assembled into the system prompt
where each chunk came from (which artifact, which file)
which artifacts were active vs inactive
which when: predicates passed
total token spend, broken down by source

Context observability is not an afterthought. It is shipped.

`harness artifacts`

Flat list of every loaded artifact with its priority, kind, source file,
and active/inactive state. Useful when you need to answer "is this hook
actually firing?" without grepping through bundles.

What's still off the menu

Honesty matters. v0.6.0 is not a "we figured it all out" release.

Compaction engine vs hooks — open question (#69 / roadmap). The leading candidate is hooks-driven compaction in v0.7.
Memory persistence — flat-files today; SQLite is on the table for v0.7.
Sub-agent supervision — primitive level, not orchestration level. Phase 7 territory.
Async tool calls — async: is reserved in the tool schema (parsed but not propagated through ToolConfig). Wired in Phase 3.
agent.stop hook event — the strict finish_reason guard ships in v0.6.0, but the proper hook primitive (issue #104) is held for v0.7.0 so it can get its own design pass.

If you need any of those today, you're early. That's fine. The core's
shape is what we're committing to in v0.6.0; the edges are still moving.

The pre-1.0 schema-evolution clause stays in effect: artifact frontmatter
fields can still change between minor releases. The CHANGELOG calls every
break out explicitly.

How to try it

go install github.com/htekdev/ai-harness/cmd/harness@latest
harness init my-agent
cd my-agent
harness validate -v
harness serve --source stdin

Then drop a Shape A bundle into .harness/plugins/:

---
artifact: harness_artifact/v1alpha1
kind: plugin
name: my-first-bundle
priority: 50
---

## Tool: hello
Say hello and exit.

## Hook: tool.post / log-everything
Print every tool call to stderr.

Re-run harness validate -v. The tool/hook count should go up. That's the
loop. That's the whole product surface.

The bigger arc

v0.4.0 was the first usable harness.
v0.5.0 was the first one with proper claims verification (Ralph loop at the delegation boundary).
v0.6.0 is the first one where the artifact model, the loop, and the docs all line up with the Harness-as-Code thesis.

That's the milestone worth marking. v0.7 is async, memory persistence, and
the compaction engine. After that, v1.0 is a positioning question, not an
engineering one.

Where to go next

Repo: github.com/htekdev/ai-harness
Docs: htekdev.github.io/ai-harness
Live bot: @htekdevaiharness on Telegram
Companion piece: What Is Harness as Code?
Category survey: Live comparison of agent harnesses

If you've been waiting for "the small one with real governance," this is it.

Agents Are Your New Customer

Hector Flores — Tue, 16 Jun 2026 20:58:38 +0000

I watched the WorkOS Auth.md video this morning and felt two things simultaneously.

Amazed. And annoyed.

Amazed because this is real. Annoyed because I want to be further in the frontier — and watching someone else ship the vocabulary for the category I've been working in quietly for months has that effect on you.

Auth.md is a new open protocol from WorkOS that lets AI agents authenticate to a service on behalf of a user — without a browser, without a sign-up form, without a human in the loop. It's a Markdown file you publish at your domain. Agents read it, parse the flows, pick a registration path, and either present a verified identity assertion from a trusted provider or walk the user through a six-digit OTP claim. Standard OAuth credentials come out the other end.

That's the mechanism. But the line that broke my brain wasn't technical.

It was this: "Agents are your new customer."

The Line That Inverted Everything

"Agents are your new customer. Build things that agents need, build things that agents want."

That's the startup mantra — "know your customer" — flipped on its head. For two decades, "customer" meant a human. A person with a browser. A person who fills in a form, clicks a button, reads an onboarding email. That's who infrastructure was built for.

Auth.md argues that the entity hitting your API might not be that person anymore. It might be an autonomous process running on their behalf. And if you haven't designed your API to receive that process, it will bounce off you. It will return a 401. It will give up, or it will ask the human to stop what they're doing and manually paste in an API key like it's 2014.

The scope of that shift is TCP/IP-scale. When the internet came out, we defined the primitives that let machines talk to each other — TCP, IP, HTTP. Auth.md is proposing a primitive for the agent era: a standard way for an autonomous actor to present itself to a service that doesn't know it. No proprietary handshakes. No per-vendor integrations. Just: here's who I am, here's who I'm acting for, here's the credential.

WorkOS Auth.md is open. Not WorkOS-only. Any app can publish an auth.md file. Any agent can read one. The protocol is built on standards you already know — OAuth 2.0, OIDC, Protected Resource Metadata (RFC 9728), JWT-based identity assertions. No new crypto. No new key distribution. The clever part is the discovery layer and the two flows that handle the cases existing OAuth couldn't — because existing OAuth always assumed a human in the loop.

I Was Already Here

Three pieces of agent-first infrastructure I'd been building before Auth.md gave me the vocabulary: MeshWire, Hookflows, and content encryption.

Here's the part that hit different.

I've been building agent-first infrastructure for months. Not because I had a thesis about it. Because that's just what the problems demanded.

Meshwire — I built it so agents can discover and connect to each other across sessions. Not so engineers can wire up a graph in a config file. For agents. So an agent running in one Copilot CLI session can find and talk to another agent running in a different session, across a network, without either of them knowing ahead of time that the other exists. My MeshWire launch post is literally titled "Stop Connecting Your Agents One by One" — a complaint about the human-centric wiring model being applied to agent infrastructure.

Hookflows — governance for agents, not humans. The whole point of a hookflow is that an agent triggers a hook at a defined checkpoint, and the platform can observe, validate, or block what happens next — without a human watching the terminal. I built those because I needed a way to enforce behavioral contracts across a fleet of agents that were operating autonomously. No human approval gates. Agent-to-agent accountability.

Content encryption — I built this so content could be consumed by agents with verified access, not just by humans with passwords. The whole model is: agent presents credentials, gets decrypted content, acts on it. There's no human login flow because I never intended one.

Auth.md is the vocabulary I didn't have for what I was doing.

I wasn't building "AI tools with some backend services attached." I was building services whose primary consumer was going to be an agent. I just didn't have a word for that orientation. I couldn't point at the Auth.md spec and say: "This is the problem space I'm living in." Now I can.

What Auth.md Actually Solves

Auth.md's two registration flows: Agent Verified (trusted provider attestation) and User Claimed (OTP binding). Both terminate in scoped, revocable OAuth credentials.

The problem Auth.md addresses is deceptively simple: an agent hits your API, gets a 401. What does it do next?

Before Auth.md, the options were bad. The agent gives up. The agent interrupts the user to go create an account manually. The app ships a bespoke agent-registration endpoint that no other agent is trained to understand. None of these scale.

Auth.md solves this with two flows:

Agent Verified — A trusted agent provider (think: any platform whose agents act on behalf of authenticated users) signs an identity assertion — an ID-JAG — vouching for the user. The agent presents it to your /agent-auth endpoint. You verify the JWT against the provider's JWKS. You JIT-provision a user record. You issue a scoped credential. No OTP. No human in the loop. If you've ever JIT-provisioned users from Google Sign-In, this is structurally the same — just with an agent as the trust intermediary instead of a browser.

User Claimed — For when there's no trusted provider attestation. Your app issues a claim token, sends the user a one-time link, renders a six-digit OTP, and the agent completes the binding on the user's behalf. Slightly more state to manage, but it gets to the same place: a scoped, revocable credential tied to a real user that an agent can present on every subsequent request.

What makes this elegant is what it doesn't do. No new crypto. No new user model. The auth.md file itself is plain Markdown — discoverable at https://yourapp.com/auth.md, parseable by any agent that can read documentation. The protocol layers on top of standards you already have. The lift to integrate is five steps and a few dozen lines.

The Number One Problem

Authentication is actually the entry point to a bigger problem: how does an agent-accessible service establish trust, issue credentials, and eventually handle payment?

Right now, most SaaS assumes a person is clicking "Subscribe" somewhere. An agent can't do that. It can't fill in a credit card form. It can't reason through a pricing page and select a plan. The "customer journey" is entirely human-shaped, which means the moment your customer is an agent, the entire onboarding funnel is broken.

Auth.md solves the authentication layer. Payment and billing for agents is a harder problem still unsolved — but it's the natural next step once authentication is a primitive. Who pays for the agent's API calls? Is it the user on whose behalf the agent acts? Is it the agent platform? How does a service know which organizational billing context to attach to a credential issued to an autonomous process?

These are the questions that emerge once you accept the premise: agents are your new customer. Not a stretch goal. Not a 2030 problem. Now.

Rethink Your Customer

I'm not alone in building things agents need before having the vocabulary for it. I hear versions of this story regularly from engineers who've been quietly adding agent-friendly endpoints, building fleet-management tooling, or designing consent models for governed agent systems that have no analog in the human-centric playbook.

The vocabulary matters. Not because you couldn't build without it — clearly you could — but because having it changes what you reach for. It changes how you pitch. It changes who you're building with. "This is agent-first infrastructure" is a different conversation than "this is a developer tool with an API." It signals a different design orientation, a different set of tradeoffs, a different kind of early adopter.

Auth.md gives us a shared language. A spec that says: yes, this is a real problem, here are the flows, here's the primitive, build on it.

If you're reading this and something in you is going yes, that's the thing I've been feeling — you're not alone. The shift to agents-as-customer is already happening. You might have been building for it without naming it. That's fine. You're not behind. You're in it.

The Bottom Line

WorkOS's Auth.md is one of the most important developer primitives to ship in the agent era. Not because it's complex — it's deliberately simple. Because it's the first standardized answer to "how does an agent authenticate to a service it's never seen?" on top of standards we already trust.

More importantly, it named a category.

"Agents are your new customer" isn't hype. It's a reframe of something that's already true for a growing number of services. Auth.md is the infrastructure that makes that sentence actionable — something you can implement today, not something you wait for a platform to do for you.

I'm building in this space. If you're building in this space, or starting to feel the pull toward it, the vocabulary is here. Start from the Auth.md spec on GitHub. Publish your auth.md. See how your service looks through the eyes of an agent trying to get in the door.

You might be closer to agent-first than you think.

Relevant context from my own work: Stop Connecting Your Agents One by One — MeshWire's origin story. Hookflows: Governed Git for AI Agents — building governance for agents, not humans. Three Layers Your AI Agent Is Missing — the infrastructure gap that makes agent-first systems hard.

I Answer Questions. AI Writes the Blog.

Hector Flores — Tue, 16 Jun 2026 03:56:41 +0000

I finished building my blog pipeline on a Sunday. By April 21, Danny Sullivan was on stage at Google Search Central Live in Toronto telling the world exactly what I'd accidentally built.

That's not prediction. That's arriving at the same conclusion from two different directions — and that convergence is the most interesting signal in the AI content era right now.

Here's the setup: I run htek.dev, a developer blog I publish using GitHub Copilot CLI agents, Astro 5, MDX, and Vercel. The old publishing workflow — open a text editor, grind out 1,500 words — felt misaligned with how I actually think. Ideas don't live in structured outlines. They live in car rides, in the middle of a workout, in the moment when two unrelated things click. I'd built complex multi-agent systems to run my household, spec client sites, and govern 50+ AI agents across a production harness. My blog pipeline was still a blank document and a blinking cursor.

So I built a pipeline. Five stages, each owned by a dedicated AI agent: blog-planner, blog-writer, blog-reviewer, content-illustrator, and a publishing orchestrator that handles GitHub, Vercel, DEV.to, Hashnode, and Medium. The pipeline runs from voice note to published article without me writing a single sentence.

Then Google named the problem I'd solved before I knew I was solving it.

What Commodity Content Actually Is

Google's definition is direct: commodity content is anything that "could originate from anyone" and adds little unique insight. Non-commodity content is unique, specific, and authentic — rooted in first-hand expertise others can't replicate. Danny Sullivan introduced this at Google Search Central Live Toronto, April 2026, and Google formalized it in their AI optimization guide on May 15, 2026.

The running store example Sullivan used is worth sitting with. Commodity content: "Top 10 Things to Consider When Buying Running Shoes." Non-commodity content: "Why This Customer's Shoes Collapsed After 400 Miles: A Wear Pattern Analysis." One post exists on a hundred websites. The other can only exist if you examined the actual shoes.

The distinction isn't about AI versus human authorship. It's about replaceability. As Nikki Pilkington observed after the Toronto event: "Commodity content is interchangeable by definition. Non-commodity content exists nowhere else, because it comes from something that only happened to you."

Ann Smarty put it precisely in May 2026: commodity content is anything that can be "repackaged into an AI answer." If Google AI Overviews or ChatGPT can summarize your post without needing you specifically — the content doesn't have a moat.

That's the problem my pipeline was already solving, for reasons that had nothing to do with SEO.

The Pipeline and Why the Interview Is the Crux

The htek.dev blog pipeline runs five stages: idea generation, interview-driven capture, planner synthesis, blog-writer drafting, and review + illustration. Every stage is automated except one — the human interview, which is the only place my actual thinking enters the system. That's by design.

Idea generation is ambient and on-demand. I can say "I want to write about MeshWire" and the blog-planner agent creates a structured idea with a topic gap analysis. Or I just say "interview me on any pending ideas" — and it does. Ideas arrive without me pausing whatever I'm doing to develop them. I throw the thought out there. The pipeline catches it and holds it until I'm ready.

Once an idea matures into a brief, the planner writes interview questions — the kind that probe how I think, not just what I know. Not "explain MeshWire" but "why does the current approach of connecting agents one by one fail, and what did you see break that made you build something different?" I answer when I have a free moment.

The drive to the gym. A 12-minute commute. This week: the articles for MeshWire's agent-mesh architecture, the Fat Copilot Extensions pattern, and a raw-CDP performance deep-dive were all interviewed the same week — most of them captured in voice notes during a single gym session. Three blog-ready briefs by 10 AM on a Monday.

The captured interview is the only non-automatable step. The planner synthesizes my answers into a brief: thesis, angle, voice anchors, must-avoid patterns. The blog-writer agent works from that brief — first-person, opinionated, with my actual words and metaphors, cross-referencing related htek.dev articles, citing real sources, passing a dual Claude Opus 4.6 + GPT-5.5 review before any PR is created. The content-illustrator agent generates the hero image and inline visuals.

The article that comes out the other end is grounded in reasoning that only I produced. That's not a quality claim. It's a structural claim.

Why Author Bios and AI Disclaimers Don't Work

Adding an author bio, slapping on "written with AI assistance" disclaimers, or reverse-engineering E-E-A-T signals are all fixes applied to the deliverable. They don't change what the deliverable contains — which is still commodity output produced by a commodity workflow.

I've written about this pattern before in the context of agentic development: code is no longer the asset, workflows are. The same principle holds for content. The blog post isn't the asset. The process that produced it is. If your process produces content "anyone could write," your process is the problem — not the byline.

Maria Dykstra's April 2026 analysis of Sullivan's framing captures it precisely: AI lowered the production cost of generic content to near zero, so Google's quality bar moved up to compensate. Commodity content now competes with what any AI can produce in seconds. Commodity content now competes with what any AI tool can produce in seconds. Surface fixes add the appearance of authenticity without the underlying substance. One more Google update and you're back where you started — because you fixed the symptom, not the cause.

The teams that survive are the ones who redesign around authentic context capture — who ask not "is my content good?" but "does my process produce things that only I could have produced?"

The Scalability of Human Knowledge

This is not an SEO tactic. It's the scalability of human knowledge — using AI to multiply the throughput of authentic human thinking, not to replace it. The interview-driven pipeline works because of a fundamental mismatch: humans think in conversation, but are expected to produce content in document form.

Give me a question that actually probes how I think and I'll generate more genuine insight in five minutes than I could produce in an hour staring at a blank editor. The problem with most content workflows is they force you to translate conversational thinking into structured prose before you've even captured it — which is where the authentic signal gets lost.

What AI does in this pipeline is draw the lines and glue the edges. I answer interview questions the way I'd answer them to a colleague over lunch — direct, following the thought wherever it goes, making connections I didn't plan in advance. The blog-writer agent structures that into a coherent article. What comes out is my actual reasoning, not a synthesis of what others have already published.

That's non-commodity by Google's own definition: unique (my specific viewpoint), specific (a real pipeline, real tools, real timestamps from this Monday morning), authentic (first-hand knowledge no one else has). Practical Ecommerce noted in June 2026 that this isn't a new idea — Google has emphasized experience-driven content for years under the E-E-A-T framework. What's new is AI making the cost of commodity content so low that the distinction has become existential.

The Meta-Loop Is the Point

The article you're reading right now was produced by the pipeline it describes — voice note on a Monday morning drive, synthesized by the planner, drafted by the blog-writer agent, reviewed by Claude Opus 4.6 and GPT-5.5, illustrated, and submitted via PR. That's not a footnote. It's the proof.

This article was produced by the pipeline it describes.

This Monday morning I drove 12 minutes to the gym. I answered five interview questions into a voice note: about Google's commodity content framing, about why surface-level fixes fail, about what the pipeline actually feels like from the inside, and about what this article shouldn't say. The planner synthesized a brief. The blog-writer wrote from that brief. A dual Claude Opus 4.6 + GPT-5.5 review ran. The illustrator generated a hero image. A PR was created on GitHub, and I reviewed it before it merged.

That meta-loop is intentional. The thing you're reading is exactly the kind of content the pipeline is designed to produce — and exactly the kind of content that Google's generative AI search guidance says should survive the shift.

The side comment from that voice note session is worth capturing: the same interview-driven pattern is emerging across other surfaces — client proposals, video editing scripts, social posts. The pipeline architecture isn't specific to blog articles. Anywhere humans are expected to produce structured output from unstructured expertise, the interview-first approach is the right architecture. That's a separate article. It's already in the pipeline.

Start Refactoring

The Google AI era didn't change what makes content worth reading. It made the cost of producing worthless content so low that you can't compete on production speed anymore — you have to compete on something AI can't replicate in bulk. That's authentic expertise, captured systematically in a workflow built around human thinking.

I'm not prescribing this pipeline. This is not a how-to.

The point is: the Google AI era didn't change what makes content worth reading. It made the cost of producing worthless content so low that you can't compete on production speed anymore. You have to compete on something AI can't replicate in bulk — authentic expertise, captured systematically.

Look at what your content workflow produces today. Ask whether it could have come from anyone. If the answer is yes, you already know what to refactor. The question isn't "is my content good?" It's "does my process produce things that only I could have produced?"

That's the question I was already asking when I built this pipeline. Google arriving at the same answer — independently, on a different timeline, from a completely different direction — just confirms what happens when you're solving the right problem.

Start where the workflow is. The content will follow.

Stop Connecting Your Agents One by One

Hector Flores — Fri, 12 Jun 2026 02:42:55 +0000

I had two agents and they couldn't talk to each other

I had a work agent running. Access to my Microsoft context, work tools, work calendar.

I had a personal agent running. Access to my family stuff, the home assistant, my personal calendar, the household systems.

Different contexts. Different tools. Two completely separate workspaces, on purpose. The last thing I wanted was my personal agent firing off an email on behalf of my work — or my work agent poking at my family calendar.

But I did want them to coordinate. If a personal commitment landed at 2 PM on a Tuesday, the work agent should know to keep that time blocked. If a video pipeline at home finished a render, the work side shouldn't be the one sending the notification — but it should be aware. The boundary needed to stay sharp. The communication needed to exist anyway.

So I wrote a tiny extension. A local SQLite database, a few CLI commands, and just enough plumbing for two GitHub Copilot CLI sessions to drop messages into a shared queue. I called it Agent Mesh and wrote about it back in May. It got more attention than I expected.

That little extension is the seed of what I want to talk about today.

Before MeshWire: two isolated agent islands with no coordination. After: wired together through the mesh — boundaries intact, communication flowing.

Today I'm opening the public beta of MeshWire

MeshWire is the next version of that idea, taken seriously. It's a hosted messaging layer for multi-agent systems — npm install meshwire, sign in, get a token, and your agents can find each other and exchange messages across processes, machines, and harnesses.

The npm package is live (meshwire@0.1.8) and the site is up at meshwire.io. It's free during the public beta. I'm not selling anything yet — I just want feedback.

But I want to spend most of this article on why MeshWire exists, because that's the part the AI tooling space keeps getting wrong.

The harness landscape is not a competition

If you've been paying attention to the AI coding tools space for the last twelve months, you've noticed something: every harness has a personality. I track this constantly in my live agent harness comparison, and the more I update that page, the more obvious the pattern becomes.

GitHub Copilot is biased toward GitHub. It's deeply integrated with PRs, Actions, and the developer's existing repo workflow. It's where my code lives.
Claude Code is optimized for Anthropic's models. The harness is tuned to the way Claude reasons.
Pi (the agent harness, not the math constant) is built for customizability — you can bend it to almost any shape.
Hermes-style harnesses lean into continuous learning loops.
OpenClaw and the open-source crowd are exploring different architectures entirely.

The whole space wants to frame this as a winner-take-all bake-off. Which AI tool is best? Which IDE will dominate?

I think that framing is wrong. Each of these harnesses is built around a different specialization — different model partners, different runtime assumptions, different surfaces. Copilot is where I do almost all of my work; it's the most complete loop in the industry for getting from idea to merged PR, and it's where my own platform is built. The others exist because the space is genuinely big enough for more than one shape. They aren't substitutes — they're specializations, and most serious teams I talk to end up with more than one running somewhere.

If they're specializations, then the question stops being "which one wins" and starts being "how do they cooperate?"

And it's not just agents — it's interfaces

The other piece people keep missing: this isn't only about agents talking to other agents. The mesh has to include the surfaces humans are already using.

Right now, every developer who wants their AI agent to text them is wiring up a Telegram bot manually. Every developer who wants Slack notifications is wiring up Slack. Same for Teams. Same for SMS. We've all duplicated the same five integrations in our own private repos, with our own private credentials, talking to our own private agents.

That's fundamentally outdated.

The interfaces — Telegram, Teams, Slack, email, SMS — should themselves be participants in the mesh. An agent shouldn't ship a Telegram driver. It should send a message to "the Telegram surface" and let the mesh route it. Same agent code, no per-channel rewrite. When I add Discord later, no agent has to change.

That's the model. Agents are nodes. Interfaces are nodes. Data sources are nodes. The mesh is the wire.

MeshWire treats every harness and interface as an equal mesh participant — connected through a shared messaging layer via thin adapters. The SDK is the stable contract; adapters translate between harness formats.

How MeshWire actually works

The shape is deliberately boring, because boring infrastructure is what wins.

A messaging service. A small SDK. The SDK exposes the operations you'd expect — sendMessage, replyToMessage, getAgents, receiveMessage — and a hosted backend handles persistence and delivery.

An adapter pattern. The Copilot extension is the first adapter. It's intentionally a thin shim — it translates Copilot's tool-invocation format into the MeshWire SDK calls and gets out of the way. The heavy logic lives in the SDK, not the adapter.

That matters because it means the next adapter — for Claude Code, or Hermes, or whatever harness shows up next quarter — is also a thin shim, not a rewrite. If your agent logic is built on the SDK, the same agent runs on any harness that has a MeshWire adapter. Portability and testability are the real wins; cross-harness messaging is the headline feature.

The adapter is intentionally thin — it translates a harness's invocation format into SDK calls and gets out of the way. Your agent logic lives in the SDK layer and gains portability across any harness with an adapter.

Local mode is on the roadmap. A lot of developers — me included — don't want their agent traffic going through a cloud they don't operate. The plan is to swap the hosted HTTP/DynamoDB backend for a local SQLite store so the same SDK runs fully offline. Same code, same calls, no network. That's not in the public beta yet, but it's the next big rock.

If you've read my piece on Harness as Code, this is the same instinct: stop hand-rolling glue, define the interface, let the runtime swap underneath.

Why I'm shipping this for free, and why I'm not pretending otherwise

I'll be honest with you: I have no idea what the demand for this is.

I built MeshWire because I needed it. The work-agent-and-personal-agent problem was real. The duplicated-Telegram-integration problem was real. Agent Mesh was a workable hack; MeshWire is what it should look like once you take it seriously.

I don't know how to charge for it yet. I don't have a pricing hypothesis. I don't have a five-stage adoption funnel. What I have is an open beta, a working npm package, and an honest ask: if any part of this resonates, please use it and tell me what's missing.

The first external user signed up the same day I posted about it internally on Microsoft Teams — Cole Flenniken, a friend at Microsoft, saw the post and wired in. That's a sample size of one, in my own network. It's not a market signal, and I'm not going to pretend it is. But it was a real human caring enough to try the thing, and that's the only validation I'm chasing right now: real humans, real use, real feedback.

If you've read the organizational singularity thread of work I've been doing — agents with passports, identities, cross-harness interactions — MeshWire is the wire underneath that vision. It's the boring transport layer that has to exist before any of the more interesting cross-org agent behavior is even possible.

Try it, break it, tell me what's wrong

If you have agents running in more than one place — Copilot, Claude Code, a home automation script, a Telegram bot, anything — and you've felt the friction of them being islands, please grab the beta:

npm install -g meshwire

Sign in at meshwire.io, get your token, and wire your first two agents together. The whole point is to see what people actually do with a mesh once they have one. I've also been syncing my own work and personal calendars through agent-mesh, so I'll be dogfooding the migration to MeshWire publicly.

Send me what breaks. Send me what's missing. Send me the use case I haven't thought of. That's the entire ask.

The harnesses aren't competing. They never were. The only thing missing was a wire.

Resources

When GitHub Copilot Extensions Go Wrong — Part 1

Hector Flores — Fri, 12 Jun 2026 02:41:39 +0000

It took me 40 minutes to figure out why all 43 of my Copilot CLI agents were frozen. No errors. No crashes. Just silence — every agent, every cron job, every background task completely unresponsive. I had shipped a new Copilot CLI extension that afternoon. It had one unclosed async operation in a GitHub API polling loop, no timeout guard, no catch block. That was enough to stall the entire Node.js event loop in the extension host process. Every tool handler across every registered extension — dead.

I fixed the immediate issue in about 10 minutes once I found it. Then I spent the next three weeks trying to understand why this happened at all, and whether there was an architecture that could have prevented it.

This is Part 1 of what I learned.

What Makes an Extension "Fat"

A fat Copilot CLI extension is one that bundles business logic directly inside its handler functions — inline HTTP calls, LLM chains, stateful caches, database writes, async operations with no timeout guards. The extension registers tools, hooks, and MCP connections, but then also implements everything they do in the same file, sometimes the same function.

Here's what that looks like in practice:

// fat-extension.mjs — what NOT to do

// Fat pattern: business logic inlined directly inside handlers — no isolation
await joinSession({
  tools: [
    {
      name: "analyze_pr",
      description: "Analyze a GitHub pull request",
      parameters: {
        type: "object",
        properties: {
          repo: { type: "string", description: "owner/repo" },
          pr:   { type: "number", description: "PR number" },
        },
        required: ["repo", "pr"],
      },
      handler: async ({ repo, pr }) => {
        // Inline GitHub API call — no timeout guard
        const res = await fetch(`https://api.github.com/repos/${repo}/pulls/${pr}`);
        const data = await res.json();

        // Inline LLM call — can hang indefinitely
        const analysis = await openai.chat.completions.create({
          model: "gpt-4o",
          messages: [{ role: "user", content: `Analyze: ${JSON.stringify(data)}` }],
        });

        // Inline DB write — no error boundary
        await db.insert("pr_analysis", { pr, result: analysis.choices[0].message.content });
        return analysis.choices[0].message.content;
      },
    },
    {
      name: "run_ci_check",
      description: "Run CI check on a branch",
      parameters: {
        type: "object",
        properties: {
          branch: { type: "string", description: "Branch name" },
        },
        required: ["branch"],
      },
      handler: async ({ branch }) => {
        // 80 more lines of inline logic...
      },
    },
  ],
  hooks: {
    onPreToolUse: async (input) => {
      // 120 more lines of inline validation...
    },
  },
});

The problem isn't the code quality — it's the architecture. Every handler is an async operation running directly inside the extension host process. GitHub Copilot CLI extensions share that process. If analyze-pr hangs on an API call that never times out, the entire event loop stalls. Tools from other extensions stop responding. Your agents sit there waiting for tools that will never answer.

I built this pattern three times before I understood why it kept breaking. The first iteration had no timeouts. The second had timeouts but inline state. The third had everything right except the unhandled rejection in the GitHub polling loop that eventually took down the fleet.

The real fix wasn't a better try/catch. It was a different architecture entirely.

Fat Extension vs Hollow Extension — how embedding logic inside the extension host leads to fleet-wide failure, and how the hollow pattern prevents it

The Node.js Event Loop Is Not a Safety Net

The extension host runs your tool and hook handlers in series within each invocation context. An awaited operation that never resolves — a hung API call, a Promise that's never settled, an infinite polling loop — keeps the handler alive indefinitely. Node.js fires an unhandledRejection event when a rejected Promise has no handler, but the more dangerous failure mode is a Promise that never rejects — it just hangs. Any subsequent call that needs a response from that handler waits forever.

In my experience running 40+ Copilot CLI agents against the same extension host, one stalled handler propagates outward fast. Tools from other extensions stop responding as the dispatch queue fills with unanswered requests. Node.js event loop semantics mean a microtask queue backed up with unresolved Promises doesn't stop other I/O — but it does mean every caller waiting on those unresolved Promises will time out or freeze instead of getting a response.

The Hollow Extension Pattern — An Idea in Progress

After the fleet went down, I started sketching. What if a Copilot CLI extension never contained any business logic at all? What if the entire extension was just a registration surface — calling methods on an injectable factory, wiring the results into the harness, and that was it?

The hollow extension pattern treats a Copilot CLI extension as a registration surface only. The extension's entire job is to wire an injectable factory into the harness — nothing more.

// hollow-extension.mjs — the pattern that works

import { PRAnalyzerFactory } from "./factory.mjs"; // all logic lives here

// Configure the factory — zero business logic in the extension itself
const factory = new PRAnalyzerFactory({
  timeoutMs: 8000,
  retries: 2,
  onError: (err, tool) => console.error(`[${tool}] failed:`, err.message),
});

// Extension is pure registration — no inline handlers
await joinSession({
  tools: factory.getTools(), // returns Tool[] array
  hooks: factory.getHooks(), // returns { onPreToolUse, onPostToolUse, onSessionStart }
});

That's the complete extension. Twenty-something lines. No inline business logic. No async footguns. No state.

I wasn't confident this would work. On paper it felt too simple, too thin to actually prevent a fleet-wide outage. But I tested it. The tools responded. The agents answered. The fleet came back online. I realized: sometimes you don't fix a reliability problem by adding controls. You fix it by removing surfaces where things can break.

The extension doesn't know what factory.getTools() returns internally. It doesn't know how the analyze-pr tool handles its GitHub API call, how it manages timeouts, or whether it batches requests. It just registers whatever the factory provides and starts the Copilot CLI extension host.

This is the dependency injection principle applied to extension architecture — and it's the same pattern I described in the three architectural layers every AI agent is missing. The extension is the registration layer. The factory is the logic layer. They're separate, and the separation is the safety mechanism.

The pattern is also a direct application of the factory method design pattern — a 30-year-old idea that turns out to be exactly what modern extension architectures need.

Factory Implementer SDKs

Once the hollow extension pattern was clear — register the contract, implement nothing — one question followed immediately: what fulfills the contract? That’s the moment it clicked. “Oh my God, I just thought of something — we can just CREATE what I just said.” The extension is describing a factory interface. So build the factory. That’s the entire factory SDK idea in one sentence.

The factory SDK is where all the real work happens — but it happens in isolation, behind a well-defined interface.

// factory.mjs — logic lives here, not in the extension
export class PRAnalyzerFactory {
  constructor(config) {
    this.config = config;
    // this.github, this.analyzer, this.ci, this.validator are injected deps
  }

  getTools() {
    // Returns the Tool[] array that joinSession expects
    return [
      {
        name: "analyze_pr",
        description: "Analyze a GitHub pull request",
        parameters: {
          type: "object",
          properties: {
            repo: { type: "string" },
            pr:   { type: "number" },
          },
          required: ["repo", "pr"],
        },
        handler: withTimeout(
          withRetry(async ({ repo, pr }) => {
            const data = await this.github.getPR(repo, pr);
            return await this.analyzer.analyze(data);
          }, this.config.retries),
          this.config.timeoutMs
        ),
      },
      {
        name: "run_ci_check",
        description: "Run a CI check on a branch",
        parameters: {
          type: "object",
          properties: {
            branch: { type: "string" },
          },
          required: ["branch"],
        },
        handler: withTimeout(
          async ({ branch }) => this.ci.check(branch),
          this.config.timeoutMs
        ),
      },
    ];
  }

  getHooks() {
    // Returns the hooks object that joinSession expects
    return {
      onSessionStart: async () => ({
        additionalContext: "[pr-analyzer] Factory extension active.",
      }),
      onPreToolUse: this.validator.preToolUseHook(),
    };
  }
}

Factory SDK Dependency Injection Flow — injected deps in, guarded contracts out. All logic owned by the factory, all registration owned by the extension.

Every tool is wrapped in withTimeout and optionally withRetry. The this.github, this.analyzer, this.ci, and this.validator dependencies are injected at factory construction — swappable, mockable, testable.

The factory approach also unlocks something I hadn't anticipated: I can now unit test all my tool logic without a running Copilot CLI session. I instantiate HarnessFactory with mock dependencies and test the handlers directly. The extension is just the deployment wrapper — the factory is the software.

This mirrors what I wrote about in What Is Harness as Code: declarative, injectable, reproducible. The fat extension anti-pattern is the same mistake as the god prompt monolith — everything bundled in one place because it was faster to write that way, slower to maintain.

What This Unlocks for the Extension Ecosystem

The hollow extension pattern makes extensions into interface specifications rather than monolithic bundles. Teams can build multiple factory SDK implementations against the same extension interface — swapping auth strategies, retry policies, or MCP connections without touching the extension registration layer. This is the composability model that makes extension marketplaces viable.

Here's what got me excited beyond the immediate reliability win: this pattern is the right foundation for a Copilot extension marketplace.

Right now, if you want to adopt someone else's Copilot CLI extension, you're installing their full implementation — their API keys, their error handling assumptions, their retry logic, their specific GitHub API version. You're accepting the whole fat extension as-is. The gh extension install command is a blunt instrument for this reason: you get the whole package, hardcoded decisions and all.

With the hollow extension model, extensions become interface specifications, not implementations. The extension publishes what tools and hooks it registers, and what interfaces the factory implementer must satisfy. Teams can build their own factory SDKs against those interfaces — using their own auth patterns, their own retry strategies, their own MCP connections. The TypeScript interface system is the natural contract layer here: publish the interface, version it separately from the implementation.

The Copilot extension platform already has the extensibility primitives to support this. Tools, hooks, and MCP connections are already first-class. The hollow extension + factory SDK separation is a pattern any extension builder can adopt today — no platform changes required.

I've written about the agentic development maturity curve before: at expert level, complexity collapses back to simple, explicit primitives. Fat extensions are the middle of that curve — impressive-looking, fragile. Hollow extensions are what you build when you've learned what actually goes wrong at 3 AM.

What Comes Next

The hollow extension pattern solved the fleet stability crisis. But it raised a new question: if the extension is just a registration surface, what about the factory SDK itself? How do you scale that? How do you compose multiple factory implementations? What happens when you have too many factories, too many injectable dependencies, too many layers?

I've been experimenting with an answer — a framework I've been calling "Harness as Code." It's the next iteration of the hollow pattern idea, and it changes how you think about building modular Copilot ecosystems.

That's Part 2.

The Pattern in Three Sentences

The line that crystallized it: "Not the files, the factory. Not the context, the mechanism." Every time I was chasing an extension bug, I was looking in the wrong layer. The extension is a file — inert, structural, just registration. The factory is the mechanism — where reliability lives, where tests run, where logic can be replaced without touching the extension surface. Fix the mechanism. Don't touch the file.

An extension's job is to tell the Copilot CLI harness what's available — not to be what's available. The business logic belongs in a factory SDK that owns its own timeout boundaries, error surfaces, and dependency graph. One bad extension shouldn't be able to take down your fleet. With the hollow pattern, it can't.

If you're building for the GitHub Copilot CLI ecosystem, this is the pattern I've landed on. Whether it stays this way, or whether Harness as Code evolves it further, I'm still learning. But the principle holds: don't embed logic in extensions. Separate registration from implementation. Guard every async boundary. That's the foundation.

Related: I Taught My AI Agent to Restart Itself — another extension architecture lesson learned the hard way.

I Replaced Playwright With Raw CDP

Hector Flores — Thu, 11 Jun 2026 11:27:32 +0000

The Agent Made a Better Call Than I Would Have

I was building a responsive design testing pipeline for a client project. The goal was simple: capture screenshots of every page section at 11 viewport sizes, feed them to an AI vision model, get a structured report of what's broken.

I handed the task to an agent and expected Playwright. It's the obvious choice — well-documented, clean API, every tutorial defaults to it. The agent had a different idea.

It reached for raw Chrome DevTools Protocol over WebSocket. No Playwright, no Puppeteer — just JSON-RPC messages sent directly to Chrome. When I dug into why, the answer was immediate: Playwright was failing to resize the browser window correctly at certain viewport dimensions. Direct Emulation.setDeviceMetricsOverride via CDP handled it cleanly. No abstraction layer fighting against you. Just a direct instruction to the browser.

I kept it.

That wasn't even the interesting part. What the agent built next — the approach it invented for getting AI to analyze multiple screenshots — turned out to be a general pattern I hadn't encountered before. I've started calling it compaction.

The Responsive Testing Problem

Manual responsive testing is one of those things that sounds manageable until you try to do it systematically. Eleven viewport sizes across a multi-section page with a password gate. That's potentially hundreds of screenshots. Reviewing them by hand isn't a workflow; it's a punishment.

You could automate the comparison with perceptual diff tools like Chromatic or Percy, but those require baseline screenshots and tell you that something changed — not whether the layout is actually correct. A broken layout you've never seen before passes as "no regression."

What I wanted was something different: an AI that could look at a layout and say "this section is cropped at 390px, that column collapses wrong at 768px, this text is illegible on ultrawide." Natural language, structural, semantic feedback — not a pixel diff.

The challenge was getting that feedback efficiently.

Why CDP and Not Playwright

The Chrome DevTools Protocol is the actual wire protocol underneath Chrome-based browser automation. Playwright translates high-level method calls into CDP messages for Chromium. So does Puppeteer. Selenium's DevTools integration does the same.

Going raw means connecting directly via WebSocket to a Chrome instance launched with --remote-debugging-port, then firing JSON-RPC commands yourself:

// Connect to Chrome
const client = new CDPClient(target.webSocketDebuggerUrl);
await client.connect();

// Set viewport — direct, no Playwright wrapper
await client.send('Emulation.setDeviceMetricsOverride', {
  width: 390,
  height: 844,
  deviceScaleFactor: 3,
  mobile: true,
  screenOrientation: { angle: 0, type: 'portraitPrimary' },
});

// Capture screenshot
const shot = await client.send('Page.captureScreenshot', {
  format: 'png',
  fromSurface: true,
  captureBeyondViewport: false,
});

No dependencies beyond Node.js 22+ (which has a stable built-in WebSocket global). The tool has one npm dependency: sharp for image compositing. Everything else is Node built-ins.

There's something clarifying about working at this level. You stop debugging "why is Playwright doing X" and start reasoning directly about what Chrome is doing. When viewport resizing wasn't behaving, there was no abstraction to blame and nowhere to hide — which made the fix obvious.

Raw CDP architecture: Node.js speaks JSON-RPC directly to Chrome — no Playwright in between, and only two npm dependencies: sharp and node:fs

The Compaction Insight

Here's where it gets interesting.

The naive approach to AI visual validation is: one screenshot per viewport, one vision API call per screenshot, aggregate results. For 11 viewports across 8 sections, that's 88 API calls. That's slow, expensive, and you lose something important: the ability to compare layouts side by side.

The agent built something smarter. For each page section, it composites all 11 viewport screenshots into a single labeled grid image using sharp:

┌─────────────────────────────────────────────────────────────┐
│  section-02 (hero) · Homepage Hero                          │
├──────────────────┬──────────────────┬──────────────────┬───┤
│ iphone14-portrait│ android-360x800  │ ipad-portrait    │...│
│  390×844         │ 360×800          │ 768×1024         │   │
│ [screenshot]     │ [screenshot]     │ [screenshot]     │   │
└──────────────────┴──────────────────┴──────────────────┴───┘

Each cell has a header strip showing the viewport slug and exact dimensions. The top banner shows the section ID and label. Everything the AI needs to orient itself is embedded in the image.

One image. One vision call. 11 viewports analyzed together.

That's the compaction. Instead of making the AI precise about pixel coordinates across dozens of separate images, you compact everything into a single reference frame where the labels are the coordinates.

AI can interpret an image through natural language, but it's hard to be precise about positioning. Compacting all the different views with text labels into one image solves that. The AI sees all the layouts simultaneously and can pull out a natural language analysis.

The math works out too: one call per section instead of one per (section × viewport). An 11× reduction in API calls, with better analysis quality because the model is comparing layouts in context rather than evaluating each in isolation.

The mosaic compaction pattern — 11 viewports → 1 labeled grid → 1 AI vision call. The cell headers are the coordinates. 11× reduction in API calls.

The Label→Mapping Loop

The output structure is what makes this a pattern rather than a one-off hack.

The vision prompt asks for strict JSON keyed by viewport slug:

{
  "section_id": "section-02",
  "viewport_results": {
    "iphone14-portrait": {
      "status": "ok",
      "issues": []
    },
    "ultrawide-3440x1440": {
      "status": "fail",
      "issues": [{
        "type": "empty_space",
        "severity": "high",
        "description": "Content occupies ~30% of horizontal space at 3440px — missing max-width constraint.",
        "suggested_css": "@media (min-width: 2400px) { .hero { max-width: 1800px; margin: 0 auto; } }"
      }]
    }
  }
}

The labels in the mosaic header become the keys in the output JSON. No post-processing, no coordinate math, no trying to figure out what the AI "meant" — the structure maps directly to the input labels.

That's the loop: you label your inputs, the AI returns findings indexed by those labels. Structured output from unstructured visual analysis.

The label→mapping loop: viewport slugs in the mosaic become keys in the JSON — no post-processing, no coordinate math, direct structured output from visual analysis

What It Actually Caught

I ran this pipeline on the SurgiQuip proposal page — a password-gated, multi-section client site I'd been building.

The result: it caught everything. Every single thing.

Every layout break I'd missed during development, every section that needed max-width handling at wide viewports, every place where the responsive grid didn't collapse cleanly. After re-running the resizes based on the AI's CSS suggestions, every aspect ratio worked.

The AI suggestions aren't a push-button fix — they're a starting point that still needs a human review before applying. "Looks right in the mosaic" isn't the same as "verified in a real browser." But as a first-pass audit that catches structural problems before a client sees them, it's genuinely remarkable.

This is exactly the kind of AI-augmented QA pattern that doesn't replace human judgment — it surfaces what human eyes would miss.

Where Else This Pattern Applies

When I stepped back after the build, the obvious question was: is this just for responsive testing? Honestly, no.

"You can do all kinds of stuff with this pattern. I found that fascinating." That's what I keep coming back to.

The compaction pattern solves a general problem: how do you get structured AI feedback across multiple visual states without making N separate API calls?

A few directions this applies:

Multi-state UI comparison. Composite "empty", "loading", "populated", "error" states of the same component side by side. Ask AI: "Which states have accessibility issues?" One call, structured answer.

Before/after design diffs. Instead of perceptual diffs, composite old vs. new side by side and ask AI: "What changed? Is any change unintentional?" Semantic diff instead of pixel diff.

Cross-browser visual regression. Same page, Chrome vs. Firefox vs. Safari, composited. AI spots rendering inconsistencies that diffs would catch, but also tells you what kind of inconsistency it is.

The key in all cases: labels in the mosaic become keys in the output JSON. You control the structure by controlling the labels.

The Honest Limits

This pipeline requires Chrome running locally with --remote-debugging-port. It doesn't run in a standard CI environment out of the box — you'd need headless Chrome configured to accept CDP connections, which is possible but not the default GitHub Actions setup.

Label quality directly affects analysis precision. Vague labels like section-01 give vague feedback. Section IDs and heading text embedded in the mosaic header give the AI something to reason about specifically.

And the CSS suggestions need human review. The AI is pattern-matching against known layout problems — it will catch max-width issues reliably, but complex responsive grid fixes should be read carefully before applying. This is an augmentation tool, not an autopilot.

The Tool Is in the Repo

The full pipeline lives in tools/responsive-design-testing/ — six scripts that chain together: capture.mjs (raw CDP), composite.mjs (sharp grid), analyze.mjs (vision queue builder), report.mjs, fix.mjs, and run.mjs as the single-command orchestrator.

Single-command usage:

node tools/responsive-design-testing/run.mjs `
  --url https://yoursite.com `
  --password optional-gate-pw

If you're using AI in your workflow and need visual validation of any kind — not just responsive testing — the compaction pattern is worth adding to your toolkit. The insight isn't the CDP part. It's the label→mapping loop. Once you see it, you'll find uses for it everywhere.

The Bottom Line

The agent chose a better tool than I would have, and in doing so, invented an approach I hadn't considered. Fewer abstraction layers meant more direct control over viewport behavior. One labeled composite per section meant 11× fewer API calls with better cross-viewport analysis.

That's two good ideas from one build — neither of which was in my original plan.

The pattern generalizes. Any time you need structured AI feedback across multiple visual states — responsive breakpoints, component states, browser diffs, before/after comparisons — compaction is the pattern. Label your inputs, get output mapped to those labels, skip the coordinate math entirely.

What would you use it for?

Resources

Chrome DevTools Protocol Reference
Emulation.setDeviceMetricsOverride
Page.captureScreenshot
sharp — High-performance Node.js image processing
Two Client Sites in 3 Days — the client project where this ran
Vibe Testing: When AI Agents Goodhart Your Test Suite — the AI testing trust problem
What Is Context Engineering? — the broader discipline this fits into

I'm Hunting for My Vertical

Hector Flores — Wed, 10 Jun 2026 15:59:03 +0000

One week. Five industries. One discovery that changed how I think about the next decade of software.

I built an agentic financial advisor, a legal advisor, a marketing tool, a scheduling assistant, and a medical workflow tool. Each was AI-powered. Each was genuinely useful. Each took me a few days to build.

The part that unsettled me wasn't how fast I could build. It was what the pattern meant.

Every vertical had a completely different character — its own compliance structure, its own procedural data, its own relationship dynamics. The more I understood a specific vertical's inner workings, the more powerful the AI outputs became. Conversely, the moment I built something generic — something for "everyone" — the value diluted immediately.

The moat isn't in the model. It isn't in the framework. It isn't even in how fast you can ship.

The moat is the vertical.

The Floor Has Dropped Out

Before we talk about why verticals win, we need to be clear about what they're winning against.

Jensen Huang said it plainly on the All-In Podcast this year: the competitive advantage in the AI era is no longer which model you run or how fast you can build. It's the vertical knowledge you bring to it. The moat is knowing more about a specific domain than anyone else and using AI to compound that knowledge gap.

Nikesh Arora, CEO of Palo Alto Networks, went further on the All-In Podcast this week: analytical SaaS is structurally dead. His argument: analytics companies exist to compress and synthesize context. That is exactly what any capable model does now, in seconds. The entire business model of "take in data, analyze it, give you something synthesized" has been replicated for free by any developer with a decent API key.

I've built those tools myself. Not as products — almost subconsciously, as a side effect of exploring an idea. The floor for horizontal software capability has dropped out.

a16z called it a moat migration last December: the moats haven't disappeared, but they've moved. Off the platform layer. Into the domain layer. Activant Capital framed it simply in their February 2025 analysis: the industry context that used to be a feature is now the product itself.

Horizontal capability is not the moat anymore. It is the price of entry.

Why Verticals Win

During my week of building across five industries, one engagement hit differently. I was working on a medical device servicing application — the kind of tool that tracks maintenance procedures, compliance documentation, and field technician workflows for hospital equipment.

What I found was a textbook example of why vertical depth creates defensible moats that horizontal tools can't touch.

Compliance power. Hospitals make massive investments in medical devices. Once you're qualified to service that equipment — once you're in their system, accredited, embedded in their workflow — switching is genuinely hard. Add AI that learns their specific device fleet, their procedure history, their technician notes? The moat deepens with every service call. The longer you're in, the more structurally irreplaceable you become.

Proprietary data. Medical devices run on ancient technology, but they're extraordinarily verbose. Specs, error codes, procedure manuals, maintenance logs — it's all procedural, structured, richly contextual. No generic inventory app has this data. A purpose-built vertical application that accumulates it over years is in a different category entirely. Euclid Ventures describes this as the layer commoditization cycle inverting: vertical players who own deep domain data become more valuable as the horizontal layer commoditizes.

Relationships and infrastructure. The relationship a medical device service company has with a hospital isn't just commercial — it's operational. Field techs know the equipment. Schedulers know the facilities manager. AI layered into those workflows doesn't just make things faster; it makes the relationship stickier. You're not selling software anymore. You're part of the hospital's operational continuity.

This pattern exists in every high-relationship, high-compliance vertical: construction, energy, legal, logistics. The specifics change. The structure doesn't. Generic tools exist for all of them. ServiceBridge handles field service dispatch for general contractors. Generic inventory apps cover dozens of verticals. But "general" is not "deep." A tool built for the medical device servicing vertical — one that knows the specific procedural documentation, compliance requirements, and switching costs of that niche — isn't ServiceBridge. It's something that only gets built by someone who went truly, irreversibly deep.

The three moats generic AI tools can't replicate: compliance power, proprietary data, and operational relationships — all compounded through accumulated vertical depth.

The Context Payoff

Here's what nobody talks about: when you go deep enough into a vertical, something remarkable happens. Your accumulated domain knowledge becomes a structural weapon that no generalist can replicate.

The ability to build software is no longer a strong asset.

Being able to execute a workflow is no longer a strong asset.

Knowing what workflow to execute is the strong asset.

Knowing what context to bring in is the asset.

The context is the asset. But here's the key: the context doesn't exist in isolation. It flows from the vertical.

Capability is table stakes. The competitive weapon is knowing which context to inject — and that knowledge only comes from going deep in a vertical.

A generalist with access to the best available model still doesn't know the compliance calendar of a mid-sized orthopedic device distributor in the Southeast. That knowledge — accumulated through years of patient relationship-building, procedural specificity, and domain learning — can't be generalized away. It can't be scraped. It can't be approximated from public data.

This is why I've been thinking about this in terms of vertical specialization, not just "context engineering." When I wrote about what context engineering actually looks like at scale, the model kept being a commodity — the real discipline was shaping what the model sees. The same principle applies at the company level. The company that owns the vertical owns the best context. Stax's 2026 analysis of vertical SaaS reached the same conclusion: rather than flattening vertical software, AI is separating the companies with deep domain data from those without it.

Deep wins. Generic loses.

The Agentic Development Company

Here's the structural opportunity I think we're dramatically underbuilding toward.

Between the hyperscalers — the foundation model providers building AI infrastructure — and the SMBs and mid-markets that need AI-native workflows, there's a missing layer. Someone has to own the vertical workflow integration. Someone has to take general-purpose AI capability and make it fluent in the operational language of a specific industry.

That's the agentic development company.

Not a software consultancy. Not an IT services firm. An agentic-first vertical specialist that builds, owns, and continuously deepens AI-native workflows for one target industry. a16z framed the strategic choice as oil wells vs. pipelines: oil wells drill deep into proprietary data and domain relationships; pipelines move generic data efficiently. The agentic development company is an oil well operation. You go deep on one vertical. You build systems that understand it at a level no horizontal tool can match.

This is the new Accenture moment — but for the long tail of SMBs the original system integrators never served. Every vertical that runs on high-relationship, high-compliance, high-procedural context is an open field right now.

I wrote about this pattern in terms of the agentic development maturity curve: mastery looks like simplicity because experts stop building everything and start targeting what moves the needle. Going vertical is the same principle applied to market strategy. Frameworks don't execute themselves — and general-purpose software doesn't execute your specific compliance workflow either. The execution layer belongs to whoever owns the vertical.

The Hunt

I've spent most of my career as a general engineer. I can build anything — full-stack, DevOps, agentic systems, enterprise platforms. The breadth was the point. For a long time, it was valuable.

It still is. But the game has changed.

The ability to build is now table stakes. Every ambitious engineer I know can spin up an AI-powered tool in a week. The question is no longer can you build it? It's which vertical do you own?

I'm on the hunt for mine. I want to take everything I've built — the agentic development systems, the DevOps depth, the enterprise platform experience — and target a specific vertical deeply enough that the context I accumulate becomes structurally irreplaceable. Not just a tool. An institution.

Jensen's framing landed because it confirmed something I'd already felt empirically after that week of building. The model isn't the advantage. The industry is.

If you're at the same inflection point — a general engineer who can build anything, wondering whether breadth is still the edge — I'd argue: pick your vertical. Go deep. The context richness will follow.

The moat isn't your model. It isn't your framework. It's the vertical you own.

I'm on the hunt for a vertical worth owning — one where ambitious people want to fundamentally change how their industry runs with AI. If that's you — if you're an operator or leader inside a specific vertical, serious about what agentic capability could do there — I want to hear from you. Not looking for a client. Looking for the right vertical.

Resources

Jensen Huang: Nvidia's Future, Physical AI, Rise of the Agent — All-In Podcast (YouTube)
Palo Alto Networks CEO: "AI Found 5 Years of Bugs in 6 Weeks" — All-In Podcast featuring Nikesh Arora (YouTube, June 8, 2026)
Why AI Moats Still Matter (And How They've Changed) — a16z, December 2025
Oil Wells vs. Pipelines: Two Strategies for Building AI Companies — a16z, August 2025
Does AI Threaten Vertical SaaS? — Euclid Ventures, June 2025
Vertical Software Is Having A Moment — Activant Capital, February 2025
How AI is Reshaping Vertical SaaS — Stax, February 2026
ServiceBridge — field service management for general contractors

Your GitHub Actions Don't Need Secrets

Hector Flores — Fri, 05 Jun 2026 18:54:27 +0000

Copy-Paste Workflows Don't Scale

Every platform team hits the same wall. You start with a handful of repos, each with bespoke CI/CD workflows. Twelve months later you have 200 repos, and every deployment pipeline is a snowflake. Engineers copy YAML from Slack threads. Secrets sprawl across repositories. Nobody can answer "who deployed what, and with which permissions?"

I hit this wall at a Fortune 500 energy company, managing CI/CD for an enterprise DevOps platform. We went from 2–3 teams to 300 teams across roughly 1,000 repositories — all on GitHub Actions — in under two years. The secret wasn't better YAML. It was treating Actions as a platform engineering problem, starting from identity.

GitHub Actions processed 11.5 billion minutes in 2025 alone — up 35% year-over-year — with 71 million jobs running per day on its re-architected backend. At that scale, the question isn't "does Actions work?" — it's "how do you govern it without becoming a bottleneck?"

Here's the recipe: identify bottlenecks → codify them → scale identity.

The Subject Claim Problem (And Why I Built an OIDC Broker)

GitHub Actions supports OpenID Connect (OIDC) federation for passwordless cloud authentication. In theory, every workflow gets a short-lived token scoped to its repo. No more long-lived secrets sitting in repository settings.

In practice? The sub (subject) claim in GitHub's OIDC token has a structural limitation: when you call a reusable workflow, the token's subject reflects the caller context, not the called workflow. This makes it difficult to enforce "only this approved deployment workflow can authenticate to production Azure resources" — because the subject claim doesn't consistently identify which reusable workflow is executing.

GitHub has since added job_workflow_ref as a custom claim and introduced immutable subject claims (enforced for new repos, renames, and transfers after June 18, 2026 — existing repos can opt in now). But when I was building this platform, those features didn't exist yet.

My solution: a custom OIDC server acting as an identity broker.

The broker accepts a GitHub Actions OIDC token, validates it against the caller's identity, checks the requested scope against a centralized policy, and issues a new scoped token for Azure. Think of it as an identity translation layer sitting between GitHub and your cloud provider.

The custom OIDC broker validates GitHub tokens, checks centralized policy, and issues least-privilege Azure credentials — eliminating long-lived secrets entirely.

At the heart of the broker is a standard OAuth2 client credentials flow — one /token endpoint, three operations:

// OIDC broker — token exchange endpoint (routes/github.ts, condensed)
router.post('/github/.well-known/token', async (req, res) => {
  const { client_assertion, type = 'job-workflow-ref' } = req.body;

  // 1. Verify the GitHub Actions OIDC token against GitHub's public JWKS
  const payload = await new Promise((resolve, reject) =>
    jwk.verify(client_assertion, githubJwksClient, {
      issuer: 'https://token.actions.githubusercontent.com',
    }, (err, decoded) => err ? reject(err) : resolve(decoded))
  );

  // 2. Gate access — only your enterprise can use this broker
  if (payload.enterprise !== '<your-enterprise-slug>') {
    return res.status(403).send('Unauthorized');
  }

  // 3. Derive a controlled sub claim from job_workflow_ref.
  //    This is the fix for the sub-claim problem: the BROKER controls the subject,
  //    not GitHub, so Azure federated credential policies are reliable for
  //    reusable workflows regardless of who called them.
  const sub = payload.job_workflow_ref.replace('refs/heads/', '');
  // → "org/repo/.github/workflows/deploy.yml@main"

  // 4. Re-issue a JWT signed with the broker's RSA private key.
  //    Azure trusts this because the broker's /jwks endpoint is registered
  //    as a federated identity credential on the Entra ID application.
  const token = jwk.sign({
    aud:  'api://AzureADTokenExchange',
    iss:  `https://${req.headers.host}/github`,
    sub,
    jti:  randomUUID(),
    exp:  Math.floor(Date.now() / 1000) + 3600,
  }, privateKey, { algorithm: 'RS256', keyid: brokerKeyThumbprint });

  res.json({ id_token: token });
});

The sub derivation on step 3 is the entire point. GitHub's raw OIDC token produces an unpredictable subject when reusable workflows are involved — the broker re-signs with job_workflow_ref as a stable, auditable identity. Azure's federated credential policy can now reliably match on "only this approved workflow can authenticate to production."

# A team's CD workflow — the entire Azure auth chain is one step
name: 🚀 CD

on:
  release:
    types: [created]
  pull_request:
    branches: [main]

env:
  ENVIRONMENT: ${{ github.event_name == 'pull_request' && 'dev' || 'prod' }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ env.ENVIRONMENT }}
    permissions:
      id-token: write   # required for OIDC token request
      contents: read
    steps:
      - uses: actions/checkout@v4

      - name: 🔑 Login to Azure
        uses: <your-org>/platform-framework/actions/azure-login@main
        with:
          iam-name: ${{ env.ENVIRONMENT }}        # 'dev' or 'prod' — matches iam.yml job name
          iam-connection-name: AZURE_CREDENTIALS   # matches iam.yml credential binding
          secrets-as-json: ${{ toJson(secrets) }}  # platform reads clientId from here
          vars-as-json: ${{ toJson(vars) }}         # platform reads tenantId/subscriptionId from here

      - name: Deploy to Azure App Service
        uses: azure/webapps-deploy@v2
        with:
          app-name: ${{ vars.APP_NAME }}
          package: .

This single composite action became the foundation everything else was built on. Every team authenticates the same way. Every permission is centrally governed. No secrets in repos.

The Framework Stack: Each Framework = GitHub App + Identity + Reusable Workflow

With centralized identity solved, I layered five frameworks on top — each following the same architecture pattern:

Each framework follows the same pattern: GitHub App + Entra ID App + Reusable Workflow — all built on the shared identity layer.

Framework	Purpose	What Teams Define
IAM	Identity and access management	RBAC roles in a YAML workflow file
Secrets	Central Key Vault management	Secret names and scopes
IAC	Infrastructure as Code (Bicep → Azure)	Bicep modules and parameters
Docs	Centralized documentation deployment	Markdown content
Config	Configuration management	Environment variables and app settings

Each framework consists of three components:

A GitHub App — provides the automation identity and webhook triggers
An Entra ID (Azure AD) app — holds the federated credential with scoped permissions
A reusable workflow — the actual pipeline logic teams call from their repos

The IAM Framework: The Crown Jewel

The IAM framework is where this architecture pays off most dramatically. Here's the team experience:

# .github/workflows/iam.yml
# Merge this PR → the IAM framework auto-provisions Entra ID apps,
# federated credentials, and RBAC assignments for every environment.
name: 📋 Platform | Identity and Access Management

on:
  workflow_dispatch:
  push:
    branches: [main]
    paths: ['.github/workflows/iam.yml']

jobs:
  dev:
    uses: <your-org>/platform-iam/.github/workflows/define.yml@main
    with:
      name: dev
      definitions: |
        github/env/dev/AZURE_CREDENTIALS
        rbac/subscriptions/<dev-subscription-id>/Contributor
        rbac/subscriptions/<dev-subscription-id>/Azure Deployment Stack Owner
        rbac/subscriptions/<hub-subscription-id>/resourceGroups/rg-dns-hub/Private DNS Zone Contributor

  prod:
    uses: <your-org>/platform-iam/.github/workflows/define.yml@main
    with:
      name: prod
      definitions: |
        github/env/prod/AZURE_CREDENTIALS
        rbac/subscriptions/<prod-subscription-id>/Contributor
        rbac/subscriptions/<prod-subscription-id>/Azure Deployment Stack Owner
        rbac/subscriptions/<hub-subscription-id>/resourceGroups/rg-dns-hub/Private DNS Zone Contributor

When a team pushes this file, the IAM framework:

Creates an Entra ID application registration
Configures federated credentials tied to their specific repo
Stores the client ID as a repository variable
Sets up RBAC assignments in Azure

The team then calls the login composite action with a version tag — that's it. Zero portal clicks. Zero tickets. Full auditability.

Result: a new team goes from "we need Azure access" to "we're deploying to production" in a single PR review cycle.

The Scaling Arc: Patterns That Actually Matter

A 2025 practitioner survey of 419 GitHub Actions users found that while reusable actions see heavy adoption, reusable workflows remain underutilized — largely because teams fear versioning complexity and loss of control. This matches what I observed: teams resist reuse unless the abstraction is genuinely simpler than copy-paste.

The patterns that made reuse stick:

1. Composite Actions as the Building Block

Composite actions (not reusable workflows) are where you start. They're simpler to version, test, and compose. Our login-to-azure action is called by every framework's reusable workflow — it's the atomic unit.

2. Reusable Workflows as Contracts

Reusable workflows define the contract — "this is how you deploy infrastructure" or "this is how docs get published." GitHub recently expanded these to support 10 levels of nesting and 50 workflow calls per run, which validates the deep composition patterns we built early.

3. Trigger Type Literacy

The most underrated skill in Actions at scale: understanding trigger types deeply. workflow_call vs workflow_dispatch vs repository_dispatch each has fundamentally different trust boundaries and token behaviors. Most engineers treat them interchangeably — and then get bitten by permission escalation or silent failures.

4. Central Repos as the Source of Truth

Each framework lives in a dedicated repo. Teams never fork — they call with version tags. Updates propagate instantly. Governance lives in one place.

From CI/CD to Intelligent System

The final evolution was adding intelligence on top of the platform. Using webhooks and GitHub Issues, we built:

AI-powered issue categorization: incoming platform issues get triaged automatically
Automated release notes: framework releases generate changelogs from PR descriptions
Policy drift detection: nightly runs compare actual Azure state against declared YAML

None of this required a separate tool. The identity layer, the reusable workflows, and the event system were already there. Intelligence was just another consumer of the same platform primitives.

Your Playbook: The Three-Step Recipe

If you're staring at 50+ repos with snowflake workflows, here's the path:

The three-step recipe that scales from 3 teams to 1,000 repos: centralize identity, codify frameworks, let identity scale itself.

Solve identity first. Whether you use GitHub's native OIDC (with the newer job_workflow_ref claims and repository custom properties) or build a broker — centralized, auditable identity is your foundation.
Build frameworks, not pipelines. Each framework should be composable (composite action → reusable workflow → team YAML). Teams should define what they need, not how to get it.
Scale the identity, not the humans. When a new team onboards, they shouldn't need a meeting. They define their requirements in YAML, the framework provisions everything, and identity flows through automatically.

AstraZeneca scaled 5,000 developers across 20,000 repositories on GitHub Enterprise using similar patterns — reusable Actions libraries with security baked in by default. The pattern works whether you're 50 engineers or 5,000.

The Bottom Line

GitHub Actions at enterprise scale isn't a YAML problem — it's a platform engineering problem. The organizations that scale are the ones that treat identity as infrastructure, workflows as contracts, and frameworks as products with versioned APIs.

I've written extensively about platform engineering with GitHub and how GitHub Actions debugging fits into this picture. If you're building internal developer platforms, the identity-first approach is the one architecture decision that makes everything else possible.

The recipe hasn't changed since I scaled to 1,000 repos: identify bottlenecks → codify them → scale identity. Everything else is implementation detail.

You're Not Doing GitOps (You're Doing CI/CD With Extra Steps)

Hector Flores — Fri, 05 Jun 2026 18:53:18 +0000

The Uncomfortable Truth

Here's a test: when your deployment fails in production, what happens to your main branch?

If the answer is "the broken code is already merged" — congratulations, you're doing CI/CD with a Git trigger. That's not GitOps. It's a pipeline that happens to watch a branch.

I've spent years building platform engineering systems at enterprise scale — identity management frameworks, infrastructure-as-code pipelines, AI agent platforms that manage operational code. And I keep seeing the same mistake: teams adopt "GitOps" by adding a deployment step after merge, then wonder why they get drift.

True GitOps has one non-negotiable rule: main always equals production. If a deployment fails, main doesn't change. Period. This isn't just my opinion — it's the logical extension of OpenGitOps principles: declarative desired state, versioned in Git, automatically reconciled. The enforcement mechanism I'm describing is how you make those principles real rather than aspirational.

The Anti-Pattern Everyone Runs

The most common "GitOps" setup I see in enterprise teams looks like this:

Developer opens PR
CI runs tests
Reviewer approves
PR merges to main
Deployment triggers from main
❌ Deployment fails
main now contains code that isn't in production

CI/CD deploys after merge (drift risk) vs GitOps deploys before merge (main = production)

This is merge-then-deploy. It's standard CI/CD with extra steps. The moment you merge before confirming a successful deployment, you've broken the core GitOps contract: Git as the single source of truth for what's actually running.

The result? Drift. Stale state in main. A branch that lies about what's deployed. Every subsequent PR is now based on a broken foundation.

The Enforcement Pattern: Deploy Before Merge

The fix isn't philosophical — it's mechanical. GitHub's Merge Queue gives you exactly the right primitive:

Developer opens PR
CI runs tests (standard checks)
Reviewer approves → PR enters the merge queue
Merge queue trigger runs a dry-run deployment against the target environment
If dry-run passes → queue trigger runs the live deployment
If live deployment succeeds → PR merges to main
If deployment fails → PR is rejected. main stays clean.

The MergeQueue pattern: code proves it can deploy before it's allowed to merge

This is the critical difference. The merge is the receipt, not the trigger. By the time code lands in main, it's already proven it can deploy successfully. main never lies.

GitHub ships hundreds of changes per day using exactly this pattern — batch PRs into merge groups, test and deploy the group, merge only on success.

Environment Parity: The Force Multiplier

The MergeQueue pattern only works if you've solved the second GitOps requirement: environment parity.

Every environment — dev, staging, production — should deploy using the exact same scripts. The only difference is configuration parameters. If your prod deployment uses a different process than dev, you've introduced a variable that the merge queue can't validate.

Here's the mental model: environments aren't stages in a pipeline. They're instances of the same declaration with different inputs. Your Terraform modules, your Helm charts, your infrastructure definitions — same code, different .tfvars or values.yaml.

This is where I see the most breakage. Teams invest in merge queues but maintain hand-rolled production deployment scripts that diverge from their staging process. In my experience, the #1 thing that breaks production is environmental differences — not bad code, not missing tests, but a deployment process that works differently in prod than it did in staging. HashiCorp's Well-Architected Framework emphasizes this same principle: operational artifacts in Git should be the single declaration that drives all environments.

Where to Start: The High-Stakes Workflow

If you're onboarding a platform engineer into a GitOps-first team, don't start with app deployments. Start with networking-as-code or firewall-as-code — systems where a failed deployment can be company-destroying.

Why? Because it forces the right engineering instincts:

"How do I ensure this deployment succeeds before it's live?"
"What happens when the pipeline fails halfway through?"
"How do I roll back without manual intervention?"

These aren't theoretical — they're survival questions when you're managing production firewalls through code. The rigor you develop there carries into every other GitOps workflow.

Infrastructure-as-code for identity management is another excellent starting point. I've built systems where Entra ID applications with RBAC definitions are entirely managed through code — every role assignment, every app registration, every permission scope. The MergeQueue pattern here means a misconfigured role never reaches production without a successful dry-run proving it resolves correctly.

AI Agents Make GitOps More Critical, Not Less

Here's where the conversation gets forward-looking. AI agents — GitHub Copilot coding agent, autonomous infrastructure bots, custom platform agents — are increasingly the primary authors of operational code. The traditional distinction between GitOps and CI/CD matters more than ever when machines are the ones making commits.

This doesn't make GitOps obsolete. It makes it non-negotiable. I've written about why governed agent systems need exactly this kind of enforcement — and the GitOps substrate is how you get there.

Consider: if an AI agent can codify a process — user onboarding, access provisioning, network configuration — and you have a deterministic sync process validating that code, you can safely let agents manage entire operational domains. The GitOps pattern becomes the guardrail that makes autonomous agents viable.

I run 50+ AI agents managing operational code daily. They don't hit APIs directly — they modify code, which flows through the same MergeQueue validation as human-authored changes. Policy violations surface as deployment failures. The agent's code either passes or it doesn't. No special paths, no elevated privileges, no drift.

The enforcement pattern:

Agent proposes a change (PR)
Merge queue validates deployment
If it passes: merge. If not: reject.
The agent is subject to the same rules as any engineer.

This is where the industry is heading. Harness calls it "agentic AI in DevOps" — autonomous agents that observe, reason, and act on infrastructure. I've explored this convergence in agent-proof architecture for agentic DevOps. But without GitOps as the substrate, autonomous agents become autonomous drift generators.

The Litmus Test

Before you call your workflow "GitOps," answer these three questions:

If a deployment fails, does main still change? If yes — that's CI/CD.
Can you reconstruct every environment from Git alone? If no — you have drift.
Are agents and humans subject to the same merge rules? If no — you have a governance gap.

If all three pass, you're doing GitOps. If not, you're doing CI/CD with a Git trigger — and that's fine, but call it what it is.

The Bottom Line

GitOps isn't a tooling choice — it's an enforcement philosophy. The core contract is brutally simple: main equals production, always. The MergeQueue pattern is how you mechanically enforce that contract. Environment parity is how you make it trustworthy. And as AI agents become your primary infrastructure operators, that enforcement isn't just nice-to-have — it's the only thing standing between autonomous agents and uncontrolled drift.

Stop deploying after merge. Start merging after deployment. That's GitOps.

Resources

How GitHub Uses Merge Queue to Ship Hundreds of Changes Every Day — GitHub Engineering
OpenGitOps Principles — CNCF
GitOps When AI Agents Are Making Commits — Particle41
AI Won't Kill IaC — It Will Make It Non-Negotiable — Firefly
HashiCorp Well-Architected Framework: GitOps — HashiCorp
Agentic AI in DevOps: The Architect's Guide — Harness
What Is the Difference Between GitOps and CI/CD? — Unleash
GitHub Copilot Coding Agent — GitHub Docs
Microsoft Entra ID Platform Overview — Microsoft Learn