Executive thesis
Author the workflow once, adapt it at the runtime edge
Portable AI product-management workflows should be designed as a reusable workflow kit that sits above the agent runtime, not as a pile of OpenClaw-specific or Hermes-specific prompts. The useful target is a package made of six things: a product operating charter, small reusable skills, machine-readable tool and artifact contracts, approval policies, eval datasets, and delivery templates.
OpenClaw and Hermes Agent are useful because both expose the primitives product teams need: skills, typed tool surfaces, lifecycle hooks, stored sessions, automation, and MCP-style extension paths. That means a B2B SaaS team can define one governed PM workflow library and deploy it into either runtime with thin adapter layers for scheduling, approvals, packaging, and delivery.
Operating principle
Do not make the runtime your product-management system of record. Keep feedback, roadmap, analytics, docs, issues, releases, and customer communication in dedicated systems. Let the agent read, draft, request approval, and leave a trace.
Showcase
See the workflow contract in action
The power of a portable PM workflow is that the same product semantics survive across runtimes. A feedback-to-roadmap workflow should produce the same Evidence Card, approval request, and trace whether it runs through OpenClaw scheduled tasks or a Hermes Kanban handoff.
Shared skills and schemas sit above OpenClaw and Hermes Agent. Runtime adapters handle hooks, cron, task state, delivery, and approvals without changing the PM workflow contract.
Feedback items, account metadata, roadmap items, source URLs, segment definitions.
Normalize evidence, dedupe themes, preserve quotes, connect themes to roadmap opportunities, create draft evidence.
Evidence Card and roadmap evidence draft.
PM approves roadmap links and any customer follow-up.
Trigger through webhook, scheduled task, or slash command; package logic as feedback-triage and roadmap-evidence skills.
Route intake into a Kanban task or webhook run; store prior attempts and reviewer comments on the board.
Portability layer
The shared layer that makes OpenClaw and Hermes compatible
The first portability layer is context, not tools. Put operating policy in AGENTS.md, tone and escalation stance in SOUL.md, and product-specific preferences in durable memory or team-owned files. Then keep the PM workflow logic in small skills and shared artifact schemas.
| Layer | Portable recommendation | OpenClaw mapping | Hermes Agent mapping |
|---|---|---|---|
| Context | Put operating authority in AGENTS.md, tone and escalation stance in SOUL.md, and durable team preferences in memory files. | Workspace context and standing orders. | Project context discovery and session-start AGENTS.md loading. |
| Skills | Use small Agent Skills-compatible workflows instead of one giant PM operating skill. | SKILL.md folders across workspace, personal, shared, and managed roots. | Progressively loaded skills exposed through local skill libraries and slash commands. |
| Tool contracts | Own JSON/YAML schemas for PM actions, then compile to runtime-native plugin or tool surfaces. | Typed tools, plugin manifests, config schema, hooks. | Central tool registry, plugin manifests, schemas, and hooks. |
| MCP and integrations | Expose feedback, analytics, tickets, CRM, docs, and roadmap systems through shared MCP or typed APIs. | MCP bridge and managed MCP server definitions. | MCP server discovery and registration into the normal tool registry. |
| Orchestration | Break long-running PM work into bounded stages with explicit state transitions. | Background tasks, cron, heartbeats, sub-agents, and Task Flow. | Sessions, cron, webhooks, delegation, and durable Kanban. |
| Governance | Write policy as human-readable authority and executable enforcement. | AGENTS.md, SOUL.md, Gateway allow/deny, hooks, retained logs. | Approval modes, pre-tool hooks, gateway dispatch hooks, sessions, and JSONL traces. |
Operating model
The portable PM workflow kit
A practical team model has four owners: the workflow author defines the business procedure and success rubric, the runtime operator controls credentials and scheduling, the approver signs off on sensitive mutations or external communication, and the eval owner maintains golden cases and drift checks.
| Operating layer | Recommendation | Why it matters |
|---|---|---|
| Workflow | Define each PM workflow as a reusable skill with clear inputs, outputs, stop conditions, and approval gates. | Prevents runtime-specific prompt sprawl. |
| Context | Keep operating authority in AGENTS.md and product-specific tone or escalation stance in SOUL.md. | Lets both runtimes start from the same durable policy. |
| Artifacts | Standardize Evidence Cards, Decision Records, Delivery Artifacts, and workflow run manifests. | Makes outputs reviewable and portable. |
| Tools | Own shared tool schemas before implementing runtime adapters. | Avoids coupling PM workflows to one plugin format. |
| Approvals | Use draft-only defaults and named approval policies for external communication or roadmap mutations. | Preserves PM judgment. |
| Evals | Maintain golden traces for feedback, prioritization, PRD, launch, and comms workflows. | Tests workflow behavior, not just prose quality. |
Workflow library
Reusable AI PM workflows for both runtimes
Every workflow should produce three durable objects: an append-only Evidence Card, a Decision Record that explains the choice and alternatives, and a Delivery Artifact such as a PRD, stakeholder memo, release note, launch checklist, help-doc change request, or onboarding-analysis summary.
| Workflow | Inputs | Agent actions | Output | Approval gate |
|---|---|---|---|---|
| Raw feedback to roadmap evidence | Feedback items, account metadata, roadmap items, source URLs, segment definitions. | Normalize evidence, dedupe themes, preserve quotes, connect themes to roadmap opportunities, create draft evidence. | Evidence Card and roadmap evidence draft. | PM approves roadmap links and any customer follow-up. |
| Launch readiness review | Decision Record, release ticket, help docs, analytics, support notes, target segment. | Check missing docs, unsupported claims, rollback triggers, metrics, support risk, and launch copy gaps. | Launch checklist, risk register, comms pack, and approval request. | PM, PMM, support, and engineering owner approve before publication. |
| PRD and spec generation | Decision Record, evidence IDs, constraints, non-goals, success metric, unresolved questions. | Draft PRD, user stories, acceptance criteria, risks, open questions, and review notes. | PRD draft and engineering handoff brief. | PM approves problem framing; engineering approves feasibility and acceptance criteria. |
| Onboarding drop investigation | Funnel data, cohort definitions, recent changes, user feedback, tours, checklists, help content. | Compare cohorts, assemble evidence by funnel stage, identify friction points, draft no-code experiments. | Onboarding diagnosis memo and experiment brief. | PM approves experiment setup, audience, success metric, and customer-facing changes. |
| Help doc maintenance | Release diff, changed UI labels, support tickets, existing docs, product tours. | Find stale docs, draft exact changes, cite release source, flag uncertain copy. | Help-doc diff and support-risk summary. | Support or PM approves before publishing. |
Tool contracts
Shared tool contracts before runtime adapters
Your PM workflow contract should live in your own JSON or YAML schemas first, then compile downward into runtime-native plugin or tool surfaces. That prevents one runtime’s manifest or registry from becoming the only source of truth.
| Tool | Input schema | Output schema | Level | Safety rule |
|---|---|---|---|---|
| searchFeedback | { query, segment?, productArea?, from?, to?, limit } | { items: EvidenceSource[] } | Read | Return source IDs and URLs; never summarize without citations. |
| findRoadmapItems | { query, productArea?, status? } | { items: RoadmapItem[] } | Read | Expose public/private visibility and status; do not mutate. |
| createEvidenceDraft | { roadmapItemId, evidenceIds, summary, confidence } | { draftId, reviewUrl } | Draft | Never publish, reprioritize, or notify customers. |
| queryAnalytics | { metric, segment, window, filters } | { queryId, result, caveats } | Read | Return time window and query definition with every result. |
| draftAnnouncement | { audience, sources, changeSummary, tone } | { draftId, copy, unsupportedClaims } | Draft | Mark unsupported claims and require approval before send. |
| requestApproval | { approverRole, action, artifactId, risk } | { approvalId, status } | Control | Pause the run until the named role approves the exact action. |
| writeTrace | { runId, inputs, tools, outputs, policy } | { traceRef } | Write | Trace every durable PM workflow before delivery. |
| replayTrace | { traceRef, rubricId } | { pass, failures, firstDivergence } | Eval | Fail if evidence is invented or approval gates are skipped. |
Code examples
Implementation-ready examples
These examples are intentionally runtime-neutral. The OpenClaw adapter can map them to skills, plugin manifests, hooks, cron, and Task Flow. The Hermes adapter can map them to skills, plugin schemas, hooks, cron, webhooks, and Kanban tasks.
Portable workflow manifestyaml
workflow_run:
workflow_id: roadmap-evidence
workflow_version: 1.2.0
runtime: openclaw-or-hermes
triggered_by:
type: webhook
actor: feedback-intake
inputs:
feedback_ids: [FB-2184, FB-2191, FB-2207]
segment: enterprise-admins
controls:
delivery_mode: draft_only
approval_policy: roadmap-evidence-v1
external_send_allowed: false
outputs:
evidence_card: artifacts/evidence/EV-2026-084.md
decision_record: artifacts/decisions/DR-2026-084.md
approvals:
required: [product-manager]
granted: []Evidence Card schemajson
{
"id": "EV-2026-084",
"sourceIds": ["FB-2184", "FB-2191", "FB-2207"],
"productArea": "Admin onboarding",
"segment": "Enterprise admins",
"theme": "SSO setup blocks workspace activation",
"quotes": [
{
"sourceId": "FB-2184",
"text": "We could not invite the team until SSO was configured.",
"url": "https://example.com/feedback/FB-2184"
}
],
"confidence": "medium",
"missingEvidence": ["activation funnel by account tier"],
"recommendedNextAction": "Create roadmap evidence draft"
}Feedback triage prompt frametext
You are a product operations agent for a B2B SaaS team. Use only the provided feedback, account metadata, roadmap items, and analytics. Task: 1. Cluster feedback by product job, not keyword. 2. Preserve exact customer quotes with source IDs. 3. Separate facts, inference, and missing evidence. 4. Create an Evidence Card for each theme. 5. Draft roadmap evidence only when an existing roadmap item matches. Stop if: - Source evidence is missing. - The request would change roadmap priority. - The output would be customer-facing. Return: theme, affected segment, source IDs, quotes, duplicate count, confidence, roadmap match, recommended next action, approval request.
Governance
Approvals belong in policy and enforcement
Governance must live in the control plane, not only in prompt text. Write the policy as human-readable operating authority in context files and as executable enforcement in hooks, approval logic, tool permissions, or workflow schemas.
Tool execution approval
Required for destructive commands, external writes, production-adjacent mutations, new credentials, or widened scopes.
Publication approval
Required for customer-visible release notes, help-center updates, external stakeholder messages, or lifecycle emails.
Policy-change approval
Required for new cron jobs, new MCP servers, shared-skill promotion, or broader delivery permissions.
Draft-only until approved
Every PM workflow should default to drafts unless the workflow run has an explicit approval policy and granted approver.
Evals
Evaluate workflow contracts, not just answer quality
Portable evals should test evidence assembly, tool order, approval behavior, artifact structure, trace completeness, and delivery safety. A PM workflow is not successful because the model writes fluent prose; it is successful when the artifact can survive review and replay.
| Metric | What it measures | How to evaluate |
|---|---|---|
| Evidence citation accuracy | Whether every claim links back to a real source. | Replay traces and sample citations against source systems. |
| PM edit rate | How much human correction each artifact needs. | Track accepted, edited, rejected, and rewritten outputs. |
| Approval rejection rate | Whether the agent is overreaching or producing weak drafts. | Measure rejected approval requests by workflow and reason. |
| Launch readiness completeness | Whether launch workflows catch docs, support, analytics, rollback, and comms gaps. | Compare against historical launch checklists. |
| Trace replay pass rate | Whether a workflow still matches accepted PM behavior after changes. | Run golden cases after prompt, skill, tool, or model updates. |
| Support deflection | Whether docs and comms updates reduce avoidable support load. | Compare ticket volume before and after approved updates. |
Rollout
Roll out in stages
The safest rollout starts in read-only and draft-only mode. Once manifests, approvals, and evals are stable, move to scheduled internal summaries and launch-readiness assistance. External publication workflows should remain behind named approval policies.
| Stage | Allowed workflows | Allowed tools | Metrics to track |
|---|---|---|---|
| Read-only PM research assistant | Search, summarize, cite, and prepare evidence views. | Read-only feedback, docs, roadmap, analytics. | Evidence citation accuracy, PM usefulness, hallucination rate. |
| Draft-only workflow agent | Create Evidence Cards, Decision Records, PRDs, launch checklists, and release-note drafts. | Draft tools only; no publish or priority changes. | PM edit rate, approval rejection rate, artifact completeness. |
| Approved product ops agent | Create approved draft updates and route review tasks. | Read, draft, request approval, write trace. | Approval latency, skipped-gate failures, support-risk catches. |
| Multi-system workflow agent | Coordinate feedback, roadmap, docs, analytics, and issue tracker workflows. | Bounded writes behind role approval. | Trace replay pass rate, cycle time, rollback frequency. |
| Monitored automation | Scheduled summaries, stale-doc sweeps, release-readiness scans, and post-launch reviews. | Cron/webhook plus exception review. | Drift, cost, latency, incident count, outcome impact. |
Architecture
Reference architecture
The architecture is deliberately simple: source systems stay authoritative, the runtime hosts execution, the tool layer mediates access, the approval layer controls risky actions, and the trace/eval layer records what happened.
Source systems
feedback | roadmap | analytics | docs | issues | releases
↓
Tool contracts
searchFeedback | findRoadmapItems | queryAnalytics | requestApproval
↓
Agent runtime
OpenClaw adapter or Hermes Agent adapter
↓
Durable artifacts
Evidence Card | Decision Record | Delivery Artifact | Workflow Run Manifest
↓
Trace replay and evals
citations | tool order | approval gates | artifact quality | delivery safetyTemplates
Repository structure for a portable PM workflow kit
Keep shared workflow assets at the top and runtime adapters at the edge. This lets the same PM process run in either OpenClaw or Hermes Agent without duplicating the actual workflow semantics.
pm-workflows/
AGENTS.md
SOUL.md
skills/
feedback-triage/SKILL.md
roadmap-evidence/SKILL.md
launch-readiness/SKILL.md
prd-generation/SKILL.md
helpdoc-maintenance/SKILL.md
contracts/
evidence-card.schema.json
decision-record.schema.json
workflow-run.schema.json
delivery-payload.schema.json
templates/
prd.md
launch-checklist.md
release-notes.md
helpdoc-diff.md
stakeholder-update.md
evals/
fixtures/
rubrics/
golden-cases.jsonl
adapters/
openclaw/
hermes/Where Userorbit fits
Portable agent workflows need trustworthy product context. Userorbit brings feedback, roadmap, surveys, announcements, product tours, checklists, and help center content into one product communication system, giving OpenClaw or Hermes Agent workflows a safer product layer to read from and draft into.
The best pattern is to let Userorbit remain the customer-evidence and product-communication source of truth while the runtime handles orchestration. Agents can create evidence drafts, launch-readiness drafts, help-doc suggestions, onboarding experiment briefs, and segmented announcement drafts without publishing anything until a PM approves.
FAQ
AI product management workflow questions
What are AI product management workflows?
AI product management workflows are repeatable PM processes where an agent gathers product context, calls tools, produces structured artifacts, pauses for approval, and leaves a trace. Examples include feedback triage, roadmap evidence, PRDs, launch readiness, release notes, help-doc maintenance, and onboarding analysis.
How can product teams use OpenClaw and Hermes Agent together?
Treat OpenClaw and Hermes Agent as compatible runtime targets. Put the reusable workflow logic in Agent Skills, shared schemas, approval policies, and eval fixtures, then use thin runtime adapters for packaging, scheduling, hooks, delivery, and task state.
Which workflow should product teams automate first?
Start with raw feedback to roadmap evidence or stale help-doc detection. Both are evidence-heavy, frequent, reviewable, and recoverable. Avoid autonomous roadmap priority changes or customer-facing sends until approval gates and trace replay are mature.
Can these workflows replace product management tools?
No. Agent runtimes should not become the product system of record. Keep feedback, roadmap, analytics, docs, issues, release controls, and customer communication in dedicated systems, then let agents read, draft, and request approval across them.
How do you evaluate AI PM workflows?
Use workflow-level evals: evidence citation accuracy, quote fidelity, tool order, approval behavior, artifact completeness, PM edit rate, and trace replay against real historical PM cases.
What makes a workflow portable across OpenClaw and Hermes Agent?
A portable workflow keeps semantics outside the runtime: AGENTS.md policy, small skills, shared tool schemas, durable artifact contracts, approval policies, eval fixtures, and thin runtime-specific adapters.