Open Workflow GraphPre-release
Introduction

Agentic workflows and certainty

What changes when workflows are written by machines rather than people, the four things you must be able to establish about a workflow before running it, and how OWG makes each of them checkable.

View as markdownMachine-readable source for agents and scripted implementers

The workflows running a production have always been written by people — in a scheduling tool, on a whiteboard, or in the head of the coordinator who knows how this show does things. That is changing quickly. A production tracker can already emit its own task list. An agent that knows how to run a step can propose the subgraph for that step. A supervisor can describe an episode's finishing plan in a sentence and get back a hundred tasks wired into a dependency graph.

This page is about what that does to the industry's oldest assumption: that somebody read the plan before the work started.

The bottleneck moves

Authoring a workflow used to be the expensive part. It is about to be the cheap part.

When a machine can emit two hundred workflow documents in an hour, the constraint is no longer writing them. It is establishing that any given one is safe to execute — and prose review does not scale to that volume. A human reading a hundred generated plans reads the first three carefully and skims the rest, which is worse than not reading them, because it produces the appearance of oversight.

So review has to become mechanical. Not "a person looked at it", but: the document was checked against a published schema, its references resolved, its authority chain terminated at a named human, and its ceilings were declared before anything ran. What a person then reviews is the small remainder those checks could not settle.

That is what we mean by workflow certainty, and it is a property of the format rather than of the model that generated the document.

What a prompt cannot do

The natural place to put an agent-written workflow is in prose — a request, a plan, a chat transcript. Prose is a poor container for a plan somebody is accountable for.

Prose planOWG document
Can a machine check it before it runs?NoYes — validation
Can two versions be diffed?Only by readingYes, it is structured data
Can it be scoped for a vendor?NoYes — subgraphs
Can it be replayed exactly?NoYes — definition and run are separate
Does it say who is accountable?SometimesRequired — operated_by
Does it record what happened?NoAutomatically, as structural edges

A generated OWG document is a proposal expressed in a form that can be argued with. That is the whole difference.

The four certainties

Before executing a workflow — whoever or whatever wrote it — four questions have answers, and in OWG each answer is checkable rather than assumed.

1. Structural: will it run at all?

Every document is validated against the published schema before a single task executes. Cycles in the dependency graph, depends_on pointing at a task that does not exist, an asset consumed that was never declared, a when expression that does not parse, a field name that the model invented — all of these are validation failures rather than mid-shoot discoveries.

This is the one certainty that generative authoring makes more necessary rather than less. People mistype field names occasionally. Models produce plausible field names constantly, and a plausible field name is far more dangerous than an obvious typo. additionalProperties: false across every object is what turns an invented field into an error instead of a silently ignored instruction.

One caveat worth stating plainly, because it is the difference between a guarantee and a claim: the four passes are what the specification requires of a conformant validator, and a validator performing only the structural pass will accept documents that cannot execute. Establish which passes yours implements before treating a clean result as certainty. See Validation for the passes and the error codes.

2. Authority: who is accountable for this?

An agent is a participant like any other, and every agent participant carries operated_by — a chain that must terminate at a human or an organization. There is no anonymous actor in an OWG graph and no way to express one.

So "an AI did it" is never a complete answer. The complete answer is this agent, operated by this person, at this company, at this time, and it is a query rather than an investigation. When an agent writes a workflow instead of merely performing a task, the same rule applies to the authorship: the document records what proposed it and who accepted it.

See Participants and authority.

3. Assurance: how much of this is a guess?

A machine-authored workflow is not uniformly confident. Some of it is certain — this file is that file, because the checksums match. Some of it is a matcher's opinion with a score attached.

OWG requires that distinction to be carried in the document rather than flattened away. Every explicit relationship is attested, asserted, or inferred, and an inferred edge must carry both a confidence score and a stable identifier for the method that produced it. An accepted proposal stays inferred and gains accepted_by — it is never promoted, because promoting it would erase the fact that a machine proposed it and a named person agreed.

The practical consequence is an acceptance policy instead of a review queue nobody reads: above your threshold, edges accept automatically; below your floor, never; the band in between is the only thing a human sees. And because method is recorded, a class of matches that later proves unreliable can be selected and re-reviewed as a set.

The failure mode this guards against is specific and worth naming: an agent that rounds its confidence to 1.0. Overstating confidence is the one behaviour that corrupts the graph rather than merely wasting a review.

See Relationships and assurance.

4. Bounds: what can it spend, touch, and re-run?

An autonomous author working at machine speed needs limits expressed in the document rather than in somebody's judgement about how far it is likely to go.

  • governance ceilings cap the run — total cost, total re-routes.
  • max_reroutes bounds any gate that routes backwards, so a self-correcting loop terminates.
  • Permissions attach per object, so an agent handed a subgraph gets that subgraph and nothing adjacent to it.
  • executor.credentials_key names a credential rather than carrying one, so a generated document can never contain a secret it should not have had.

The ceiling is part of the plan, and it is checked before execution rather than enforced by somebody noticing.

What certainty does not mean

It does not mean predicting the output of a generative task. A diffusion model will produce a different image on the second run, and no schema changes that.

Certainty in OWG is about four other things, all of which are knowable in advance:

  • The plan is structurally sound and will not fail on a reference error.
  • The authority is named and terminates at a human.
  • The bounds are declared and enforceable.
  • The record the run will produce is determined by the document, so you know before you start what the audit trail will say.

That last one matters more than it sounds. Structural edges — used, produced, performed_by, ran_on — fall out of executing the work, at no extra cost and requiring nobody's diligence. A workflow that runs has documented itself. High-volume AI work is precisely the case where nobody has time to document anything afterwards.

EU AI Act Article 50 came into force on 2 August 2026. It requires deployers to disclose AI-generated public-interest content and deepfakes.

Disclosure is a lineage question — was a model involved anywhere upstream of this frame — and a pipeline that cannot answer it cannot comply. OWG makes it answerable by requiring ai_role on every task and refusing to infer AI involvement from the executor type: an agent executor may be shuffling files, and a saas_api executor may be running a diffusion model, so only the explicit declaration counts.

The obligation lands hardest on organizations whose agent-authored workflows generate content faster than anyone records what generated it. See AI disclosure and compliance.

The symmetry that makes it work

Nothing on this page is a special path for machine-authored documents. There is no agent mode, no separate schema, no relaxed validation for a trusted model.

An agent writes in the same format a person would use, and the document is checked in exactly the same way. A workflow written by a supervisor gets the same scrutiny as one written by a model, and a workflow written by a model can be edited by a supervisor without conversion, because there is only one representation.

That symmetry is what allows an agent-authored workflow to be trusted at all. Trust does not come from believing the author. It comes from the document being checkable, the authority being named, the confidence being honest, and the bounds being declared — regardless of who or what wrote it.

Next: For agents for the authoring rules and pre-flight checklist, or Core concepts for the model underneath.