How it works

How one workflow gets from every run reviewed to running on its own

Nobody hands the business to AI in one decision. Work moves from human-checked to autonomous one workflow at a time, and each stage is held in place by something specific. This page is the method: where a workflow can be, what holds it there, and the six steps that take it off.

Move from human-checked to autonomous, one workflow at a time.

For what Cogward is and what it provides, see the homepage. For the architecture underneath, see the platform.

The path

Delegation moves in stages, and each one is held by something specific

Nobody goes from a reviewed pilot to an autonomous process in one move. Work climbs, one workflow at a time, and each stage is held in place by a different problem. Here is the whole path, what holds a workflow at each stage, and the step that takes it off.

Every step below moves the same thing: one supervisory context per unit of delegated work, holding its intent, its execution, the identity and delegated authority behind it, the policy decisions that applied to it, what your authoritative systems say happened, and the limits and accumulated exposure that remain. The steps are the order in which an enterprise builds that context up and starts trusting it.

where a workflow can be · what holds it there
  1. Every run reviewed A person behind each run, checking work the agent already did Nothing says which runs need a look Step 1 · Step 2
  2. Sampled or rule-flagged A percentage checked, the rest taken on trust The sample misses what nobody predicted Step 3
  3. Evidence-flagged exceptions People see only the work that cannot close unattended Every exception still costs a person Step 4 · Step 5
  4. Recovered automatically The system reconciles what it safely can; people take the residue Autonomy grows on instinct, not on measured loss Step 6
  5. Autonomy within declared bounds The work runs. You hold the bounds and the evidence behind them  ·  The destination, for the work that has earned it

Most production AI programs are on the first two rows. The six steps below are how a workflow gets to the rest.

Step 1of six

Start with one workflow. Cogward establishes the baseline

Pick one workflow that people currently check. Cogward reads the work that already ran and reports how much of it can be independently established, how much cannot, and what the routine checking costs today. Nothing is enforced and nothing changes in your systems at this stage.

The headline is the unattended completion rate: the share of eligible delegated work reaching its intended completion state without human review. Few teams measure this directly today. It is the baseline every later step is scored against, and it is usually the moment the problem stops being abstract.

Autonomy readiness · refunds · last 30 daysillustrative
delegated work items1,608
result independently established71%
incomplete or contradicted6%
no establishable result23%
reviewer hours spent checking240 / month
largest single causeproduct DB not connected

The 23% is the interesting part. Some of it is missing connectivity, some is work that genuinely cannot be established yet, and knowing which is which is what makes the rest of the path plannable.

Step 2of six

Establish what actually happened, from the systems that hold it

Cogward watches the agent's trajectory to check behaviour against intent while the work is still steerable, and reads the systems that actually hold the result to establish what happened. For state-changing work, authoritative enterprise state is the strongest basis for establishing completion. It uses the connectivity you already have: direct APIs, MCP servers, iPaaS, event streams, warehouses, and your own adapters.

Every work item then carries a result on two axes, because "the work failed" and "the check could not run" are different problems with different owners.

Outcome · what the work did
  1. Confirmed
    Authoritative evidence establishes the intended result
  2. Partial
    Some required state is established and some is not
  3. Contradicted
    Evidence disagrees with the claimed result
  4. Unknown
    The evidence cannot establish what happened either way
Evidence · whether the check could run
  1. Fresh
    The authoritative read succeeded and is current
  2. Window open
    The effect is still propagating and the window has not closed
  3. Stale
    The read succeeded but is too old to establish the result
  4. Unavailable
    Not connected, unreachable, or the entities do not bind

Unknown against unavailable evidence is a binding gap for your platform team to close, and it shrinks as you connect systems. Contradicted is work that genuinely went wrong. Keeping them apart is what makes the residue actionable instead of alarming.

Missing evidence stays unknown instead of becoming false completion. Unknown stays unknown until it is reconciled or escalated, and it blocks anything that would compound it.

Step 3of six

Let the evidence pick the exceptions, and stop checking the rest

This is the step where human review stops scaling with agent volume. The queue a person works is generated by evidence rather than by a sampling rate: they see the work that cannot close unattended, results established as contradicted or partial and outcomes that are genuinely unknown, weighted by what it would cost if it is wrong. Everything the evidence closes, closes unattended.

