PM Agents

Partially implemented. The registry, API, dashboard pages, manual trigger, and the durable workflow scaffolding are shipped. The effect layer is stubbed: the workflows do not yet dispatch a real agent session (the dispatch step logs and returns a synthetic session id) and do not yet mutate Linear (no labels, comments, or follow-up issues are written). The archetype behaviors below describe the design intent the stubs will be wired to.

PM Agents are scheduled, durable agents that handle recurring product-management hygiene - tasks too periodic to wire into a workflow trigger but too important to do manually. Unlike SDLC agents that run in response to issue events, PM agents run on a cron schedule and are backed by durable Inngest workflows so they survive server restarts and can wait for async events.

How PM agents work

Each PM agent (by design):

Fires on a cron schedule (or via manual trigger in the UI).
Dispatches one or more Rensei agent sessions via ctx.step.run.
Waits for session completion via ctx.step.waitForEvent with a configurable timeout.
Takes a follow-up action (post a summary, open issues) based on the session result.

Today steps 2 and 4 are stubs: the dispatch step generates a deterministic per-day session id and logs the dispatch record instead of creating a session, and the apply step logs the recommendations it would write without mutating Linear. The cron triggers, step memoisation, completion-event bridge, and timeout handling around them are real.

Sessions dispatched by PM agents are tracked under the agent's observationAgentId in the observations table, so memory analytics reflect PM-agent activity alongside SDLC-agent activity.

Viewing PM agents

Navigate to Factory → PM Agents in your project. The page lists all registered PM agents, their schedule, last-run status, and a Run now button for manual triggers.

Each agent's detail page shows:

Archetype and description
Cron schedule (UTC)
Required capabilities
Last 10 run outcomes (started / completed / timed-out / failed)
Run history detail (timings, timeout/failure reasons)

Registered archetypes

Two PM agent archetypes ship with every Rensei installation:

Archetype 1 - Backlog Groomer

Name: backlog-groomer Schedule: Every Monday at 09:00 UTC (0 9 * * 1) Capabilities: linear.read, linear.labels.write, linear.comments.write Work type: pm.backlog-grooming

The Backlog Groomer is designed to perform a weekly review of the project's Linear backlog:

Tag issues that lack a specification with the needs-spec label
Flag issues that have been in backlog for more than 30 days as stale
Leave a grooming comment summarising what it checked and what it flagged

This agent is read-heavy by design - it does not create or close issues. Its goal is to surface the information a human PM needs to prioritise the next sprint without requiring them to scroll through the full backlog. (The backlog read is implemented; the label/comment writes are the stubbed apply step.)

Example Linear comment the Backlog Groomer is designed to leave:

Backlog review (2026-06-02):
- 3 issues tagged `needs-spec` (ENG-412, ENG-389, ENG-374)
- 2 issues stale > 30d (ENG-301, ENG-288) - no updates since last sprint
- 12 issues reviewed total, 7 look ready for sprint planning

Archetype 2 - Outcome Auditor

Name: outcome-auditor Schedule: Every Monday at 09:00 UTC (0 9 * * 1, fortnightly by design via workflow skip logic) Capabilities: linear.read, linear.comments.write, linear.issues.write Work type: pm.outcome-audit

The Outcome Auditor is designed to run a post-acceptance gap analysis on recently merged issues:

Read the last N issues that moved to Accepted (configurable, default 20)
Compare each merged PR against the original intent and acceptance criteria in the Linear issue
Surface identified gaps back to the team (summary comment; follow-up issues are a design option, not current behavior)

This creates a feedback loop between shipped work and the original specification - surfacing cases where implementation drifted from intent or where the acceptance criteria were incomplete. Today the accepted-issue loader is a stub (returns an empty set) and no Linear writes occur, so the workflow runs end-to-end but audits nothing.

Manual trigger

Run any PM agent immediately without waiting for the next cron fire:

Navigate to Factory → PM Agents.
Click on the agent you want to run.
Click Run now.

The run appears in the agent's history panel within seconds.

POST /api/pm-agents/<name>/trigger
Authorization: Bearer rsk_live_...

# Example: trigger the backlog groomer
POST /api/pm-agents/backlog-groomer/trigger

Returns 200 { run: { id, triggeredAt } } on success.

PM agent registry API

# List all registered PM agents
GET /api/pm-agents

# Get a single agent by name
GET /api/pm-agents/<name>

# Trigger a manual run
POST /api/pm-agents/<name>/trigger

GET /api/pm-agents returns the full PmAgentRegistration array:

[
  {
    "name": "backlog-groomer",
    "displayName": "Backlog Groomer",
    "archetype": "Archetype 1 - Backlog Groomer",
    "description": "Weekly review of the project's Linear backlog...",
    "scope": "system",
    "capabilities": ["linear.read", "linear.labels.write", "linear.comments.write"],
    "cron": "0 9 * * 1",
    "workType": "pm.backlog-grooming",
    "observationAgentId": "system/backlog-groomer"
  },
  {
    "name": "outcome-auditor",
    "displayName": "Outcome Auditor",
    "archetype": "Archetype 2 - Outcome Auditor",
    "description": "Fortnightly audit of the last N accepted issues...",
    "scope": "system",
    "capabilities": ["linear.read", "linear.comments.write", "linear.issues.write"],
    "cron": "0 9 * * 1",
    "workType": "pm.outcome-audit",
    "observationAgentId": "system/outcome-auditor"
  }
]

Adding a custom PM agent archetype

To register a new PM agent (requires platform source access):

Implement the workflow in src/lib/inngest/functions/pm-<name>.ts. Export a DurableWorkflow object and a trigger event name constant.

Append a PmAgentRegistration to PM_AGENT_REGISTRATIONS in src/lib/pm-agents/registered.ts. The observationAgentId must match the agent_id written to the observations table by your workflow.

The PM session completion bridge (pm-session-completion.ts) derives its detection set from pmAgentObservationIds(), so any new registration is automatically detected when its inner sessions complete.

Memory and observations

PM agents write structured observations to the platform memory store under their observationAgentId. These observations appear in:

Memory analytics under the agent's ID
Agent skill evolution charts in the factory intelligence panel
Cross-project knowledge transfer (if the observation content qualifies and the Cedar policy permits)

This means the Outcome Auditor's gap findings are durable and queryable across future PM-agent runs - patterns in acceptance-criteria gaps accumulate over time.

Long-Running Agents - the DurableWorkflow abstraction backing PM agents
Agent Cards - agent identity and capabilities
Memory Analytics - see PM agent observation accumulation
Linear Integration - Linear credentials and OAuth required by PM agents

On this page