Project 4: a team pilot and risk register
Goal: a pilot package you can put in front of a team — why, for whom, within which boundaries, with which risks, and what you will measure.
This is not a technical document but a decision document. Its readers are a team lead, information security and often legal. A good pilot package does not say "the agent is great" — it says which work, within which boundary, measured how.
Six parts of the package:
- Scope — the two or three workflows in the pilot; everything else is explicitly out
- Role matrix — who may automate what, and who approves (the table from Stage 4)
- Technical boundary — the backend, toolsets, managed configuration, allowlists
- Data flow — what data the agent gets, which provider it reaches, and what it never sees
- Risk register — for each risk: description, likelihood, impact, mitigation, residual risk
- Success criteria — when the pilot counts as a success, as a number
Turning success into a number looks hard, but it is the most important part of the pilot. Examples that work: "at least 3 hours saved per week", "the daily report takes 10 minutes instead of 40", "cost stays under $50 a month", "no unapproved destructive command was executed". That last one matters especially — it makes the security outcome measurable too.
Practice. Write the pilot document (two or three pages is enough) and show it to a real person — a team lead or the security owner. Done means: at least one question came back and you changed the document because of it. If it raises no questions, it is probably not concrete enough.
📚 Sources and documentation
- Managed scopeofficialhermes-agent.nousresearch.com
- Securityofficialhermes-agent.nousresearch.com
- User storiesofficialhermes-agent.nousresearch.com
When choosing the pilot's scope, look at what comparable teams did.
- Release notesofficialgithub.com