Guide

Process automation architecture: a reference implementation

Reliable automation is an architecture problem: governance + execution + integrations. This blueprint shows the minimum enterprise set—gates, evidence, drift loops, and mission oversight.

No credit card required. Switch to a paid plan any time.

Process automation reference architecture

A practical model: governance plane + execution plane + integration surfaces—measured by proof and variance.

Architecture knobs

Integration surface

Exception rate

18%edge cases

Higher exceptions demand stronger gates + evidence.

Approval strictness

62thresholds + roles

More gates increases proof; too much slows the run.

Readiness

Needs governance

proof & variance

81/100

Variance signal

If variance is high, your automation is fragile. Strengthen gates, evidence, and exception paths before scaling.

Architecture blocks

Policy engine

rules, data classes, tool allowlists

Approval gates

thresholds, roles, dual control

Evidence ledger

records: who/what/when/why

Workflow execution

humans + systems in one run

Integration surface

selected: MCP tools

Command Center

missions, exceptions, oversight

16–22 min read
Advanced

Reference architecture (copyable mental model)

Researched: 2026-03-05

This guide is updated regularly. Sources are listed under “References & evidence.”

A useful enterprise model is three planes:

  1. Governance plane (policy + approvals + evidence)
  2. Execution plane (workflows running across people + systems)
  3. Integration surfaces (API / MCP tools / browser agents / RPA)

Why this matters

Most automation breaks at the boundaries:

  • approvals happen outside the flow
  • evidence is not produced during execution
  • exceptions dominate and drift isn't owned

A reference implementation fixes this by design: gates + artifacts + drift loops are first‑class.

The three planes in detail

1) Governance plane

  • Policy engine: data classes, tool allowlists, least privilege, thresholds
  • Approval matrix: role × threshold × evidence required
  • Evidence ledger: approval_record / exception_record / version_log

2) Execution plane

  • Workflows model decision points and exception paths.
  • HEIDI guides execution (voice + screen context) and captures evidence during the run.
  • Drift signals route remediation to owners with SLAs.

3) Integration surfaces

  • API: reliable, explicit contracts (best when available).
  • MCP: standardized tool surfaces for models (pair with workflow gates).
  • Browser agents: for internal apps without APIs (require tighter guardrails).
  • RPA: task automation; treat as a surface, not the operating model.

Implementation checklist (what to build first)

Start with the minimum that makes automation provable:

  • Define the decision points (what can go wrong, what needs approval).
  • Define the evidence schema (what must be produced to prove outcomes).
  • Build the approval matrix (thresholds + roles + dual control where needed).
  • Add exception paths with owners + SLAs (no “email exceptions”).
  • Add a drift loop: should vs is → remediation → closure evidence.

Scale rule

Only scale automation when evidence completeness and exception aging are stable. If those metrics drift, scaling multiplies risk.

References & evidence

Researched: 2026-03-05

Third‑party product names are used for identification only and may be trademarks of their respective owners.