A project agent reads Jira issues and their comment threads, drafts a risk-log entry in Dock with proposed severity and mitigation, then waits for a named PM to approve. Jira keeps the issue. Confluence keeps the program docs. Dock keeps the interpreted risk, the reviewer, and the timestamp. One node in our Dock for project management cluster.
Jira 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: a Program Risk Log table
| Risk ID | Jira link | Agent draft | Severity | Reviewer | Status | Decided at |
|---|---|---|---|---|---|---|
| RSK-204 | PLAT-1188 | "Auth migration blocked on SSO vendor reply; slip likely" | High | @priya (PM) | Approved | 2026-05-29 14:02 |
| RSK-205 | PLAT-1192 | "Comment thread shows scope creep on billing rewrite" | Medium | @priya (PM) | Edited then approved | 2026-05-29 16:40 |
| RSK-206 | PLAT-1197 | "QA flake rate rising on checkout suite" | Low | @priya (PM) | Sent back for re-read | 2026-05-30 09:11 |
Every row holds the agent's identity, the Jira issue key, the comment IDs cited, and the PM's verb. The agent does not hold opinions. It holds drafts. The PM holds the decision. The split is covered in Agent collaboration: a primer.
One worked workflow: Jira issue plus comments to risk log
The agent risk-scout-2026 watches a saved Jira filter for issues labeled program-risk. On a hit, it re-fetches the issue and the last 20 comments from Jira's API, summarizes the thread, and proposes a severity. It writes a Dock row pointing back to the Jira key and cited comment IDs, then mentions the program PM. The PM opens the row, sees the draft beside a live Jira embed, and either approves, edits, or sends back for re-read. The decision writes to the row. Nothing changes in Jira unless the PM acts there directly. The identity model lives in What agent identity actually means.
Why this matters
PMs do not want another tool. They want fewer surprises at standup. Reading every Jira comment thread does not scale past about thirty active issues. An agent can read all of them every morning, but only if its drafts are attributable. Putting the interpreted risk in Dock keeps Jira clean and gives the audit team a record. Same pattern in Dock for compliance and agent audit and compliance.
The architectural reason is covered in Cloud 2.0 for product: agents need a workspace of their own, separate from the platforms they read.
Try it
Wire risk-scout-2026 to your Jira project and your Dock risk log this week. Start with one PM, one saved filter, one named agent.
FAQ
Q: Does the agent write back to Jira? A: Only if the PM tells it to in the Dock row. Default is read-only on Jira. The agent's job is interpretation, not mutation.
Q: What happens when Jira state changes after the agent drafts? A: The Dock row stores the draft and the comment IDs it cited. When the PM opens the row, the agent re-fetches the issue so the PM sees current Jira state next to the original draft.
Q: Why not use Jira custom fields for risk? A: Jira is the system of record for the issue. The agent's interpretation is a different object with a different audit trail. Mixing them makes the issue history unreadable. Atlassian describes a Jira work item as the fundamental unit of tracked work, not an audit log for third-party interpretation (Atlassian docs).
Q: Does Confluence fit in here? A: Yes. The program runbook stays in Confluence, which Atlassian positions as a single source of truth for documentation (Atlassian). Dock links to the page; it does not replace it. Jira is positioned as a tool to plan, track, and deliver projects (Atlassian), which is the system-of-record role we leave it in.
