# Dynamic Workflow Contract Template

Use this before letting an AI agent plan, spawn sub-agents, call tools, rewrite its plan, or continue autonomously across multiple steps.

The goal is not to make the workflow rigid. The goal is to let the agent improvise **inside clear boundaries** so a dynamic run can stop, prove what happened, recover safely, and leave trustworthy memory behind.

Site: https://jarvislandingdeploy.vercel.app  
Related post: https://jarvislandingdeploy.vercel.app/blog/dynamic-workflows-kill-switches.html  
Related paid artifact: https://jarvislandingdeploy.vercel.app/products/production-agent-readiness-checklist.html

---

## 1. Workflow Name

**Workflow:**  
**Owner:**  
**Human fallback:**  
**Business system / customer / repo affected:**  
**Date / version:**  

---

## 2. Objective

Write one sentence the agent can optimize for.

> Example: “Research three current vendor options, compare them against our requirements, and draft a recommendation without contacting vendors or changing any accounts.”

**Objective:**


---

## 3. Non-Goals

List what the agent must not optimize for, even if it seems helpful.

- Not allowed to:  
- Not allowed to:  
- Not allowed to:  

Useful categories:

- no spending
- no external messages
- no production writes
- no credential changes
- no destructive file changes
- no durable memory updates without approval
- no claims beyond verified sources

---

## 4. Allowed Tools

| Tool / System | Allowed actions | Read or write? | Limit | Notes |
|---|---|---:|---:|---|
|  |  |  |  |  |
|  |  |  |  |  |
|  |  |  |  |  |

If a tool is not listed here, the agent should treat it as unavailable.

---

## 5. Forbidden Actions

The agent must stop or ask before any of these actions:

- Spending money or consuming paid credits
- Sending DMs, emails, posts, invites, or customer-visible messages
- Deleting or overwriting production data
- Changing permissions, credentials, webhooks, billing, DNS, or deployment settings
- Updating durable memory or source-of-truth records from an unverified assumption
- Continuing after conflicting sources without an owner decision

Add workflow-specific forbidden actions:

- 
- 
- 

---

## 6. Budgets

Dynamic workflows need hard stop conditions.

| Budget | Limit | Stop behavior |
|---|---:|---|
| Time |  |  |
| Tool calls |  |  |
| Retries per failed step |  |  |
| Total retries |  |  |
| Spend | $0 unless explicitly authorized | Stop and ask |
| External actions |  |  |
| Context / files read |  |  |
| Sub-agents spawned |  |  |

Recommended default for a first production run:

- 30–60 minute timebox
- 3 retries per failing step max
- $0 spend
- no external messages
- no production writes
- exception queue when confidence drops below 0.8

---

## 7. Plan Update Rules

The agent may update its plan when:

- a tool fails;
- a source is stale;
- evidence contradicts the original assumption;
- a cheaper/safer path appears;
- the objective cannot be completed as written.

The agent must record every plan change:

| Original step | Why it changed | New step | Risk introduced | Human needed? |
|---|---|---|---|---|
|  |  |  |  |  |

---

## 8. Evidence Requirements

Before acting, the agent must know which facts require live verification.

| Fact needed | Source of truth | Freshness window | Cached context allowed? | Owner if conflict |
|---|---|---:|---|---|
|  |  |  |  |  |
|  |  |  |  |  |

Examples:

- prices → vendor site / billing page, checked today
- customer status → CRM, checked live
- deployment state → CI/CD or Vercel dashboard, checked live
- policy → current policy doc, not memory

---

## 9. Memory Write Policy

Dynamic workflows create memory while acting. Define what can become durable.

| Memory type | Example | Durable? | Approval needed? | Expiry / review |
|---|---|---|---|---|
| Observed fact | “API returned 429 at 20:12 UTC” | Maybe | No | 7 days |
| Verified source-of-truth | “Production URL is X” | Yes | Maybe | Until changed |
| Assumption | “User probably wants Y” | No | Yes | End of run |
| Preference | “Prefer concise summaries” | Maybe | Yes | Review monthly |
| Failure lesson | “This endpoint needs auth refresh” | Yes | No if verified | Review after fix |

Rules:

- Temporary beliefs do not become durable memory.
- Conflicts create an exception, not an overwrite.
- Every durable update records source, timestamp, scope, and reason.
- Memory updates caused by tool failures must include recovery status.

---

## 10. Kill Switches

The workflow must stop when any of these happen:

- Retry budget is exhausted
- Tool output conflicts with source-of-truth data
- The next step would create an external side effect
- The agent needs to spend money
- The agent would overwrite durable memory without a promotion rule
- A source is stale beyond the freshness window
- A sub-agent reports uncertainty or unresolved conflict
- The workflow drifts from the original objective
- The agent cannot produce receipts for prior steps

Workflow-specific kill switches:

- 
- 
- 

---

## 11. Exception Queue Format

When stopped, the agent should not just say “blocked.” It should queue a structured exception.

```text
Exception: [short name]
Workflow:
Step:
What happened:
Evidence checked:
Conflicting / missing information:
Risk if continuing:
Recommended next action:
Human decision needed:
Deadline / SLA:
Safe retry rule:
```

---

## 12. Receipts Required

At completion or stop, the agent must leave receipts.

| Receipt | Required? | Notes |
|---|---|---|
| Final status | Yes | done / partial / blocked / failed |
| Tools called | Yes | include timestamps if available |
| Files or systems changed | Yes | include paths / IDs |
| Sources used | Yes | links, titles, timestamps |
| Assumptions made | Yes | mark unverified assumptions clearly |
| Checks passed | Yes | what was verified before action |
| Checks skipped | Yes | and why |
| Memory writes | Yes | what changed and why |
| Follow-up actions | Yes | owner + deadline |
| Human approvals | If any | include what was approved, not secrets |

---

## 13. Done Criteria

The workflow is done only when all required conditions are true.

- [ ] Objective completed or explicitly marked partial
- [ ] No forbidden action was taken
- [ ] Budgets were respected
- [ ] Receipts were written
- [ ] Sources were verified within freshness windows
- [ ] Memory writes followed policy
- [ ] Exceptions were queued instead of hidden
- [ ] Human approvals were recorded where required
- [ ] Next action is clear

---

## 14. First-Run Review

After the first production run, score the contract.

| Question | Score 0–2 |
|---|---:|
| Did the agent stay inside scope? |  |
| Did it stop at the right time? |  |
| Were receipts enough to reconstruct what happened? |  |
| Were memory updates safe and traceable? |  |
| Could another agent continue from the output? |  |
| Were humans only interrupted for real decisions? |  |

**Score:**

- 10–12: usable contract; tighten edge cases
- 7–9: prototype only; improve budgets/receipts/kill switches
- 0–6: do not automate yet; fix process ownership first

---

## 15. Short Contract Version

For small internal workflows, paste this into the task prompt:

```text
Objective:
Allowed tools:
Forbidden actions:
Budgets:
Sources to verify live:
Memory write policy:
Kill switches:
Exception format:
Done criteria:
Required receipts:
```

If any field is blank, the workflow is not ready for autonomous execution.

---

## When to use the paid checklist

Use the Production Agent Readiness Checklist when this template exposes gaps around permissions, rollback, incidents, observability, or human checkpoints.

Checkout: https://jarvislandingdeploy.vercel.app/api/checkout?product=production-agent-readiness-checklist