How to Know When an AI Agent Can Work Unsupervised - Evan Kormos, Coinbase

Trust in agent-driven, policy-governed workflows is built by separating stable policy from dynamic running systems, modeling processes as graphs (DAG/DCG), a...

How to Know When an AI Agent Can Work Unsupervised: A Framework for Trust in Agentic Workflows

Abstract

Enterprise adoption of autonomous software agents is constrained less by model capability than by the absence of credible mechanisms for establishing trust in agent-produced work. This synthesis, drawing on Evan Kormos's analysis at Coinbase, argues that trust in agent-driven, policy-governed workflows emerges from three coordinated design commitments: the architectural separation of stable policy from dynamically evolving running systems; the representation of business processes as graphs, specifically Directed Acyclic Graphs (DAGs) at the workflow level and Directed Cyclic Graphs (DCGs) at the node level; and the construction of a statistical confidence layer built from evaluations and runtime traces. The analysis identifies the quality check as the binding constraint on trustworthiness and derives criteria for placing agents within a workflow graph, culminating in a staged automation trajectory moving from supervised to sampled to exception-only human oversight.

1. Introduction

The deployment of software agents into regulated and risk-bearing business processes raises a governance question distinct from the engineering question of agent capability: how does an institution come to trust work it did not directly perform or review? This question grows more urgent as organizations move agents from experimental pilots into workflows carrying financial, legal, and compliance consequences.

The classical enterprise operating model decomposes an organization into people, process, and technology. Agents resist clean placement within this taxonomy because they cut across all three dimensions simultaneously - they collaborate with people, execute process steps, and are built from and consumers of technology. This analysis concentrates on the intersection of agents and process, where three practical questions recur: what work is delegated, what boundaries constrain that work, and how confidence in the result accumulates over time.

The central thesis is that trust is an architectural property rather than a model property. It is produced by separating stable institutional intent from fast-moving implementation, by making process structure explicit and machine-readable, and by replacing deterministic output comparison with statistical evaluation. Section 2 establishes the policy foundation and operating-model context. Section 3 develops the graph-based process model, exception handling, input quality, and the evaluation problem. Section 4 consolidates actionable technical findings. Sections 5 and 6 discuss implications and limitations.

2. Background and Related Work

Policy is defined as the set of rules governing how work is performed, encompassing risk and compliance constraints and expressed in normative must / may / should language. The framing offered is structurally useful: "Think of policy as the original institutional intent or the original system prompt." This analogy carries design weight - a system prompt is stable, declarative, and bounds all downstream behavior; policy occupies the same position relative to an operational workflow. A corollary separation distinguishes build state, the activity of defining or amending policy, from run state, in which the system operates and evolves continuously under product pressure while remaining bound by the slower-moving policy layer.

Graph-based workflow orchestration has established prior art. Apache Airflow exemplifies DAG-based representation of workflows in Python, offering a mature reference for dependency-aware, acyclic execution. LangChain/LangGraph are cited as open-source tooling suited to managing the cyclic, stateful behavior of individual process nodes - a complementary rather than competing abstraction layer.

3. Core Analysis

3.1 Graphs as the Representational Substrate

Workflows frequently require gated, directional progress: approval before a product goes live, verification before an account opens, compliance review before a token lists. These dependencies map naturally onto a DAG, where nodes represent steps and edges represent dependencies without loops. Agents introduce a new capability here - previously, parallel coordination of independent reviews (e.g., simultaneous KYC and financial verification in commercial lending) was too costly or operationally complex to sustain; agents make such parallelism tractable at scale.

Critically, individual nodes within the DAG are not simple pass/fail gates. A code review step, for example, functions as an internal loop in which work iterates against feedback until judged "good enough" to proceed - structurally a DCG. The outer flow therefore maintains the policy boundary deterministically, while the inner flow permits adaptive collaboration between people and agents. This is captured directly: "The recipe really is to keep it deterministic on the outside and make it adaptive on the inside." This nested graph structure - DAG containing DCGs - is the paper's core representational contribution.

