How does an agent run risk management for a product team without becoming the risk itself? It reads tickets and dependency chains across the team's platforms, drafts a structured risk register update in Dock, and routes each row to a named PM reviewer. Mitigations are not applied to source platforms until the PM approves. The agent never closes its own loop. This is the Cloud 2.0 split for product teams.
Jira, Asana, and Confluence stay the system of record for the raw data. Dock is the system of record for what the AGENT INTERPRETS. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.
The Dock surface: risk_register table
| risk_id | source_refs | category | drafted_mitigation | reviewer | status |
|---|---|---|---|---|---|
| RSK-204 | jira:PLAT-1182 | dependency-slip | Cut SSO v2 scope to Okta for M4 | priya.s | approved |
| RSK-205 | confluence:SPEC-Billing-v3 | spec-ambiguity | Add proration rule; block BIL-440 | marco.t | pending |
| RSK-206 | jira:PLAT-1190 | capacity | Move ticket from sprint 24 to 25 | priya.s | rejected |
Every row links back to the originating ticket or page. The reviewer column is a named human, not a queue. The status field is the only gate the agent checks before pushing outbound.
A worked workflow
The agent runs on a four-hour cron. Each run, it pulls open tickets from Jira and Asana that touch the active milestone, fetches linked Confluence specs, and builds a dependency graph. It scans for three patterns: blockers that slipped, specs whose acceptance criteria contradict a downstream ticket, and sprint capacity above historical throughput by fifteen percent.
For each hit, it writes a risk_register row with source refs, a drafted mitigation, and the on-call PM as reviewer. It posts a single digest to the team channel. The PM approves, edits, or rejects with a comment. On approval, a second agent pass writes the mitigation back to the Jira ticket or Confluence page, with a footer noting the Dock row id and the approving PM. Nothing reaches the platforms unattributed. See the agent collaboration primer: the agent drafts, the human decides, both sign.
Why it matters
A register an agent maintains alone drifts into ritual. A register a PM maintains alone misses cross-ticket patterns. Splitting the work gives coverage without surrendering judgment. Because every row carries agent identity and a reviewer name, the register doubles as an audit trail. When the postmortem asks who deferred SSO v2, the answer is in the row.
PMI's risk register pattern recommends categories, impact, mitigations, and triggers as columns (PMBOK guidance). ISO 31000 frames risk management as identification, analysis, evaluation, treatment, and monitoring integrated into core work (ISO 31000:2018). The Dock surface maps to both.
For the same trail on SOC 2 evidence, see Dock for compliance and agent audit and compliance. For the full PM cluster, start from Dock for project management.
FAQ
Can the agent close risks on its own?
No. It can mark mitigation-applied after writing back, but closure requires the named PM. The closing transition is human-only.
What if the PM is out and a risk is time-sensitive? The reviewer field accepts a backup. The agent reads the current backup from a team roster doc each run. Escalation past the backup is a paging event, not a silent retry.
Does the agent edit Jira tickets directly? Only on approved rows, and only to append a mitigation note. Original ticket fields are untouched. Jira remains the system of record for ticket state.
How is this different from a Jira automation rule? A Jira rule fires on a single ticket event. This agent reads across Jira, Asana, and Confluence, correlates them, drafts prose mitigations, and waits for human approval. The audit row exists whether or not the mitigation is applied.
