The audit log is the input layer

The thesis

Most writing about enterprise AI agent governance treats the control plane as the answer: identity for agents, policy engines, threat response, an enterprise “agent control plane” that sits above whatever the agents actually do. That layer is real and necessary. It is not sufficient.

The reason it is not sufficient on legacy systems is mundane. SAP GUI, Oracle EBS, Jack Henry, Fiserv, FIS, Epic, Cerner, eClinicalWorks, mainframe terminals do not ship the kind of audit logs you need to reconstruct an automated session from the system side. SAP's CDPOS / CDHDR change documents help for some objects and not others. Banking-core green screens are usually mute. So the agent itself becomes the only complete record of what happened in the screen. And the shape of that record is fixed by the agent's input layer, not by the policy engine wrapped around it.

A pixel-matching or screenshot-based agent saw a 1920x1080 image, predicted a coordinate, and dispatched a click. What it can log is that image and that coordinate. A “see and click” LLM agent can log its own prose, but the link from the prose to the actual control is whatever the model chose to say, not a stable identifier. An accessibility-API agent, in contrast, walked a tree of named elements that the OS exposes for screen readers. It always knew the role, the application, the automation_id, the field name, and (for text input) the value before and after. The structured record is a side effect of how the agent had to find the control in the first place.

What lands in the log, exactly

This is the StepResult struct that every Mediar step writes intoworkflow_executions.execution_logs, alongside the columns on the row itself. It is unedited from the executor source on disk.

// crates/executor/src/models/execution.rs (lines 75-95)
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct StepResult {
    pub step_id: String,
    pub tool_name: String,
    pub status: StepStatus,            // Pending | Running | Success | Failed | Skipped | Retrying
    pub result: Option<Value>,
    pub error: Option<String>,
    pub duration_ms: Option<u64>,
    pub retry_count: Option<u32>,
}

// On the workflow_executions row itself:
//   trace_id           OpenTelemetry trace, joins to ClickHouse logs
//   client_id          who called the agent
//   client_ip          where from
//   execution_params   the inputs passed in
//   results            the structured output
//   execution_logs     jsonb step-by-step
//   screenshots        per-step image array
//   error_message      on failure
//   error_category     Infrastructure | WorkflowLogic | Unknown
//   started_at, completed_at, execution_duration_seconds

The recorder side, which captures the workflow once before the agent runs it deterministically forever after, emits one log line per UI event with the element identity attached. The OS gives the recorder the role and application name for free; that is the same API a screen reader uses to read controls aloud.

// apps/desktop/src-tauri/src/workflow_recorder.rs (lines 620-700, abridged)
fn log_event_verbose(event: &TerminatorWorkflowEvent, n: i32) {
    match event {
        TerminatorWorkflowEvent::TextInputCompleted(e) => {
            // "field_name", "field_type", "text_value", "keystroke_count"
            // captured from the OS accessibility tree, not from a screenshot
            info!("TEXT INPUT {}: \"{}\" ({} keystrokes) field=\"{}\" type={}",
                n, e.text_value, e.keystroke_count, e.field_name, e.field_type);
        }
        TerminatorWorkflowEvent::Click(e) => {
            // role(), application_name() - the same identifiers a screen reader uses
            info!("CLICK {}: \"{}\" role={} app={}",
                n, e.element_text, e.metadata.ui_element.role(),
                e.metadata.ui_element.application_name());
        }
        // ...
    }
}

Source files: crates/executor/src/models/execution.rs and apps/desktop/src-tauri/src/workflow_recorder.rs in the Mediar product repo. The recorder uses the Windows UI Automation tree, the same surface area exposed in the open-source Terminator SDK.

Where the audit fields come from

The legacy desktop apps on the left have no API. They expose themselves to screen readers via OS accessibility, and that is the only structured surface there is. Mediar treats that surface as the ground truth for both finding the control and logging what was done to it. The same tree walk that locates a SAP customer field also names it for the audit row.

Failures are attributable, not narrated

Half of governance is “what happened when something went wrong, and was the agent allowed to recover by itself”. Mediar splits failures into three categories at runtime via a static classifier in the executor; only Infrastructure failures auto-retry, WorkflowLogic ones halt and escalate.

