In the same room, barely an hour later, another engineer said something I now hear everywhere: “AI is moving fast, and I feel like I am standing outside the room.”

Two different complaints. One answer. You do not go back to VMs, and you are not outside the AI room either. You go one level down, to the open standard underneath Docker. And that same standard, it turns out, is your on-ramp into AI. Let me show you why.

The three roads to AI Native

The way I see it, there are three roads a DevOps engineer can take into AI. I call this the AI Trinity for DevOps:

1. AI-Augmented DevOps. You use AI to do your existing job better. Copilots for your pipelines, agents that triage your alerts, AI that writes your Terraform.

2. AI Infrastructure. That is MLOps, LLMOps, and AgentOps. You build and run the platforms that AI workloads live on. Someone has to serve the models, wire the vector databases, package the artifacts, and keep the whole thing secure. That someone looks a lot like you.

3. Agentic DevOps. You build agents and agentic systems that do engineering work themselves.

This series walks the second road. And here is the important point: the second road does not start with mathematics or model training. It starts with something you already know very well. Containers.

You already have the skills. Really.

Ask yourself what an AI stack actually needs in production. It needs a model served behind an API. It needs a database. It needs an app. It needs images built, versioned, pushed to a registry, scanned, signed, and shipped through CI.

Sound familiar? It should. This is your day job with one new workload type on top.

So who is best placed to run AI infrastructure? Not the data scientist who trained the model. The engineer who has been packaging, serving, isolating, and shipping software for years. That is you.

But there is one decision to get right before anything else, and it is the subject of the rest of this article.

Container-native, not Docker-native

Imagine you are standing at a shipping yard. A crane lifts a steel box off a ship and sets it down on a waiting truck. Stop here for a second and notice what nobody at the yard is doing. Nobody opens the box to check what is inside. Nobody asks which company owns the truck. The crane operator would handle ten thousand of these boxes a year without knowing what a single one contains. Why? Because the box follows a standard. Every crane, every ship, and every truck in the world is built for the same box.

Your application is the cargo. The container spec is the box. And Docker, Colima, OrbStack, Rancher Desktop, and Podman? They are just the carriers. The yard does not belong to any one of them.

Now, why does this matter suddenly? Because Docker Desktop is now paid for organisations with more than 250 employees or 10 million dollars in revenue. That is the email my workshop participant got. That one pricing change broke a lazy assumption the whole industry had been carrying: that “container” means “Docker Desktop”.

But here is the good news. The standard underneath Docker is fully open. It has two parts:

• The OCI image format, that is the standard for how container images are built and stored.

• The Compose Spec, that is the standard for describing a multi-service stack in one file.

Every serious runtime implements both. So the same compose.yaml would run without any changes on Colima, OrbStack, Rancher Desktop, or Podman.

One file. Four runtimes. The same result. So the rule for this whole series is simple: we learn container-native, not Docker-native. Which carrier you pick is your business.

What do containers actually buy an AI stack?

Think of a container as a sealed shipment. The model server, the embedding pipeline, the vector database, and the agent each travel in their own sealed box. Any machine can open them.

Concretely, containers give an AI system four things:

Role What it means in practice Package Lock the Python version, the CUDA driver, and every library version. “Works on my machine” becomes “works on every machine”. Serve Run the embedding service, the vector DB, and the gateway behind predictable ports. Nothing pollutes the host. Isolate Two AI frameworks with clashing dependencies? Each lives in its own container. No virtualenv juggling. Ship Push to any OCI registry, that is GHCR, Docker Hub, or Quay. Pull and run anywhere.

Package, serve, isolate, ship. Keep these four words in mind. Every article in this series is about one or more of them, applied to AI.

The one wrinkle: your laptop’s GPU

Now here is the catch, and I want you to know it exists before you run anything.

On Apple Silicon Macs, a container cannot see the GPU. macOS gives the container’s virtual machine CPUs and memory, but no graphics device. So a model running inside a container on a Mac would fall back to CPU, and what takes one second natively would take three to six in the container. You cannot fix this with configuration. It is a hard platform boundary.

The pattern that solves it: run the model server natively on the Mac, where it can use the Metal GPU, and containerise everything else. The containers reach the model at one magic address:

http://host.docker.internal:11434

.

The next article is entirely about this. For now, just keep the picture in mind: the model stays native, everything else is a container.

Prove it yourself in a few minutes

Enough reading. Let’s prove the wiring works. We assume you have a container runtime installed (any of the four above) and Ollama installed natively.

Pull a small model. This one is under 1 GB:

