PM Agents

Rearchitected since this page was first written. PM Agents used to be a bespoke registry with their own API, an Inngest durable-workflow subsystem, and a dedicated Factory dashboard. That subsystem was hard-deleted and PM Agents are now ordinary scheduled workflow templates on the same substrate as any other workflow. The /api/pm-agents/* routes and the standalone PmAgentRegistration registry described in older material no longer exist. The core agent behavior described below (real Linear mutations, not a stub) is live - it runs in-session via the agent's own Linear tool calls, not through a separate "apply" step. The one piece that still carries an explicit non-headless verification caveat is the deferred run-summary write-back (see below).

PM Agents are scheduled agents that handle recurring product-management hygiene - tasks too periodic to wire into an issue-driven workflow trigger but too important to do manually. They ship as two official marketplace workflow templates (category Product Management) that any project can install, rather than as a subsystem baked into every installation.

How PM agents work

Each PM agent template is two independent, top-level-triggered branches in one workflow:

Branch 1 fires on a cron schedule and dispatches the system agent (agent://system/backlog-groomer or agent://system/outcome-auditor) via an agent.invoke node. The agent does all of its Linear reads and writes itself, in-session, via rensei linear - there is no separate platform-side "apply" step to stub out. This is real for both archetypes.
Branch 2 is a second, independent trigger on the same workflow: an agent.exit trigger filtered to this role's sessions (profile filter). When the dispatched session ends, the runner emits a completion event, a new instance roots at this trigger, and an issue.create step writes the agent's final-message roll-up into a dedicated run-summary issue. This is not wired as agent.invoke → agent.exit in one branch - agent.exit on the same edge would fire at cron-tick, before the agent runs.

The agent.exit branch carries an open, code-documented verification caveat: the profile filter value it scopes on must match what the runner actually stamps on a live exit event for this role, and a live scheduled run's project-id threading has not been confirmed outside of the source comments. A wrong filter value means the run-summary issue silently never gets created (fails safe, no spurious issues); the code accepts that risk explicitly rather than shipping an unfiltered (and cross-session-firing) trigger. Branch 1 - the actual grooming/audit work and Linear mutations - does not depend on this and is unaffected either way.

Sessions dispatched by PM agents are tracked under the agent's observationAgentId (system/backlog-groomer, system/outcome-auditor) in the observations table, so memory analytics reflect PM-agent activity alongside SDLC-agent activity.

Installing and viewing PM agents

PM agent templates are not auto-installed. Install them like any other workflow template:

Open Marketplace → Product Management for your project (the legacy /factory/pm-agents link now redirects here).

Install PM - Backlog Groomer and/or PM - Outcome Auditor. Installing creates a normal workflow instance in your project, on the default weekly Monday 09:00 UTC cron (author-tunable after install, same as any schedule.cron trigger).

Manage and inspect runs from the Workflows section like any other installed workflow - there is no separate PM Agents dashboard anymore. Use Test Run mode to validate a copy without dispatching a real agent session or touching Linear.

Registered archetypes

Two PM agent archetypes ship as official templates:

Archetype 1 - Backlog Groomer

Agent URI: agent://system/backlog-groomer Default schedule: Every Monday at 09:00 UTC (0 9 * * 1, tunable post-install) Work type: backlog-groomer Model tier: haiku

Each run, the Backlog Groomer enumerates top-level issues in the tracker's configured grooming-target status (default Icebox for Linear) and cascades into every sub-issue of each one it finds. It directly enacts changes, not just flags them:

Rescopes an issue (priority, estimate, description) when the codebase has visibly moved under it
Cancels non-viable, obsolete, or superseded issues (sets status to Cancelled)
Records real blocking relations where the tracker supports them
Marks a research-only issue Accepted once all of its related and sub-issue work is itself Accepted
Applies existing labels (e.g. needs-spec, stale) where they clarify state - it does not invent new labels

It leaves a short comment on each issue it changes, explaining what and why. It does not post a run-level roll-up as a Linear comment - that goes into the final agent message, which Branch 2 above captures into a dedicated run-summary issue instead. It is idempotent per-issue: before re-enacting a change, it checks that issue's recent history for the same change it already made that day and skips the duplicate.

Earlier documentation described this archetype as "read-heavy... it does not create or close issues." That is no longer accurate - the shipped system prompt has it cancelling and accepting issues directly, by design (founder-approved: it enacts, not merely proposes).

Archetype 2 - Outcome Auditor

Agent URI: agent://system/outcome-auditor Default schedule: Every Monday at 09:00 UTC (0 9 * * 1) Work type: outcome-auditor Model tier: sonnet

Each run, the Outcome Auditor re-reads a batch of recently-accepted issues in its scoped project, re-reads their original goal and acceptance criteria, and inspects what actually shipped (merged PR, final issue state, QA/acceptance evidence) to judge whether the work delivered the intent, not just the letter of the criteria. For every real gap it finds, it opens a new, well-scoped follow-up issue with the evidence and links it to the audited issue, then posts a PASS or GAP summary comment on the audited issue. It is deliberately conservative - it does not open follow-ups for stylistic nits or speculative future work, and it does not re-run QA or re-transition an already-accepted issue itself.

Adding a custom PM agent archetype

There is no runtime registry to append to. A new PM agent archetype is a new workflow template (requires platform source access):

Add a system AgentCard spec for the archetype in src/lib/factory/system-pm-cards.ts (role, workType, system prompt, tool allow/disallow list) and seed it with scripts/seed-system-pm-cards.ts.

Build a workflow template under src/lib/workflow/templates/pm-<name>/, following pm-backlog-groomer or pm-outcome-auditor as a model: a schedule.cron → agent.invoke agent://system/<name> branch for the work, plus an independent agent.exit (profile-filtered) → issue.create branch if you want a run-summary issue. The shared node builders live in pm-shared/node-helpers.ts.

Publish the template bundle with scripts/publish-pm-templates.ts (or a sibling script following its pattern) so it appears in the Marketplace's Product Management category.

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 durable-workflow patterns PM agents used to rely on directly
Test Run mode - validate a PM workflow without a real dispatch
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