// crates/executor/src/config/retry.rs (lines 46-164, abridged)
#[derive(Debug, Clone, PartialEq)]
pub enum ErrorCategory {
    Infrastructure,   // VM down, MCP unreachable, network reset; retry automatically
    WorkflowLogic,    // Validation failed, record not found, permission denied; do NOT retry
    Unknown,          // Ambiguous; surface for human review
}

pub fn classify_error(error_message: &str) -> ErrorCategory {
    let infrastructure_patterns = [
        "connection refused", "connection reset", "503 service",
        "vm is down", "machine not responding", "deadline exceeded",
        // 30+ patterns
    ];
    let workflow_logic_patterns = [
        "validation failed", "invalid input", "missing required",
        "record not found", "permission denied", "unauthorized",
        "step failed", "assertion failed",
        // 18 patterns
    ];
    // ...
}

The implication for a control owner: a “permission denied” or “validation failed” in a legacy app will not get retried into a thousand events that hammer the system. It surfaces, with its category and step, on the workflow_executions row. The retry budget itself (max_infrastructure_retries: 3, exponential backoff starting at 30s, capped at 10 minutes) lives in retry.rs and is part of the workflow definition the auditor reads.

Side by side: the audit log a control owner gets

This is the comparison that matters when you write the controls document. Same workflow on SAP GUI, two different agent architectures, two very different review experiences.

Counterargument: the policy layer still matters

A reasonable objection: agent identity, policy enforcement, and a centralized control plane are real governance work, and a structured per-step log does not by itself give you any of that. That is correct. The argument here is not that Forrester's AEGIS-style frameworks or a Google-Cloud-style agent control plane are wrong. They are necessary. They are also load-bearing on a substrate.

The substrate is the per-action log. A policy engine that says “an agent may write to customer master data only if X” works only when you can later prove the agent did or did not write to customer master data. On a legacy system whose own log is silent, that proof has to come from the agent. If the agent's log is a screenshot and a coordinate, the proof is weak. If it is a step record naming the application, the field, and the value, the proof is the same kind of evidence a system admin would write in a manual process.

So the practical recommendation is to pick the input layer first, then put the policy plane on top. Not the other way around. You can always add an AEGIS-style governance layer on top of an accessibility-tree agent. You cannot retrofit a structured per-step log onto an agent whose input layer never carried element identity.

What a review session actually looks like

For a workflow on SAP B1 or a Jack Henry teller, a Mediar review session is roughly:

1. Read the workflow. It is a TypeScript or YAML file under the deployed_workflows row, usually under 200 lines for one business process. The steps name the windows and fields they touch, in plain language.
2. Pull recent runs. Open the dashboard, filter workflow_executions by workflow_id, look at status counts, error_category breakdown, and the median duration_ms. Anything in Unknown gets read in full.
3. Spot-check a successful run. For one execution, read the StepResult array. Each step has tool_name, the element role, the field name, and the value. Check that the field names line up with the legacy app's data dictionary.
4. Spot-check a failed run. Pull the error_category and the failing StepResult. Confirm the failure was halted (WorkflowLogic) or retried within budget (Infrastructure). For each retry, the retry_count and duration_ms are on the step.
5. Tie back to the system of record. For SAP, the field name and timestamp on the step line up with CDPOS entries on the same record. For Epic, with the audit log entry. The agent log is a superset of what the system itself recorded; the two should agree on what changed.

RPA Center-of-Excellence leads finish first-pass review in a couple of hours per workflow. The bottleneck is auditor familiarity with the legacy app, not log parsing.

Picking the input layer for a legacy environment

A short, blunt guide for picking the agent architecture before you pick the governance framework on top:

• If the workload is a modern SaaS app with a stable DOM and a real audit log, browser or vision agents are fine; the audit trail you keep on top of them is supplementary.
• If the workload is a Windows desktop legacy system with no API (SAP GUI, Oracle EBS, Jack Henry, Fiserv, FIS, Epic, Cerner, eClinicalWorks, mainframe terminal emulators), pick an accessibility-tree agent. The legacy app's own log is too thin to govern from, and the agent's log has to carry the weight.
• If the workload mixes both, treat the legacy hop as the constraint and let the agent there decide the architecture. A browser agent calling out to an accessibility-tree agent for the SAP step is a normal shape.

FAQ