ollama pull qwen2.5:1.5b

Check it is being served natively:

curl -s http://localhost:11434/api/tags

Now the real move. Start a throwaway container and call the model from inside it:

docker run --rm curlimages/curl:latest -s \
  http://host.docker.internal:11434/api/generate \
  -d '{"model":"qwen2.5:1.5b","prompt":"Say hi in 5 words.","stream":false}'

You should get back JSON with a "response" field and a short reply from the model. Stop here for a second and notice what just happened. A container, which is your world, just called a locally served LLM, which is the new world, over a standard HTTP API. That is the whole bridge. Everything we build in this series stands on it.

Where this series goes

Over the next thirteen weeks we will build one realistic system, one step at a time, and every step runs on a normal 16 GB laptop:

1. Serve a local model behind an OpenAI-compatible API, and swap engines without touching app code

2. Scale it with vLLM and understand batching and quantization

3. Package and version models as OCI artifacts, the same way you ship images

4. Build a RAG assistant over real runbooks, and see exactly where naive RAG breaks

5. Define an agent in plain Markdown files, with tools and guardrails

6. Grow it into a multi-agent incident crew

7. Secure the whole thing: guardrails, SBOM, scan, sign, eval

8. Ship it end to end, and prove portability by swapping the runtime

No GPU cluster and no cloud bill. Just the open container standard, open-source AI tools, and the skills you already have.

If you understand this well, the rest will be easy to figure out. See you in the next one.

This series is adapted from my 2-day hands-on workshop, Containers for GenAI & Agentic AI — The Open-Source Way, where we build this entire stack step by step on a regular 16 GB laptop. If your team wants to run it live, reach out. And if you want the next article, subscribe — it’s free.

Uber’s method is simple. Pair an AI-proficient engineer with a domain expert. Shadow the real work. Find high-impact opportunities. Build an agent. Validate it with users. Then ship.

The strongest lesson is this: the workflow is the unit of automation, not the individual task.

That fits operations well. Our work is full of repeated checks, manual investigation and context gathering. But operations also has a larger blast radius. So the method needs stronger boundaries, better testing and gradual automation.

Start with the work humans should not be doing

The first agentic operations team should look more like an L1 SRE or associate DevOps team than a group of autonomous senior engineers.

This is where agents can create immediate value. They can take on boring, repeatable and manual work. Work that is necessary, but not a good use of human attention.

• Search 100,000 log lines for the one abnormal pattern.

• Collect incident context from alerts, metrics, logs and recent changes.

• Enrich and deduplicate alerts.

• Check why a Kubernetes workload is pending.

• Verify a deployment and compare before-and-after signals.

• Investigate a failed CI/CD or ML pipeline.

• Draft an incident timeline or handover.

• Run safe, well-defined parts of a runbook.

• Prepare capacity, reliability and cost reports.

These are not trivial problems. They often consume hours because the evidence is spread across many tools. Agents are good at searching, collecting, correlating and summarizing that evidence.

Build agents the way we build teams

A profile should represent a role. A skill should represent a capability. A workflow should combine skills to achieve a goal.

Profile = Role • Skill = Capability • Workflow = Work • Goal = Outcome

Profiles map to real roles. Examples include SRE for Team X, PlatformOps Engineer, Deployment Engineer, Kubernetes Operations Engineer or MLOps Engineer.

The profile defines the agent’s scope, services, tools, permissions, memory, policies and escalation path. An SRE for Team X should know Team X’s services, dashboards, SLOs, repositories, clusters and on-call process.

Skills map to functions and capabilities. Examples include querying logs, collecting incident evidence, inspecting Kubernetes workloads, checking recent deployments, detecting configuration drift, calculating SLO impact, preparing a rollback plan or drafting an incident report.

The same skill can be reused by many profiles. A Kubernetes inspection skill may be used by an SRE, a PlatformOps engineer and an MLOps engineer. Each profile uses it with different context and permissions.

A goal combines several skills. To investigate a rise in checkout-service errors, the SRE profile may collect alert context, search logs, inspect Kubernetes, check recent deployments, correlate metrics, explain the likely cause and prepare the next action.

A compact way to adapt Uber’s method

Pick one high-toil, low-risk workflow. Read-only investigation is usually the best first target.

Pair the operator with an agent builder. The operator knows the real work. The builder knows models, tools and automation.

Shadow the workflow. Capture the hidden checks and judgement that are missing from the runbook.

Create a profile for the role. Add only the context, tools and permissions that role needs.