3.2 Exception Handling and Volume Dynamics

A workflow's resilience depends on handling exceptions - canceled code, security-standard failures - without either stalling the pipeline or over-engineering for every conceivable edge case. A second-order effect follows from agent adoption: adding agents shifts volume across the flow. If upstream steps accelerate via agent automation, downstream steps (e.g., security scans) must correspondingly accelerate or become bottlenecks. Consequently, operational visibility into process metrics becomes more consequential than the workflow authoring tool itself; organizations need the ability to visualize throughput and add parallel capacity while preserving controls.

3.3 Input Quality and Contextual Grounding

The analysis posits that higher-quality inputs yield better outputs at lower compute cost. Quality inputs are tied directly to establishing trusted context for agents - specifically, injecting DAG state into an agent so it understands its position within the larger process. Over long time horizons, this context-efficiency becomes a cost and reliability lever rather than a cosmetic concern.

3.4 The Check as the Binding Constraint

The mechanism determining whether work is "good enough" to advance - termed the check - is identified as the hardest and most consequential design element: "The loop is really only as trustworthy as the check itself." Because agents are probabilistic, identical requests can yield different outputs that are nonetheless all acceptable, rendering exact output comparison inadequate. Trustworthy evaluation instead requires representative datasets assessed through repeated statistical series rather than single-instance comparison. Combined with traces (runtime logs), this evaluation apparatus forms a confidence mechanism explicitly analogous to unit tests in traditional software engineering - a structural translation of software verification practice into probabilistic systems.

4. Technical Insights

Several implementation-relevant findings emerge. First, DAG representation (e.g., via Apache Airflow) suits the outer, policy-bound workflow layer, while DCG-oriented tools like LangGraph suit inner, iterative node behavior - implying a two-tool architecture rather than a single orchestration layer. Second, confidence mechanisms must be built from representative datasets evaluated statistically across repeated runs, not single-output diffs; this is a direct consequence of agent non-determinism and has direct implications for eval infrastructure investment. Third, placement of agents within a graph should be decided against four criteria: whether work can be checked against policy, whether it can run in a bounded loop, whether it can be traced, and whether a human fallback exists. Fourth, decision nodes - checks against policy - are likely to remain human-driven longer than execution nodes, since the former embodies institutional judgment rather than procedural execution. A trade-off surfaces here: agent-driven parallelism increases throughput but requires commensurate scaling of downstream verification capacity, meaning naive automation can create new bottlenecks rather than eliminating them.

5. Discussion

The framework reframes a common industry question. As stated directly: "What we're really talking about is not whether or not AI is involved, but whether or not AI we expect to take over at some point." This reframing shifts the governance conversation from a binary adoption decision toward a staged confidence-building trajectory - supervised review, sampled review via traces, and finally exception-only oversight - mirroring how statistical process control matured in manufacturing and software testing.

A notable gap concerns the generalizability of the "check" across domains with differing tolerance for ambiguity; regulated financial workflows (KYC, lending) may admit clearer statistical thresholds than creative or open-ended tasks. Future work might examine how the hill-climbing progression generalizes outside compliance-heavy contexts, and how trace-based confidence scores might be standardized across organizations analogous to test-coverage metrics in software engineering.

6. Conclusion

This synthesis contributes a structural account of trust in agentic workflows: policy as stable system prompt, nested DAG/DCG graph representation, and statistical evaluation via traces as the confidence layer. The practical takeaway is that organizations should invest in explicit process graphs and eval infrastructure before scaling agent deployment, since the check - not the model - is the binding constraint on safe automation. Applying the supervised-sampling-exception progression offers a concrete, measurable path toward unsupervised agent operation.

Sources

• How to Know When an AI Agent Can Work Unsupervised - Evan Kormos, Coinbase - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub