Six Things That Start a Loop

A standing-order loop starts when the world moves — a clock ticks, a file arrives, a record changes, a person drops an artefact, another system emits an event, or an operator presses run. McKinsey’s 2025 State of AI keeps showing the same gap: most organisations now use AI in at least one function, while far fewer have redesigned how recurring work actually begins. Triggers are that redesign. They are how habit forms: the job starts because a signal fired, not because someone remembered to open a tab.

Before the six doors, three nouns that sound alike and mean different things:

• Loop (this article). A compiled standing order in loop engineering. Something starts it; it runs the same recipe; you read the result on a run page. See a loop is not an agent.
• Eval loop. An independent check that the job is actually done — schema, read-back, a human signer — that does not take the model’s word. See eval loops for enterprise agent harnesses. A standing-order loop may include eval steps; “eval loop” is not a synonym for “automation.”
• Agentic workflow. A sequence of steps a person designed, with stops and approvals, often when the path is known but the inputs are messy. See what is an agentic workflow. Workflows are authored; loops are standing orders you reuse.

If a vendor collapses those three into one slide, ask where the run page lives. Gartner’s Hype Cycle for Artificial Intelligence has spent several years documenting the distance between experimentation and operational habit. Triggers are how that distance closes for work that already has a finish line.

Operators do not care which door opened the loop. They care whether Monday’s close ran, whether nothing changed so nothing was written, and whether Legal can open the run without asking the person who “knows the prompt.” Stanford HAI’s AI Index tracks capability rising faster than operational maturity. Capability without a start condition is a demo. A start condition without a run page is folklore.

All six triggers below should land in the same place — one kernel, one run page — even if a team describes them as “the cron,” “the shared folder,” or “when the CRM sneezes.”

1. Schedule — the calendar as a contract

The oldest trigger is still the right one for rhythm work: weekly pipeline hygiene, monthly accrual prep, quarter-end pack assembly, a Friday exception list that Finance has run by hand for a decade.

A schedule is not “AI that runs sometimes.” It is a contract with the calendar. McKinsey’s survey is useful here because it separates usage from redesign. Scheduled loops are how redesign looks to an operator: the job exists whether or not anyone opened Slack. The recipe does not wait for a hero to remember the steps.

Good schedule design names the skip condition up front. If the source file is empty, the loop should record quiet success — ran, nothing to do — not fail loudly and not invent work to look busy. That distinction separates a standing order from a brittle script that emails the on-call every public holiday. Quiet success is a first-class outcome. Silence without a record is indistinguishable from a missed run.

Finance teams often start here because the calendar already owns the work. Same extract, same variance template, same roster notified when the pack is ready for sign. See loops for finance and planning. The educational question is not “can a model summarise last month?” The question is “does Tuesday’s run exist as an object if the author is on leave?”

Schedule triggers fail when teams treat them as cron plus a prompt. A prompt that is re-derived each Monday is not a recipe. A recipe that cannot skip is not ready for unattended hours. If you cannot point to ten consecutive skipped runs on a quiet week, you do not have a schedule. You have a reminder.

2. File lands in a folder — arrival as an event

Many operational jobs still begin when a file shows up: a bank statement, a carrier invoice, a partner’s CSV, a signed PDF from outside counsel. The operator’s job today is often “notice the file, download it, start the ritual.” A folder trigger is the standing-order version of that notice.

Folder triggers match how people already work. Someone drops a file; the loop picks it up. The operator does not copy paths into a chat box. Dropbox’s enterprise automation guidance treats “file arrived” as a first-class event for a reason — it is how documents still enter companies, even in organisations that have spent years buying “digital transformation.”

The run page should show which file version ran, not only “processed.” If two files land ten minutes apart, you want two runs, not one overwritten thread. That is the difference between collaborative AI on a shared job object and a personal assistant that read the wrong attachment. Lineage is not a nice-to-have. It is how an independent reader answers “which statement produced this pack?”

Folder triggers fail when the watch is pointed at a personal drive, when versions collide without a new run, or when the loop treats “a file appeared” as permission to write to a live system. Arrival is a start condition. It is not a signature. Pair file intake with write-back governance if the next step touches a system of record.

