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.