Convert the runbook into small skills. Each skill should have clear inputs, tools, expected evidence, constraints and an escalation path.

Test in shadow mode. Compare the agent’s output with real incidents and experienced engineers.

Move up the safety ladder slowly. Add approvals, audit logs and bounded execution only after the workflow proves reliable.

Use Hermes to experiment, not to skip governance

Hermes can be a useful starting harness because it supports separate profiles, memory, sessions, tools and skills. That maps well to role-based operational agents.

For example, you could create profiles such as sre-team-x, platform-ops, deployment-engineer, mlops-team-y.

Start with a few shared skills: collect incident context, search logs, inspect Kubernetes, check deployments and draft a report. Then test them against real cases.

Do not measure success only by autonomy

Most teams can get strong value before an agent is allowed to change production.

Observe: gather evidence.

Explain: summarize what is happening.

Recommend: suggest the next step.

Prepare: draft commands, patches or change plans.

Execute with approval: act only after a human reviews the exact action.

Levels one to four can remove a large amount of toil. Full autonomy is not the goal. Reliable help is.

The practical recommendation

Do not begin by building an autonomous SRE platform. Begin by building a small agentic operations team for L1 work.

Create profiles that match real roles. Give them reusable skills. Combine those skills into clear workflows. Start with read-only access. Validate on real incidents. Keep humans responsible for important decisions.

Let agents handle the noise. Let engineers handle the impact.

Uber’s Agentic Pods method gives us a useful operating model. The operations adaptation adds the pieces our field needs: role boundaries, reusable capabilities, deterministic tools, shadow testing, approvals and auditability.

Start small. Automate the boring. Build trust. Then expand.

Sources and further reading

Uber Engineering: Agentic Pods overview

Google SRE: Eliminating Toil

Hermes Agent: Profiles documentation

Hermes Agent: Skills system

The newest AI employee apparently costs $20, $100 or perhaps $200 a month.

It writes code. It analyses logs. It creates Terraform. It investigates incidents. It never sleeps, never asks for a promotion and never complains about being on call.

Place that next to the salary of a senior SRE, DevOps engineer or platform engineer, and the conclusion appears obvious:

The engineer is an expensive legacy interface. The agent is the future.

There is only one problem.

The comparison is economically meaningless.

A flat-rate AI subscription is the price of giving one person access to a model under usage controls. It is not the cost of operating an autonomous production worker that continuously reads telemetry, retrieves context, invokes tools, retries failed actions, validates results, maintains state, produces audit evidence and remains available during an incident.

Replacing an engineer means replacing more than the visible actions they perform.

You must replace the work, the context, the judgement, the coordination and the accountability.

Once we calculate that system honestly, the $200 AI employee starts looking less like an employee and more like a heavily discounted demonstration.

Welcome to Signal Over Hype

This is the first edition of Signal Over Hype, a new Agentic Ops Dispatch series for DevOps, SRE, platform, infrastructure and AI engineers.

The purpose of this series is not to dismiss AI.

I use these systems every day. I believe AI will automate a substantial portion of operational work. Engineers who learn to work effectively with agents will have a serious advantage over those who ignore them.

But engineers are increasingly being asked to make career, architecture and workforce decisions in an environment filled with vendor incentives, executive predictions, benchmark theatre and social-media fear and FOMO.

In each edition, we will take one popular claim and examine it using:

Facts.

First principles.

Production experience.

Economic incentives.

And ordinary engineering common sense.

The recurring question will be simple:

What remains true after the keynote ends and the system has to run in production?

The job-displacement claim is not imaginary

In May 2025, Anthropic CEO Dario Amodei warned that AI could eliminate half of entry-level white-collar jobs within one to five years and push unemployment significantly higher. The statement was framed as a warning rather than a celebration, but it contributed to a powerful narrative: organisations should prepare for rapid labour replacement because the technology is moving faster than workers or governments realise.

It would be foolish to dismiss this simply because the prediction came from the CEO of an AI company.

The models are improving quickly.

METR’s research has found that the difficulty of software tasks frontier agents can complete with 50% reliability has increased rapidly over several years. Its researchers originally estimated a doubling in the measured task horizon roughly every seven months. METR also stresses an important qualification: this measures the difficulty of a task based on how long a human would take to complete it. It does not mean that an AI agent can safely run unattended in production for that many hours.

There will be displacement.

Some teams will become smaller. Some entry-level activities will disappear. Some companies will use AI to reduce hiring. Others will use AI as the explanation for cuts they already wanted to make.

