Skip to main content
Insight

Agents Are Services

An agent running in your pipeline is not a clever developer tool. It is a service. It gets an identity, a permission scope, a sandbox, a budget, and a short list of things it is never allowed to do - the same contract every other workload in production already signs. Skip that contract and you have an unmonitored engineer with production access and no judgment.

Most organizations have not skipped it on purpose. They bought Era 3 tooling - agents that run for hours, open pull requests unattended, and repair their own builds - and dropped it into an Era 2 process designed for one human reading one human's diff. That gap is where every failure pattern I see actually lives.

This piece is the contract, written down: what an agent gets, what it never gets, and what it does when it hits a wall.

Hire Me
Agents in a CI pipeline run as services with their own identity, permissions, sandbox, and budget

"An agent with write access to a protected branch is an unmonitored engineer with no judgment. Nobody would hire that person. Teams grant it to a bot every week."

Context

Three Eras, Three Units of Trust

Autocomplete

2021 to 2023

Keystroke-level suggestions, tab to accept. Copilot previewed in June 2021 and went GA in June 2022. The developer controlled every line, because every line was still typed or explicitly accepted by a human.

Unit of trust: the line.

Synchronous Agents

2023 to 2025

Chat and agentic IDE loops. One task at a time, a human watching the whole time, directing and correcting. The developer stopped reading every keystroke and started reading the result.

Unit of trust: the diff.

Autonomous Agents

2025 onward

Agents run for hours in CI and cloud sandboxes, open pull requests unattended, and run in parallel fleets. The developer defines the problem, approves the plan, and reviews the artifacts and the evidence - not the keystrokes, and increasingly not the whole diff.

Unit of trust: the plan and the evidence pack.

The third era is not a forecast. GitHub's coding agent authored over one million pull requests between May and September 2025. By March 2026 more than one in five code reviews on GitHub was a Copilot review, 60 million in total. By September 2026 GitHub was previewing AI review approvals that count toward required reviews. Anthropic said more than 80 percent of the code merged to its own production in May 2026 was authored by Claude. Treat every vendor figure as a self-report with its own definition of "authored," but the direction is not in dispute.

Era 2 practice - a human reads every line - does not scale to Era 3 volume. Era 3 practice, meaning plan approval, risk-tiered review, generated evidence, and mutation-scored tests, is not yet common. The rest of this piece is the part of that practice that applies to the agent itself.

The Contract

Identity, Permissions, Sandbox, Budget

Four things every agent in a pipeline gets before it runs a single task. None of them are exotic. All of them are the things a platform team already does for a microservice, applied to a workload that happens to write code.

Identity

Seats authenticate humans. Pipelines get their own identity: a service account or workload identity on the vendor's API platform. Never a personal OAuth token, and never a shared key sitting in a repo secret that outlives the person who created it.

Prefer workload identity federation where the vendor supports it - the CI job exchanges its OIDC token for short-lived access and nothing is stored. Anthropic's went GA in June 2026. Constrain the federation rule to specific repos and refs; a bare repo:org/* subject matches fork pull requests.

One identity per workflow class - review, repair, implement - so audit and budget are attributable to the workflow, not to whoever set it up. On the source-control side the agent acts as a GitHub App, not the default GITHUB_TOKEN and not a person.

Commits land under a bot identity that carries the ticket ID. When something breaks, the postmortem can name the workflow, the model version, and the task in one query.

Permissions

