Use case

AI Workflows for Policy Review and Updates

Name: Fleet
Author: Fleet

Company policies rot quietly. The security policy references a tool you retired; the data-retention policy predates the product feature it should constrain. Reviewing them is everyone's job and no one's, so updates happen in bulk panic before an audit or after an incident.

When updates do happen, the chain of custody is murky: a doc edited by several hands, approved in a meeting nobody minuted, published to a wiki without versions. For documents whose entire value is being authoritative, that's self-defeating.

How it works with an agent fleet

A Fleet workflow drafts the policy revision against what changed, routes it through a legal/owner review that flags substantive concerns, and publishes only after a recorded approval.

genflows:
  - name: policy-update
    steps:
      - {name: revise, prompt: "Draft the policy revision described in the trigger ticket. Preserve unchanged sections verbatim; mark every change.", corpus: ["policies/security.md", "docs/systems/*.md"], kind: report, out: revision.md}
      - {name: counsel-review, prompt: "Review the revision for legal exposure, contradictions with other policies, and unenforceable language.", depends_on: [revise], kind: review, out: concerns.md}
      - {name: owner-approval, depends_on: [revise, counsel-review], kind: approval, out: decision.md}
      - {name: publish, depends_on: [owner-approval, revise], kind: publish, out: published.md}

Each revision is a fresh run: drafted, reviewed, approved, published — four artifacts with lineage. The policy's history becomes a sequence of approved revisions instead of a wiki page's edit log.

The fleet pattern

Label-triggered revision → counsel review → owner approval gate → publish. The bureaucratic virtue (who approved this wording, and when?) falls out of the machinery instead of requiring discipline.

Guardrails that matter here

Publication depends on the gate — an unapproved revision cannot become the published policy
The review step cross-references sibling policies from the corpus, catching the contradiction class of error (two policies disagreeing about retention windows)
Approver identity and timestamp are recorded against the exact revision — chain of custody by construction

Who this is for

Compliance, legal, and security owners maintaining policy sets that auditors, customers, or regulators actually read — anywhere 'who approved this version' is a question with consequences.

Frequently asked questions

Can the legal review step be a human instead of AI?

The review step drafts the findings; the approval gate is always human. Many teams treat the AI review as counsel's first pass — it flags, counsel reads the flags plus the diff at the gate, and the approval records their decision.

How do we trigger a revision?

Manually from the dashboard, or by labeling a ticket that describes the needed change — the run starts seeded with that ticket. Scheduled annual-review runs work too: the draft step reports 'no changes needed' or proposes them.

Related use cases

AI Workflows for Compliance Evidence →AI Workflows for Security Advisories →AI Workflows for Marketing Content Governance →

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.

See how it works Install Fleet