Field Note #1: Building an Agentic Ops Harness

Superpowers for DevOps, SRE, Platform Engineering, and MLOps

Today’s experiment started with a simple question:

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