Read access to the repo. Write access to a branch namespace the agent owns, agent/*, and nothing else. No write to protected branches. No approve on its own pull requests.

A tool allow list: build, test, lint, formatter, and the package manager in lockfile mode. A deny list: anything that deploys, anything that touches credentials, anything destructive. Least privilege, enforced in the harness configuration, not requested in the prompt.

No production credentials in the agent's environment. No production data in its fixtures. Synthetic only.

Every MCP server and connector the agent can reach is reviewed like a dependency - who wrote it, what it can read, what it can write, whether it carries instructions in its responses - and pinned by version. Several MCP servers, including the reference filesystem and git servers, have shipped CVEs.

Sandbox

An ephemeral runner or container per task. Nothing persists between runs except what lands in the pull request. If the agent went somewhere strange on Tuesday, Wednesday's run does not inherit it.

Network egress allow-listed to the package registries and APIs the task actually needs. An agent that can reach the whole internet is an agent that can be talked into fetching instructions from it.

Secrets injected at runtime with the narrowest possible scope, and never written to the working tree. A secret in the working tree is a secret one confused commit away from the repo.

Budget

A per-workflow token budget, so a runaway loop costs twelve dollars, not twelve hundred. That number is the difference between a Slack message and a meeting with finance.

Spend tagged by repo, workflow, and ticket. If you cannot say what a merged pull request cost the agent to produce, you cannot say whether the work class was worth delegating.

A hard monthly cap on the API platform with an alert at 70 percent.

Attempt limits. Two repair attempts, then the agent pages a human and stops. Not three, not "until green." Two.

Non-Negotiable

Seven Hard Rules, Enforced in the Workflow

These are not guidelines and they are not prompt text. Each one is a check in the workflow definition that fails the run when it is violated.

  • The agent never pushes to a protected branch. It opens a pull request. There is no exception for "it was only a lockfile."
  • The agent never modifies an assertion, deletes a test, or adds a skip to make a build pass - unless the pull request is labeled test-weakened and routed to a human. The cheapest path to green is almost always weakening a test, and a model under pressure will find it.
  • Two repair attempts, then it pages a human and stops. A third attempt is a model guessing harder, not understanding better.
  • Every repair pull request carries the original failure log. The reviewer sees what actually broke, not the agent's summary of what it thinks broke.
  • If the agent cannot produce a failing test for a bug, it posts its analysis to the ticket and stops. No patch without a repro. A confident patch for a misdiagnosed bug is worse than no patch.
  • Every agent pull request states its model version, its task source, and what it verified. Unpinned means unreproducible, and "it passed" is not a verification statement.
  • The agent never approves, merges, or re-requests review on its own pull request. Every production change has a named human approver willing to own the outcome.

The part teams get wrong is where these rules live. Instruction files - CLAUDE.md, AGENTS.md - are advisory. They are the right place for conventions, build commands, and architectural context, and I keep them short and reviewed like code. But the model can and will deviate from them under pressure, because that is what a model optimizing for a green build does.

Anything that must never happen is a hook or a harness permission that blocks the tool call before it executes. A pre-tool hook that refuses a push to main is enforcement. A sentence in a markdown file asking the agent not to is a request. Put the never-events in hooks.

Delegation

What Runs Unattended, and What Never Does

Safe to Delegate Unattended

Opens a draft pull request, goes through normal review, no human watching the run.

  • Test backfill on existing behavior
  • Dependency bumps and deprecation fixes
  • Copy and i18n
  • CRUD endpoints behind a flag, schema-driven forms
  • Lockfile drift, formatting, type errors after a dependency bump
  • Flaky test quarantine and snapshot updates
  • Release notes and documentation

Never Unattended

A human directs the agent in the IDE, or the agent does not touch it at all.

  • Money and eligibility math
  • Auth and session handling
  • PII paths
  • Rule engines
  • External adapters to systems of record
  • Infrastructure and deploy configuration
  • Anything where the cheapest path to green is weakening a test

The safe class is boring on purpose. The most common way I have seen unattended agents go wrong is a team that got comfortable on dependency bumps and decided the auth module was basically the same thing. It is not. The safe class earns trust because a mistake there is cheap to catch and cheap to revert. The never-unattended class is the list of places where a plausible-looking mistake ships to a customer, a regulator, or a ledger.

Operating Model

Two Lanes, and a Failing Test Before Any Patch

Lane A - The Default

Developer-driven, with an agent in the IDE. The developer is the author of record, directs the work, reads what comes back, and owns the pull request. This is where most work lives and it is where all of the never-unattended class lives.

Lane B - Labeled

Agent-driven, on tickets explicitly labeled agent-eligible. The agent opens a draft pull request unattended. It starts on the safe class only and expands one work class at a time, and each expansion is gated on change failure rate holding flat. If the failure rate moves, the lane narrows again.

Inside Lane B, the pattern that keeps bug fixes honest is that the agent's first deliverable is a failing test, not a patch:

  • An error surfaces in monitoring. The agent triages it from the session replay and the trace.
  • Can it write a test that fails today? If not, it posts its analysis to the ticket and stops. A human picks it up with a head start instead of a wrong patch.
  • If it can, it commits the failing test first. That commit is the proof the bug was understood.
  • It fixes until that test passes, and only that test. No opportunistic refactoring on the way through.
  • It opens a draft pull request carrying the before-and-after evidence, and the pull request enters risk-tiered review like anything else.

Without the failing-test rule you get confident patches for misdiagnosed bugs, which is worse than no patch. The patch looks finished, the ticket closes, and the actual bug is still there wearing a green checkmark.

The same discipline applies to self-healing pipelines. Auto-repair works on a narrow failure class - lockfile conflicts, formatting, type errors, snapshots, flaky tests, infrastructure retries - and is dangerous outside it. The workflow classifies the failure first. Anything outside the safe class pages a human. Inside it, the agent gets its two attempts, and any fix that weakens a test gets labeled and routed to a human instead of merged. A pipeline that heals itself by lowering its own bar is not healing.

Sourced

What the Evidence Says

  • The volume is already here. GitHub reported over one million pull requests created by its coding agent between May and September 2025. Every one of those entered a review process that was designed before agents could open pull requests. GitHub Octoverse 2025 (source dated 2025-10; verified 2026-09)
  • Human oversight erodes quietly. Faros AI's 2026 report, covering 22,000 developers across 4,000 teams, found pull requests merged with no human review up 31.3%, 25% of pull requests now reviewed by an AI agent, and incidents per pull request up 242.7%. That is what Lane B looks like without tiered review and a merge queue. Faros AI, The Acceleration Whiplash (source dated 2026-05; verified 2026-09)
  • AI review helps, and humans step back at the same time. Qodo found that among developers reporting productivity gains, 81% of those using AI code review saw quality improvements, versus 55% of fast-moving teams without it. From the same vendor's own telemetry: when an AI review tool is enabled, 80% of pull requests receive no human comment or review, and 17% of pull requests contained a high-severity issue. Both findings are true. You have to manage the second one. Qodo, 2025 State of AI Code Quality (source dated 2025-06; verified 2026-09)
  • The review layer is now mainstream. GitHub reported 60 million Copilot code reviews by March 2026 - more than one in five code reviews on the platform - with 71% surfacing actionable feedback. A first pass that catches the mechanical issues is worth having. It is not a human approver. GitHub, 60 million Copilot code reviews (source dated 2026-03; verified 2026-09)
  • And the platform will now let it approve. Since September 2026, Copilot code review can count toward required approvals - in preview, off by default, and scopable by path. An AI approval satisfying a human approval requirement is the exact control failure the rest of this page exists to prevent. Leave it off for every Tier 3 path, and probably everywhere until your no-comment-merge metric is instrumented. GitHub changelog, Copilot code review approvals (source dated 2026-09; verified 2026-09)
  • The controls exist; the work is turning them on. GitHub's Enterprise AI Controls and agent control plane went GA on 26 February 2026 with an AI Administrator role, per-agent enable and disable policy, an actor_is_agent flag in the audit log, and MCP server allow and deny lists. Anthropic's workload identity federation gives a CI job short-lived, single-use API access with no stored key. Neither of these is on by default. GitHub, agent control plane GA and Anthropic, workload identity federation (sources dated 2026-02 and 2026-06; verified 2026-09)
  • The threat model has names now. OWASP's Top 10 for Agentic Applications, published 9 December 2025, catalogs the failure modes this contract addresses: prompt injection through content the agent reads (ASI01), excessive agency from over-broad permissions (ASI03), memory and context poisoning through corrupted instruction files (ASI06), and human-agent trust exploitation, where reviewers rubber-stamp because the agent's summary sounded confident (ASI09). OWASP Top 10 for Agentic Applications 2026 (source dated 2025-12; verified 2026-09)

What I Do About It

Every agent in a pipeline I run has its own identity, a scoped token, a branch namespace, and a per-workflow budget before it runs its first task. Nothing an agent must never do lives in a prompt. It lives in a hook or a permission that blocks the call, because I have watched a model under pressure treat an instruction file as a suggestion.

Humans own merges. A named approver stands behind every production change, and no agent approves, merges, or re-requests review on its own work. Lane B starts boring - dependency bumps, test backfill, copy - and earns each additional work class by holding change failure rate flat. The auth module and the money math never make the list.

And the review agent gets smarter every quarter, because every escaped defect becomes a rule in its library. The model is rented. The rules, the hooks, the fixtures, and the evidence are owned. That is the asset that compounds.

Hire Me →