Workflow Runtime Contract: What Must Be Fixed Before AI Employees Run Automatically
A Workflow Runtime Contract is the operating agreement an AI employee needs before it runs automatically. It fixes the trigger, input boundary, Skill chain, artifact, Trust Mode, exception route, and replay key. Many teams still handle repetitive, manual, error-prone work every day, but they move too quickly from a successful Agent demo to a scheduled job. The usual failure is not that the model cannot write. The failure is that one run reads the wrong material, another skips a step, and a later run crosses a confirmation boundary. Axon's workflow-first route exists to make LLM execution controllable before it becomes autonomous.
Anthropic's Building Effective Agents draws a useful line between predefined workflows and more open-ended agents, and it emphasizes feedback, checkpoints, and human input. NIST's AI Risk Management Framework asks organizations to govern, measure, and manage AI systems across their lifecycle. In Axon product terms, the practical layer is the Workflow Runtime Contract.
Automation should not mean "let the Agent improvise." Automation should mean the stable parts are fixed, and the risky parts are explicitly routed to a person.
Seven things the runtime contract fixes
An AI employee should not be launched only because a demo worked once. A runtime contract answers the questions that make scheduled execution safe:
| Contract item | Question | Failure signal |
|---|---|---|
| Trigger | When does it run: manual, scheduled, or event-driven? | Duplicate runs or missed runs |
| Source Data | Which material is in scope? | The Agent guesses the source boundary |
| Skill chain | Which Skills must run, and in what order? | Similar tasks call unrelated capabilities |
| Artifact | What file or record is delivered? | The output is only a chat answer |
| Trust Mode | Which actions require confirmation? | Email, publish, or overwrite happens silently |
| Exception route | Who receives failures, with what evidence? | A failed run can only be retried from scratch |
| Replay key | How do we identify comparable runs? | Two runs cannot be compared |
This extends the idea behind Replayable AI Workflows. Replayability asks what evidence a run leaves behind. A Workflow Runtime Contract asks what the workflow must promise before the run starts.
A minimal runtime contract
runtimeContract:
workflow: "daily supplier quote review"
trigger: "workdays 09:00"
sourceData:
required:
- "supplier quote sheet"
- "customer email thread"
- "margin rule"
skillChain:
- "extract quote terms"
- "compare margin and payment risk"
- "draft negotiation options"
artifact: "quote-review.md"
trustMode:
requireConfirmBefore:
- "send email"
- "publish customer-facing wording"
exceptionRoute:
owner: "sales operations"
include: ["missing source", "failed Skill", "artifact draft"]
replayKey: "customer_id + quote_date"
The point is not to make configuration heavy. The point is to put the business owner, Skill owner, and Agent on the same page. Without that page, "automation" often becomes a model improvising under a calendar trigger.
Why this is not just a settings table
A settings table tells software how to run. A Workflow Runtime Contract tells a team why the workflow is allowed to run. That distinction matters.
Engineering settings are about execution. Runtime contracts are about trust. A business owner rarely cares whether the cron expression is elegant. They care whether the workflow will read the right sources, avoid overwriting files, stop before sending email, and leave enough evidence after failure. The contract makes those concerns visible.
If a workflow already has Workflow Evals and Trust Mode, the runtime contract becomes the final launch check. Evals prove the workflow can complete. Trust Mode defines which actions cannot be released automatically. The runtime contract connects trigger, input, artifact, and exception route.
Three cases that should not run automatically yet
Case one: the input boundary is still unclear.
If the team still debates what material the Agent should read, do not schedule it. Start by fixing Source Data. For traceability, see Source-to-Decision Lineage.
Case two: the artifact has no acceptance rule.
If the result is judged only as "pretty good," automation will amplify subjective review. At minimum, define the artifact name, format, and acceptance rule.
Case three: nobody owns exceptions.
The most dangerous automation failure is not a failed run. It is a failed run with no owner, no evidence, and no continuation path.
A short launch review
Keep the review small:
- The business owner confirms trigger and Source Data.
- The Skill owner confirms Skill chain and artifact.
- The risk owner confirms Trust Mode and exception routing.
- The team runs one dry run and checks whether the replay key locates the run record.
That is not bureaucracy. It is the step that makes "fully automatic" a responsible claim.
Runtime Questions
Q1: Does every Agent need a Workflow Runtime Contract?
No. Ad hoc exploration, one-time research, and private drafts can stay lighter. Scheduled, external, cross-team, or file-overwriting workflows need a contract.
Q2: Does this slow down launch?
It adds one review. It usually saves far more time by preventing source confusion, permission mistakes, and unowned failures.
Q3: How is this different from Workflow Evals?
Evals prove that the workflow can complete. The runtime contract defines the conditions under which it is allowed to run.
Contract one workflow before scaling
For the first Axon automation rollout, choose one frequent, low-risk workflow. Write down trigger, Source Data, Skill chain, artifact, Trust Mode, exception route, and replay key. Then connect the contract to the AI Workflow interface so business users can review it. Start with that runtime boundary, explore run evidence next, and expand only after the first digital employee is stable.