But we should also notice that the industry narrative is not uniform.

OpenAI’s own 2025 employment paper said that the evidence available at the time pointed towards AI helping developers do more rather than simply replacing them. Anthropic’s 2026 labour-market research similarly reported limited evidence of broad employment effects so far, although it found suggestive evidence that hiring of younger workers may have slowed in highly exposed occupations.

That is the signal:

AI can perform more engineering work, and the labour market is beginning to adjust.

The hype begins when we jump from that observation to:

A $200 subscription can replace an SRE.

The first trick: compare a seat licence with a salary

Claude Max currently offers an individual plan priced at $200 per month with higher usage capacity than its standard plans.

That is real.

It is also almost entirely irrelevant to the cost of replacing an engineer.

Anthropic describes the Max plan as an individual-user product. It separately states that Claude subscriptions and Claude API usage are different products with different billing. Additional API or usage-credit consumption is charged independently of the subscription.

This distinction matters.

A person using Claude Code interactively is not the same workload as an autonomous operations platform.

A person chooses a task, provides context, waits for the result, inspects the answer and stops when the work is complete.

A production agent may:

Wake up for every alert.

Read logs, traces, dashboards, manifests, tickets and runbooks.

Send much of that context back to the model at every reasoning step.

Launch parallel subagents.

Retry failed tool calls.

Ask another model to review the first model.

Retain state across a long-running incident.

Create an evidence trail for every action.

Operate when nobody is watching.

And escalate to a more capable model whenever the cheaper one becomes confused—which, as production engineers know, is usually shortly before the dangerous part.

The $200 plan is not deceptive.

It is simply the wrong unit for the comparison.

Comparing an AI seat licence with the salary of an engineer is like comparing the price of Microsoft 365 with the cost of running the finance department.

The viral 320-million-token receipt

The image that inspired this article compares a $200 Claude subscription with an $8,000 API bill for 320 million tokens.

The arithmetic can be correct under a particular assumption.

Anthropic currently lists Claude Opus 4.8 at $5 per million input tokens and $25 per million output tokens. At those rates, 320 million output tokens would indeed cost $8,000. The same number of input tokens would cost $1,600.

But “320 million tokens” by itself is not a workload description.

You need to know:

Which model was used?

How many tokens were input versus output?

How much repeated context was cached?

How many tool results were added back into the conversation?

How many retries occurred?

How many agents operated in parallel?

Was the workload interactive, batched or long-running?

Was an expensive model used for everything, including tasks a smaller model or a twenty-line script could have handled?

Using the published Opus rates, a workload containing 90% input and 10% output would cost roughly $2,240 for 320 million total tokens—not $8,000.

A cheaper model could reduce it further. Prompt caching and batching could reduce some costs again. Poor context management, excessive retries and uncontrolled subagents could send them in the opposite direction.

So the honest conclusion is not:

Your $200 subscription secretly costs $8,000.

The honest conclusion is:

A subscription price tells you almost nothing about the cost of a production agent until you define the model, input-output ratio, context, caching, concurrency, retry behaviour and workload.

That is less viral.

It is also true.

Anthropic’s own Claude Code documentation says enterprise deployments average around $150–$250 per active developer per month, although costs vary significantly with model choice, codebase size, automation and concurrent usage.

That is important counterevidence.

Useful AI assistance can be economically attractive.

But notice the unit again:

Per developer.

That is the cost of augmenting a human.

It is not the cost of replacing the organisational function that the human performs.

An SRE is not a command-typing machine

The original SRE concept was never based on paying humans to repeat shell commands forever.

Google defines toil as repetitive, predictable and automatable operational work. Its SRE organisation has historically aimed to keep operational toil below half of an engineer’s time, leaving at least 50% for engineering work that reduces future toil or improves reliability, performance and utilisation.

In other words:

The role includes:

Designing systems that fail safely.

Defining SLOs and error budgets.

Building delivery and rollback mechanisms.

Reviewing production readiness.

Managing capacity and cost.

Improving observability.

Coordinating incidents.

Understanding dependencies.

Negotiating risk with product and business teams.

And creating systems that need less human intervention over time.

A model can generate a kubectl command.

That is not the same as knowing whether the command should be run.

It does not automatically know whether the evidence is complete, whether the operation is reversible, what the blast radius is, which customer commitment is at risk, whether the database can tolerate the failover or who has authority to accept the consequences.

The pager is not requesting text generation.

It is requesting ownership.

The five real costs of replacing an SRE

1. Model access

This is the cost everyone talks about:

Input tokens.