This door is also how partner-heavy work enters legal and compliance. A redline lands; the loop extracts obligations and routes a summary to the roster. See loops for legal and compliance. The artefact is the trigger. The run page is the evidence that the artefact was seen.

3. Data changes — a field crosses a line

Record-driven triggers start the loop when a field crosses a line you defined: opportunity stage, case status, contract effective date, inventory below threshold, a period that just closed.

This is where revenue operations already lives. Salesforce’s process automation documentation has taught a generation that “when field X changes, do Y.” A standing-order loop is the recipe on the other side of that event — not fifteen disconnected flows copied from a sandbox, but one versioned sequence with a run page. The CRM remains the system of record. The loop is the system of work that reacts.

Data-change triggers demand a skip rule. If the field flapped twice in an hour, did you run twice or dedupe intelligently? Operators should see both attempts on the run page, with the second marked skipped because nothing material changed. Without that, you train people to ignore alerts, which is how real exceptions get lost.

See loops for revenue operations for the roster and notification patterns that keep sales from learning about a write from a random direct message. The educational point is ownership: the people who own the stage definition should own the recipe that fires when the stage moves. If RevOps cannot open last Tuesday’s run, the automation belongs to whoever still has the sandbox password.

Data-change triggers fail when every field is treated as equally material, when test records in a shared org fire production recipes, or when the loop writes back into the same object without a quoted payload and a signer. A stage change is a signal. It is not consent.

4. Someone drops a file — urgency without a new ritual

Not every job waits for the calendar or the CRM. Sometimes a controller drops the corrected extract at 4pm and wants the pack before a board call. Sometimes counsel forwards a redline that cannot sit until Monday’s schedule.

Manual drop is a trigger, not an apology for missing automation. It preserves the same recipe and the same run page as the scheduled job — so “emergency rerun” does not become “whoever had the best prompt that afternoon.” The habit to enforce: dropping a file starts a new run. It does not edit the old one. Audit readers care about that distinction even when the operator just wants speed.

This door is how you keep dignity in exception weeks. The recipe does not change because the clock did. The roster does not change because the file arrived late. What is human-in-the-loop AI is relevant here: a person is allowed to start work; a person is not allowed to silently rewrite the definition of work.

Manual drop fails when it becomes a side channel with weaker controls than the scheduled path. If the 4pm run can write without the signer the 6am run requires, you do not have a loop. You have a bypass. The same skip rules, the same quoted writes, and the same notification list should apply. Urgency is a start condition. It is not a policy exception.

Legal and compliance teams use this door constantly because the artefact arrives when the counterparties are ready, not when the calendar is. The loop should still refuse to send anything customer-facing without a designed stop. See what is an agentic workflow when the drop needs a person mid-flight rather than an unattended recipe.

5. Another system pings — react without becoming the stack

Modern stacks emit events: a charge succeeded, a period closed, a ticket reopened, a warehouse scan completed, a partner API posted a payload. An external ping is how loops sit in a stack without becoming the stack. The billing system remains authoritative. The loop reacts with the company’s recipe — notify finance, attach the invoice to the workstream, draft the matching journal for sign, refuse to post if the roster is empty.

IBM’s overview of event-driven architecture is useful vocabulary: something happened elsewhere; your process responds with idempotence and a record. If the same webhook delivers twice, the run page should show one outcome and one duplicate skipped — not two posts. Idempotence is not an implementation detail. It is the difference between a standing order and a double-entry incident.

This trigger is often how loops complement agentic workflows. The workflow handles the messy multi-step case; the loop handles the repeated reaction when the world sends the same signal again. Compare loop vs workflow vs agent. Novelty belongs to the reasoner. Repetition belongs to the standing order.

External pings fail when the loop trusts the event more than the system of record, when retries are not visible, or when a test topic in a lower environment can reach a production recipe. They also fail when “we have a webhook” is treated as governance. A ping is a start condition. The write still needs a quoted payload and a named signer if a live system will change.

6. Run now — the same recipe, on purpose

Run now is the trigger you use in proof of value, in training, and on the day the scheduled job failed because someone forgot daylight saving time. It must produce the same run page as every other door. If “manual” runs hide their outputs in a private chat, you will never pass an audit that asks what happened on March 12.

