Module 3: Understanding your Agentic AIOps Team

Deep Agents is one example of an agentic harness — a framework that wraps and drives an LLM rather than letting it run unsupervised. Other harnesses include Claude Code (Anthropic’s coding agent) and the Claude Agent SDK (for building custom agents). What they share: the harness manages context, tools, delegation, and output parsing. A well-designed harness makes smaller models perform like larger ones — which is why you can switch to open source models in Module 4 without losing quality.

Athena uses all four pillars. The ops_manager maintains an explicit plan (the triage protocol in AGENTS.md). Skills and incident data live on the filesystem. Specialist subagents are spawned on demand and destroyed after use. And each subagent operates in context isolation — sre_linux never sees the networking error that sre_networking is investigating.

At the center is ops_manager, a long-running Deep Agent that uses the ReAct (Reason + Act) pattern. When a failure arrives via webhook, ops_manager:

The ops_manager stays running across the entire analysis — it’s the orchestrator that holds the conversation together.

The four sre_* subagents are ephemeral — they’re created on demand when ops_manager calls task(), and discarded after they return their analysis. Each one is a focused expert:

This is a critical architectural decision. Consider what would happen if a single agent handled everything:

Ephemeral subagents solve this. Each sre_* agent starts with a fresh context — only the incident data and its domain-specific skills. When it finishes, its context is discarded. The ops_manager only sees the final TicketPayload result, not the specialist’s internal reasoning. This keeps every analysis clean and focused.

Each subagent is loaded with skills — markdown documents that provide domain-specific diagnostic workflows, institutional knowledge, and output formatting guidance. Skills are the reference library that turns a general-purpose LLM into a domain expert.

Agents can call tools — functions that let them interact with external systems. In Athena, the key tool is task() which lets ops_manager delegate to subagents. Subagents also have web_search for looking up documentation.

Each agent can use a different model from MaaS. The ops_manager might use a frontier model for complex reasoning, while subagents use a smaller, cheaper model for focused domain analysis. The reviewer can use an even lighter model since it only validates, not analyzes.

In the next exercises, you’ll see a gap in the current team’s capabilities, explore the architecture, add a specialist, and then watch the same failure get handled far better.

Here’s what the new sre_package_management agent entry looks like:

Rather than manually editing YAML in a terminal editor (where a single indentation error would break the configuration), download the complete pre-built subagents.yaml that includes sre_package_management:

You need to update two keys in the ConfigMap: subagents.yaml (to add the new agent) and AGENTS.md (to update ops_manager’s routing rules so it knows to delegate package failures to `sre_package_management instead of sre_linux).

The ops_manager uses an error-classifier skill to identify the failure domain before routing. The version on your PVC was initialized from the image at first boot and doesn’t know about the package_management domain yet — so even with the new agent in place, the classifier would still emit ansible or linux for a dnf failure.

Adding a new domain to the classifier is the same as teaching a team lead a new category of problem. You’re telling it: "when you see 'No package X available', that’s a package management issue, not an Ansible issue."