What Uber’s Agentic Pods Can Teach Ops Teams
How to build an L1 agentic operations team with role-based profiles, reusable skills and safe workflows
This is an operations adaptation of Uber’s published Agentic Pods method. It is not presented as an original replacement for Uber’s model. The goal is to apply the same core idea to SRE, Platform Engineering, DevOps and MLOps.
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.
Senior engineers should still handle novel failures, architecture decisions, trade-offs, high-risk remediation and unclear situations. The agentic team removes noise. Humans handle impact.
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.
One warning matters: a profile is not a security boundary. Prompts can guide behaviour, but they do not enforce permissions. Use least-privilege credentials, tool allowlists, sandboxes, approval gates, timeouts, rollback and audit logs outside the model.
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