Run now is also how operators recover with dignity: rerun the recipe, do not re-prompt from memory. How to evaluate loop engineering treats “can I rerun without copying the old Slack channel?” as a buying test for good reason. Recovery that depends on folklore is not recovery. It is a second incident.

This door is easy to underestimate because it looks like a button. The educational content is the sameness. Training environments, dry runs, and production reruns should share a recipe version and a comparable run page. If the training button calls a different prompt than the Monday schedule, you have taught operators a lie.

Run now fails when it is the only trigger a team ever ships. A button that requires a person is not a standing order; it is a nicer checklist. Use it to prove the kernel. Then attach the door the team already watches. Loop engineering vs harness engineering is the sibling distinction: compiling repeat work is not the same craft as wrapping an interactive model.

One kernel, six doors

Conceptually there is one kernel. Triggers are inputs; the recipe is the standing order; the run page is the output contract.

That diagram is intentionally boring. Boring is the point. Operators should not learn six products. They should learn six ways work begins and one place it ends. Thoughtworks’ operating-system framing for enterprise AI is useful here if you keep it modest: isolation, permissions, and durable state belong to the job, not to the chat session that happened to start it.

What good looks like on the run page

A useful run page answers five questions without a tour guide:

1. Which trigger fired? Schedule, file, field, drop, ping, or manual — with timestamps.
2. What recipe version ran? Policies change; Tuesday needs a definition you can still open.
3. Was anything skipped? “No op” is a success if nothing changed. Silence is not.
4. What was produced? Files, drafts, quoted writes waiting on sign — attached to the run, not scattered in email.
5. Who was notified? The roster on the job, not a channel that was copied when someone left the company.

Compare that to a loop is not an agent: an agent reasons when the path is unknown; a loop executes a recipe you already trust. Triggers do not turn a standing order into an improviser. If a trigger fires and the system “figures it out,” you bought a scheduled agent call. That may be useful. It is not a loop.

ISO/IEC 42001 wants named actors and records around AI systems. A run page is how that requirement becomes something a controller can open. “The bot ran” is not a record. “Sarah said it looked fine in Slack” is not a record.

How this differs from “we already automate”

Spreadsheet macros die with the laptop. Loops belong to an organisational recipe library.

Personal automation chains often lack a run page, skip semantics, and a roster. Fine for personal glue; thin for regulated work. The test is whether a second person can reconstruct last month without the author’s inbox.

RPA bots click the UI. Loops prefer APIs and structured payloads when available — and skip when the screen, file, or field did not change. See loop vs RPA for when clicks are still the right tool. Do not pretend a selector farm is a standing-order library.

Chat triggers (“@bot run close”) produce transcripts, not runs. Transcripts are not controls. They are useful for exploration. They are a poor home for month-end.

The pattern underneath all four contrasts is the same: automation that cannot name its start condition, its skip, and its outcome is not operational. It is a convenience that will fail the first time the author is out.

Starting with one trigger

Pick the door your team already watches:

• If close is calendar-driven → schedule
• If partners email files → folder or drop
• If CRM stage drives handoffs → data change
• If billing already emits webhooks → ping
• If you are proving value this week → run now

Wire one recipe. Run it ten times. Require a quiet outcome when inputs are empty. Only then add a second trigger to the same kernel. How to evaluate loop engineering is the RFP version of that week. The four pillars of an enterprise AI platform situates loops beside communication, collaboration, and governance — as a platform pattern, not as a feature list.

Related reading: what is loop engineering, loop vs workflow vs agent, and how to evaluate collaborative AI when the loop feeds a signed pack rather than a silent write.

How this shows up in Nimbus

Nimbus treats the six doors as start conditions on the same Loop object, not as six products. A schedule, a file landing in Conflux, a CRM field change, a manual drop, an inbound event, and Run now all open a run on a workstream. The recipe, skip rules, and governance gates do not change because the door did.

That mapping is an example of the pattern, not a requirement for the pattern. If you are scoring vendors, take the eight tests in how to evaluate loop engineering and run them on any platform that claims standing orders. Nimbus is one place those tests can be exercised; it is not the definition of a trigger.

The useful question for a buyer is still operational: can an independent reader open Tuesday’s run, see which door fired, and see what was skipped — without asking the person who configured it?