Output tokens.

Reasoning tokens.

Cache reads and writes.

Tool-call context.

Web searches.

Multimodal input.

Retries.

Parallel agents.

Background jobs.

And escalation to premium models.

It may still be much cheaper than an engineer’s salary.

That is entirely possible.

But it is only the first line of the bill.

2. The execution harness

A production agent requires an operating environment around the model.

You need identity and access control.

Secrets management.

Tool or MCP gateways.

Policy enforcement.

Approval workflows.

State and memory.

Scheduling and event triggers.

Sandboxed execution.

Model routing.

Evaluations.

Observability.

Audit logs.

Rate and cost limits.

Rollback mechanisms.

Provider failover.

And a way to stop the agent when it begins confidently fixing the wrong problem.

Google’s SRE guidance describes automation as a force multiplier, not a panacea. Thoughtless automation can create as many problems as it solves.

LLMs make this principle more important, not less.

Traditional automation is generally wrong in repeatable ways.

Probabilistic automation can be wrong creatively.

3. Human review

Automation does not eliminate labour whenever someone must inspect, approve or correct its output.

A more useful formula is:

Net automation value = labour avoided − review labour − correction labour − platform cost − expected failure cost

Suppose an agent saves an engineer forty minutes.

It then requires twenty minutes of review.

Once every ten runs, it creates an hour of correction work.

The productivity benefit is not forty minutes.

And that is before accounting for infrastructure, token usage, security controls and context switching.

Research on AI productivity is not one-directional.

DORA’s 2024 findings associated AI adoption with improvements in individual productivity, flow and job satisfaction, while also finding negative relationships with software delivery stability and throughput. Its 2025 work described AI more positively as an amplifier of the surrounding organisational system: strong teams benefit more, while weak processes become faster at producing downstream chaos.

METR’s 2025 study of experienced open-source developers found that participants took 19% longer when permitted to use AI tools on mature projects they understood well. Strikingly, the developers believed they had become faster.

Both results can be true.

AI can accelerate well-scoped work while slowing experts in high-context environments where prompting, reviewing, correcting and steering the tool becomes expensive.

Production operations is one of the highest-context environments we have.

4. Failure and blast radius

A wrong answer in a document creates editing work.

A wrong production action can:

Delete data.

Expose credentials.

Break routing.

Corrupt state.

Increase cloud spending.

Violate a regulatory control.

Extend an outage.

Or create a second incident while attempting to resolve the first.

Uptime Institute’s 2026 analysis found that 57% of respondents said their most recent major outage cost more than $100,000. One in five said it exceeded $1 million.

You do not need many autonomous-agent mistakes at that price before the salary comparison starts looking childish.

The expected failure cost is not:

Probability of a model error × cost of an API request.

It is:

Probability of an unsafe decision escaping your controls × business impact of the action.

That is why dry runs, bounded permissions, staged execution, canaries, approvals and rollback are not bureaucratic additions.

They are part of the product.

5. Knowledge and accountability

Experienced engineers hold knowledge that is only partly documented.

Why does the architecture look unnecessarily complicated?

Because the simpler version failed during a peak event four years ago.

Why has nobody removed that temporary workaround?

Because it quietly became load-bearing.

Why is one alert routinely ignored?

Because it lies.

Why is another apparently harmless warning taken seriously?

Because it appears fifteen minutes before the system collapses.

Which customer cannot tolerate a five-minute disruption?

Which deployment order is dangerous?

Which dashboard stays green during the precise failure you fear?

An AI system can retrieve recorded knowledge.

It cannot reliably retrieve what the organisation never recorded.

If a company removes engineers before converting that knowledge into runbooks, executable skills, tests, policies, dependency maps and incident history, it is not eliminating cost.

It is deleting state.

Accountability is harder still.

NIST’s generative-AI risk guidance recommends defining human-AI responsibilities, applying suitable human oversight, and maintaining review, tracking and documentation appropriate to the risk.

When an agent recommends deleting a cluster, who approves the decision?

When it is wrong, who owns the incident?

When the regulator asks who accepted the risk, do we provide the model ID?

Follow the money—but do not invent a conspiracy

It is tempting to tell a neat story:

AI companies are subsidising subscriptions now.

They want organisations to become dependent.

Once companies fire their employees, token prices will rise.

The vendors will collect the difference forever.

Parts of this are plausible.

The full story is not yet proven.

Technology companies frequently use flat-rate plans, free tiers, credits and generous usage limits to accelerate adoption. Production workloads then move towards metered infrastructure, enterprise contracts and consumption-based billing.

