Agent class · Native substrate

Govern your workflow and RPA automations.

From bot logs to proof of delivery.

Execution histories, queues, schedules, exception logs — workflow platforms already keep most of what the standard requires. As deterministic bots turn agentic, GOVENANT is how the audit trail that made RPA trustworthy survives the upgrade.

Agent-agnostic by design

GOVENANT does not govern “Claude agents” or “OpenAI agents.” It governs the evidence trail of autonomous work. Keep the runner (the tool you audit from) separate from the system under audit (your agents):

What runs the audit

ClaudeChatGPTClaude CodeCursorCodexVS CodeWindsurfCline

An AI client you already use reads the open instrument and drives the read-only sweep. This is the runner — not the thing being judged.

What gets audited — incl. RPA & workflow agents

UiPathAutomation AnywhereTemporaln8nMakeInngestZapier

Any agent system with an observable record of actions and outcomes — whatever built it. The agent never has to "support GOVENANT."

Ground truth: the database + actions + outcomes + duties + gates — the substrate, never the logs’ self-report.

Why govern RPA & workflow agents

You’re closer to conformance than anyone

Execution histories, queues, schedules, exception logs — workflow platforms already keep most of what the standard requires. The integration is a mapping and a handful of gaps, not a rebuild.

Agentic upgrades need governance continuity

As deterministic bots become agentic, the audit trail that made RPA trustworthy must survive the upgrade. GOVENANT is how the governance record carries over when the worker starts thinking.

Exceptions become an honest miss log

Every workflow platform has a failure path; few treat it as a first-class delivery record. The standard does: misses written down, ratios computed, silence made impossible.

Where this bites — a real scenario

An automation CoE runs 1,200 n8n and UiPath workflows — invoicing, onboarding, data sync — increasingly with an LLM step in the middle.

The challenge

Execution logs show jobs “succeeded,” but success means the job ran, not that the downstream effect happened. As bots turn agentic, the audit trail that made RPA trustworthy is quietly eroding — and exceptions are a number the dashboard omits.

What the record reveals

Runs map to duty-runs, schedules to duties, exceptions to an honest miss log. The sweep — read-only over the execution store — finds a nightly sync that “succeeded” for weeks while writing zero rows, and puts the exception rate back on the board where it belongs.

How it works

The substrate: The execution record: runs → duty-runs, schedules → duties, exceptions → an honest miss log. Append-only engines are nearly there already.

The path — Native substrate: The platform already produces records that map to the standard — the sweep reads what it already keeps.

  1. Map the execution history: runs to duty-runs, schedules to duties, exceptions to misses.
  2. Register automation targets as levers with named owners; gate the high-consequence ones.
  3. Key completion to verified outcomes — the downstream effect happened — not “job succeeded.”
  4. Run the sweep read-only over the platform’s own store; review the capability probe for gaps.
  5. Schedule the sweep as a workflow on the platform itself — the system auditing its own substrate.

The full requirements live in the open standard (CC BY 4.0) — the substrate shapes, the acceptance tests, and the conformance ladder your record is measured against.

What you can claim

Platforms with append-only execution history can reach the standard’s Tier-1 substrate requirements faster than any other class — for some engines the ledger requirement is already met. Wear the Built-on badge with a real mapping; publish levels to the registry with probe logs; claim nothing the record can’t reproduce.

Stacks that build RPA & workflow agents

Per-stack integration patterns for common ways to build RPA & workflow agents — each with its own natural hook into the substrate:

Building it a different way? Browse all integrations — or run the free audit from any MCP-capable tool.

Governing RPA & workflow agents — FAQ

Our platform already has audit logs. Isn’t this redundant?
Audit logs record what happened; the standard tests whether what was owed was delivered and verified. The mapping reuses your logs as evidence — then adds the questions logs alone can’t answer: coverage, verified outcomes, and whether silence would be noticed.
Does the sweep touch production workloads?
No. It reads the execution record with read-only credentials, SELECT-only, enforced in code. It never writes, never retries jobs, never touches configuration.
Do my agents have to “support” GOVENANT?
No. GOVENANT governs the substrate — the record of what agents did and whether it verifiably delivered — not the agent. If the system of record around your agents can be read, or you can instrument the action boundary, they can be measured, whatever framework, model, or vendor built them.
What is “performed autonomy”?
Agents that look busy — fluent plans, satisfied logs — but don’t verifiably ship. Motion is not delivery. GOVENANT measures verified outcomes against the record, never the logs’ self-report.
What is GOVENANT, and who controls it?
An open standard for provable AI agent governance: three laws, a conformance ladder, and acceptance tests any implementation runs against its own record. Free to all under CC BY 4.0, with a citable companion paper (DOI 10.5281/zenodo.21440225), conformance self-assessed and published openly — no certifying authority.

More agent classes

All agent types · All integrations · Run the audit