what reaches a person, and why
Delegated work
evidence state
uncertainty × exposure
Low

Continue

Evidence sufficient, low exposure. The work proceeds without interruption.

Medium

Verify

Reconcile or verify before a sensitive continuation.

High

Hold or escalate

Hold, approve, redirect, or involve a human.

Human review is not failure. It is the correct outcome when uncertainty cannot be resolved at acceptable risk.

Step 4of six

Say what done means, on the work where it pays to

The further a workflow goes, the more precise "done" has to be. That precision is earned rather than demanded up front: you define more only where you want more autonomy, and the agent stays free to choose how the work gets done.

  1. Level 1 · implicitThe objective you already have
    Cogward knows the work, the identity, the authority, the actions, and the external effects. That is enough to produce evidence and an unknown rate. Nothing to author.
  2. Level 2 · partialA few conditions that matter
    "Refund issued and support case closed." Two or three declared conditions are usually enough to generate a real exception queue for a workflow.
  3. Level 3 · formalA completion definition
    Required postconditions, authoritative systems, entity bindings, timing windows, contradiction rules, and when the result is unknown. For work heading toward running on its own.

A completion definition is a short reviewed artifact rather than a modelling project: a handful of conditions, the systems that establish each one, and how entities bind to the work. Your team writes and owns it.

  1. work objectivewhat was accepted
  2. agent executes freelyhow is the agent's choice
  3. evidence from enterprise systemsthe systems that hold the result
  4. is the intended state established?the question done answers
Step 5of six

Move supervision into the execution path

Steps 1 to 4 need no control over how your agents run. Cogward can observe and verify from outside the execution path, because establishing a result means reading the systems that hold it. Holding or redirecting an action is different: for that, Cogward has to be inline. Recovering an ambiguous action safely means being in the path when it is dispatched.

This is the step teams reach for once evidence-flagged exceptions are working and the remaining cost is the person clearing the queue. How far in you go is a choice per workflow, and the far end is a different kind of thing from the rungs before it.

  1. Observe see what happened what the environment emits outside the path
  2. Verify establish the result reads of your systems of record outside the path
  3. Supervise inform what happens next SDK or middleware in your harness beside the path
  4. Enforce make the decision binding inline in the dispatch path in the path
  5. Execute close the supervision loop work runs in Cogward's runtime the path

lightest integration → deepest supervision

You choose the depth per workflow, and you can run different workflows at different depths. Breadth and depth are both the point: supervise the heterogeneous estate you already have, and run the work that warrants it inside Cogward. Capabilities carries the current availability of each.

Inside Cogward's runtime, supervision becomes part of execution: one durable context holds the objective, the authority, every attempted effect, the evidence, and the decision about what may happen next. See the runtime architecture and the closed loop →

Step 6of six

Expand on what you proved, not on how it felt

A workflow that has run supervised for a quarter carries a record: what it did, how often the result could not be established, what the exceptions cost, and which version produced them. That record is what an autonomy decision should be argued from, and it is what makes the second workflow cheaper than the first.

Expansion still moves in bounded steps. Evidence from the envelope a workflow runs in today does not carry automatically to a wider one, so the ceiling moves by rollout and measurement rather than by extrapolation.

  1. Within a workflowWiden the bounds you can defend
    Raise the value ceiling, drop a required approval, or extend to a second region, against measured exposure rather than instinct.
  2. Across workflowsReuse the shape
    Refunds, provisioning, access grants, incident remediation, and invoice reconciliation each have a recognisable completion shape and a usual set of authoritative systems. The second of a kind starts from the first.
  3. Across versionsAttribute outcomes to a release
    Every settled result is bound to the agent version that produced it, so production becomes ground truth for the next release. Rolling back a version does not roll back its effects, and those get settled or compensated.

A production lifecycle for delegated work

The control plane manages the operational definitions around the work: identity, authority, evidence bindings, policies, versions, deployment environments, completion definitions, and supervision history. Agents are still built with the frameworks and models your teams choose.

  • Define
  • Version
  • Deploy
  • Observe
  • Verify
  • Improve

Step one is a workflow, not a program

Bring one workflow people still check by hand. Cogward measures how much of it can be established today, where the evidence is missing, and what the routine checking costs. Everything after that is the path above, taken one stage at a time.

Book a technical briefing