But model prices can also fall as hardware, inference software and competition improve. Customers can route workloads to cheaper models. Caching and batching can reduce costs. Open models and local inference create alternatives.

The stronger, evidence-based argument is this:

Subscription access and API consumption are different products.

Production automation tends to expose real usage costs.

Operational integration creates switching costs.

And once your company’s runbooks, workflows, memory, tooling and approvals are built around one provider, that provider gains commercial leverage—even when the cost per token falls.

The largest risk is not necessarily that a token becomes more expensive.

The risk is that your organisation becomes unable to operate without a particular model, memory format, proprietary agent runtime or vendor-controlled tool ecosystem.

We have seen this movie before.

This time the lock-in comes with a friendly chatbot.

What will actually be automated

A large portion of today’s operational toil is highly automatable:

Alert enrichment and deduplication.

Log and trace summarisation.

Incident timeline construction.

Runbook drafting.

Routine script generation.

Configuration and policy checks.

Change preparation.

Documentation.

Dependency lookup.

Ticket triage.

Known-issue diagnosis.

Post-incident summaries.

Capacity analysis.

And execution of constrained, reversible procedures.

Some of this should use frontier models.

Some should use smaller or local models.

Some should use conventional code.

Calling the most expensive model available to parse a known JSON document is not AI-native engineering.

It is a refusal to write twenty lines of Python.

The goal is not maximum AI usage.

The goal is the minimum reliable cost for the required outcome.

What should remain human-led—for now

Most serious organisations should continue to keep human ownership around:

Incident command.

Architecture decisions.

Reliability and cost trade-offs.

Risk acceptance.

Security-sensitive changes.

Ambiguous diagnosis.

Cross-team coordination.

Customer communication.

Novel failure modes.

Regulatory accountability.

And any action whose blast radius exceeds the system’s ability to recover safely.

The boundary will move.

Agents will become more capable. Evaluations will improve. Organisations will gather successful production history. Permissions and policies will become more granular.

But the correct way to move this boundary is through evidence:

Tested historical incidents.

Measured success rates.

Controlled production deployments.

Bounded permissions.

Demonstrated rollback.

And clear escalation paths.

Not because an executive said the future was arriving next quarter.

Can AI reduce the size of an SRE team?

Yes.

That is an entirely reasonable outcome.

AI may reduce the number of engineers needed for some kinds of systems.

But this becomes responsible only when:

The service has clear SLOs.

Operational knowledge is documented.

Common incidents have tested runbooks.

Deterministic actions use deterministic code.

Agent permissions are narrowly scoped.

High-risk actions require approval.

Changes are staged and reversible.

Telemetry is trustworthy.

The agent is evaluated against historical incidents.

Costs are measured end to end.

Humans can take control.

And the remaining team has enough capacity to improve the system instead of spending every day supervising bots.

It is not responsible when the organisation has:

Weak observability.

Undocumented systems.

Shared administrator credentials.

Unreliable tests.

No rollback process.

No incident-command discipline.

Unclear ownership.

And a management strategy that can be summarised as:

Claude will figure it out.

The more chaotic the environment, the more impressive an AI demonstration can appear.

It is also the environment in which autonomous execution is most dangerous.

The architecture that makes economic sense

The sensible Agentic DevOps architecture is not:

Send every operational event to the largest frontier model available.

It is layered.

Deterministic code for deterministic work

Use scripts, APIs, controllers, workflow systems and policy engines when the rules are known.

A model does not need to decide how to restart a service when the procedure is already deterministic, tested and safe.

Skills for reusable operational knowledge

Convert runbooks and procedures into versioned skills containing:

Instructions.

Scripts.

Expected evidence.

Preconditions.

Tests.

Permissions.

Escalation rules.

And rollback steps.

This turns institutional knowledge into a portable operational asset rather than a collection of documents an agent may or may not interpret correctly.

Smaller or local models for predictable cognition

Use efficient models for:

Classification.

Extraction.

Routing.

Summarisation.

Known-pattern diagnosis.

And low-risk decision support.

These workloads do not always need frontier reasoning.

Frontier models for genuinely hard problems

Use the most capable models when ambiguity, novel incidents, architecture analysis or complex synthesis justifies the additional cost.

The expensive model should be an escalation path.

Not the default parser for every log line.

A governed execution harness around everything

Add:

Identity.

Policy.

Approvals.

Observability.

Evaluations.

Budgets.

Audit.

Isolation.

Rollback.

And human escalation.

