Working with agents, role by role: a new practical guide
Most material about AI agents in operations is written for the person deciding whether to buy one. Very little of it is written for the person who has to open the console on Monday morning and get through their queue.
That gap shows up in every rollout we run. Leadership signs off, the connections get made, the agents start producing — and then eight different people, doing eight different jobs, each have to independently work out what "using agents" means for their day. The SRE's answer looks nothing like the security engineer's. The engineering manager's looks nothing like either.
So we wrote the guide for them. Working with agents, role by role is a 19-page practical guide: one chapter on the platform, one chapter of shared habits, then eight roles. It is free, readable in full on the web, and downloadable as a PDF in English and Vietnamese.
What is in it
The guide is deliberately narrow. It does not argue that you should adopt agentic operations — we have written that argument elsewhere. It assumes you already have agents connected and answers a much more concrete question: which part of your specific queue can an agent hold, and which part stays yours?
Each of the eight role chapters follows the same four-part shape:
- How this work changes — how the task is done today, why it stalls, and what changes with an agent in the loop.
- What the day looks like — morning, in flow, end of day. Where the delegation actually happens in a working day.
- What to delegate — the two agents most relevant to that role, and the exact sentence to type to get started.
- The common mistake — the failure mode we see most often in that role, named plainly.
Every role chapter then ends with a real product screen and three notes on how to read it, because the habit only sticks if it survives contact with the console.
The eight roles
| Role | The question it answers |
|---|---|
| Platform / DevOps Engineer | Which part of a growing request queue can an agent hold? |
| Site Reliability Engineer | How do you keep availability without answering every alert at 2am? |
| Software Engineer | What should be checked before a human reads your diff? |
| Security Engineer | How do you tell less real exposure from a smaller backlog? |
| Cloud Architect / Cost Owner | How do you see architecture and cost at the same time? |
| Engineering Manager | Where do you read system state without asking people to write status? |
| On-call Engineer | How do you spend a pager week on real failures? |
| Automation Owner | What work qualifies for automation, and who has to own it? |
Three habits that run through all of them
Before the role chapters there is a short chapter on habits. These three showed up in enough engagements that we stopped treating them as advice and started treating them as prerequisites.
Delegate repetition, keep judgement. Repetition is the signal to look for. The second time you write the same runbook, review comment or query, that task is a candidate for an agent. Not the hardest task — the most repeated one.
Review the decision, not the keystrokes. Ask for the plan and the evidence before approving an action. Reading a plan takes a minute and teaches you how the agent reasons. Teams that skip this either approve things they cannot read, or refuse to approve anything at all; both stall the rollout.
Send it back with a reason. When output is wrong, write down why. The reason narrows the next attempt. A silent rejection guarantees the same work comes back next week, unchanged.
The measure that actually matters
The guide argues one thing more than once, so it is worth saying here too:
Time is saved where work stops waiting on a person, not where prompts get longer.
This is why the Engineering Manager chapter tells managers to stop counting agent volume. Agent volume is easy to report and tells you almost nothing. The number that shows whether any of this is working is waiting time — how long a change sat idle because it needed a human to look at it — and its companion, repeat work, meaning anything a person did twice that an agent could have owned.
A rollout where agents did ten thousand things and humans still wait four days for an approval has not moved. A rollout where agents did far less but nothing waits has.
How much autonomy, and when
The guide is opinionated about pace, and it is slower than most vendor material:
- Week one: read-only. Agents observe and report. Compare their conclusions with yours to learn where they are reliable.
- Then: propose and wait. Agents draft the change and stop. A named person approves before anything lands, so mistakes stay cheap.
- Steady state: act in a boundary. Agents act inside a scope you wrote down, and every action leaves a trail you can read afterwards.
This maps onto graduated autonomy in the product, but the guide frames it as something a team earns rather than something an admin configures. The sample screens in the book reflect that honestly — the Engineering Manager roll-up shows zero incidents closed with no human touch, because at that stage of rollout everything is still approval-gated by choice.
Read it or download it
The whole guide is readable on the web, chapter by chapter — no download, no gate on the reading. If you want the designed PDF to circulate internally or hand out at a workshop, it is available in English and Tiếng Việt from the same page.
If you are setting strategy rather than doing the work, the Leadership Edition covers the executive case, and the Engineer Edition goes deep on the harness — context engineering, safety, policy-as-code, and evaluation. All three now live together in the eBooks library.