/azure-sre-agent

Azure SRE Agent Bundles

Bundles are modular capability packs used to build production SRE Agents without editing the core skill file.

Use bundles to add, remove, or evolve capabilities over time.

Why Bundles

1. Keep SKILL.md stable and concise.
2. Isolate capabilities by domain (core, observability, triggers, source RCA, workload, governance, connectors).
3. Make capability changes additive and versionable.
4. Improve reuse across multiple agents/environments.

Bundle Layout

Each bundle folder should include:

1. bundle.yaml (metadata + capability manifest)
2. Optional agents/ definitions
3. Optional response-plans/ definitions
4. Optional scheduled-tasks/ definitions
5. Optional http-triggers/ definitions
6. Optional hooks/ definitions
7. Optional connectors/ templates
8. Optional roles/, templates/, and checklists/

Hook resources must use the v2 ExtendedAgent shape with spec.hooks, failMode, and maxRejections. Scheduled task, response-plan, and HTTP trigger resources must default to Review mode or document equivalent portal-import settings. Custom-agent templates should include explicit allowed_skills so agent-specific overrides do not accidentally drop required skills.

Manifest Metadata

Every bundle.yaml must include:

1. capabilities
2. triggers
3. required_inputs
4. outputs
5. risk_level (low, medium, or high)
6. autonomy_default: Review

This metadata makes bundle routing, review, and automation-readiness easier for agents and humans. Catalog and local manifest versions must match.

Current Bundles

• base-core
• observability-amba
• http-triggers-production
• http-trigger-auth-bridges
• source-rca-remediation
• pr-deployment-guard
• knowledge-lifecycle
• security-identity
• operational-metrics
• azure-workload-production
• vm-cosmos-production
• aks-production
• containerapps-production
• drasi-aks-production
• incident-platforms
• governance-kt
• tool-permissions-governance
• connectors-observability
• connectors-collab-handoff
• proactive-ops-governance
• waf-review
• ai-foundry-posture
• digital-native-governance

See catalog.yaml for bundle index and ownership.

How to Extend

1. Create a new bundle directory with bundle.yaml.
2. Add only capability-specific resources (avoid duplicating unrelated resources).
3. Register the bundle in catalog.yaml.
4. Add manifest metadata: capabilities, triggers, required inputs, outputs, risk level, and autonomy default.
5. Link it from references/bundles-operations.md and references/capability-matrix.md when useful.
6. Add acceptance tests/checklists for operational readiness.

Naming Guidance

1. Use lowercase and hyphens only.
2. Name by outcome or domain.
3. Keep resources environment-neutral using placeholders.

Upgrade Guidance

1. Prefer adding new bundles over editing many existing bundles.
2. If breaking changes are necessary, bump version and document migration.

Deployment Methods

Method 1: Portal (No Code Required)

1. Open Azure Portal → search "SRE Agent" → your resource
2. Navigate to Response Plans → Add
3. Paste YAML from bundle file
4. Replace @@PLACEHOLDER@@ values using parameters.example.yaml
5. Save

Time: ~5 minutes | Skill level: Portal-user | Rollback: Delete response plan

Method 2: Data-Plane API (Azure CLI + REST)

There is no az sre-agent CLI command group (verified 2026-08-10 against the Azure CLI reference and extensions index). Response plans are applied through the agent's data-plane API with a token for the https://azuresre.dev audience:

# Resolve the data-plane endpoint from the agent resource (api-version 2026-01-01)
AGENT=$(az resource list --resource-type Microsoft.App/agents --query '[0].id' -o tsv)
ENDPOINT=$(az rest --method GET --url "https://management.azure.com${AGENT}?api-version=2026-01-01" --query properties.agentEndpoint -o tsv)
TOKEN=$(az account get-access-token --resource "https://azuresre.dev" --query accessToken -o tsv)

# PUT creates, POST updates. The id MUST be in the PATH -- writing to the
# collection path returns 405 with an empty body, which reads like a transient
# failure rather than the wrong URL. An "id" in the JSON body is not enough.
curl -s -X PUT "$ENDPOINT/api/v1/incidentPlayground/filters/core-high-severity" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  --data @bundles/base-core/response-plans/core-high-severity.yaml

Time: ~10 minutes | Skill level: CLI-familiar | Rollback: POST the previous plan body (never DELETE-then-PUT a live plan; a rejected PUT after DELETE leaves alerts routing nowhere)

For full CI/CD automation, use apply-extras.sh from the upstream microsoft/sre-agent templates, which applies response plans, hooks, HTTP triggers, and knowledge files in the data-plane phase.

Method 3: Terraform / Bicep (Production Recommended)

See ../references/aks-containerapps-production.md for ready-made modules that wrap these bundles.

Time: ~30 minutes | Skill level: IaC-familiar | Rollback: terraform destroy or az bicep deploy --rollback

Troubleshooting Deployment

3. Keep deprecated bundles readable until replacement bundles are adopted.