This architecture reduces dependence on any one model vendor.

It also allows the organisation to improve its operational system while models continue to change.

Models are replaceable components.

Your skills, telemetry, controls and institutional knowledge are the durable assets.

The verdict

AI will change SRE, DevOps and platform engineering profoundly.

It will eliminate toil.

It will compress some roles.

It will allow smaller teams to run larger systems.

It may eventually operate significant production environments with limited human supervision.

But replacing an SRE with a chatbot subscription is not transformation.

It is an accounting illusion.

The real comparison is not:

Engineer salary versus AI subscription.

It is:

The fully loaded cost and risk of a human-led engineering system versus the fully loaded cost and risk of an AI-led engineering system.

Sometimes the AI-led system will win.

Frequently, the best answer will be a smaller and stronger engineering team operating a well-governed automation platform.

And in immature organisations, removing the engineers first may be the most expensive decision of all.

So automate aggressively.

Measure token consumption.

Measure review time.

Measure failed actions.

Build reusable skills.

Use local models where they are sufficient.

Use frontier models where they earn their cost.

Require human approval where the blast radius demands it.

But do not fire the people who understand production because somebody compared their salary with the promotional price of a model subscription.

Fire the toil. Keep the SRE. Modernise the pager.

Because the pager does not care about the keynote.

And when it rings at 3:17 in the morning, somebody still owns the outcome.

About Signal Over Hype

Signal Over Hype is an Agentic Ops Dispatch series, curated by Gourav Shah, examining the claims shaping DevOps, SRE, platform engineering, AI infrastructure and agentic operations.

No reflexive optimism.

No reflexive pessimism.

Just facts, incentives, first principles and production reality.

Subscribe now

Sources and further reading

Anthropic, “Choose a Claude plan” and documentation covering subscription versus API billing.

Anthropic, Claude Platform pricing and Claude Code cost guidance.

Anthropic, “Labor market impacts of AI: A new measure and early evidence,” March 2026.

OpenAI, “Jobs in the Intelligence Age,” September 2025.

METR, research on AI task-completion horizons and experienced developer productivity.

DORA, 2024 and 2025 research on AI-assisted software development.

Google, Site Reliability Engineering: “Eliminating Toil” and “The Evolution of Automation at Google.”

NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.

Uptime Institute, Annual Outage Analysis 2026.

What would an Ansible-like system look like if it were designed for AI-native operations?

Not “AI writes a shell script once.”

Not “chat with a bot and hope it remembers your infra.”

I mean something closer to the way real ops teams work: roles, teams, responsibilities, reusable capabilities, project context, runtime permissions, workflows, and operating models.

That led to today’s build: AOH: Agentic Ops Harness.

Repo: https://github.com/agenticdevops/aoh

AOH is my first cut at a Git-native harness for designing and running agentic DevOps, SRE, Platform Engineering, and MLOps capabilities.

The Thought Process

The first instinct was to model “skills.”

That made sense because tools like Hermes, Goose, Claude Code, Codex, and others are converging on some form of reusable agent skill: instructions, scripts, references, and runtime behavior bundled together.

But very quickly, “skills” alone felt too small.

In real organizations, we do not just have a pile of skills. We have teams.

A platform team has SREs, DevOps engineers, platform engineers, maybe MLOps engineers. Each role has different responsibilities, different tools, different access patterns, and different operating habits.

So the model evolved:

Org / Business Unit / Project
  -> Team
    -> Role
      -> Skills / Capabilities
      -> Workflows
      -> Runtime Requirements
      -> Model Profile

That felt much closer to reality.

An SRE role might get:

• service health reporting

• incident triage

• log analysis

• Kubernetes read-only diagnostics

A DevOps automation role might get:

• deployment automation

• Terraform plan review

• release verification

• rollback workflows

An MLOps role might get:

• training job triage

• GPU utilization checks

• model deployment diagnostics

• checkpoint/retry guidance

Same team. Different roles. Different capabilities.

That became the core abstraction.

What I Built Today

I built the first working MVP of AOH: Agentic Ops Harness.

Right now AOH is a Git repository structure plus a small CLI/compiler.

It contains:

• Packs: source-of-truth bundles for agentic ops capabilities

• Teams: org/project/BU-level groups

• Roles: real-world job functions like SRE, DevOps Engineer, MLOps Engineer

• Skills: reusable agent capabilities written as SKILL.md

• Workflows: repeatable ops flows

• Runtime requirements: tools and capabilities needed by a role/workflow

• Model profiles: model/provider intent

• Adapters: compilers into agent runtimes

