Key takeaways
- A useful example names the trigger, systems, owner, finish condition and exception path. A list of departments is not an automation design.
- The strongest first candidates coordinate several people or systems but have a stable normal path: intake, reporting, onboarding and scheduled reviews.
- Keep judgment narrow. Reading a messy request may need a model; checking a threshold, writing a record and calculating a date should stay deterministic.
- The human gate belongs immediately before an irreversible or consequential action, not at the end of every harmless data movement.
- Evidence is part of the workflow. Each example ends with the record a reviewer would need to understand what happened without reconstructing it from chat.
Six examples at a glance
These examples were chosen because they expose different process shapes, not because they promise the largest savings. Google's definition of operational toil emphasises work that is manual, repetitive, automatable and growing with its source. Each example has that shape, but each spends human attention in a different place.
| Example | Stable core | Judgment | Human gate |
|---|---|---|---|
| Request intake | Create, deduplicate and route a case | Classify messy free text | Commit to a customer-facing date |
| Client reporting | Gather, calculate and format | Explain unusual movement | Release the external report |
| Supplier onboarding | Collect documents and create records | Identify an unrecognised document | Approve the supplier |
| Renewal review | Trigger, collect terms and usage | Find material changes | Renew, renegotiate or cancel |
| Failed handoff | Detect, retry and preserve state | Summarise an unfamiliar failure | Choose a corrective action with impact |
| Meeting follow-up | Create tasks and reminders | Separate decisions from discussion | Accept ownership and deadline |
1. A shared request queue that stops living in an inbox
Trigger and inputs. A form or approved inbox receives the requester, subject, free-text need, requested date and attachments. A message ID prevents the same request from creating two cases.
Rules and judgment. Code checks required fields, matches the requester and routes named request types. A model classifies free text only when an exact rule does not apply, and may choose from a fixed list with an “unclear” fallback.
Gate and exception. The system may acknowledge receipt from an approved template. A person approves any reply that promises a completion date. Missing context returns to the requester; unclear classification enters a triage queue.
Evidence. The case retains received time, category source, owner, promised date, status and closure reason. The useful metric pair is elapsed time and correction rate, not messages processed.
2. A recurring client report that fails loudly
Trigger and inputs. A Monday schedule starts the run. It reads an approved client list, reporting period, source dashboards and the prior report. Each source carries a freshness timestamp.
Rules and judgment. Code gathers values, calculates changes and fills the fixed sections. A model drafts a short explanation only for movements outside a stated threshold, using the attached source records. It cannot change a number.
Gate and exception. The account owner reviews the assembled report before release. A stale or missing source stops the run with the missing field named; it never publishes a partial report that merely looks complete.
Evidence. The record stores source timestamps, calculations, drafted commentary, edits, approver and sent message ID. Compare preparation time with post-send correction time.
3. Supplier onboarding with one accountable approval
Trigger and inputs. A budget owner submits the legal name, contact, service, expected spend, start date and internal sponsor. The request creates one supplier case.
Rules and judgment. The flow sends a document-request template, tracks receipt, creates the standard folder and checks the package against the organisation's own list. A model may identify the likely type of an unfamiliar document but cannot mark it accepted.
Gate and exception. The process owner confirms completeness and approves creation in the system of record. Unsupported documents, conflicting names or missing ownership route to a review queue.
Evidence. The run retains the request, document list, timestamps, reviewer, approval reason and created record ID. Jurisdiction-specific due diligence stays outside this example.
4. A renewal review that starts before the notice window closes
Trigger and inputs. The contract record starts a review a fixed number of days before the organisation's internal decision deadline. Inputs include terms, owner, spend, usage, open issues and prior decision.
Rules and judgment. Code calculates dates, checks required sources and formats the brief. A bounded agent may research material changes in approved public sources when the useful pages cannot be named before the run.
Gate and exception. A person chooses renew, renegotiate, reduce or cancel. Missing ownership or contract data escalates immediately rather than waiting for the final reminder.
Evidence. The record links every source, calculation, recommendation, decision and communication. Track decisions completed before the deadline and unused licences discovered, without presenting either as guaranteed savings.
5. A failed system handoff that preserves enough state to recover
Trigger and inputs. A run monitor sees that an expected destination record was not created after a source status changed. The event carries the source ID, intended action, payload hash and prior attempts.
Rules and judgment. Code distinguishes known transient errors from validation errors, retries only the first group and checks again for an existing destination before writing. A model may summarise an unfamiliar error alongside documentation, but cannot choose an unapproved repair.
Gate and exception. Exhausted retries create an owned incident with the live state attached. A person approves any repair that changes source data or could create a duplicate.
Evidence. The run retains attempts, errors, state checks, repair, actor and destination ID. Resolution time is measured from first failure, not from when somebody happened to notice.
6. Meeting follow-up where accepting a task is the handoff
Trigger and inputs. An approved meeting record arrives with agenda, attendees and transcript or notes. The run is limited to the meeting and its named project spaces.
Rules and judgment. A model proposes decisions, action items, owners and dates in a fixed schema. Code validates that proposed owners attended or belong to an approved directory and links each item to supporting text.
Gate and exception. The meeting owner reviews the list. Each proposed owner must accept or correct their item; a task is not handed off because a bot created it in their name. Unclear ownership returns to the meeting owner.
Evidence. The record retains source passage, reviewer edits, owner acceptance, due date and task ID. Measure accepted actions completed, not action items generated.
How to adapt an example without copying its mistakes
- 01Replace every nounHuman approvalName your trigger, records, systems, actors and finish condition. If a generic noun survives, the design is not yet yours.
- 02Bring three normal cases and two exceptionsHuman approvalUse real shapes with sensitive values removed. The exceptions test whether the attractive normal path is actually stable.
- 03Assign each stepCodeMark code, model judgment or human approval. The variance budget keeps the model out of settled rules.
- 04Define exception ownershipHuman approvalMicrosoft's adoption guidance says each task needs one accountable person. Name the individual or rotating role that receives the case, plus a response target.
- 05Write the closure evidenceHuman approvalNIST's AI risk framework emphasises documentation, monitoring and clear human-AI roles across the lifecycle. Decide which fields let the next reviewer reconstruct a run.
Limitations and when not to use this
- Every scenario and figure on this page is simulated. They are design examples, not customer results, benchmarks or claims that all-agents currently supports every named system.
- The examples omit organisation-specific legal, security, financial, employment and regulatory requirements. Add those controls with the relevant practitioner before release.
- A familiar process shape can hide different consequences. Copy the design fields, not the approval boundary; your policy determines which action a person must keep.
- Six examples cannot represent the full operations category. The parent guide provides the readiness score for candidates that do not resemble these.
Sources
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 28 July 2026
- AI Risk Management Framework Core — NIST Accessed 28 July 2026
- Define roles and responsibilities — Microsoft Learn Accessed 28 July 2026
Write one example in your own nouns
Copy the six fields from the closest example, replace every system and actor with yours, and record the first exception the example misses.
Write one example in your own nounsUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.