The first runtime adapter is for Hermes Agent.

For Hermes, AOH compiles:

AOH Team -> multiple Hermes profiles
AOH Role -> one Hermes profile
AOH Skills -> profile-local Hermes skills
AOH Role instructions -> SOUL.md
AOH launch -> launch.sh

So a team definition can generate multiple runnable Hermes agents.

The First Real Example

I created an example pack:

examples/acme-platform-ops

It models an imaginary Acme Platform Ops Team with three roles:

platform-ops team
  -> sre-platform
  -> devops-automation
  -> mlops-training

Each role has a different capability set.

The SRE role gets:

service-health-report
docker-disk-cleanup

The DevOps role gets:

deployment-automation
terraform-plan-review
service-health-report

The MLOps role gets:

ml-training-job-triage
service-health-report

That is the important part: the agent is not just “an AI assistant.” It is a scoped operational role with a curated capability set.

Why This Matters

Most AI tooling today is still very individual-agent centric.

You launch a coding agent. You give it a task. It works in a repo.

That is useful, but DevOps and SRE work is team-shaped.

We need AI-native ops systems that understand:

• who the agent is acting as

• what team it belongs to

• what project or business unit it serves

• what capabilities it should have

• what workflows it can run

• what runtime should execute it

• what tools it needs

• what model profile makes sense for the job

AOH is trying to make that structure explicit and version-controlled.

How It Works

At the source level, AOH is just files in Git.

A simplified pack looks like this:

acme-platform-ops/
  AOH.yaml
  teams/
    platform-ops.yaml
  agents/
    sre-platform.yaml
    devops-automation.yaml
    mlops-training.yaml
  skills/
    service-health-report/
      SKILL.md
    deployment-automation/
      SKILL.md
    ml-training-job-triage/
      SKILL.md
  workflows/
  models/
  runtime-requirements/
  evals/

Then the CLI validates and compiles that pack into runtime-native artifacts.

For Hermes:

uv run aoh install-hermes-team examples/acme-platform-ops \
  --profiles-dir ~/.hermes/profiles \
  --team platform-ops \
  --profile-prefix acme-platform \
  --provider openai-codex \
  --model gpt-5.4 \
  --cwd "$PWD"

That creates Hermes profiles like:

acme-platform-sre-platform
acme-platform-devops-automation
acme-platform-mlops-training

Each profile has its own role instructions, local skills, config, and launch script.

Where We Are Now

The MVP is working.

I tested the generated Hermes profile for the DevOps role:

~/.hermes/profiles/acme-platform-devops-automation/launch.sh \
  -q "Answer in one sentence: what AOH role are you, and which AOH skills are associated with you?" \
  --max-turns 2 --quiet

The generated agent responded:

I’m the AOH DevOps Engineer for Acme Platform in the devops-automation role,
and my associated AOH skills are deployment-automation, terraform-plan-review,
and service-health-report.

That is a small test, but it proves the shape:

• team defined in Git

• role defined in Git

• skills associated with role

• Hermes profile generated

• role-specific agent launched

• associated skills preloaded at runtime

That is the harness.

What This Is Not Yet

This is not a finished platform.

It is not yet a full registry, package manager, or policy engine.

It does not yet have adapters for Goose, Codex, Claude Code, or OpenCode.

It does not yet have a complete eval runner.

It does not yet model enterprise-grade approvals, secrets, RBAC, or audit trails deeply.

But the foundation is now there.

The source-of-truth model is becoming clear.

What Comes Next

The next steps I’m thinking about:

1. Goose adapter
   Map AOH skills and workflows into Goose skills, recipes, sub-recipes, and extensions.

2. Codex and Claude Code adapters
   Compile AOH roles into project instructions, skills, and launch conventions.

3. Eval runner
   Validate whether a generated role-agent can actually perform the workflow it claims to support.

4. Registry
   Share AOH packs across teams and organizations.

5. Runtime requirement negotiation
   Let a runtime say: “I can satisfy these requirements, but not these.”

6. Policy metadata
   Keep AOH engine-neutral but allow adapters to map risk, approvals, and tool access into runtime-native guardrails.

Why I’m Excited About This

This feels like a useful bridge between traditional automation and AI-native operations.

The old world had:

roles
playbooks
inventories
modules
runbooks

The new world needs:

teams
agent roles
skills
workflows
runtime adapters
evals

AOH is an attempt to make that transition concrete.

Not as a slide.

As a repo you can clone and run.

Try it here:

https://github.com/agenticdevops/aoh